[cisco-voip] SIP trunk failover question

Ryan Ratliff rratliff at cisco.com
Wed May 15 09:50:50 EDT 2013


Actually when I started the email I was thinking that there were big differences in how RLs hunt between members of a RG and between RGs, but that document actually helped correct my misunderstanding.   The biggest reason I can think now to use separate RGs if if you need to do digit manipulation when sending the call to one gw vs another and wish to do it at the RL level.


-Ryan

On May 14, 2013, at 3:47 PM, Robert Kulagowski <rkulagow at gmail.com> wrote:

On Tue, May 14, 2013 at 1:32 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> You may also want to look at the behavior available to you by having
> multiple route groups in a route list vs multiple devices in the RG.
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_0_1/ccmsys/a03rp.html#wp1045311
> does a decent job of covering this.

Can you dive a little deeper into this?

For my SIP testing, I've got a single route group, and in that route
group I have the SIP trunk first, then H.323 gateways after it. During
my testing the 2851 stopped responding; even with the ethernet port
shut down on the switch side (thereby removing any traffic if it was
due to a DOS), I still couldn't get a response on the console port,
and had to have remote hands reboot it. It was still "up" enough to
respond to pings (even though they were taking 2000ms instead of 2ms),
so CM was still sending it calls, but the caller was just hearing dead
air.

Since then we've been watching it like a hawk.

If the SIP trunk is moved to its own RG, and the RL is updated so that
it now has two RGs in it, would that have mitigated what happened?

Thanks.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130515/bd500c16/attachment.html>


More information about the cisco-voip mailing list