PDF(180.3 KB) View with Adobe Reader on a variety of devices
ePub(135.1 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(197.3 KB) View on Kindle device or Kindle app on multiple devices
Updated:June 28, 2016
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Today, the telecommunications industry is in the process of making the transition from long establishing switching and transport techonologies to IP-based transport and edge devices. The IP communication revolution has started to create a tremendous commercial impact in small and medium businesses. These small and medium businesses are realizing that the use of IP is very efficient because IP can use Voice, Video, and Data capabilities over a single network, instead of using three separate special-purpose networks. Figure 1 shows an IP telephony deployment trending towards IP trunking.
Figure 1 - IP Telephony System
IP PBXs are starting to predominate in the business of the Voice technology, and the TDM PBXs are no longer the primary source as the crossover going between two Voice networks. The usage of the TDM PBXs has decreased in the last couple of years, and the use of the IP PBX is becoming a good investment in IP LANs and WANs. In order to connect to the PSTN, PBXs need some sort of trunking such as TDM (T1/E1) or analog lines. IP PBXs can access the PSTN using these types of trunks, but need a media gateway that converts the IP voice traffic to traditional PSTN, which sometimes can result in successive translation from IP domain to TDM domain. These successive translations increase the maintenance costs of the gateways, increases latency, and reduces voice quality.
In order to avoid these problems, the IP PBXs use protocols for session initiation and management, the most prominent of which is Session Initiation Protocol (SIP). This document provides a description on SIP trunking and Cisco CallManager Express (CME), and a configuration to implement an IP-based telephony system with CME using SIP trunking for inbound and outbound calls.
Ensure that you meet these requirements before you attempt this configuration:
CME release 4.1 is installed
An image of Cisco IOS® Software Release 12.4(11)XJ or IOS 12.4(6th)T is on the router
An NM-CUE module is installed with CUE release 2.3.4
The information in this document is based on these software and hardware versions:
Cisco 3825 Router on Cisco IOS Software Release 12.4(11)XJ
Cisco Catalyst 3550 Switch on Cisco IOS Software Release 12.4
Cisco IP 7960 Phone
Cisco CallManager Express 4.1
Cisco Unity Express 2.3.4
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
SIP is an ASCII based, application-layer control protocol that can be used to establish, maintain, and terminate calls between two or more endpoints. SIP has rapidly emerged as the standard protocol used in IP communications, because it is a multimedia protocol that can be used for video sessions and instant messaging in addition to voice. Also, SIP can handle conference sessions and broadcasts, as well as one-to-one sessions. SIP has great potential in transforming and developing the way people communicate. For this reason, Cisco has and continues to play an important role in taking a leadership to create new technologies that make SIP and its applications the standard of IP communications.
SIP trunks are similar to a phone line, except that SIP trunks use the IP network, not the PSTN. In addition, SIP trunks permit the convergence of voice and data onto common all-IP connections. In order to access the IP network using a SIP trunk, it is necessary that configurations be made on the service provider, as well as on the customer side. Customers need to set and configure CME, which is the PBX that will interpret the SIP signal adequately and pass traffic successfully. The service provider needs to configure an SIP Proxy Server. However, SIP trunks are more complicated to establish than regular PSTN trunks. The reason is that a customer faces challenges in handling different interpretation and implementations of SIP by equipment vendors, delivering security, managing quality of service (QoS), enabling Network Address Translation (NAT) and firewall traversal, and ensuring carrier-grade reliability and continuity of service.
These points describe why SIP trunks are becoming so apparent in small and medium businesses:
Quick and Easy Deployment
Improved Utilization of Network Capacity
Potential for Consolidating and Lowering Telephony Costs
Economical Direct Inward Dial (DID)
CME SIP Trunk Support
Cisco CME is an IP telephony solution that is integrated directly into Cisco IOS software. CME permits small and medium businesses to deploy voice, data, and video on a single platform. An IP telephony network is simple to set because CME runs on a single router, which delivers a PBX functionality for businesses. Therefore, by using CME, small and medium businesses can deliver IP telephony and data routing using a single converged solution with minimal costs.
DTMF Relay for SIP Trunks
CME started to support SIP trunking when CME 3.1 was released. However, some problems existed when an SIP phone called an SCCP phone or tried to access voicemail. The problem is that SCCP phones connected to CME require the use of out-of-band DTMF relay to transport DTMF (digits) across VoIP connections, and SIP phones use in-band transports. A DTMF distortion existed between the two devices. When CME 3.2 was released, support was added to the DTMF relay. DTMF digits from SCCP could be converted to in-band DTMF relay mechanism through RFC2833 or Notify methods.
CME currently supports this list of DTMF internetworking for SIP to SIP calls:
Notify <---> Notify since 12.4(4)T
RFC2833 <---> Notify since 12.4(4)T
Notify <---> RFC2833 since 12.4(4)T
Inband G711 <---> since 12.4(11)T [Requires Transcoder]
CME currently supports this DTMF internetworking for SIP to SCCP calls:
SCCP out-of-band - SIP Notify / RFC2833 since 12.4(4)T
Codec Support and Transcoding
Another important aspect to consider when you set up an SIP trunk is the codecs supported. Codecs represent the pulse-code modulation sample for signals in voice frequencies. SIP trunks support these codecs: G.711 and G.729. However, for different features such as Cisco Unity Express (CUE) and Music on Hold (MOH), only codec G.711 is supported. This means that voice calls that use SIP trunks using codec G.729 cannot access CUE, unless a transcoder exists to permit the compression and decompression of voice streams to match the CUE capabilities. MOH can also use codec G.729 to save bandwidth, but the codec does not provide adequate quality MOH streams. This is due to the fact that G.729 is optimized for speech. Therefore, you must force MOH to use G.711.
When a call comes in on a SIP trunk and gets forwarded (CFNA / CFB / CFA), then the default behavior is for the CME to send the 302 "Moved Temporarily" SIP message to the Service Provider (SP) proxy. The user portion of the Contact Header in the 302 message might need to be translated to reflect a DID that the SP proxy can route to. The host portion of the Contact Header in the 302 message should be modified to reflect the Address of Record (AOR) using the host-registrar CLI under sip-ua and the b2bua CLI under the VoIP dial peer going to the CUE.
Some SIP proxies might not support this. If so, then you need to add this:
This method will allow hairpinning of the 302 SIP messages for call forwards on the CME. The above is also required if there are certain extensions that have no DID mapping as the SP proxy might not know how to route such calls. If you disable the 3xx response, the calling-number initiator can be used to preserve the caller ID of the original calling party.
When a call comes in on an SIP trunk to an SCCP Phone or CUE AutoAttendant (AA) and is transferred, the CME by default will send a SIP REFER message to the SP proxy. Most SP Proxy Servers do not support the REFER method. This needs to be configured in order to force the CME to hairpin the call:
Figure 3 shows the behavior of the CME system with the REFER method disabled.
Figure 3 - Transfer with REFER disabled
If REFER is supported on the SIP proxy, the user portion of the Refer-To and Referred-By must be translated to a DID that the SP proxy understands. The host portion of the Refer-To and Referred-By fields must be an IP address or DNS that the SP proxy can route to as well (this occurs by default on CME 4.1).
If an SCCP phone places a call from PSTN on HOLD, the CME locally changes the media. No SIP messages are sent across on the SIP trunk. Music on Hold will be played to the user across the SIP trunk based on the CME configuration.
In this section, you are presented with the information to configure the features described in this document.
This document uses this network setup:
These configuration elements provide an outline of the steps required to configure your CME with SIP trunks:
Infrastructure Elements: Interfaces, TFTP and DHCP services, NTP, etc.
Telephony-service: Enables IOS "PBX" call control on the CME platform including elements of phone management
Ephones an Ephones-dns: Define IP phones and their telephone numbers