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 4.1 Sigdigits Issue

Hi

I have a CVP 4.1 with Split PSTN/VXML Gateways and have enabled sip.sigdidits feature to strip off the significant digits to route calls to specific VXML Gateways.

I have a SIP Trunk pointing towards the Call server with a prefix of 4 digits. These digits are discarded and the DNIS is sent to the ICM to invoke the Appropriate Script. The Script uses a Send2VRU with NVRU Label as 77777 which is returned back to the Call server.

The call server also has a Local route specified as 4 Digit Prefix + NRVU Label pointing to the VXML Gateway. The VXML gateway has a Voip Dialpeer that matches the Digits sent by the call server ie. Prefix Digits + NVRU Label + CorrID and triggers the Bootstrap.tcl

The problem we are facing is that the VRU Leg never engages and disconnects with an Error 38 (network Outage)

THe call server logs indicate there is a problem with DN Routes or Gateway Dial-peers, however, everything seems perfectly fine to me.

I am not using any SIP Proxy server, any help would be much appreciated.

Attached are the call server logs.

1 ACCEPTED SOLUTION

Accepted Solutions
Green

Re: CVP 4.1 Sigdigits Issue

http://:8000/cvp/diag

From the drop down box, pick each of the subsystems in turn and turn on debug with the "set" button. For complete tracing you should see each subsystem say debug/41 except for the Dynasoft library which should say debug.

Once you have it set up, open the CVP.xx.log file with a decent editor like GVIM and delete all the lines. You can't do this with a stupid editor like notepad.

Now make the call and check the log.

Regards,

Geoff

11 REPLIES
Green

Re: CVP 4.1 Sigdigits Issue

There have been a few posts here on SIP.sigdigits (I've been in some of them) so you may want to do a search and check them out.

Let's see. I don't see anything obviously wrong, but let's go over it.

CVP is configured with SIP.sigdigits and the value = 4.

The VOIP dial peer towards CVP prefixes 4 digits before sending it to CVP. Let's assume you prefix "8888". Your setting on this dial peer is to send it directly to the SIP Back-to-Back User Agent on CVP using ipv4:a.b.c.d:5060.

When the call arrives at CVP, it strips off 4 digits - i.e. "8888", and sends the resulting DNIS up to ICM through the PG. This starts the ICM script, and hits the "Send to VRU" node. The script pauses and returns the label configured on the Type 10 NVRU for the CVP routing client. You say that this is "77777".

Your label "77777" looks a bit odd. The length is 5. I assume you mean to do this, and have your CVP configured with a DNIS length of 5. True?

This is not as is recommended by Cisco. Normally, one makes this length 10 and you should have a label like "7777777777".

Anyway, CVP gets this label, prepends the sig digits it saved ("8888") and looks for a static route, since you don't have an Outbound Proxy.

You have a static route that catches "888877777" and sends it to the appropriate voice gateway.

Now, on the VXML gateway, you have a dial peer here that catches "888877777T" and tries to run the bootstrap. It sends the complete number back to CVP, and it again applies SIG.digits and strips off "8888", so it looks on "77777" to find the correlation ID.

The only thing that bugs me is the NVRU label.

One thing you say that I can't follow is "I have a SIP Trunk pointing towards the Call server with a prefix of 4 digits."

Are you speaking of a SIP Trunk in Call Manager? This is for getting the call to the agent, and because of SIP.sigdigits, the label returned will be "8888".

Assume all agent extensions are 5 digits.

You need to configure this trunk with significant digits = 5 (it counts from the right hand side). It's not that it discards digits, especially the SIP.sigdigits prepended - it just looks from the RHS and counts 5.

You will need this to get the call to the agent, but not for making the call queue on the gateway; so I wonder why you mention this.

Regards,

Geoff

New Member

Re: CVP 4.1 Sigdigits Issue

Hi Geoff,

Thanks for replying.

I have the configurations just the way you have described now and the ones you have posted earlier on this forum.

I did try this with a 10 Digit NVRU label but still stuck with the same thing. I can see the digits are being stripped and then prepended to the NVRU label back to the VXML Gateway, it matches the correct dial-peer which has the Service Bootstrap assigned to it but fails to establish the VRU leg with an Error 38 (Network out of order).

When the Sigdigits parameter is disabled, the normal comprehensive flow works perfectly.

So here is brief Call flow

1. Dial 8100 from an IP Phone

2. Route Pattern on call manager does a Prefix with "1111" and the resulting DNIS sent to the Call server is "11118100"

3. Call Server has a SIP.Sigdigits=4, hence strips off 1111 and sent the actual DNIS "8100" to ICM in the route request

4. ICM script invoked and sends a SEND2VRU label "77777" ( I had this changed to 5 digits as i thought the CVP max dnis value could be a problem, i shall revert back to 10 digit Dnis).

5. Call Server has a static route defined a 11117>VXML Gateway

6. VXML gateway has a Voip dialpeer with Incoming called as "11117T" and service Bootstrap to it.

When I turn up VXML tracing/debug on the gateway, i can see that it sends a NEW Call request to the call server and then errors out with handoff.tcl

IOS Version 12.4(15) T7

ICM 7.2 SR 5

Call Manager 6.1(2

Green

Re: CVP 4.1 Sigdigits Issue

Ah, you should have started off your original post by saying this is for UCM-orignated calls, not for inbound TDM calls.

>When the Sigdigits parameter is disabled, the normal comprehensive flow works perfectly.

This is not really a "normal comprehensive flow" - that would be for a call coming in from the PSTN.

Anyway, minor details.

You say that the send to VRU label on the UCM routing client is of length 5, and the CVP maximum DNIS length is also 5. Correct?

What do you see on the CVP side? Turn up the tracing using the diag servlet. What do you see in the Call Router - turn up tracing with rttrace.

Regards,

Geoff

New Member

Re: CVP 4.1 Sigdigits Issue

You are correct, it is not comprehensive call flow as documented by cisco.

So getting onto the problem, Do i need to define a Label for the UCM Routing client? I have the NVRU Label defined for the CVP routing client as CVP is doing call control and CVP max dnis length is 5 you are right.

Do i need to define a NVRU Label for the UCM Routing client is that required? It works fine when i disable the Sigdigits feature without having to define it for the UCM routing client.

Green

Re: CVP 4.1 Sigdigits Issue

If it works fine without SIP.sigdigits, then your config is correct. As you apply SIP.sigdigits and it fails, you will surely see the error in the CVP logs. Turn up tracing using the CVP diag servlet - including the Dynasoft library - and I am sure you will find the error.

Regards,

Geoff

New Member

Re: CVP 4.1 Sigdigits Issue

Thanks Geoff,

Appreciate all your help, is there a documentation which explains on using CVP Diag servlet and the Dynasoft library as i havent used it before. Also what tracing values should be set to get desired Error logs.

Regards

Mohsin Kazi

Green

Re: CVP 4.1 Sigdigits Issue

http://:8000/cvp/diag

From the drop down box, pick each of the subsystems in turn and turn on debug with the "set" button. For complete tracing you should see each subsystem say debug/41 except for the Dynasoft library which should say debug.

Once you have it set up, open the CVP.xx.log file with a decent editor like GVIM and delete all the lines. You can't do this with a stupid editor like notepad.

Now make the call and check the log.

Regards,

Geoff

New Member

Re: CVP 4.1 Sigdigits Issue

Thanks Geoff,

The logs indicated that the DNIS Sent back to the call server uses the CVP max dnis length for stripping and setting the Corrid to match the call leg with ICM.

So i simply changed the CVP Max dnis length to include the prefix + NVRU label (in my case it was "9") and it worked!!

Thanks for you all your help.

Green

Re: CVP 4.1 Sigdigits Issue

Good stuff. The CVP logs are pretty good around the handling of SIP.sigdigits and you can see it save the digits on the way in, then prefix them on the way out. The CVP setting for DNIS length is obviously critical (as you have found out) as CVP needs to be able to find that correlation ID under all conditions. Again, the CVP trace is pretty good in this area.

Regards,

Geoff

New Member

Re: CVP 4.1 Sigdigits Issue

Hello Geoff,

Is it mandatory that we should use the SIP sigdigits feature for the distributed deployement model. or will it work without the sig digits feature also. In our setup we have one Ingress and One VXML Gateway

Regards,

Dass

Green

CVP 4.1 Sigdigits Issue

With only 1 ingress gateway and 1 VXML server you have no need to add the complexity of SIP sigdigits. The static route in your Proxy server (or Call Server, if you don't use a SIP Proxy) for the VRU transfer label (e.g. 8111111111) just points at the one VXML gateway.

Can I ask why you don't make these into two combined ingress/VXML gateways providing some measure of redundancy at the PSTN interface? What models do you have?

Regards,

Geoff

791
Views
0
Helpful
11
Replies
CreatePlease to create content