Background
Exchange UM integrates with Cisco Call Manager using SIP trunking. The SIP trunking provides the signaling for calls that are routed from the Cisco phone system into Exchange UM servers. This SIP signaling goes directly between the Cisco Call Manager servers and the Exchange UM servers. It’s also possible to configure the voice traffic to also go through the Call Manager and go directly to the Exchange UM server. But this only works if you are using G711 as your voice codec. Because…. Exchange 2010 UM only supports the G711 codec. If you are using G729 Exchange UM will not answer your calls, you will get fast busy. Doh.
If this is the case for you, you have 2 real options, detailed in the sections below:
1 – Just Use G711 between all remote sites and Exchange UM
You can just configure a new region in CCM for your Exchange UM SIP trunk. Then you make sure that all calls from any other remote site regions to the Exchange 2010 SIP trunk uses G711. In this case:
- Call comes in to the remote site
- Gateway strips the number down to the CCM extension
- CCM sets up a SIP call between Exchange UM and CCM
- Voice traffic passes from the Gateway to the CCM, then to the Exchange UM server. G711 across the board.
Pros:
- No hardware transcoding required
- Simple setup
Con:
- G711 uses up more bandwidth – you may oversubscribe your remote site links
Don’t underestimate the con, even though it’s only a single con. Let’s say you have a 356k link (yeah – they still exist!). And let’s say you have a CCM “location” configured that allows half of the available bandwidth (180k) for voice calls. With G729, that gets you 6 calls (roughly 30k per call). But if you are using G711 (roughly 80k per call) for voicemail between that site and Exchange UM, and you have 2 people checking their Voicemail at once: no more calls will be allowed between that site and anywhere in the network. So it is a pretty big deal.
2 – Use G729 for calls, but transcode calls to Exchange UM
In many Cisco IPT deployments with several remote locations, calls are often made using the lower-bandwidth G729 codec. As I mentioned earlier: Exchange UM will not be able to handle these calls; they must be first transcoded from G729 to G711. To add to your misery, Cisco Call Manager servers are not capable of transcoding; only hardware-based resources can transcode. DSP (Digital Signal Processing) modules in a Cisco router are the most common transcoding resources.
This will work well – but you will be limited by the amount of DSP resources you have to transcode the calls. If you have enough resources to transcode 12 calls, then you can only have 12 simultaneous calls from CCM into Exchange UM.
To get this to work, you need to make sure you have plenty of DSPs to as transcoding resources. Then you assign those to your SIP Trunk’s Media Resource Group. Once you’ve done this, the call flow looks like this:
- Call comes in to the remote site
- Gateway strips the number down to the CCM extension
- CCM sets up a SIP call between Exchange UM and CCM
- Voice traffic passes from the Remote gateway to the gateway in the datacenter, which transcodes from G729 to G711 for the leg to the Exchange UM server
This assumes that you have a Cisco gateway with spare DSPs in your datacenter. If you don’t have extra DSPs, you are going to need to buy additional modules to use for transcoding.
Pro:
- You can use your low-bandwidth codec everywhere.
Con:
- You may need to buy additional DSP resources to allow for session transcoding.
(Non) Option 3 – use DSP resources in remote site routers
You may be thinking to yourself: “ha! There’s another option you’ve overlooked; use more DSPs in your remote site routers”. Well, I’ve tried this one too. And it kinda sorta works. You can get more calls through to Exchange UM if you allocate DSP transcoding resources from remote site routers. I tried it and it works. But here’s the issue. Let’s say you have 10 remote sites and you allocate 12 DSPs from each site. You have to stick them all in the same media resource group. Meaning you don’t have any way to assign “Chicago DSPs” to just Chicago VM calls. You could end up with a call coming in the Chicago gateway & routing to voicemail, but getting transcoded by the Detroit router. That means the call goes from Chicago to Detroit then down to your datacenter and into Exchange.
In short: you generally want to keep your DSPs close to your Exchange UM servers to avoid burning bandwidth between sites. So this is an option, but it’s highly not recommended.
Real life experience
With the 2000 user Unity to Exchange UM migration I mentioned at the beginning, we saw this happen. They had a single Cisco voice gateway in their main datacenter where Exchange was located. It only had enough transcoding resources to allow about 20 phone calls through to Exchange UM. We ended up stuffing a bunch of spare DSP modules they had into another router in the data center. We assigned all those DSP transcoding resources to the Media Resource Group for our Exchange UM SIP trunk. This increased capacity to over 100 calls, which is what we wanted.
The 20 calls would have most likely satisfy the day-to-day requirements of the busy organization. However, it did not account for periods of high usage. For example: a company-wide voicemail being accessed and retrieved by many users at once would have likely overloaded the router’s capacity. To ensure the system had all required capacity, we added additional transcoding resources to convert an additional 96 calls from G729 to G711.
It is worth noting that the reason for the diminished capacity was solely due to the widespread use of G729 in the environment combined with Exchange 2010’s lack of native support for G729. If G711 were used throughout the network, no transcoding resources would be required. In that case, capacity would have been limited only by the Exchange UM servers themselves: approximately 200 calls.
