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.