Load-balancer for NSS

[prb]

Hello,

We have a setup that uses CVP comprehensive call flow with ASR/TTS over MRCPv2. It uses CUSP as the load-balancer.

By default ASR and TTS request for a call land on different speech servers.

We are trying to find a way to bind both ASR & TTS request [for a given call ] to land same speech server.

I followed the instructions as per CVP config guide:

    IVR Service in the Operations Console, select the  ASR/TTS use the same MRCP server option.     

and

• ip host asrtts- <locale>  <IP Address Of MRCP Server>
•   ip host asrtts- <locale>  -backup <IP Address Of MRCP Server>        
• Modified host name , SIP URI patterns

I still see the requests landing on different servers. Did anyone got this working? Can anyone help me understand how this CVP option works to make ASR/TTS go to same server?

Thank you

[ptindall]

Are you using CVP microapps or a Studio application?

If it's the former, then your ASR/TTS requests by default will still be using MRCPv1 and rtsp as this is what's built-in to the VoiceXML templates that are uesd to generate the VoiceXML docs when microapps are invoked.  So, are you actually using MRCPv2?

If you want to use MRCPv2 then you should use CVP Call Studio apps.   You can use microapps but you'll have to edit the templates and comment out the recogniser/synthesiser URLs so the gateway ivr asr-server and ivr tts-server commands will be used.   Of course, be mindful that officially you'd be unsupported using modified templates.

Paul

[prb]

Hi Paul,

We are using Studio apps. The tts and asr host names are defined in the gateway.

Since the gateway sets up asr and tts using 2 different dial-peers , and presence of loadbalancer makes it difficult to bind these 2 requests to same server.

But the config guide setting [ASR/TTS use the same MRCP server] makes me believe there is a way , but I am unable to figure out.

[ptindall]

I don't know if it's possible to do this using CUSP simply because you'd have to send the separate SIP Invites for both ASR and TTS sessions to the same servers within the available ASR/TTS farm.  I don't know how you'd configure that association.

As an alternative suggestion or interim solution, what you might want to try is setting the com.cisco.asr-server and com.cisco.tts-server VoiceXML properties at the start of the Studio app to a SIP URI that contains an index value selected randomly.  For example use sip:asr-N@xyz.lab.com and sip:tts-N@xyz.lab.com where N is an index/suffix calculated randomly across the number of speech servers you have.   Then use either separate dial-peers to match the different URI patterns and route directly to the speech servers or go via CUSP if you prefer.

[prb]

Thanks Paul. That's a nice idea. The only concern is load balancing and high availability

The load distribution will depend on random function .

It limits the failover ; because the CUSP or Dial-peer entries can be only 1:1

[ptindall · Accepted solution]

Yes, I totally agree it's not the ideal solution but for failover I would implement fallback dial-peers with lower preference to allow the other server(s) to be targeted.  There is of course still some element of risk that you could get ASR and TTS sessions on different servers if the timing of a failure occurred just after a successful initial speech server connection.  That said, if there was such a failure, you would hit an error situation anyway on that call and have to do some recovery.

For load balancing, if you don't like the random approach then as an alternative you could maintain a global variable that cycles through the server list.

I will post an update if I uncover a better solution but for now I think that's about the best I can do.

Paul

[prb]

Thanks a lot for your help Paul.  We will try these options.

Actually ,  apart fro CUSP , we are exploring the option of F5 for load balancing using From header as persistence key.

Any idea about using F5 for SIP traffic. I know its not officially supported - but it seems to support SIP load balancing.

[ptindall]

Unfortunately, I don't have any F5 / SIP experiences I can offer.   It does seem like there's a very real use-case here on MRCPv2 where F5 might prove useful.  If you can update the thread on success or not with F5 that would be really useful; this is a use case we should aim to have a supported/documented solution for.

Paul

[prb]

Sure Paul, I will update with my findings after my testing is complete.

[abbottchase]

SIP itself is a tough proto to manage during session so F5 BIG-IP really operates as a SIP Session proxy, basic LB but cannot due much to the payload as it can with other protocols.  And in those configurations, SIP is supported.

https://www.f5.com/pdf/deployment-guides/load-balancing-sip-dg.pdf

I know several places that still use BIG-IP in front of multiple SBC's (in this case Acme) for traffic management and it can manipulate SIP header data if needed but as SBC's are better equipped for that, most of the time the BIG-IP is just for traffic distribution (using the ACME for header manipulation).  Here's an example of using BIG-IP to mitigate Shellshock in front of a vulnerable SIP server, again, no header manipulation but inspection and prevention:

Shellshock – The SIP Proxy Edition

Regarding MRCP, like Paul said, not much of a case there, and in my opinion to simplify troubleshooting and management should be manipulated as little as possible and on something tailored for this such as an SBC.