Call routing redundancy stuff

Hi Guys,

So something you can probably expect to see on the test is call routing and call routing redundancy.

Let's just clear something up straight away: as you probably already know, there are three gateway protocols you might use on CUCM, SIP, H323 and MGCP.

For MGCP, Call routing redundancy is pretty simple, after all, an MGCP device will unregister if it loses its ISDN connectivity, and calls won't get routed to it or from it (since the ISDN is down)

H.323 and SIP are a little different, these two are peer technologies, now the basic idea for there redundancy is this:

Two dial-peers, one pointing to the publisher, one pointing to the subscriber (10.10.10.1 and 10.10.10.2 respectively)

dial-peer voice 1000 voip
preference 1
session target ipv4:10.10.10.2
codec g711ulaw
destination-pattern 55566...
!

dial-peer voice 1001 voip
preference 2
session target ipv4:10.10.10.1
codec g711ulaw
destination-pattern 55566...
!

Now the preference controls in what order the CUCM tries to route the calls, the first being the subscriber and the second being the publisher in my example. Easy right? Yep so far so good, but the problem is that the timers that H.323 and SIP have set by default on a VOIP gateway are wayyy too long, and often the ISDN hangs up or gives up long before the call has switched to the next dial peer. here are the commands to sort that out:

For H.323:

voice class h323 1
h225 timeout tcp establish 3
!

for sip:

sip-ua
retry invite 3
!

By setting these values as shown above, you can ensure that the gateway realises there down long before the ISDN does.

The default settings in CUCM itself are a bit better, with 5 seconds being the default for tcp establish time and 6 sip invites (which to be honest is a bit on the generous side)

Sometimes you might have redundancy setup, but for some reason it's not appearing to work, in this case the show dial-peer command is very much your friend.


in our example, lets say we know for a fact that the first dial-peer being hit is 1001 since that's got the highest preference (but always double check this, because sometimes it's not the dialpeer you think it is. use a show dialplan number command to check for sure!)



PeterCCIE18371#show dial-peer voice 1001
VoiceOverIpPeer1001
Time elapsed since last clearing of voice call statistics never
Connect Time = 7120, Charged Units = 0,
Successful Calls = 15, Failed Calls = 29, Incomplete Calls = 0
Accepted Calls = 1, Refused Calls = 0,
Last Disconnect Cause is "1 ",
Last Disconnect Text is "unassigned number (1)",
Last Setup Time = 433415246.
Last Disconnect Time = 433061258.

If the last disconnect text is something like shown above, we can happily know that the call is going to try and route to the next dial-peer, but if the output is more like shown below:



PeterCCIE18371#show dial-peer voice 301
VoiceOverIpPeer301
Time elapsed since last clearing of voice call statistics never
Connect Time = 7198, Charged Units = 0,
Successful Calls = 16, Failed Calls = 30, Incomplete Calls = 1
Accepted Calls = 1, Refused Calls = 0,
Last Disconnect Cause is "11 ",
Last Disconnect Text is "user busy (17)",
Last Setup Time = 433457836.
Last Disconnect Time = 433429422.

we know (and could rightfully expect) that the router will NOT attempt to route the call any further to the next dial-peer. because we received an error: the user is busy, why would we try and route it to the next dial-peer we will only receive the same user busy status.

There are service parameters in CUCM (not sure about on IOS routers) that control this behavior:


"

Stop Routing on Out of Bandwidth Flag	True False	False
Stop Routing on Unallocated Number Flag	True False	True
Stop Routing on User Busy Flag	True False	True

"

The defaults make perfect sense in 99 percent of situations. If the user is busy, don't reroute the call, if the numbers unallocated, don't reroute the call, if the other end is out of bandwidth, try and reroute the call.

THe unallocated number might be the only one you would want to potentially change, lets say for example you have a remote site Phone that can be reached either via a H.323 Gatekeeper over your private wan, then maybe a SIP trunk over the internet

you want to use the gatekeeper first (obviously) you have your router at the remote site register to the gatekeeper. You tell it to advertise its E.164 address to the gatekeeper, but the WAN connection between your remote site and gatekeeper dies, suddenly when you route the call to the gatekeeper, it is going to spit back that it is an unallocated number, and your SIP trunk will never be attempted to be routed to.

This might be a good reason to change this option here.

Be very careful though, any of these stop routing settings not set properly could cause a routing loop.

The guy from Internetworkexpert mentioned that you might want to turn off unallocated unassigned number for + dialing.. I can't see why, if anyone knows why please post below.

Thanks guys!
Pete