cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1751
Views
19
Helpful
13
Replies

is Sigdigits feature mandatory for the Ingress and VXML Gateway

Dass Prakash R
Level 1
Level 1

Hi All,

We have a CVP Comprehensive setup where there are three Ingress Gateways and one VXML Gateway. If there is one Ingress and one VXML gateway we can use the static route in CVP. Could someone guide/help if there are more than one Ingress gateways and One VXML gateway the CVP Static route will work?

Regards,

Dass

13 Replies 13

Kris Lambrechts
Level 1
Level 1

No, if you have only one VXML Gateway you do not need signaling digits. In fact, singaling digits are useful to logically have each Ingress Gateway use a specific VXML Gateway, so if you had 2 Ingress & 2 VXML Gateway you can make sure that calls from Ingress GW1 go to VXML GW1, etc.. This is useful in scenarios where you have multiple branches for the gateways and don't want RTP streams to cross the WAN.

Note: in general, you should re-consider having only one VXML gateway as it obviously is a sngle point of failure.

Cheers,

Kris

Hello Chris,

Thanks for the info provided. As per your info static route would suffice the requirement. On point#2, we are having two VXML gateways acting on redundancy which will use the SRV record to choose the appropriate VXML Gateway. Please correct me if i'm wrong

Regards,

Dass

It appears from your posts that you don't have a SIP Proxy server. Is that correct?

And yet you mention SRV records to choose a VXML gateway - that's not how SRV is meant to be used. SRV (whether using DNS or local SRV.xml file) is there to choose which of your two SIP proxy servers the Call Server should send the outbound SIP invites to,

In the absence of a SIP Proxy server, you can simply have two static routes in your Call Server for the VRU transfer label to find a VXML gateway to run the bootstrap.

Let's say that the VRU transfer label is 8111111111 and you have two VXML gateways 10.10.0.1 and 10.10.0.2. You could have two static routes in the Call Server

81111>,10.10.0.1

81111>,10.10.0.2

The Call Server will alternate these. If one is down, the INVITE will fail and the Call Server will try again, choosing the other one. You would need to turn down the number of retries or it will retry the same one up to the number of specified tries before it goes back and the Call Server asks for the other one. The normal SIP mechanism is to double the time between retries, starting with 0.5 seconds.

It's the same as what you would have to reach an agent. Let's say you have two Subscribers 10.10.2.2 and 10.10.2.3, and your agent phones are all 7XXXX. You would have two static routes in the Call Server

7>,10.10.2.2

7>,10.10.2.3

No SRV required.

SRV is used when you have two proxy servers. If you have just 1, you can specify Outbound Proxy and set it in the drop-down box. But if you have two, you should specify "Use SRV" and configure the SRV records in your DNS or local SRV file to load balance your two proxy servers. Now you need the cluster name config to match - what you put in the Call Server and what you configure in CUPS/CUSP.

These mechanisms all rely on a failure to trigger a retry. Server Groups were added to CVP 8.0 to provide a more dynamic assessment of readiness using the SIP OPTION = PING message set. Have you investigated that?

Regards,

Geoff

Hello Geoff,

Thanks for your valuable inputs.

1. Yes we do not have a SIP Proxy server in our setup.

2. Presently we are using a local srv file instead of pointing to 2 static routes. Also, I remember in one of the TAC cases we had raised with Cisco, the CVP team had come up saying that CVP will look only for the first static route configured and it will not look on the second static route.

3. SIP OPTION = PING I have not investigated on that. Could you please provide me a link or some guideliness on this

Thanks in advance

Regards,

Dass

2. Presently we are using a local srv file instead of pointing to 2 static routes. Also, I remember in one of the TAC cases we had raised with Cisco, the CVP team had come up saying that CVP will look only for the first static route configured and it will not look on the second static route.

I find that hard to believe - but I will test this in my lab today.

3. SIP OPTION = PING I have not investigated on that. Could you please provide me a link or some guideliness on this

Look up Server Groups. It's in the CVP 8.x Guide.

Server Groups are also implemented in the CUSP - one of the reasons this is superior to the SIP Proxy in the Presence Server (CUPS) and the preferred option for a Proxy.

Regards,

Geoff

Thanks Geoff. Will wait for your updates on the static route.....

Regards,

Dass

Feel free to try it out in the lab Geoff, but it is accurate, as soon as the Call Server locks on to a Static Route, it will not hunt further in case of failures. You should be using Server Groups (whhich essentially populate srv.xml) for any kind of SIP fail-over.

Cheers,

Kris

I did just try it. I can't believe I've never attempted this - my main defence is I would not put in a production system without a pair of SIP proxy servers.

But you are dead right Kris, and so was Dass.

I set the gateway to send SIP INVITE direct to the Call Server, removed my outbound proxy, removed the "send to originator" for 8333>, and added two static routes for the transfer label 83333> - one goes to the ingress/vxml gateway at .237 and one goes to another vxml gateway at .236 which doesn't have a dial peer for 8333.

When it is in the order shown below, it works. If I move .236 up, it fails.

Of course, Kris, there are no Server Groups in CVP 7.x, so the only solution to the OP's problem is SRVs on that platform. I'll have to try that.

Thanks God I don't do this for money.

Regards,

Geoff

OK, that was interesting. This lab is CVP 7.0(2)

I created the srv.xml file with my gateways:

 

   

   

 

and changed the SIP settings:

* enable outbound proxy = yes

* use DNS SRV type query = yes

* Resolve SRV records locally

* No outbound proxy Host selected

* Outbound SRV domain name (FQDN) = vg.ucce.icm (which matches the srv host name)

Now it works correctly. I have not debugged the SIP messages through the com.dynamicsoft.DsLibs.DsUALibs to see exactly what SIP messages are sent, and how the SIP srv lookups work, but it is working, and the timeout is not particularly obvious when it goes to the .236 address.

I should look at the SIP messages to complete this story.

What I am struggling with is the following:

if SRV.xml is used for finding a VXML gateway, and the setting in the SIP CVP for Outbound SRV domain name (FQDN) matches what is in the srv.xml file for host name, then how can we use the SRVs for finding a Subscriber when we want to give it to an agent.

We can obviously write into the srv.xml file another section with a different host name and the two Subs:

 

   

   

 

but how can we tell CVP that it must use this section? There is only one place to configure a cluster name.

As I said before, it is my opinion that SRV was meant to load balance the outbound SIP proxy servers and that is all.

Have I missed something obvious?

Regards,

Geoff

I'm looking at DEBUG on SIP and on com.dynamicsoft.DsLibs.DsUALibs and I wonder how this SRV mechanism in CVP actually works. There have never been any technical details published as far as I know.

I made a number of calls and one of them failed (the second one), but from then on, they all worked. The trace shows the failure and then CVP puts that address in a table:

"UnreachableDestinationTable - add (16.91.120.236:5060:1). Current count: 0"

If I look for "Resolver: using ServerLocator resolver" in the trace file, I see a number of occurrences of this and below it I see the IP address selected - I guess from the SRV layer. For example:

"LlSM.client: connection addr: /16.91.120.237"

Now I only see one case where the resolver returns .236 (the disabled gateway), and after that I see the "UnreachableDestinationTable" trace and the next occurrence finds .237 (the good gateway). From then on, every request to the locator comes back with .237. It knows what is going on.

So my opinion of this is that Cisco is keeping an internal copy of the SRV file (that's sensible) and has marked one of the possibilities as "unreachable" and is not going to use it again.

My questions are:

(a) how long does it hold onto this information before it allows the address to be tried again?

(b) does it take a failure to occur (customer hears survivability) in order to mark the address as unreachable?

My guess for (b) is YES.

Regards,

Geoff

Hey Geoff,

As for your 2nd to last post, the option you're using there is only useful if you're routing all traffic to a set of SIP proxies. In the you've got here you should actually be using 'Static Routes' BUT rather than using an IP your static route should be i.e. 777>, somehost.com etc.. so you can have Static Routes, they just need to point to some SRV hostname you've configured.

As for question a, I don't remember off the top of my head, as for B, yes absolutely for CVP 7.x.. That however is working a lot better in CVP 8.5(x) (not quite sre on 8.0(x) right now) where a SIP OPTIONS ping will check up on the routes prior to a call being routed out of any of these entries.

Hope this helps.

Cheers,

Kris

In the you've got here you should actually be using 'Static Routes' BUT rather than using an IP your static route should be i.e. 777>, somehost.com etc.. so you can have Static Routes, they just need to point to some SRV hostname you've configured.

Ah, of course. I should have recalled that bit. I do remember seeing that - I'll try that.

Sure, that works fine. After restart (required of course when one drops the outbound proxy) the first call failed, then Ok from then on. I've never set this up like this, but understand now.

Also agree that Server Groups in 8.x have beefed this all up and my questions are not going to be that relevant going forward. I guess I like to know how things work.

Anyway, thanks for stepping in here and helping. To the original poster, Dass - sorry for the diversion.

Regards,

Geoff

Hello Kris / Geoff,

Thank you for your valuable inputs

@Geoff - It was not a diversion at all. This post has helped me in learning a lot

Regards,

Dass

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: