Pages

Usually I advertise in advance upcoming user group meetings, unfortunately this one slipped my mind. So to make amends I am blogging live from The Pacific Northwest Unified Communications User Group meeting. For anyone on the Seattle area interested in networking with your IT peers and learning something about Microsoft Unified Communications this is a great group which has moved its meetings on to the Redmond campus. The turnout for this meeting is about 25, which is no surprise as the topic is Exchange 2010. In future I will make sure to get the meeting on the blog a little earlier as I think user groups certainly hold value.

Sometimes it’s the unseen that consumes resources and takes a hold bringing everything to a raging holt. Sounds dramatic doesn’t it. Something like the start of a horror novel. But this is certainly one way to describe routing loops in voice networks. What happens to the call that doesn’t terminate anywhere? Well, a number of things. The most common is a time out that occurs which ends in the caller hearing a fast busy tone. Unsure whether they reached a wrong number or not they may call again.

When looking at network traffic though this could lead to a serious consumption of resources, particularly if there are a number of simultaneous calls to vacant numbers on a large internal network or in the case of a serious failure somewhere it could be your whole DID range. Unless loop prevention is part of the design in routing tables, a royal mess ensues and the possibility of call blockage becomes a big issue. If however you are directly connected via a gateway or SIP trunk to a service provider, they could be taking care of this for you.

One recent case I had was our interoperability environment between our Cisco and OCS deployment. It relies on a gateway between the two environments. When OCS would reject a call from a DID number range that was allocated to OCS the gateway would send the call back to Cisco Communication Manager (CUCM)which would then look up its routing tables to send the call back to our gateway and then the fun began. One call quickly looked like 50 on the gateway and did not seem like ending. There are also some ways to prevent this in CUCM but your design may be limited by using them.

There are a number of places where loop prevention can be deployed. Where I work we deployed loop prevention in a number of places. Using dial peers configured in a hunt group we have an unallocated number announcement provisioned for any rejected number coming back from OCS to the gateway. We also allocate an all circuits busy on Cisco Callmanager when circuits are down between the two environments. This stops Callmanager from routing calls destined for OCS elsewhere other than an announcement. Then finally, we have a mediation server dedicated to sending unallocated numbers directly to an announcement server. In my diagram, I have used OCS speech server 2007 but it could be any number of SIP enabled speech server type applications including a Cisco router setup for announcements.

The OCS dial plan plays an important part in successfully sending call to an announcement. An overlapping route pattern is required to get calls sent to the announcement that also includes the numbers allocated to users. For example 555-555-5xxx maybe your number range for allocating number in OCS to users. This is also the route pattern you would use for sending call to an announcement on speech server. Then in speech server for your announcement application you could use the * wildcard to indicate any inbound called number.

In the end you may be unaware of routing loops in your system if traffic volumes are low. In high traffic environments issues can arise when leaving things to their own devices so it’s best to have a plan in place for failing circuits and vacant DID’s. I realise with this post I haven't given the exact configuration because there are a million ways this could be achieved but hopefully the diagram and description help highlight what can be a not so obvious problem.

Well after a short break in this series, I am back onto Response Group in R2 and giving the diagrammatic version of what is possible. This entry will focus on enhanced hunt group.Enhanced hunt groups are very similar to basic but with the added features of a welcome message and scheduling business hours. MOH makes its first appearance while waiting for a contact to answer. I will let the diagram tell the rest of the story.

Join Node-Flint Support

Email Subscription

Subscribe To VoIPNorm

Followers

Disclaimer

This is my personal weblog. The opinions expressed in this blog are my own views and not those of Cisco. And yes from time to time my opinion can change.

All information provided on this site is for informational purposes only. VoIPNorm (Chris Norman) makes no representitive as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delay in this information or any losses, injuries, or damages arising from its use. All information is provided on an as-is basis.