UC Doers Live
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.
How to Avoid a Routing Loop Using Announcements
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.
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.
Response Group Part 2: Enhanced Hunt Group
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.
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.
CIPTUG Northwest Chapter Meeting
Cisco IP Telephony Users Group Northwest Chapter Meeting
Tuesday, April 14, 2009
11:00 am - 3:00 pm
The meeting is open to Cisco end users who are either CIPTUG Members or interested in becoming members and CIPTUG Vendor Members.
Interested?
Plan to attend the CIPTUG Northwest Chapter Meeting!
Who: CIPTUG Members and Cisco IPT users
What: CIPTUG Northwest Chapter Meeting
Agenda:
• 11:00 - 11:30 am
Welcome & Chapter Business
• 11:30 am - 12:00 pm
Cisco Roadmap - Chris Steffy
Cisco Unified Communications Portfolio
• 12:00 - 12:30 pm
Lunch Provided by Agito
• 12:30 - 1:30 pm
Cisco - Laura Smith
Cisco Mobile Unified Communications
• 1:30 - 2:30 pm
Agito Networks - Jim Alexander
Agito Networks RoamAnywhere Mobility Router
• 2:30 - 3:00 pm
Birds of a Feather/Open Mic
• 3:00 pm
Meeting Adjourns
When: Tuesday, April 14, 2009
11:00 am - 3:00 pm - Please RSVP - Lunch will be served
Where: Cisco Systems Bellevue WA Office
500 108th Ave. NE - 5th Floor
Bellevue, WA
RSVP:Click here to Register
Virtual details will be available to registered participants. Giveaways (in person participants only): Plantronics Bluetooth Headset, Cisco Books, CIPTUG Logo'd Merchandise.
Tuesday, April 14, 2009
11:00 am - 3:00 pm
The meeting is open to Cisco end users who are either CIPTUG Members or interested in becoming members and CIPTUG Vendor Members.
Interested?
Plan to attend the CIPTUG Northwest Chapter Meeting!
Who: CIPTUG Members and Cisco IPT users
What: CIPTUG Northwest Chapter Meeting
Agenda:
• 11:00 - 11:30 am
Welcome & Chapter Business
• 11:30 am - 12:00 pm
Cisco Roadmap - Chris Steffy
Cisco Unified Communications Portfolio
• 12:00 - 12:30 pm
Lunch Provided by Agito
• 12:30 - 1:30 pm
Cisco - Laura Smith
Cisco Mobile Unified Communications
• 1:30 - 2:30 pm
Agito Networks - Jim Alexander
Agito Networks RoamAnywhere Mobility Router
• 2:30 - 3:00 pm
Birds of a Feather/Open Mic
• 3:00 pm
Meeting Adjourns
When: Tuesday, April 14, 2009
11:00 am - 3:00 pm - Please RSVP - Lunch will be served
Where: Cisco Systems Bellevue WA Office
500 108th Ave. NE - 5th Floor
Bellevue, WA
RSVP:Click here to Register
Virtual details will be available to registered participants. Giveaways (in person participants only): Plantronics Bluetooth Headset, Cisco Books, CIPTUG Logo'd Merchandise.