Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Cvp Nic Unplugging problem

Hi

   I am presently facing a problem with a NRFU Test case in which when the nic of CVP(Active lic server) is unplugged the new calls placed are not failing over to the CVP (Redundant port server).We are running on a comprehensive setup with multi site env.The same cases with services got down(Call and Vxml) on active server the failover is happening fine.Some other scenarious like shutting the active dial-peer and checking if calls are serviced at 2nd CVP too works fine.

The ICM is on 7.5(7),CVP on 7.0(2) with ES of CVP7.0.2_ES22,CVP7.0.2_ES27 and CVP7.0.2_ES29 upgraded,CVP  OPS Console 7.0(2) and gateway is IOS c3845-ipvoicek9-mz.124-24.T3.Can't really find a reason on this not functioning.I do see the Label of 7777777777 + corelation id reaching my gateways when the nic is got down and new call is placed.However the VXML Session just does not seem to get invoked after that and it only tries to GET the active server on http request.

A tac case is open for this but it is taking a bit long.Can anybody suggest if any idea?

Thanks

Ganesh

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Cvp Nic Unplugging problem

hi

Can you tell us , is it a SIP based deployment or H323 based Deployment . one thing is clear you are not using CSS ,

As you can see TransferLabel+ correlation ID it means failingover is not working when customer is listening a prompt .

Can you Please check have u define IP host media-server & IP host media-server-backup and in ICM script instead of using IP address of media server  use media-server , if gateway is unable to reach first media server it will append -backup and check second media server.

24 REPLIES

Re: Cvp Nic Unplugging problem

hi

Can you tell us , is it a SIP based deployment or H323 based Deployment . one thing is clear you are not using CSS ,

As you can see TransferLabel+ correlation ID it means failingover is not working when customer is listening a prompt .

Can you Please check have u define IP host media-server & IP host media-server-backup and in ICM script instead of using IP address of media server  use media-server , if gateway is unable to reach first media server it will append -backup and check second media server.

New Member

Re: Cvp Nic Unplugging problem

Hi

      To answer your questions

  1. It is a Sip based deployment.
  2. No we are not having CSS for the site.
  3. Yes the commands which you have mentioned of mediaserver and backup hostname is configured in the gateways.The configs are similar to some of our deployments earlier from gateway perspective.We also have the icm script configured as mediaserver.

Thanks

Ganesh R

Green

Re: Cvp Nic Unplugging problem

Just so I can understand more of the picture.

1. Do you have a SIP Proxy (CUPS)? I will assume you have a pair of CUPS.

2. Make sure you are using UDP throughout.

3. Turn the retry counts down on the gateway and the proxy. You want the system to respond quickly, not retry the default number of tries - which is 6.

4. From the gateway's perspective, when a call comes in and needs to find a proxy, how do you do that? With first and second preference dial peers?

5. When the proxy is asked to find a CVP, are the static routes equal weights?

6. When the VRU transfer label wants to find it's way back to the ingress gateway, do you use send to originator? Are your gateways combined ingress/VXML gateways?

Things are a bit strange here. You say that you see the transfer label come back to the gateway with the NIC unplugged - but what happens then? The bootstrap will direct the call back to the Call Server that sent it - it knows where it came from. Are you overriding this with an isn-vxml setting in your ip host table on the gateway - that ws required with CVP3?

Run debug vxml application on the gateway and look at where the bootstrap is trying to send the VXML query to - it should be the CVP that is not unplugged.

Regards,

Geoff

New Member

Re: Cvp Nic Unplugging problem

Hi Geoff

            Thanks.Pls find my answers below.

1 No we do not have any CUPS in our setup

2 Where do i configure this value and what will be the command.

3 Retries is on 2

4 My dial peers are pointing to call servers directly.Pref 1 to server at site 1 and pref 2 to site 2

5 No proxy.

6 We are using a DNS SRV Lookup from the CVP.The labels are using local static routes to reach their destination i.e either GW or UCM.

I have the commands below in my gw to find the servers.When i unplug the nic of server 1(10.8.127.113) on running the debug i do  not see the http request trying to get vxmlserver-backup.The gateway tries the call server 2 (10.14.102.185) and gets the Label+Cor Id from the CVP 2.It also triggers the Bootstrap dial-peer but then no http request.From user expirience i can see the caller hearing nothing and call droping eventually.

ip host vxmlserver 10.8.127.113
ip host vxmlserver-backup 10.14.102.185


I have attached the vxml logs taken and the sh run running on the gateway.

Green

Re: Cvp Nic Unplugging problem

UDP is on the Call Server config in OPS Console.

I asked if this is a branch office design.

Are you using combined ingress and VXML gateways or are they split? If this is a combined gateway you should use "Send To Originator" to send the VRU label back to the requesting gateway. You would need static routes to send the transfer label to CUCM for warm transfer and to find the gateways in such calls, but this can coexist with "send To originator" to get the transfer label back to the ingress gateway.

What are you looking up in the SRV? Normally the SRV is used to find a CUPS. But you don't have one.

The setting for "ip host vxmlserver" is for Audium apps to find the CVP VXML server - not for the bootstrap.

Regards,

Geoff

Green

Re: Cvp Nic Unplugging problem

I looked at the Gateway config. Please post an screenshot of the CVP Ops Console SIP page. I can't be sure without seeing the SIP page, but regarding the gateway config:

1. In the ip host section you don't have configuration for media or media-backup. How do you find the WAV files?

If you are using microapps for simple prompts and, of course, for queuing, you need a symbolic name here to fetch the WAV files and you set the ECC variable user.microapp.media_server to use this symbolic name. You do have a spec for vxmlserver, which I assume is the Audium server.

Strange.

2. Why do you have three name servers listed. The normal config for CVP gateways is "no ip domain lookup".  You should not be hitting the name servers.

3. You have defined a voice translation-rule for 987654 and a profile called "block", and you have used it on 3 voip dial peers. I like to see it on all voip dial peers.

4. Along with the above rule, you must have a dial peer to catch it:

dial-peer voice 900987654 voip
description CVP: needed for Play Media micro-app
translation-profile incoming BLOCK
incoming called-number 987654

5. The SIP ringtone and error dial peers use 9191 and 9292. The normal default is 91919191 and 92929292 - I assume your Ops Console settings have been changed to match. If not, you should have the full pattern here. Show me the screenshot to confirm.

6. You have no cvp-survivability service call on the incoming pots dial peer. All PSTN calls should go through this - something like:

dial-peer voice 1 pots
description CVP Call Survivability
service cvp-survivability
trunkgroup INCOMING
incoming called-number .T
forward-digits all

7. I like to turn all the SIP retries way down, but we have a very solid network.

sip-ua
retry invite 1
retry response 1
retry bye 1
retry cancel 1
timers expires 60000

Regards,

Geoff

Green

Re: Cvp Nic Unplugging problem

Now I looked at your debug trace from the gateway, and things are a little clearer. You should post your ICM script.

1. This test case is an Audium test case. The incoming call in ICM runs a GS,Server,V microapp and wants to invoke the application "HelloWorld". You should have told us this. This looks like a new deployment - but you implied you already had this working at other gateways. Confusing.

2. When the path through the ICM routing script encounters a Run Ext Script node, it does an implicit "Send to VRU".

This is not the way to handle this correctly, in my opinion. You should be absolutely explicit and insert a "Send To VRU" node yourself.

This should be the first node - and I mean the first node. Don't have any set nodes for the ECC variables - they come after. Failure of the S2VRU node should return an "End" - this will make survivability on the gateway handle the call correctly. Of course, you have to add this service on your pots dial peer, but I mentioned that. Then set your variables and add your GS,Server,V node.

3. Now that you have decoupled the Send to VRU from your Run Ext Script, failures in the bootstrap will be more clearly seen.

The call comes into the gateway and is sent to CVP, which establishes the switch leg and starts the routing script. At the S2VRU node, the CallRouter pauses the script, returns the VRU label + correlation ID to CVP. CVP uses Send To Originator (or some static routing) to send the call to the VXML gateway. The call enters the voip dialpeer (in your case on 7777T) and starts the bootstrap service.

Don't confuse this with "HelloWorld".

Now the http new call request for cvp/VBServlet occurs and a request for instruction is sent up through the PG to the CallRouter, which finds the paused script and continues with it.

You should have a simple Play Media microapp script and test this first. Find out how it behaves with NICs being unplugged and so on.

Introduce the HelloWorld application later.

Regards,

Geoff

New Member

Re: Cvp Nic Unplugging problem

Hi Geoff

           Thanks for your information and configs posted.Pls find the attached script running with the ops console configs.I have the present script on Customer application with same results.

  1. Yes the VXML and Ingress are co resident and there are 2 such gateways at same site.
  2. We are using DNS Srv lookup to point to Call Managers to Gateways with priority.
  3. Yes we have tested all scenarios with Application and nothing with Micro Apps.Hello world,Custom application was used as a part of testing.
  4. True it is a new setup and the site has yet not gone live.
  5. The reason for the Survivability not yet added is the port on which we are going to terminate the links is not yet decided and we will configure it soon.
  6. For the ip name server the customer is using it for some other purpose nothing related to IPCC Setup.
  7. Sure i will have the configuration which you have posted done and test it again.Good idea to test it with Micro app script too and i will test it to see if things are fine.I will post the updates.

    Thanks

    Ganesh R

New Member

Re: Cvp Nic Unplugging problem

Hi Geoff

           I had it tested with Micro apps and it works fine.There is a delay of about 14 sec for the prompt to cache from CVP2 but works fine without a problem.

Green

Re: Cvp Nic Unplugging problem

OK, thanks for the pictures of the Ops Console.

1. Use Send to Originator

Now that you have stated that this is a branch office deployment with combined ingress/VXML gateways, I reiterate that you should be using Send To Originator for PSTN calls. You should have three patterns in the Send To Originator section. You have none. The three patterns required are:

1. 7777777777

2. 91919191

3. 92929292

These take precedence. When the Call Server gets any of these labels, it automatically sends the call back to the originating gateway. That's exactly what you want to happen. If you don't have this, your configuration is incorrect. Why?

Because, the way you have it, a call can come in on one gateway and run the VXML leg on the other gateway. It can do this because it sees the 7777> label in the static route table attached to a cluster name, does a local SRV lookup and goes to one of the gateways listed in the SRV file. This is wrong.

Let's assume that you SRV file looks like this:







A call arrives on 10.10.100.2. The VRU transfer label 7777777777 is returned and CVP sees a match in the static route table, sees a cluster name, sees that local SRV is checked so uses the file. It round robins between the two 10.10.100.2 and 10.10.100.3, so 50% of the time the VXML leg runs on the wrong gateway.

You also do the same with the ringtone and the error - ingress on one gateway, VXML on the other, ringtone on either. All messed up.

2. As I said, the ringtone and error dial peers must match exactly what you have in the Ops Console. You have the defaults, but your dial peer is looking for 9191 and not 91919191. I bet you have never heard ringback in the PSTN phone when the call is extended to an agent!!

3. Why do you have 7777777777 added as a DNIS on the ICM page of the Ops Console? You simply don't need this. You have the max length configured as 10, so when CVP gets any number longer than 10 (as it will get when the transfer label + corr ID comes back from the gateway) it considers that this is a request for instruction, pulls off the corr id and sends this up to the CallRouter to find the paused script.

4. Why are you using SRV records at all? I see 179> there and assume that your agent extensions are 179xx or something (not a good choice to start agent extensions with a 1, but let that go).

If your two primary agent subscribers are (say) 10.10.100.4 and 10.10.200.4, then just two static routes

179>,10.10.100.4

179>,10.10.200.4

The SIP agent in CVP will round robin the INVITES between these two IP addresses - just like a SIP proxy would.

5. We haven't talked about warm transfers. Send To Originator will handle all the PSTN calls, but for warm transfers you do need a way to find a gateway so you will require a static route for 7777> to queue the call during warm transfers. I would make this just go to one gateway so you know where all warm transfers are being queued. Easier to debug and the load probably does not warrant routes to both gateways. If you want the warm transfer queued on the ingress gateway for a complex branch office deployment, you have to go to SIP.sigdigits and that's another ballgame entirely. You would also need a static route for the ringtone label.

In summary, you are missing out on the power of Send To Originator, are using SRV when you don't need to, and have a few inconsistencies.

Regards,

Geoff

Green

Re: Cvp Nic Unplugging problem

I imported the script EA_Sample_Script_137.ICMS into my Script Editor (of course I can't save it because of the unresolved references) and I have to say that this is the most convoluted CVP script I have ever seen.

This can't be what you are using for testing. It won't even compile as there are so many disconnected elements. There are no comments in this script, and it's a maintenance nightmare. I can see from the way you are using EWT, before() and after() that you know a bit about ICM scripting, but oh my God, this one is a total mess.

Aside from that:

1. You are confusing what you need to pass to a VXML app as the callid for reporting to work - concatenate("callid=",user.microapp.media_id) - with passing information to cross-correlate activity logs with TCD, RCD records - concatenate("ICMInfoKeys=",Call.RouterCallKey,"-",Call.RouterCallKeyDay,"-",Call.RouterCallKeySequenceNumber). Don't call the second one "callid"!!

2. I can't see how you are queuing calls. The check mark out of a Queue to Skill group node normally leads to a couple of PM microapps in a loop (music, all agents are busy etc) but yours lead to another Audium app. How on earth does this work?

Regards,

Geoff

Green

Re: Cvp Nic Unplugging problem

OK, one final comment.

I can see from the VXML trace

MSG_TYPE=CALL_NEW&CALL_DNIS=777777777710339&CALL_UUI=&CALL_ANI=sip:17912@10.14.102.185:5060

that you are calling to test your application from an IP phone (we know that your agent extensions are 179xxxxxxx from the OpsConsole picture, and now we can conclude that the range is 179xx - I already said that I don't like agent extensions starting with 1).

You need to be making these test calls from the PSTN. Is the PSTN set up?

But since you are making CVP run from inside on CUCM, you must have this configured in the typical way:

1. A label on the NVRU for the CUCM Routing Client (say 8222222222)

2. A Route Pattern in CUCM for 8222222222 that ends up going down a SIP trunk to both your CVPs (in a Route Group)

3. The static route on 777777777 to find a gateway to run the VXML. Send to Originator only operates when the call originates from the SIP User Agent on an IOS gateway, so you definitely need this in the static route section.

When you do this, you need two Send To VRUs - the first one for the 8222222222 and the second one for the 7777777777. Many don't put the second one in but rely on and implicit "send to VRU" from a Run Ext Script or a Queue to SG.

I still don't see why you have SRV lookup.

Regards,

Geoff

New Member

Re: Cvp Nic Unplugging problem

Hi Geoff

            Thanks.Here is an interesting piece of information.The configs are changed now as per the config in the url topic Co-Resident Call Server, Media Server, and Unified CVP VXML Server in the config guide as my VXML,Call Server and Media are co resident on a single server.

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/srnd/7x/cvp_mdia.html

Now i have things working fine for the VXML Application too.I have shared the out put of show http client history below


IPCC-FL-N4-3845-1#sh http client history

  GET http://10.14.102.185:8000/cvp/VBServlet?MSG_TYPE=CALL_RESULT&CALL_ID=776A67EB546F11DF83ABECDC2C40489
  GET http://10.14.102.185:8000/cvp/VBServlet?MSG_TYPE=CALL_RESULT&CALL_ID=776A67EB546F11DF83ABECDC2C40489
  GET http://10.14.102.185:8000/cvp/VBServlet?MSG_TYPE=PING&CALL_DNIS=777777777710359&CALL_ANI=sip:17912@1
  GET http://10.14.102.185:8000/cvp/VBServlet?MSG_TYPE=CALL_NEW&CALL_DNIS=777777777710359&CALL_UUI=&CALL_A
  GET http://VIR.CVP.RC:7000/CVP/Server?DNIS=6000&ANI=17912&CallId=134-149504-0&application=HelloWorld
  GET http://VIR.CVP.RC:7000/CVP/Server?audium_root=true&calling_into=HelloWorld
  POST http://VIR.CVP.RC:7000/CVP/Server
  GET http://VIR.CVP.RC:7000/CVP/audio/helloworld_audio.wav
  POST http://VIR.CVP.RC:7000/CVP/Server
  POST http://VIR.CVP.RC:7000/CVP/Server
  GET http://10.14.102.185:8000/cvp/VBServlet?MSG_TYPE=CALL_RESULT&CALL_ID=AD0F809F547011DF83B9ECDC2C40489

Now as the guide i changed the media server ECC Var node in the script to concatenate("http://",Call.RoutingClient,":7000/CVP"), It is now taking the Rounting client values in the url.I have the host file enteries in my gateway to the respective ip address mentioned below and it just seems to work fine when i unplugg the nic of CVP on Server A.

ip host VIR.CVP.RC 10.14.102.185
ip host FLO.CVP.RC 10.8.127.113

I am still cofused on why in the earlier case with http://vxmlserver:7000/CVP in my scripts it did not failover properly.

Green

Re: Cvp Nic Unplugging problem

I am aware of the Cisco advice on a coresident VXML server in the absence of a CSS.

It is a reasonable solution that deals with one type of failure - when the Call Server box is down, or the network disconnected to that box, using the ICM variable RoutingClient to find your VXML server ensures that the Audium application runs on the same box as the Call Server.

If your IIS is also on this server, you can pass the RoutingClient into your Audium application and switch on the value to set the path to your WAV files, again ensuring that the WAV files are fetched from the same box. Once again, you are dealing nicely with the whole box being down or the network disconnected.

Obviously this does not work in a larger installation with a number of Call Servers, not all of which are VXML servers, and it will not load balance like a CSS, and it cannot deal with the Call Server being up and the VXML Server down, or the Call Server and VXML Server being up and IIS is down - but it has merit and you should use it in your case.

Let's discuss some of my points - regarding Send To Originator and your use of SRV. You are missing the big picture.

Regards,

Geoff

New Member

Re: Cvp Nic Unplugging problem

Hi Geoff

             Thanks for your inputs on the script front.I do agree with you that the script is a mess and does look bit convoluted without the detailing not gone into it and too many unrequired nodes.However this is just a test script,we have parallely build the production script which looks much clinical with detailing in it.It does have the wrong part of the nodes treated properly as required.The site still is not live and going through a pre production test phase.For other points.

  1. I am still not clear cause this is how we send the value to the application,developed and deployed by aa diffrent team and they use that for their reference.Can this be changed to fine tune it?
  2. We are using the application itself to play the ewt and not use microapps there.We are calculating the EWT using the formula,set few values which the application needs to maintain the call details during the transfer to CVP.This has been tested and works fine.
  3. phone numbers starting with 1 i do agree it is not what you would like but here we are using customer's existing call manager which is used for IPT having too many dial-plans .I am sure they would have decided to go with this dial-plan for IPCC keeping their existing dial-plan in mind.

Thanks and Regards

Ganesh R

New Member

Re: Cvp Nic Unplugging problem

Looking into your architecture which has branched locations with co located Ingress and VXML gateways it would have been a better idea to have used Sip.Sig digits where in you can have the VXML diaglouges played local to the site as where the call had originally originated.

Using the Send to call originator function would also be a better idea, but all these holds good only until you have the VXML being played out.

Once the call needs to be transffered to an agent you might have to make use of DNS SRV records to load balance between the Different CUCM which does the call processing.

The reason being i dont think  using two or more static route for different call processing CUCM would really work coz CVP sip agent doesnt have the capability to send a SIP re- invite to make use of the second Static route in case the first one has failed.

The local DNS-SRV really solves the issues related to the CUCM.

Now coming to the Warm transfers scenarios:-

you cannot use the send to the call originator function in this scenario because the the call is ideally originated fromthe CUCM and the the 77777! label used for queuing purpose would be send back from the CVP to the CUCM, which CUCM does not know wat it needs to be done with it.

So in case of the Warm transfers i again reiterate the fact that SIP.sig didgits should have been used to maintian Queue or transfer back to IVR local to the site as the where the called had originated.

Using a static route for the Warm transfers and maintaining it to only one gateway your redudancy may not achieved. Again i doubt whether the re-invires are sent and the other static routes if made use of.

if i was in your place and in an architecture with branched loactions and no Sip proxy server  i would have made use of SIP.sig digits and local DNS SRV  records. The local DNS SRV functionality does the work of the proxy servers in deployments where no proxies are used. Based on the weights and the priorities defined on the XML file it load balances and the does the failover as expected to be done by the proxy server.

i would rather suggest you to re visit the design of this and make use of SIP.sig digits in combination with local DNS SRV records.

Also regarding your the initial problem of the  CVP NIC Server failling i am not sure really as why the VXML gateway doesnt sense that the VXML server is down and it needs to try for the back up.

Could you check whether the you had set the http client connection timeout 10 and http client response timeout to 30?

Anyways the approach you had taken for by making use of the Routing Cleint ID is a better one for your architecture and you might have to only think that this kind of approach could be a disaster when complex VXML application are made use of where there is a possiblity of the java threads going  up and vxml server going into a hang state.

Cheers

Green

Re: Cvp Nic Unplugging problem

hari.kanan wrote:

Looking into your architecture which has branched locations with co located Ingress and VXML gateways it would have been a better idea to have used Sip.Sig digits where in you can have the VXML diaglouges played local to the site as where the call had originally originated.

Using the Send to call originator function would also be a better idea, but all these holds good only until you have the VXML being played out.

There is no need for SIP.sigdigits in a branch office design. Send To Originator deals with this perfectly. It ensures that the VRU leg runs on the ingress gateway. I don't know what you mean by "all these holds good until you have the VXML being played out".

Once the call needs to be transffered to an agent you might have to make use of DNS SRV records to load balance between the Different CUCM which does the call processing.

The reason being i dont think  using two or more static route for different call processing CUCM would really work coz CVP sip agent doesnt have the capability to send a SIP re- invite to make use of the second Static route in case the first one has failed.

The local DNS-SRV really solves the issues related to the CUCM.

I want to be sure that you know this for a fact. Have you indeed confirmed this?

You say that the CVP SIP Back-To-Back User Agent does not have the capability to retry an INVITE if the first one fails. If this is the case, using SRV will not work either. It does not matter if there are two static routes, one to each Sub - or there is a single route on the cluster name being resolved by entries in a DNS SRV or local SRV - if the B2BUA cannot retry on failed INVITE, nothing will work.

I personally think a production SIP CVP without a Proxy is not a viable design.

you cannot use the send to the call originator function in this scenario because the the call is ideally originated fromthe CUCM and the the 77777! label used for queuing purpose would be send back from the CVP to the CUCM, which CUCM does not know wat it needs to be done with it.

You don't know that at all.

The OP has not told us what the VRU label on the CUCM routing client is. Normally it is not the same as the label on the CVP RC. Whatever this label is, it's not sent by CVP - it's returned to the CUCM through the PG.

CUCM MUST know what to do with it - typically it's a Route Pattern that finds a CVP. Then CVP needs to find a gateway - and you are correct that it cannot use "Send To Originator" - so there must be a static route to find a gateway using 7777777777.

So - you simply need to configure both items. You add the 777777777> to the Send to Originator and you also add a pair to the Static Route section for the gateways in Warm Transfer. CVP will optimize.

So in case of the Warm transfers i again reiterate the fact that SIP.sig didgits should have been used to maintian Queue or transfer back to IVR local to the site as the where the called had originated.

OK, this part is true - although the design is complex. In a branch-office design, with a number of branches, SIP.sigdigits is the only way to ensure that the gateway found by CVP to queue the call in a warm transfer (or any CUCM-originated call) ia at the branch. The OP has not told us whether there will be multiple branches - he does not have them at the moment.

Adding SIP.sigdigits adds a layer of complexity that takes a while to work through. If you have the bandwidth between sites you can simplify a multi-branch design by choosing one gateway (or one pair of gateways) to queue the call for CUCM-generated calls.

Using a static route for the Warm transfers and maintaining it to only one gateway your redudancy may not achieved. Again i doubt whether the re-invires are sent and the other static routes if made use of.

if i was in your place and in an architecture with branched loactions and no Sip proxy server  i would have made use of SIP.sig digits and local DNS SRV  records. The local DNS SRV functionality does the work of the proxy servers in deployments where no proxies are used. Based on the weights and the priorities defined on the XML file it load balances and the does the failover as expected to be done by the proxy server.

i would rather suggest you to re visit the design of this and make use of SIP.sig digits in combination with local DNS SRV records.

You would not have a static route to one gateway - you would put both there. Once again, you say you "doubt whether the re-invites are sent and other static routes if (sic) made use of" but you provide no proof. Cisco certainly don't say this limitation exists.

As I said before, if the B2BUA cannot retry, it makes no difference if you use a pair of static routes, or a single static route with a cluster name being resolved by SRV (either DNS or local file) , you are screwed. Adding SIP.sigdigits does not solve the problem if the B2BUA cannot retry.

I always like to use the simplest solution. I don't know enough about the future plans or the inter-branch bandwidth to clearly say that SIP.sigdigits is useful.

Regards,

Geoff

Green

Re: Cvp Nic Unplugging problem

What happened to you guys? Did you get cold feet?  Geez, I was on a roll.

Regards,

Geoff

Green

Re: Cvp Nic Unplugging problem

I am still not clear cause this is how we send the value to the application,developed and deployed by aa diffrent team and they use that for their reference.Can this be changed to fine tune it?

I'm sorry. What is this in response to?

We are using the application itself to play the ewt and not use microapps there.We are calculating the EWT using the formula,set few values which the application needs to maintain the call details during the transfer to CVP.This has been tested and works fine.

I have never seen anyone use an Audium application to queue the call. How does this application work? Does it consist of a an Audio Element to play the EWT, then an Audio Element with music, followed by an Audio Element to play "all agents are busy", then looping back to the music?

You could easily do this with micro apps. That is the Cisco recommended way. I'm not saying you way is wrong - it's just unusual. What prompted you to take this path?

Regards,

Geoff

New Member

Re: Cvp Nic Unplugging problem

Sure Geoff you are always on a roll...Plus back here in India the temp has been up in its 90 °F too hot for a cold feet.

We were held up with some work for a site going live which went live yesterday not the site for which i have raised this problem.

My response  was for the question you asked earlier mentioned below.

Geoff Wrote--You are confusing what you need to pass to a VXML app as the callid for reporting to work - concatenate("callid=",user.microapp.media_id) - with passing information to cross-correlate activity logs with TCD, RCD records - concatenate("ICMInfoKeys=",Call.RouterCallKey,"-",Call.RouterCallKeyDay,"-",Call.RouterCallKeySequenceNumber). Don't call the second one "callid"!!

Ganesh wrote-I am still not clear cause this is how we send the value to the application,developed and deployed by aa diffrent team and they use that for their reference.Can this be changed to fine tune it?

From GW and VXML front since both are coresident it would be a better idea to go with the Send to vru.However from CVP to CUCM for agent transfers we have faced this problem with the failover not happening on Subscriber 1 going down which was the whole purpose to go with DNS Srv.

Geoff wrote-

I have never seen anyone use an Audium application to queue the call. How does this application work? Does it consist of a an Audio Element to play the EWT, then an Audio Element with music, followed by an Audio Element to play "all agents are busy", then looping back to the music?

You could easily do this with micro apps. That is the Cisco recommended way. I'm not saying you way is wrong - it's just unusual. What prompted you to take this path?

Ganesh

This is how we have been doing in many of our projects.This method somehow is simpler to achieve as from ICM we just set the required values setup and send to the VXML Apps.I am not the best guy to reply on what is happening on the application side as it is managed by a diffrent team who are an SME's in it.We simply loop or treate it as required till we find an agent and the values which Apps provide us is send to agent desktop as per the customer requirment.

Thanks and Regards

Ganesh R

Green

Re: Cvp Nic Unplugging problem

There seem to be a few questions/clarifications here.

Ganesh wrote-I am still not clear cause this is how we send the value to the application,developed and deployed by aa diffrent team and they use that for their reference.Can this be changed to fine tune it?

This is regarding you passing a certain string to the VXML application as "callid=xxx". This will create a session variable in the VXML server called callid. But what you are passing is not in alignment with the Cisco documentation. You should be passing the user.microapp.media_id here, not a concatenation of router key variables, which has no meaning - it's simply a point of correlation. If you one day add the Reporting server, you will be out of alignment.

The Cisco document is clear: see page 301.

From GW and VXML front since both are coresident it would be a better idea to go with the Send to vru.However from CVP to CUCM for agent transfers we have faced this problem with the failover not happening on Subscriber 1 going down which was the whole purpose to go with DNS Srv.

You are confused - I was not talking about "Send to VRU" and was not talking about SRV. I was talking about "Send To Originator".

You can use this and static routes together - that's the correct way. When the call comes from the IOS Gateway, Send to Originator is used. When the call comes CUCM, the static route is used.

Regarding DNS srv - you introduced a complexity that should not have solved the problem. But the problem disappeared - very strange. You could be right, but it sure looks odd. The normal way is to have two static routes - one to each subscriber. This works from CUPS, and it should also work from the B2BUA.

Geoff wrote-

I have never seen anyone use an Audium application to queue the call. How does this application work? Does it consist of a an Audio Element to play the EWT, then an Audio Element with music, followed by an Audio Element to play "all agents are busy", then looping back to the music?

You could easily do this with micro apps. That is the Cisco recommended way. I'm not saying you way is wrong - it's just unusual. What prompted you to take this path?

Ganesh

This is how we have been doing in many of our projects.This method somehow is simpler to achieve as from ICM we just set the required values setup and send to the VXML Apps.I am not the best guy to reply on what is happening on the application side as it is managed by a diffrent team who are an SME's in it.We simply loop or treate it as required till we find an agent and the values which Apps provide us is send to agent desktop as per the customer requirment.

I don't know what you mean by "who are an SME's in it".

I can see a number of reasons not to do it this way:

1.You are using VXML ports when you could be using Call Server ports

2. You have made a more overhead-intensive queuing application than necessary (the root document is 19k)

3. Should you need to have a more intricate routing pattern (say queue at one SG for 20 seconds, then add in a couple more SGs) you won't be able to do it.

4. If you have RONA with Router Requery and raising priority, you are screwed.

5. microapps give automatic retry through "-backup". CVP VXML don't. Nothing like a CSS, but better than most. And useful for those long music in queue files which can sometimes give problems coming down from the Media Store.

How do you pass "the values which Apps provide us is send to agent desktop as per the customer requirements" from within the Audium app?

I refer to the SRND page 6-6:

Model #3b: Comprehensive Using Unified CVP VXML Server
Model #3b does not differ significantly from Model #3a as far as call control and signaling are concerned. The only difference is that the Unified CVP Microapplications executed in Model #3b might include subdialog requests to the Unified CVP VXML Server as well. Of course, self-service applications are not likely to be invoked during the period when the call is queued. Any agent selection nodes or queue nodes in the Unified ICM routing script would therefore likely be postponed until after the self-service application has completed and control has returned to the Unified ICM routing script.

Cisco intended that the queuing be done with microapps.

Regards,

Geoff

Green

Re: Cvp Nic Unplugging problem

geoff@hp.com

Regarding DNS srv - you introduced a complexity that should not have solved the problem. But the problem disappeared - very strange. You could be right, but it sure looks odd. The normal way is to have two static routes - one to each subscriber. This works from CUPS, and it should also work from the B2BUA.

I was looking at the new CVP 8.x SRND

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/srnd/8x/cvp8xsrnd.pdf

and you may be right that static routes in the CVP SIP B2BUA have no redundancy and you can achieve this with SRV records. I would never contemplate a production CVP without a proxy server (either CUPS or CUSP), but it appears that your method is correct.

Regards,

Geoff

New Member

Re: Cvp Nic Unplugging problem

Wont we be requiring a DNS SRV records if we have two CUPS servers for redudancy purposes.

Green

Re: Cvp Nic Unplugging problem

hari.kanan wrote:

Wont we be requiring a DNS SRV records if we have two CUPS servers for redudancy purposes.

You certainly will.

If you specify that your Call Server uses an outbound proxy, you then need to put one in the Device Map and choose it and set it in the drop down box. This only allows for 1. What happens if this one is down?

You should say "no" to outbound proxy, and "yes" to SRV, and configure the static route for agent extensions to have the cluster name after the comma, then set up the CUPS correctly to use the cluster name, and configure your SRV to find the two proxys (either through DNS or the local SRV).

This is how I use SRV records - with a pair of CUPS.

Regards,

Geoff

1135
Views
0
Helpful
24
Replies