Diagram one shows the entry point to the response group for the caller.
Diagram two takes us to the results of the first and second level IVR.
Diagram three represents the agent queues for all levels.
Response Group Part 4: Two-level Interactive Template
For the last installment in this series I had to break down the diagram into sections to make it more readable.The two-level interactive template is very similar to the one level but as you would expect, another level is added, duh. I will let the diagrams do the explaining.
Diagram one shows the entry point to the response group for the caller.
Diagram two takes us to the results of the first and second level IVR.
Diagram three represents the agent queues for all levels.
Diagram one shows the entry point to the response group for the caller.
Diagram two takes us to the results of the first and second level IVR.
Diagram three represents the agent queues for all levels.
Response Group Part 3: One-level Interactive Template
Third in this series of blog posts, we are really getting to the more complex scenarios. One level interactive RG’s add the IVR style menu options that can be a voice response to set questions. As the diagram shows, this is building on the enhanced hunt group. Sure, this will not cover every requirement you may have for IVR style ACD but then again it is not supposed to either. I know where I work this type of ACD is popular on the more traditional systems and this level of complexity would cover 80% of all our requirements. The more complex IVR and ACD requirements are best left on a specialized platform like OCS 2007 Speech Server or Cisco IPCC Express for example.
What I really like about the Response Group feature is the ease of setup. Too often with simple Hunt Group and ACD requirements the complexity to get things working and needing to know scripting languages can be painful when something with the website interface setup will do.
What I really like about the Response Group feature is the ease of setup. Too often with simple Hunt Group and ACD requirements the complexity to get things working and needing to know scripting languages can be painful when something with the website interface setup will do.
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.
Subscribe to:
Posts (Atom)