Note: This article is pulled from:

Source: http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_configuration_example09186a00808ff666.shtml
All credit goes to Cisco.com
(Cisco keep moving the pages here and there so, I thot to keep a copy of it for benifit of everyeone.)

Introduction

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.

Prerequisites

Requirements

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

Components Used

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.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

SIP Protocol

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 an 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)
• Business Continuity

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 tranports. 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.

Call Forward

When a call comes in on an 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:

Router(config)#voice service voip

Router(conf-voi-serv)#no supplementary-service sip moved-temporarily

Figure 2 shows the behavior of the CME system when the 302 message is disabled.

Figure 2 – Call Forward Busy (CFB) flow with 302 message disabled

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.

Call Transfer

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:

Router(config)#voice service voip

Router(conf-voi-serv)#no supplementary-service sip refer

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).

Call Hold

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.

Configure

In this section, you are presented with the information to configure the features described in this document.

Note: Use the Command Lookup Tool ( registered customers only) to obtain more information on the commands used in this section.

Network Diagram

This document uses this network setup:

Configurations

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
• Dial Plan: Dial-peers, extensions, voice-translation rules
• IOS SIP Configuration: Enables SIP, phone registration with SIP proxy, call routing over trunks, etc
• Voicemail Support: Cisco Unity Express
• Switch Catalyst Configuration: IP address, Interfaces, etc

This is the complete configuration needed to deploy a CME system with SIP trunks:

!
AUSNML-3825-01#show run
Building configuration...

Current configuration : 8634 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname AUSNML-3825-01
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$vBU1$MCMG1rXM5ejME8Wap6W0H1
!
no aaa new-model
clock timezone central -8
clock summer-time central recurring
ip cef
!

!--- DHCP Configuration ---

ip dhcp pool Voice
   network 172.22.100.0 255.255.255.0
   option 150 ip 172.22.1.107
   default-router 172.22.100.1
!
ip dhcp pool Data
   network 172.22.101.0 255.255.255.0
   option 150 ip 172.22.1.107
   default-router 172.22.101.1
!
!
ip domain name cisco.com
ip name-server 205.152.0.20
multilink bundle-name authenticated
!
voice-card 0
 no dspfarm
!
!
!
!

!--- Voice Class and Service VoIP Configuration ---

voice service voip
 allow-connections sip to sip
 no supplementary-service sip moved-temporarily

!---Disable 302 sending

 no supplementary-service sip refer

!---Disable REFER sending

 sip
  registrar server expires max 3600 min 3600
  localhost dns:domain.test.com
!
!
voice class codec 1
 codec preference 1 g711ulaw
!
!
!
!
!
!
!
!
!
!
!

!--- Voice Translation Rules ---

voice translation-rule 1
 rule 1 /5123781291/ /601/

!--- An inbound rule for AA pilot "601

 rule 2 /5123781290/ /600/

!--- An inbound rule for the voicemail pilot "600"

!
voice translation-rule 2
 rule 1 /^911$/ /911/

!--- An outbound rule to allow "911"

 rule 2 /^9(.*)/ /\1/

!--- An outbound rule to strip "9" from PSTN calls

!
voice translation-rule 3
 rule 1 /^.*/ /5123781291/

!--- An outbound rule to change calling-number CLID to a
!--- "main" number

!
voice translation-rule 4
 rule 1 /^9(.......)$/ /512\1/

!--- An outbound rule to add areacode for local calls

 rule 2 /600/ /5123788000/

!--- An outbound rule to present the voicemail pilot extension as DID

 rule 3 /601/ /5123788001/

!--- An outbound rule to present the AA pilot extension as DID

 rule 4 /^2(..)$/ /51237812\1/

!--- An outbound rule to support transfers and call-forwards

 rule 5 /^9(.*)/ /\1/

!--- An outbound rule to strip "9" from "9+" transfers and call-forwards

!
!
voice translation-profile CUE_Voicemail/AutoAttendant

!--- Applied to the inbound dial-peers for CUE

 translate called 1
!
voice translation-profile PSTN_CallForwarding

!--- Applied to CUE dial-peers

 translate redirect-target 4
 translate redirect-called 4
!
voice translation-profile PSTN_Outgoing

!--- Applied to all outbound dial-peers

 translate calling 3
 translate called 2
 translate redirect-target 4
 translate redirect-called 4
!
!
!
!
!
!
!
vlan internal allocation policy ascending
!
!
!
!

!--- Internet Connection Configuration ---

interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
 media-type rj45
 no keepalive
!
interface GigabitEthernet0/0.1
 encapsulation dot1Q 1 native
 ip address 172.22.1.71 255.255.255.0
!
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 172.22.101.1 255.255.255.0
!
interface GigabitEthernet0/0.100
 encapsulation dot1Q 100
 ip address 172.22.100.1 255.255.255.0
!
interface GigabitEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
 no keepalive
!
interface Service-Engine1/0
 ip unnumbered GigabitEthernet0/0.1
 service-module ip address 172.22.1.253 255.255.255.0
 service-module ip default-gateway 172.22.1.71
!
ip route 0.0.0.0 0.0.0.0 172.22.1.1
ip route 172.22.1.253 255.255.255.255 Service-Engine1/0
!
!
ip http server
no ip http secure-server
!
!
!

!--- TFTP Server Configuration  ---

tftp-server flash:P0030702T023.bin
tftp-server flash:P0030702T023.loads
tftp-server flash:P0030702T023.sb2
tftp-server flash:P0030702T023.sbn
!
control-plane
!
!
!
!
!
!
!

!--- SIP Trunk Configuration ---

dial-peer voice 1 voip
 description **Incoming Call from SIP Trunk**
 translation-profile incoming CUE_Voicemail/AutoAttendant
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 incoming called-number .%
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 2 voip
 description **Outgoing Call to SIP Trunk**
 translation-profile outgoing PSTN_Outgoing
 destination-pattern 9........
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 3 voip
 description **Outgoing Call to SIP Trunk**
 translation-profile outgoing PSTN_Outgoing
 destination-pattern 9[2-9]..[2-9]......
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 4 voip
 description **Outgoing Call to SIP Trunk**
 translation-profile outgoing PSTN_Outgoing
 destination-pattern 9[0-1][2-9]..[2-9]......
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 5 voip
 description **911 Outgoing Call to SIP Trunk**
 translation-profile outgoing PSTN_Outgoing
 destination-pattern 911
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 6 voip
 description **Emergency Outgoing Call to SIP Trunk**
 translation-profile outgoing PSTN_Outgoing
 destination-pattern 9911
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 7 voip
 description **911/411 Outgoing Call to SIP Trunk**
 translation-profile outgoing PSTN_Outgoing
 destination-pattern 9[2-9]11
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 8 voip
 description **International Outgoing Call to SIP Trunk**
 translation-profile outgoing PSTN_Outgoing
 destination-pattern 9011T
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!
dial-peer voice 9 voip
 description **Star Code to SIP Trunk**
 destination-pattern *..
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte
 no vad
!
!
!

!--- Voicemail Configuration ---

dial-peer voice 10 voip
 description **CUE Voicemail**
 translation-profile outgoing PSTN_CallForwarding
 destination-pattern 600
 b2bua

!--- Used by CME to send its IP address to SP proxy instead of CUE

 session protocol sipv2
 session target ipv4:172.22.1.155
 dtmf-relay sip-notify

!--- This can also be RFC2833 going to CUE

 codec g711ulaw

!--- CUE only supports G711ulaw as the codec

 no vad

!--- With VAD enabled, messages left on CUE could be blank or poor quality

!
!
!
dial-peer voice 11 voip
 description **CUE Auto Attendant**
 translation-profile outgoing PSTN_CallForwarding
 destination-pattern 601
 b2bua
 session protocol sipv2
 session target ipv4:172.22.1.155
 dtmf-relay sip-notify
 codec g711ulaw
 no vad
!
!

!--- SIP UA Configuration ---

sip-ua
 authentication username 5123781000 password 075A701E1D5E415447425B
 no remote-party-id
 retry invite 2
 retry register 10
 retry options 0
 timers connect 100
 registrar dns:domain.test.com expires 3600
 sip-server dns:domain.test.com
  host-registrar
!
!

!--- CME Telephony Service Configuration ---

telephony-service
 no auto-reg-ephone
 load 7960-7940 P0030702T023
 max-ephones 168
 max-dn 500
 ip source-address 172.22.1.107 port 2000
 calling-number initiator

!--- Preserves the caller-id of a call when transferred or forwarded

 dialplan-pattern 1 51237812.. extension-length 3 extension-pattern 2.. no-reg
 voicemail 600
 max-conferences 12 gain -6
 call-forward pattern .T
 call-forward system redirecting-expanded

!--- Enables translation rule features for call-forwarding

 moh music-on-hold.au
 transfer-system full-consult dss
 transfer-pattern 9.T
 secondary-dialtone 9
 create cnf-files version-stamp Jan 01 2002 00:00:00
!
!

!--- Ephone and Ephone-dn Configuration ---

ephone-dn  11  dual-line
 number 201 secondary 5123781201 no-reg both

!---"no-reg both" means do not try to register either extension with SP SIP Proxy

 name John Smith
 call-forward busy 600
 call-forward noan 600 timeout 15
!
!
ephone-dn  12  dual-line
 number 202 secondary 5123781202 no-reg both
 name Enrique Zurita
 call-forward busy 600
 call-forward noan 600 timeout 15
!
!
ephone-dn  13
 number 5123788000
 description **DID Number for Voicemail**
!
!
ephone-dn  14
 number 5123788001
 description **DID Number for Auto Attendant*
!
!
ephone-dn  15
 number 8000... no-reg primary
 mwi on
!
!
ephone-dn  16
 number 8001... no-reg primary
 mwi off
!
!
ephone  1
 mac-address 0008.A371.28E9
 type 7960
 button  1:11
!
!
!
ephone  2
 mac-address 0008.A346.5C7F
 type 7960
 button  1:12
!
!
!
!
line con 0
 stopbits 1
line aux 0
 stopbits 1
line 66
 no activation-character
 no exec
 transport preferred none
 transport input all
 transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
line vty 0 4
 password ut69coe
 login
!
scheduler allocate 20000 1000
ntp server 172.22.1.107
!
end

se-172-22-1-253#show run

Generating configuration:

clock timezone America/Chicago

hostname se-172-22-1-253

ip domain-name localdomain

groupname Administrators create
groupname Broadcasters create


!--- Users ---

username Enrique create
username John create
username Enrique phonenumberE164 "5123781202"
username John phonenumberE164 "5123781201"
username Enrique phonenumber "202"
username John phonenumber "201"


!--- AutoAttendant ---

ccn application autoattendant
 description "**AutoAttendant**"
 enabled
 maxsessions 4
 script "aa.aef"
 parameter "busOpenPrompt" "AABusinessOpen.wav"
 parameter "operExtn" "601"
 parameter "welcomePrompt" "AAWelcome.wav"
 parameter "disconnectAfterMenu" "false"
 parameter "busClosedPrompt" "AABusinessClosed.wav"
 parameter "allowExternalTransfers" "false"
 parameter "holidayPrompt" "AAHolidayPrompt.wav"
 parameter "businessSchedule" "systemschedule"
 parameter "MaxRetry" "3"
 end application


!--- MWI ---

ccn application ciscomwiapplication
 description "ciscomwiapplication"
 enabled
 maxsessions 8
 script "setmwi.aef"
 parameter "CallControlGroupID" "0"
 parameter "strMWI_OFF_DN" "8001"
 parameter "strMWI_ON_DN" "8000"
 end application


!--- Voicemail ---

ccn application voicemail
 description "**Voicemail**"
 enabled
 maxsessions 4
 script "voicebrowser.aef"
 parameter "uri" "http://localhost/voicemail/vxmlscripts/login.vxml"
 parameter "logoutUri" "http://localhost/voicemail/vxmlscripts/mbxLogout.jsp"
 end application


!--- SIP ---

ccn subsystem sip
 gateway address "172.22.100.1"

!--- Must match the "ip source-address" in telephony-service

 dtmf-relay sip-notify
 mwi sip outcall

!--- Subscribe / Notify and Unsolicited Notify have not been tested

 transfer-mode blind bye-also

!--- Testing with REFER method on CUE has caused certain call flows to break

 end subsystem


!--- Trigger Phones ---

ccn trigger sip phonenumber 600
 application "voicemail"
 enabled
 maxsessions 4
 end trigger

ccn trigger sip phonenumber 601
 application "autoattendant"
 enabled
 maxsessions 4
 end trigger

service phone-authentication
 end phone-authentication

service voiceview
 enable
 end voiceview


!--- Voicemail Mailboxes ---

voicemail default mailboxsize 21120
voicemail broadcast recording time 300

voicemail mailbox owner "Enrique" size 300
 description "**Enrique_Mailbox**"
 expiration time 10
 messagesize 120
 end mailbox

voicemail mailbox owner "John" size 300
 description "**John'sMailbox**"
 expiration time 10
 messagesize 120
 end mailbox

end

!--- Interface Connected to CME/CUE Router ---

interface FastEthernet0/2
 description Trunk to 3825
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no ip address
 duplex full
 speed 100


!--- Interfaces Connected to the IP Phones ---

interface FastEthernet0/7
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 20

!--- Data Traffic ---

 switchport mode trunk
 switchport voice vlan 100

!--- Voice Traffic ---

 no ip address
 spanning-tree portfast

interface FastEthernet0/8
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 20
 switchport mode trunk
 switchport voice vlan 100
 no ip address
 spanning-tree portfast


!--- IP Address ---

interface Vlan1
 ip address 172.22.1.194 255.255.255.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.22.1.1
ip http server

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

This section provides information you can use to troubleshoot your configuration.

The Output Interpreter Tool ( registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.

Note: Refer to Important Information on Debug Commands before you use debug commands.

Troubleshooting Registration

Troubleshooting the SIP trunk on CME involves the same commands you use for IOS SIP GW troubleshooting and CME troubleshooting. Use these commands in order to check if your DN is registered:

• show sip-ua register status—Use this command to display the status of E.164 numbers that a SIP gateway has registered with an external primary SIP registrar.
• debug ccsip message—Enables all SIP SPI message tracing, such as those that are exchanged between the SIP user-agent client (UAC) and the access server.

Troubleshooting Call Setup

Commands for troubleshooting calls over SIP trunks are essentially the same as you use for regular SIP GW and CME troubleshooting.

Show commands:

• show ephone registered—Verifies ephone registration.
• show voip rtp connection—Displays information about RTP named-event packets, such as caller-ID number, IP address, and ports for both the local and remote endpoints.
• show sip-ua call—Displays active UAC and user agent server (UAS) information on SIP calls.
• show call active voice brief—Displays active call information for voice calls or fax transmissions in progress.

Debug commands:

• debug ccsip message—Enables all SIP SPI message tracing, such as those that are exchanged between the SIP UAC and the access server.
• debug voip ccapi inout—Traces the execution path through the call control API.
• debug voice translation—Checks the functionality of a translation rule.
• debug ephone detail mac-address <mac of phone> —Sets detail debugging for the Cisco IP phone.
• debug voip rtp session named-events—Enables debugging for Real-Time Transport Protocol (RTP) named events packets.
• debug sccp message—Displays the sequence of the SCCP messages.

Push Bhatkoti

CCIE voice#21569

Introduction

This document provides a configuration guide that can be used in order to help secure a Cisco Communications Manager Express (CME) system and mitigate the threat of toll fraud. CME is Cisco’s router-based call control solution that provides a smart, simple and secure solution for organizations that want to implement Unified Communications. It is highly recommend that you implement the security measures described in this document in order to provide additional levels of security control and reduce the possibility of toll fraud.

The objective of this document is to educate you on the various security tools available on Cisco Voice Gateways and CME. These tools can be implemented on a CME system in order to help mitigate the threat of toll fraud by both internal and external parties.

This document provides instructions on how to configure a CME system with various toll security and feature restriction tools. The document also outlines why certain security tools are used in certain deployments.

The overall inherent flexibility of Cisco’s ISR platforms allows you to deploy CME in many different types of deployments. Thus it can be required to use a combination of the features described in this document to help lock down the CME. This document serves as a guideline for how to apply security tools on CME and in no way guarantees that toll-fraud or abuse by both internal and external parties will not occur.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Cisco Unified Communications Manager Express

Components Used

The information in this document is based on the Cisco Unified Communications Manager Express 4.3 and CME 7.0.

Note: Cisco Unified CME 7.0 includes the same features as Cisco Unified CME 4.3, which is renumbered to 7.0 to align with Cisco Unified Communications versions.

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.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Overview

This document covers the most common security tools that can be used on a CME system to help mitigate the threat of toll fraud. The CME security tools referenced in this document include toll restriction tools and feature restriction tools.

Toll Restriction Tools

• Direct-inward-dial
• After-hours toll restriction
• Class of Restriction
• Access-list to restrict H323/SIP trunk access

Feature Restriction Tools

• Transfer-pattern
• Transfer-pattern blocked
• Transfer max-length
• Call-forward max-length
• No forward local-calls
• No auto-reg-ephone

Cisco Unity Express Restriction Tools

• Secure Cisco Unity Express PSTN access
• Message notification restriction

Call Logging

• Call logging to capture call detail records (CDRs)

Internal vs. External Threats

This document discusses threats from both internal and external parties. Internal parties include IP phone users that reside on a CME system. External parties include users on foreign systems that can try to use the host CME to make fraudulent calls and have the calls charged back to your CME system.

Toll Restriction Tools

Direct-inward-dial

Abstract

Direct-inward-dial (DID) is used on Cisco voice gateways in order to allow the gateway to process an inbound call after it receives digits from the PBX or CO switch. When DID is enabled, the Cisco gateway does not present a secondary dial tone to the caller and does not wait to collect additional digits from the caller. It forwards the call directly to the destination that matches the inbound Dialed Number Identification Service (DNIS). This is called one-stage dialing.

Note: This is an external threat.

Problem Statement

If direct-inward-dial is NOT configured on a Cisco Gateway or CME, whenever a call comes in from the CO or PBX to the Cisco Gateway, the caller hears a secondary dial-tone. This is called two-stage dialing. Once the PSTN callers hears the secondary dial-tone, they are able to enter digits to reach any internal extension or if they know the PSTN access code, they can dial long-distance or international numbers. This presents a problem because the PSTN caller can use the CME system to place outbound long-distance or international calls and the company gets charged for the calls.

Example 1

At Site 1, the CME is connected to the PSTN through a T1 PRI trunk. The PSTN provider provides the 40855512.. DID range for CME Site 1. Thus all PSTN calls destined for 4085551200 – 4085551299 are routed inbound to the CME. If you do not configure direct-inward-dial on the system, an inbound PSTN caller hears a secondary a dial-tone and must manually dial the internal extension. The bigger problem is that if the caller is an abuser and knows the PSTN access code on the system, commonly 9, they can dial 9 then any destination-number they want to reach.

Solution 1

In order to mitigate this threat, you must configure direct-inward-dial. This causes the Cisco gateway to forward the inbound call directly to the destination that matches the inbound DNIS.

Sample Configuration

dial-peer voice 1 pots
port 1/0:23
incoming called-number .
direct-inward-dial

For DID to work correctly, make sure the inbound call matches the correct POTS dial-peer where the direct-inward-dial command is configured. In this example, the T1 PRI is connected to port 1/0:23. In order to match the correct inbound dial peer, issue the incoming called-number dial peer command under the DID POTS dial peer.

Example 2

At Site 1, the CME is connected to the PSTN through a T1 PRI trunk. The PSTN provider gives the 40855512.. and 40855513.. DID ranges for CME Site 1. Thus all PSTN calls destined for 4085551200 – 4085551299 and 4085551300 – 4085551399 are routed inbound to the CME.

Incorrect Configuration:

If you configure an inbound dial-peer, as in the sample configuration in this section, the possibility for toll fraud still occurs. The problem with this inbound dial-peer is that it only matches inbound calls to 40852512.. and then applies the DID service. If a PSTN call comes into 40852513.., the inbound pots dial-peer does not match and thus the DID service is not applied. If an inbound dial-peer with DID is not matched, then the default dial-peer 0 is used. DID is disabled by default on dial-peer 0.

Sample Configuration

dial-peer voice 1 pots
incoming called-number 40855512..
direct-inward-dial

Correct Configuration

The correct way to configure DID service on an inbound dial-peer is shown in this example:

Sample Configuration

dial-peer voice 1 pots
port 1/0:23
incoming called-number .
direct-inward-dial

Refer to DID Configuration for POTS Dial Peers for more information on DID for digital T1/E1 voice ports.

Note: The use of DID is not needed when Private-Line Automatic Ringdown (PLAR) is used on a voice-port or a service script such as Auto-Attendant (AA) is used on the inbound dial-peer.

Sample Configuration—PLAR

voice-port 1/0
connection-plar 1001

Sample Configuration—Service Script

dial-peer voice 1 pots
service AA
port 1/0:23

After-hours Toll Restrictions

Abstract

After-hours Toll Restriction is a new security tool available in CME 4.3/7.0 that allows you to configure toll restriction policies based on time and date. You can configure policies so that users are not allowed to make calls to predefined numbers during certain hours of the day or all the time. If the 7×24 after-hours call blocking policy is configured, it also restricts the set of numbers that can be entered by an inside user to set call-forward all.

Note: This is an internal threat.

Example 1

This example defines several patterns of digits for which outbound calls are blocked. Patterns 1 and 2, which block calls to external numbers that begin with “1″ and “011,” are blocked on Monday through Friday before 7 a.m. and after 7 p.m., on Saturday before 7 a.m. and after 1 p.m., and all day Sunday. Pattern 3 blocks calls to 900 numbers 7 days a week, 24 hours a day.

Sample Configuration

 telephony-service
 after-hours block pattern 1 91
 after-hours block pattern 2 9011
 after-hours block pattern 3 91900 7-24
 after-hours day mon 19:00 07:00
 after-hours day tue 19:00 07:00
 after-hours day wed 19:00 07:00
 after-hours day thu 19:00 07:00
 after-hours day fri 19:00 07:00
 after-hours day sat 13:00 07:00
 after-hours day sun 12:00 12:00

Refer to Configuring Call Blocking for more information on toll restriction.

Class of Restriction

Abstract

If you want granular control when you configure toll restriction, you must use Class of Restriction (COR). Refer to Class of Restriction: Example for more information.

H.323 / SIP Trunks toll fraud restrictions

Abstract

In cases where a CME system is connected over a WAN to other CME devices through a SIP or H.323 trunk, you can restrict SIP/H.323 trunk access to the CME in order to prevent abusers from using your system to illegally relay calls to the PSTN.

Note: This is an external threat.

Example 1

In this example, the CME 1 has PSTN connectivity. CME 2 is connected over the WAN to CME 1 through a H.323 trunk. In order to secure the CME 1, you can configure an access-list and apply it inbound on the WAN interface and thus only allow IP traffic from CME 2. This prevents the Rogue IP PBX from sending VOIP calls through CME 1 to the PSTN.

Solution

Do not allow the WAN interface on CME 1 to accept traffic from rogue devices that it does not recognize. Note that there is an implicit DENY all at the end of an access-list. If there are more devices from which you want to allow inbound IP traffic, be sure to add the IP address of the device to the access-list.

Sample Configuration—CME 1

interface serial 0/0
  ip access-group 100 in
!
access-list 100 permit ip 10.1.1.2 255.255.255.255 any

Example 2

In this example, the CME 1 is connected to the SIP provider for PSTN connectivity with the sample configuration provided at Cisco CallManager Express (CME) SIP Trunking Configuration Example.

Since CME 1 is on the public internet, it is possible that toll fraud can occur if a rogue user scans public IP addresses for well known ports for H.323 (TCP 1720) or SIP (UDP or TCP 5060) signaling and sends SIP or H.323 messages that route calls back out of the SIP trunk to the PSTN. Most common abuses in this case are the rogue user makes multiple international calls through the SIP or H.323 trunk and causes the owner of the CME 1 to pay for these toll fraud calls – in some cases thousands of dollars.

Solution

In order to mitigate this threat, you can use multiple solutions. If any VOIP signaling (SIP or H.323) is not used over the WAN link(s) into CME 1, this must be blocked with the firewall techniques on CME 1 (Access-lists or ACLs) as much as possible.

1. Secure the WAN interface with the Cisco IOS^® firewall on CME 1:This implies that you allow only known SIP or H.323 traffic to come in on the WAN interface. All other SIP or H.323 traffic is blocked. This also requires that you know the IP addresses that the SIP VOIP SP uses for signaling on the SIP Trunk. This solution assumes that the SP is willing to provide all the IP addresses or DNS names they use in their network. Also, if DNS names are used, the configuration requires that a DNS server that can resolve these names is reachable. Also, if the SP changes any addresses on their end, the configuration needs to be updated on CME 1. Note that these lines need to be added in addition to any ACL entries already present on the WAN interface.

   Sample Configuration—CME 1

   interface serial 0/0
     ip access-group 100 in
   !
   access-list 100 permit udp host 1.1.1.254 eq 5060 any
   
   !--- 1.1.1.254 is SP SIP proxy
   
   access-list 100 permit udp host 1.1.1.254 any eq 5060
   access-list 100 permit udp any any range 16384 32767

2. Ensure calls that come in on the SIP trunk do NOT hairpin back out:This implies that the CME 1 configuration only allows SIP – SIP hairpin of calls to a specific known PSTN number range, all other calls are blocked. You must configure specific inbound dial-peers for the PSTN numbers that come in on the SIP trunk that are mapped to extensions or auto attendant(s) or voicemail on CME 1. All other calls to numbers that are not part of the CME 1 PSTN number range are blocked. Note, this does not affect call forwards / transfers to voicemail (Cisco Unity Express) and call forward all to PSTN numbers from IP phones on CME 1, because the initial call is still targeted towards an extension on CME 1.

   Sample Configuration—CME 1

   dial-peer voice 1000 voip
     description ** Incoming call to 4085551000 from SIP trunk **
     voice-class codec 1
     voice-class sip dtmf-relay force rtp-nte
     session protocol sipv2
     incoming called-number 4085551000
     dtmf-relay rtp-nte
     no vad
   !
   dial-peer voice 1001 voip
     permission term
   
     !--- Prevent hairpinning calls back over SIP Trunk.
   
     description ** Incoming call from SIP trunk **
     voice-class codec 1
     voice-class sip dtmf-relay force rtp-nte
     session protocol sipv2
     incoming called-number .T
   
     !--- Applies to all other inbound calls.
   
     dtmf-relay rtp-nte
     no vad

3. Use translation rules in order to block specific dial strings:Most toll frauds involve international call dialing. As a result, you can create a specific inbound dial-peer that matches specific dialed strings and blocks calls to them. Most CMEs use a specific access code, such as 9, to dial out and the international dialing code in the US is 011. Therefore, the most common dial string to block in the US is 9011 + any digits after that come in on the SIP trunk.

   Sample Configuration—CME 1

   voice translation-rule 1000
    rule 1 reject /^9011/
    rule 2 reject /^91900…….$/
    rule 3 reject /^91976…….$/
   !
   voice translation-profile BLOCK
   translate called 1000
   !
   dial-peer voice 1000 voip
   description ** Incoming call from SIP trunk **
   incoming called-number 9011T
   call-block translation-profile incoming BLOCK

Feature Restriction Tools

Transfer Pattern

Abstract

Transfers to all numbers except those on local SCCP IP phones are automatically blocked by default. During configuration, you can allow transfers to non local numbers. The transfer-pattern command is used in order to allow the transfer of telephony calls from Cisco SCCP IP phones to phones other than Cisco IP Phones, such as external PSTN calls or phones on another CME system. You can use the transfer-pattern in order to limit the calls to internal extensions only or perhaps limit calls to PSTN numbers in a certain area code only. These examples show how the transfer-pattern command can be used to limit calls to different numbers.

Note: This is an internal threat.

Example 1

Allow users to transfer calls out to only the 408 area code. In this example, the assumption is that the CME is configured with a dial-peer that has a destination-pattern of 9T.

Sample Configuration

telephony-service
transfer-pattern 91408

Transfer-Pattern Blocked

Abstract

In Cisco Unified CME 4.0 and later versions, you can prevent individual phones from transferring calls to numbers that are globally enabled for transfer. The transfer-pattern blocked command over-rides the transfer-pattern command and disables call transfer to any destination that needs to be reached by a POTS or VoIP dial-peer. This includes PSTN numbers, other voice gateways and Cisco Unity Express. This ensures that individual phones do not incur toll charges when calls are transferred outside the Cisco Unified CME system. Call transfer blocking can be configured for individual phones or configured as part of a template that is applied to a set of phones.

Note: This is an internal threat.

Example 1

In this sample configuration, ephone 1 is not allowed to use transfer-pattern (defined globally) to transfer calls, while ephone 2 can use the transfer-pattern defined under telephony-service to transfer calls.

Sample Configuration

ephone-template 1
transfer-pattern blocked
!
ephone 1
ephone-template 1
!
ephone 2
!

Transfer max-length

Abstract

The transfer max-length command specifies the maximum number of digits the user can dial when a call is transferred. The transfer-pattern max-length over-rides the transfer-pattern command and enforces maximum digits allowed for transfer destination. The argument specifies the number of digits allowed in a number to which a call is transferred. Range: 3 to 16. Default: 16.

Note: This is an internal threat.

Example 1

This configuration only allows phones that have this ephone-template applied to transfer to destinations that are a maximum of four digits long.

Sample Configuration

ephone-template 1
transfer max-length 4

Call Forward max-length

Abstract

In order to restrict the number of digits that can be entered with the CfwdALL soft key on an IP phone, use the call-forward max-length command in ephone-dn or ephone-dn-template configuration mode. In order to remove a restriction on the number of digits that can be entered, use the no form of this command.

Note: This is an internal threat.

Example 1

In this example, directory extension 101 is allowed to perform a call-forward to any extension that is one to four digits in length. Any call-forwards to destinations longer than four digits fail.

Sample Configuration

ephone-dn  1  dual-line
number 101
call-forward max-length 4

or

ephone-dn-template  1
call-forward max-length 4

No Forward Local Call

Abstract

When the no forward local-calls command is used in ephone-dn configuration mode, internal calls to a particular ephone-dn with no forward local-calls applied are not forwarded if the ephone-dn is busy or does not answer. If an internal caller rings this ephone-dn and the ephone-dn is busy, the caller hears a busy signal. If an internal caller rings this ephone-dn and it does not answer, the caller hears a ringback signal. The internal call is not forwarded even if call forwarding is enabled for the ephone-dn.

Note: This is an internal threat.

Example 1

In this example, extension 2222 calls extension 3675 and hears a ringback or a busy signal. If an external caller reaches extension 3675 and there is no answer, the call is forwarded to extension 4000.

Sample Configuration

ephone-dn  25
number 3675
no forward local-calls
call-forward noan 4000 timeout 30

Disable Auto-Registration on CME System

Abstract

When auto-reg-ephone is enabled underneath telephony-service on a SCCP CME system, new IP phones that are plugged into the system are auto registered and if auto assign is configured to automatically assign extension numbers, then a new IP phone is able to make calls immediately.

Note: This is an internal threat.

Example 1

In this configuration, a new CME system is configured so that you must manually add an ephone in order for the ephone to register to the CME system and use it to make IP telephony calls.

Solution

You can disable auto-reg-ephone underneath telephony-service so that new IP phones connected to a CME system do not auto register to the CME system.

Sample Configuration

telephony-service
no auto-reg-ephone

Example 2

If you use SCCP CME and plan to register Cisco SIP phones to the system, you must configure the system so that the SIP endpoints have to authenticate with a username and password. In order to do so, simply configure this:

voice register global
 mode cme
 source-address 192.168.10.1 port 5060
 authenticate register

Refer to SIP: Setting Up Cisco Unified CME for a more comprehensive configuration guide for SIP CME.

Cisco Unity Express Restriction Tools

Secure Cisco Unity Express: AA PSTN access

Abstract

When your system is configured so that inbound calls are forwarded to auto-attendant (AA) on Cisco Unity Express, it may be necessary to disable external transfer to the PSTN from Cisco Unity Express AA. This does not allow external users to dial outbound to external numbers after they reach Cisco Unity Express AA.

Note: This is an external threat.

Note: Solution

Note: Disable the allowExternalTransfers option on the Cisco Unity Express GUI.

Note: If PSTN access from the AA is required, limit the numbers or range of numbers that are considered valid by the script.

Cisco Unity Express Restriction Tables

Abstract

You can use the Cisco Unity Express restriction tables in order to restrict the destinations that can be reached during an outcall from Cisco Unity Express. The Cisco Unity Express restriction table can be used in order to prevent toll fraud and malicious use of the Cisco Unity Express system to make outbound calls. If you use the Cisco Unity Express restriction table, you can specify call patterns to wild card match. Applications that use the Cisco Unity Express restriction table include:

• Fax
• Cisco Unity Express Live Replay
• Message Notification
• Non-Subscriber Message Delivery

Note: This is an internal threat.

Solution

In order to restrict the destination patterns that can be reached by Cisco Unity Express on an outbound external call, configure the Call Pattern in the System > Restrictions Tables from the Cisco Unity Express GUI.

Call Logging

Enhanced CDR

You can configure the CME system to capture enhanced CDR and log the CDR to the router flash or an external FTP server. These records can then be used to retrace calls to see if abuse by internal or external parties has occurred.

The file accounting feature introduced with CME 4.3/7.0 in Cisco IOS Release 12.4(15)XY provides a method to capture accounting records in comma separated value (.csv) format and store the records to a file in internal flash or to an external FTP server. It expands gateway accounting support, which also includes the AAA and syslog mechanisms of logging accounting information.

The accounting process collects accounting data for each call leg created on a Cisco voice gateway. You can use this information for post processing activities such as to generate billing records and for network analysis. Cisco voice gateways capture accounting data in the form of call detail records (CDRs) that contain attributes defined by Cisco. The gateway can send CDRs to a RADIUS server, syslog server, and with the new file method, to flash or an FTP server in .csv format.

Refer to Feature Guides for more information on the Enhanced CDR capabilities.

Source: www.cisco.com