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

Infastructure Learning

Hi Guys,

So today I studied CCIE Voice stuff that I would normally consider basic, Boy did I learn alot!

First of all, right off the bat, did you know that the voice-VLAN is discovered via CDP? Meaning if CDP is not running.. that's right, voice-vlan is not discovered, i confirmed this myself by turning off CDP on a switch, my phones no longer correctly discovered the voice VLAN. Turning cdp back on with cdp run enabled it again (but actually went and reset every single phone on the switch without warning so keep that in mind!)

I also learnt that the ESW modules we will be using in the exam don't support switchport access vlan with a Voice VLAN configured, you have to configure a trunk.

So your config will look something like this:

int fa0/1
switchport voice vlan 10
switchport mode trunk
switchport trunk native vlan 30 <-- this is your data vlan
switchport trunk allowed vlan 10,30 (This is optional depending on if the exam asks you not to trunk unnecessarily)
spanning-tree portfast
!

I also learnt about DHCP in CUCM. You might not know this but CUCM actually assigns from the top of the addresses in the available pool downwards unlike an IOS DHCP.

I also discovered that a very common bug in CUCM 7.0 is that the DHCP server does not work with CIsco Security Agent running, to disable the cisco security agent, login to your CUCM using SSH and use your OS administration username and password when prompted, then issue:

#utils csa disable

This will require a restart of CUCM.

in TFTP Option 66 is used to use DNS as a TFTP configuration option instead of Option 150, keep that in mind guys!



Finally I learnt about NTP, its important to know that phone NTP references are only used for SIP handsets, so bare this in mind, other handsets (SCCP) get there time from CUCM which in turn can be pointed to an NTP reference. A subscriber ALWAYS gets its time from the publisher so if you point the NTP reference of the publisher to a router you will be fine.

I hope these little infrastructure hints help someone out there!

Logical Partitioning

So today Boys and Girls I studied Logical Partitioning.

What the heck is logical partitioning I hear you ask, and why should I care about yet another way to restrict calls in CUCM?

Very good question, and in the interest of full disclaimer I just want to mention at this point to potential CCIE Voice Candidates: I have absolutely no idea if this feature appears in the CCIE Voice Lab exam or not. I have a terrible habit of studying thing's for my CCIE Voice that may not even appear in the lab. I spent a very large amount of time studying VOIP Security in terms of cryptography , only to eventually find out that this is not even tested in the CCIE Voice. Doh!

Assuming you either heard it is in the exam (if you did, post a link in the comments below so we all know) or your just plain interested in knowing what it does, read on:

Logical partitioning fufils a pretty niche requirement, basically logical partitioning restricts calls from certain gateways to VOIP phones and vice versa. It differs from regular calling search space and partitions in that it can restrict mid-call features such as call transfers and call joins.

Let me explain with an example, and tell the story of the major reason why logical partitioning is even in the CUCM configuration.

In India, up until 2008, it was against the telephone regulations to have a VOIP system connected to the PSTN network. The Indian telco's successfully lobbied the government to keep these two systems separate so that they could hold onto there revenue streams and prevent toll bypass. The only way to run VOIP was to actually have two entirely separate Systems, many Cisco deployments utilized a two-line approach, with one line being part of the VOIP system while another line part of the PSTN system.

In 2008 this restriction was removed, but the law in India states that no form of toll-bypass is allowed on there network. So for example, an Indian VOIP user calling a new york number that's not part of his own VOIP cluster cannot use the VOIP gateway in new york to achieve toll bypass.

Easy I hear you say, just don't implement toll bypass for India, give them a separate calling search space, separate partition, a few translation patterns for there geographic numbering plan and translate it all to + dialing then route it out the local route group, easy as. I don't have to worry now: I am not doing any form of toll bypass for India.

Well Mr Smarty-pants, let me give you a situation where Calling Search Spaces and Partition's WON'T solve this problem and toll-bypass can be executed.

Bob and Mike work for India-US-MegaCo.
Sam is just a customer of India-US-MegaCo

Sam is a PSTN user is India, Sam Calls Bob in India and asks to speak to Mike in the American office. Bob say's no problem and transfers Sam to Mike.

That's not allowed under Indian regulations as it is now toll-bypass.

Logical partitioning will check against this kind of attempted transfer, if logical partitioning denies the call, a message "External transfer not allowed" will show.

Now, onto the configuration.

The first thing you should do is enable Logical Partitioning Globally, this can be found under the enterprise parameters:

Enable Logical Partitioning

Set this to true


The next step is to create some Geo locations, go to System -> Geo location and fill in the physical details as you require. You can get extremely specific here if you like or as specific as you need to be.

The next step is to apply a GeoLocation filter, this filter controls what actual settings from the Geolocation are going to apply to the device. With this you can say basically only the country is relevant for the use of the Logical Partitioning.

You need to go ahead and assign these settings to your gateways and phones, note that you can only apply the geolocation filter to the device pool of a phone and not directly to the phone itself, gateways you can apply both.

Now it is worth mentioning at this point the next part of logical partitioning: In logical partitioning devices are classified into two seperate elements; a border element or an interior element.

An interior element is any VOIP Phone, CTI Route Point, Voicemail SCCP Device etc. etc.

A border element is any type of gateway or trunk, for example, a H.323 Trunk, an MGCP E1 Port etc. etc.

Logical policies can apply to:

Interior to Border
Border to Interior
Border to Border

you can't use Logical partitions to restrict Interior to Interior calls, and why would you want to? they are both VOIP endpoints so no legal requirements are being breached here.

OK now that's explained, the logical partitioning page should make more sense, go to call routing -> logical partitioning.

Give the policy a name and select the identifiers that identify devices in this logical partition, this could be country for example.

Create at least two logical partition policies, you then can establish the relationship between the policies, lets say you create two policies:

Australia
India

you can then say "Border devices in Australia trying to reach Interior devices in India: Deny"

To test this, set a Gateway to Geolocation Australia, A phone to Geolocation Australia and another phone to Geolocation India, you should be able to call between the VOIP Handset in the Geolocation Australia and the handset in Geolocation India.

But to prove the deny is working, make an incoming call over your gateway in australia to your australian phone, then try having that australian phone attempt to transfer to the handset in india, while it will ring when you first try and transfer, if you click transfer again, you will receive the error on your phone "External transfer not allowed"


I hope this helps someone out there and be sure to post in the comments if you've heard somewhere that logical partitioning is in the exam (unless you'd be violating NDA, in which case please don't!)

Until next time.

Peter

Lovin UCCX and helpful hints along the way

Hi Guys,

I am loving this UCCX stuff for my CCIE Voice, it's extremely enjoyable to go back to programming, even if it is procedural and very limited. I have wrote a little script that reads from a database, concatonates all the results from a database into a container prompt then spits it out. Very useful. NOT, but fun to write

To do it though I had to use an array, I had a heck of a lot of trouble getting the Array to work in UCCX. When I debugged the script (Which, by the way is done by selecting "Reactive script" on the UCCX editor under the debug menu and then selecting the script name) I got the following error

"invalid null array"

If you get that error message in UCCX, and your wondering why, you actually have to set all your array elements or at least create them before you can use them as per the following cisco support forum post I found:


https://supportforums.cisco.com/thread/268206?decorator=print&displayFullThread=true


"

1. Make an int variable called Q, make it an array

2. Set Q= new int[6]

3. Set Q[0]=1

"

I hope this helps someone out there!

Cheers
Pete

MRG and Transcoders

Came across an issue with a co-worker of mine (Paul)

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42media.html#wp1094999

A transcoder is also capable of performing the same functionality as a media termination point (MTP). In cases where transcoder functionality and MTP functionality are both needed, a transcoder is allocated by the system. If MTP functionality is required, Cisco Unified CallManager will allocate either a transcoder or an MTP from the resource pool, and the choice of resource will be determined by the media resource groups, as described in the section on Media Resource Groups and Lists.

Thats absolutely fine, but if you do the normal config of having your HW_MRG for your hardware transcoders, place this at the top of your MRGL then have your software below, the problem is the way MRGL's pick MTP resources:

The algorithm for allocating like resources from an MRG attempts to spread the load across the like resources. When a resource has been used, a pointer for that MRG is incremented to the next device. A device may be present in more than one MRG, which will affect the pointers of all groups in which the device is a member. When MTPs are required and transcoders exist in the same group, the MTPs are always allocated until all MTPs are used, and then transcoders are used as MTPs. When resources of differing capacities exist in the same group, the load sharing attempts to allocate resources based on the capacity. The system will spread the load across resources, but because of the above factors, it frequently will not be round-robin in behavior.



So in other words, if you have a MRG with both transcoders and MTP's the Transcoders will only be used until the MTP resources are not available.

So in summary: a transcoder can act as an MTP point and will if its highest priority in your MRGL, if its inside an MRG where order doesn't matter it will always be used last.


I hope this helps someone out there!