Signed Configuration Files and Moving a Phone From CUCM 8 to CUCME

Communications Manager 8 features signed configuration files by default, however this can cause problems when moving a phone from CUCM 8 to CUCME. The phone will continue to try requesting a signed configuration file (e.g. SEP012345678912.cnf.xml.sgn) instead of an unsigned configuration file (e.g. SEP 012345678912.cnf.xml). As CUCME doesn't by default generate signed configuration files, the phone will fail to download its configuration via TFTP and then fallback to its last known configuration, resulting in a endless loop of registration failure. You can confirm what file the phone is trying to download by enabling debug tftp events.
The solution is to erase the phone's ITL configuration, the process varies between models but for the 7900 series phones it is:

Settings > Security > Trust List > ITL File > **# (to unlock the settings) > Erase

This problem can also bite you when moving a phone between CUCM clusters, Cisco have a support document explaining the fixes here.

UC500 Rewriting SIP Headers

One of the big pains with SIP trunks is the variations in implementation between different providers - often the port range for RTP or the caller ID format will be different. These are easily fixed, but what if your SIP trunk provider expects the SIP headers to be formatted in a different way from your equipment? Fortunately the Cisco Unified Border Element (CUBE) functionality allows you to use regular expressions to amend SIP headers.
For this example configuration our SIP trunk provider has specified that for Invite packets:

1. From header must contain the originating caller ID without the leading zero, e.g. From: "1143210757" <sip:1143213213@192.168.0.253>
2. To header must contain the called number with the leading zero for UK calls or 00 for international, e.g. To: <sip:07891234567@1.2.3.4>

As the dialled number will already include the correct number of preceeding zeros no changes are required for this. However we do need to strip the preceeding zero from  the caller ID via a translation profile:

voice translation-rule 200
 rule 1 /^0\(.*\)/ /\1/
!
voice translation-profile SIP_OUT
 translate calling 200

Now a UC500 series formats the Remote-Party-ID and From fields with the caller ID from the ephone-dn that initiated the call:

Remote-Party-ID: "Firstname Lastname"  <sip:1143213213@192.168.0.253>

From: "Firstname Lastname" <sip:1143213213@192.168.0.253>

To rewrite them to the correct format with the caller ID inside the quote marks we use a sip-profile. These are applied globally and allow us to amend the SIP headers:

voice service voip
 sip
  sip-profiles 100

voice class sip-profile 100
 request ANY sdp-header Connection-Info remove
 response ANY sdp-header Connection-Info remove
 request invite sip-header Remote-Party-ID modify "\"(.*)\" <sip:(.*)@(.*)>" "\"\2\" <sip:\2@\3>" 
 request invite sip-header From modify "\"(.*)\" <sip:(.*)@(.*)>" "\"\2\" <sip:\2@\3>"

The regular expression "\"(.*)\" <sip:(.*)@(.*)>" "\"\2\" <sip:\2@\3>" identifies the text contained in quote marks, followed by the text before and after the @ symbol. It then replaces the text contained in quote marks with the text before the @ symbol. The end result of this is that From: "Firstname Lastname" <sip:1143213213@192.168.0.253> becomes From: "1143213213" <sip:1143213213@192.168.0.253>.

Further reading on using sip-profiles can be found here.

Applying QoS to VoIP Packets in a VPN Tunnel

For remote sites that use VoIP and are linked to the central site via an IPsec site to site VPN you can't match the outbound VoIP packets based on port ranges, IP addresses, etc. as it has been encapsulated in the tunnel. However when a packet is encapsulated its DSCP marking is copied to the new packet header. Therefore if the VoIP traffic is correctly identified inbound to the router, you can match packets for QoS on the outbound interface via the DSCP markings.
Below is a simple configuration to match inbound RTP packets based on the port range and assign it to the outbound priority queue:

class-map match-all VOIP_OUT
 match ip dscp ef
class-map match-all RTP
 match access-group name VOICE_PAYLOAD
!
policy-map MARK_RTP
 class RTP
  set ip dscp ef
policy-map VOIP_OUT
 class VOIP_OUT
  priority 384
 class class-default
  fair-queue
!
ip access-list extended VOICE_PAYLOAD
 permit udp any any range 16384 32767
!
interface GigabitEthernet0/0
 description LAN
 service-policy input MARK_RTP
!
interface GigabitEthernet0/1
 description WAN
 service-policy output VOIP_OUT
!

Alternatively if your IP phones are already marking the RTP packets the correct DSCP value, you can do away with the inbound service-policy. For this to work you must prevent the switch from overriding the DSCP markings on packets received from the IP phone by using the mls qos trust device cisco-phone command on the interfaces phones are attached to.

You can monitor the number of packets being matched by the policy-maps using the show policy-map interface command:

GigabitEthernet0/1

  Service-policy output: VOIP_OUT

    queue stats for all priority classes:
     
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 26176/7067520

    Class-map: VOIP_OUT (match-all)
      26176 packets, 7067520 bytes
      5 minute offered rate 122000 bps, drop rate 0 bps
      Match: ip dscp ef (46)
      Priority: 384 kbps, burst bytes 9600, b/w exceed drops: 0
     

    Class-map: class-default (match-any)
      51651 packets, 8147526 bytes
      5 minute offered rate 38000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
      (pkts output/bytes output) 51651/7939473
      Fair-queue: per-flow queue limit 16

UK PSTN Route Patterns

Using the international dial plan installers from Cisco and the @ symbol for route patterns has two major shortcomings:

1. You can't easily see what numbers can or can't be dialled
2. You're at the mercy of Cisco updating it, which can lag a long way behind changes in the dial plan

So whenever I do a Communications Manager installation I manually define the PSTN access route patterns. Ofcom do publish the specifications of the UK Numbering Plan online, below is the route patterns for a simplified version.

Route Pattern	Description
00!	International dialling
101	Non-emergency police services
111	Non-emergency healthcare services
112	Emergency services
123	Talking clock
999	Emergency services
116XXX	Services of social value
118XXX	Directory enquiry services
08001111	ChildLine
08454647	NHS Direct
0[12]XXXXXXXXX	Geographic area codes
03[0347]XXXXXXXX	Nationwide numbers at geographic rates
055XXXXXXXX	Corporate numbers
056XXXXXXXX	Location independant electronic communications services
070XXXXXXXX	Personal numbering service
07[1-9]XXXXXXXX	Mobile/pager services
0[58]0XXXXXXX	10-digit Freephone
080XXXXXXXX	Freephone
082XXXXXXXX	Internet for schools
084[3-5]XXXXXXX	Special services basic rate
0870XXXXXXX	Non-geographic numbers
087[1-3]XXXXXXX	Special services higher rate
09XXXXXXXXX	Premium rate services

VoIP Fraud Prevention

If you have a router running CME or a UC500 series using a SIP trunk then it's quite likely you had to expose it to the Internet via NAT for the SIP trunk to work. Now this can cause an expensive problem!

Cisco routers with voice gateway functionality trust SIP or H323 call signalling by default, so if your router has outbound dial peers configured someone can send SIP invites to your router and provided the sent digits match a dial peer it'll connect the call. Now you may be thinking that there's no inbound dial peer to match the hacker's IP address, CODEC, DTMF relay settings, etc. but remember any inbound VoIP call that doesn't match a dial peer gets handled by the default dial peer, so it's pretty easy to guess the settings needed to make a connection!
Originally the only way to lock down your router was to apply a suitable access list on the outside interface or on the router handling Internet access, fortunately in IOS 15.1(2)T Cisco finally got around to introducing enhanced toll fraud prevention.

Using Access Lists

SIP or H323 traffic should be restricted to only be sourced from the IP address of your SIP trunk and RTP traffic allowed. Below is an example access list that would allow SSH and RTP traffic from anywhere, but lock down the inbound SIP traffic:

ip access-list extended OUTSIDE_IN
 permit tcp any any eq 22
 permit udp host 146.101.248.200 any eq 5060
 permit tcp host 146.101.248.200 any eq 5060
 permit udp any any range 16384 32767
 deny ip any any log

The limitation with this method is that call signalling received from internal sources are trusted, so if someone managed to hop onto your LAN they could potentially initiate calls from a rogue device.

Using Toll Fraud Prevention

IOS 15.1(2)T introduced the concept of trusted VoIP sources, allowing you to lock down which IP addresses can initiate a call regardless of the interface the call setup messages are received on. However to maintain backward compatibility Cisco defaults to trusting all IP addresses. The list of trustred IP addresses is defined in the voice service voip section of the router's configuration, the default to trust everything is shown below:

voice service voip

 ip address trusted list

  ipv4 0.0.0.0 0.0.0.0

So if you were to lock down the IP addresses, wouldn't it break your existing dial peers? Cisco thought of that - the router automatically adds any destinations that are defined as an ipv4 target in a dial peer to the trusted source list. You can display the dynamic list of trusted IP address with the show ip address trusted list command:

IP Address Trusted Authentication
 Administration State: UP
 Operation State:      UP

IP Address Trusted Call Block Cause: call-reject (21)

VoIP Dial-peer IPv4 Session Targets:
Peer Tag        Oper State      Session Target
--------        ----------      --------------
1003            UP              ipv4:10.1.10.1
1005            UP              ipv4:10.1.10.1
1009            UP              ipv4:10.1.10.1
2001            UP              ipv4:10.1.10.1
2002            UP              ipv4:10.1.10.1

IP Address Trusted List:
 ipv4 93.95.124.7 255.255.255.255

Here you can see that 5 entries were learnt from dial peers and 1 IP address has been manually configured. As my outbound dial peers used session target sip-server, the IP address for the SIP trunk had to be manually configured in the trust list.

Note that phones registered with CME are excluded from this fraud prevention mechanism and so can make calls, phone registration security is a separate matter.

UC500 Series Transcoding

When a device receives a call using a CODEC it doesn't support it will try to invoke a transcoding session to convert the RTP audio stream into a supported format, otherwise the call will fail. You'll encounter this problem on a UC500 when using a SIP trunk that delivers audio in G729 format as CUE only supports G711, thus callers are unable to leave voicemail messages.

The UC500 series when configured by CCA will already have a dspfarm profile for conferencing, if there's any unused DSP resources then transcoding can also be enabled. Amend the configuration below to match your IP address and the number of sessions your DSPs can handle:

voice-card 0
 dspfarm
 dsp services dspfarm
!
sccp local Loopback0
sccp ccm x.x.x.x identifier 1 version 4.0
sccp
!
sccp ccm group 1
associate profile 2 register xcodeprof
!
dspfarm profile 2 transcode
 codec g711ulaw
 codec g711alaw
 codec g729ar8
 codec g729abr8
 codec g729r8
 maximum sessions x
 associate application SCCP
!
telephony-service
 sdspfarm units 2
 sdspfarm transcode sessions x
 sdspfarm tag 2 xcodeprof
!

sdspfarm units should match the number of dspfarm profiles, in this case 2 - conferencing and transcoding. You can then confirm the DSP resources have registered with show dsp profile:

Dspfarm Profile Configuration

Profile ID = 2, Service = TRANSCODING, Resource ID = 1
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 4
Number of Resource Available : 4
Codec Configuration
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
Codec : g729r8, Maximum Packetization Period : 60

IMPORTANT!  CUE appears to have a bug whereby if the dial-peers directing calls to it use a voice class codec to determine the CODEC to use, CUE will try to use the 1st CODEC even if CUE doesn't support it (e.g. G729). To avoid breaking calls to voicemail, use codec g711 on the dial-peers to CUE instead. This issue also occurs if the inbound dial-peers from the SIP trunk use a voice class codec, the CUE module won't invoke a transcoding session, so again manually specify the codec.

CME Different Ringtones for Internal/External Calls

In Communications Manager Express and the UC500 series it's possible to set a different ring pattern for all phones when called by an external phone number:

voice register global

 external-ring bellcore-dr1

Other options are bellcore-dr2 to 5, which select different patterns of rings.

Unified Communications Licences

Annoyingly each Cisco Unified Communications application has a different licence installation process, so here's a quick overview of how licences are handled:

Cisco Unified Communications Manager
Software, node and DLU licences are installed on the Publisher.

Cisco Unity Connection
Software and mailbox licences are installed on the Publisher.
HA node licences are installed on the Subscriber.

Cisco Unified Presence
Software and node licences are installed on the Publisher.
CUPC licences are installed on the CUCM Publisher.

Unified Contact Centre Express
Software and HA licences are installed on the Publisher.

MGCP Control of a Fractional PRI

Using MGCP usually makes life much easier with Communications Manager, but unfortunately it does assume that any PRI circuit is using the full amount of channels (23 for a T1 or 30 for an E1) and therefore doesn't support fractional PRIs.
Here's how to kludge MGCP into using a fractional PRI in 7 easy steps, for this example I'm using an E1 in slot 0/0/0:

1) Configure the gateway as normal in Communications Manager, then on the gateway use the ccm-manager config commands to configure it automatically:
ccm-manager config server x.x.x.x
ccm-manager config

2) Shutdown the voice-port:
voice-port 0/0/0:15
 shutdown
controller E1 0/0/0
 shutdown

3) Remove the ISDN layer 3 binding:
interface Serial 0/0/0:15
 no isdn bind-l3 ccm-manager

4) Replace the pri-group:
controller E1 0/0/0
 no pri-group
 pri-group timeslots 1-x service mgcp

5) Restore the ISDN layer 3 binding:
interface Serial 0/0/0:15
 isdn bind-l3 ccm-manager

6) Enable the voice-port:
controller E1 0/0/0
 no shutdown
voice-port 0/0/0:15
 no shutdown

7) Disable auto-configuration downloading, otherwise Communications Manager may undo your hard work:
no ccm-manager config
copy running-config startup-config

Upgrading Old Versions of Communications Manager and Phones

This is a problem you'll encounter when either upgrading an old install of Communications Manager (usually versions prior to 6) or plugging in an old phone that was found in a store cupboard somewhere...


Both SCCP & SIP firmwares for 7900 series phones prior to 8.3.3 can't be directly upgraded to newer versions, it'll usually give an error message along the lines of "auth fail" when the phone tries to download the newer firmware. The solution is to upgrade the phone to 8.5.2, then you can upgrade to any newer firmware. To do this I have a UC540 configured with 8.5.2 firmware loads for most models of phone, then it's just a case of plugging the old phone into the UC540 to do the interim upgrade before connecting it to the live Communications Manager.
You can check a phone's firmware version by going to Settings > Model Information, the version is listed under Load File.

LDAP Synchronisation Filters

LDAP synchronisation has moved on from a nice optional feature to a necessity with Cisco's Unified Communications applications. Cisco Unified Personal Communicator is crippled without LDAP integration and if you want to do a Unified Messaging deployment in Unity Connection then integrating with Active Directory is required.

You can specify multiple user search bases to target the LDAP synchronisation, but what about the situations where you don't want to import all the users within an OU? Or worse still when there's users that aren't importing?

Users Not Importing From LDAP

Ever done a Communications Manager deployment and wondered why there's less users in Communications Manager than there is in AD? The LDAP sychronisation excludes users who lack a last name, typically users associated with an actual person will have these fields populated so you won't necessarily encounter this problem. However once in a while you may have service accounts or generic logins that require importing from AD yet lack these fields.

LDAP Filters

So your customer's AD structure is a mess and there's a ton of users you don't want to import intermingled with the users you do want. This is where LDAP filters come into play, an LDAP filter takes the form:
<filter>=(<attribute><operator><value>)

Where <attribute> is an LDAP attribute (e.g. "sn" for last name), <operator> is a boolean operator (e.g. "&" for and) and <value> is the value for comparison.
You can then nest multiple filters like so:
(<operator><filter1><filter2>)

A more detailed overview of the syntax can be found on MSDN.

Examples
A school where staff and student accounts reside in the same OUs, but student accounts begin with the year they'll graduate. We can exclude users whose username starts with a number:
(!(|(sAMAccountName=0*)(sAMAccountName=1*)(sAMAccountName=2*)(sAMAccountName=3*)(sAMAccountName=4*)(sAMAccountName=5*)(sAMAccountName=6*)(sAMAccountName=7*)(sAMAccountName=8*)(sAMAccountName=9*)))

Large numbers of staff don't have access to a telephone or only use a shared team phone, we can exclude staff without a phone number in AD:
(telephoneNumber=*)