CME Hunt Group Final Not Being Reached

Given the following configuration, what do you think will happen when 7343 is called and no one in the hunt group answers?

ephone-dn 1 dual-line
 number 7241
 label Kathleen
 name Kathleen
 call-forward busy 5000
 call-forward noan 5000 timeout 20
 huntstop channel
ephone-dn 2 dual-line
 number 7254
 label Eleanor
 name Eleanor
 call-forward busy 5000
 call-forward noan 5000 timeout 20
 huntstop channel
ephone-dn 3 dual-line
 number 7258
 label Natasha
 name Natasha
 call-forward busy 5000
 call-forward noan 5000 timeout 20
 huntstop channel

voice hunt-group 5 parallel
 final 5000
 list 7254,7258,7241
 timeout 30
 pilot 7343

Contrary to expectations, the call doesn't get forwarded to the hunt group final number of 5000. This is becaue CME won't ever use the final number in a hunt group if the time out on the hunt group is greater than the time out defined in the ephone-dns! 

UCS C200 Series Power On After Power Failure

We recently had a power cut in the office and our UCS C210 M2 server didn't automatically power back on. Normally there's a setting in the BIOS along the lines of "After Power Failure: Power On". After trawling through every option in the BIOS I couldn't find anything relevant - it turns out the setting is actually in the CIMC.
To access the CIMC GUI you need to make sure it has been configured, you can reach the configuration settings for the CIMC when the server is powering via these steps:

1. Press ESC to view POST messages
2. Press F8 to enter CIMC config

Keep an eye out whilst the server powers on and press the keys at the appropriate times - it'll say on screen. You can then set an IP address, etc.
Once the server's powerd on, go to the CIMC IP address in a web browser, e.g. https://192.168.111.175. If you've not set a username and password the defaults are as follows:

Username: admin
Password: password

Select the Sever tab on the left hand side of the screen, then Power Policies and select the Power Restore Policy you want:

Click Save Changes and you're done.

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.