There are several ways to configure a gateway for use in Cisco’s Unified Communications Manager. MGCP, H.323, SIP. Each has it’s own benefits and drawbacks.
Here are some of the big issues for me :
- Call Preservation – When network connectivity to the system goes down, it would be nice if all active calls didn’t drop
- Centralized Management – Being able to configure everything from one place and not have to duplicate settings on a per device basis
- Distributed Call Management – Calls routed optimally while maintaining a reasonably small configuration that can scale well
I know there are other issues here, but these were the important ones for me. MGCP provides the centralized management, but not the other features. Most importantly Call Preservation. This is why I rarely use MGCP for VoIP deployments.
To configure a SIP gateway for a Cisco Unified Communications Manager there are two steps.
- Configure the Gateway
- Configure the Communications Manager
Configuring the Gateway
This part is fairly easy. Here I’m assuming that you already have your PRI configured.
voice rtp send-recv
!
dial-peer voice 1000000 voip
incoming called-number .
dtmf-relay rtp-nte
!
dial-peer voice 9000100 pots
destination-pattern [2-9]......
no digit-strip
port 0/0/0:23
dial-peer voice 9000200 pots
destination-pattern 1[2-9]..[2-9]......
no digit-strip
port 0/0/0:23
You could have more dial-peers, but this is enough to get started.
Configuring the Communications Manager
Go to the Device -> Trunk menu.
Click on the Add New button
Select SIP Trunk as the type and click the Next button.
There are a few fields here that need to have information in them:
- Device Name – This can be anything, but should be descriptive
- Device Pool – Appropriate device pool for your deployment
- Location – Again use the appropriate location in your system
- SIP Trunk Security Profile – Default should be fine unless you have some special requirements
- SIP Profile – Again, Default should be fine for most users.
There are two other settings here to be aware of:
Media Termination Point Required
This should be unchecked. While some SIP gateways may require this, it’s my experience that it causes more headaches than anything else. It also causes all outbound calls to consume an MTP resource or Transcoder in some configurations.
DTMF Signaling Method
You might be wondering why DTMF signaling makes any difference… here’s why: On a Cisco Unified Communications Manager even if you have MTP requirements disabled, if the DTMF relay types do not match (or are not compatible) the trunk will dynamically allocate an MTP resource which will act as a DTMF translator converting one method to another. For maximum compatibility use : RFC 2833. You’ll see that the gateway configuration above uses RFC 2833 for it’s DTMF relay with the following command : dtmf-relay rtp-nte
The Problem with this is…
Now that our system is configured, we can make calls out. You’ll find that everything seems to work fine. There are a few cases however where it will not. An example of this is when the telco sends an announcement message prior to connecting the call. A few common uses of this method are prompts for account codes, incorrect dialing messages, etc.
SIP Trunks on Cisco’s Communications Managers create ringback locally and wait for the ISDN Connect message before actually connecting the IP media stream. So if you receive a message from your telco before their switch sends you the Connect message, you will only continue to hear ringback on the phone until the telco terminates the connection.
An easy way to fix this is to require that all calls use a Media Termination Point. I pointed out above that I don’t recommend this. It drives cost up, makes troubleshooting more difficult and can cause issues with faxing.
The better way to fix this is simple, but I’m going to go into a little background explaining the why.
Whenever your telco sends an announcement message, they will flag the Progress Indicator of the Q.931 message with an 8 (Usually.  Some telcos may do this a little differently) Your Cisco gateway will take this indicator and generate a SIP 183 Session Progress message which contains an SDP with connection parameters. This tells the Communications Manager that there is possibly some in-band data that the user may be interested in. The problem is that the Communications Manager will ignore this and continue to play the ringback tone instead of letting you hear the message.
To allow the Communications Manager to react to the 183 messages go into System -> Service Parameters, select your server then select the CallManager service. Scroll down and find the Clusterwide Parameters (Device – SIP) section. Find the SIP Rel1XX Enabled parameter and set it to True (Or use one of the Send PRACK options in 7.x). This parameter tells the Communications Manager to send ACK packets back in response to any 100 series SIP message received. The IOS command above, voice rtp send-recv, is used to connect the media path in both directions instead of just a single direction.
That’s it! Press the Save button and you’re done. Now when the system is signalled from the ISDN network it will properly cut through the media path and your users will hear any possible announcement messages.