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.