CIPT2 Passed – Have Some Notes

So I passed my CIPT2 test today. As many have mentioned know SAF and how it works, and know globalized call routing.

Test blueprint can be found at (CCO Required)


Multi-site Challenges

  • Availability Issues
  • Quality and BW issues
  • Dial Plan Issues
  • NAT / Security Issues


Quality Issues

  • Packet by Packet
    • Take Different Paths
    • No guarantee for correct order
    • RTP sequence numbers solves
  • BW shared by multiple users / apps
    • Peaks / Valleys in queues
  • Jitter / packet drop


Queuing causes jitter

BW issues

  • All inter-site traffic competes for available BW
  • BW on IP WAN links usually limited and costly
    • Link BW should be used efficiently
    • G711 not efficient in noncircuit-based environments


Availability Issues

  • Loss of WAN
  • Signaling back to CUCM for SCCP / MGCP
  • XML services


Dial Plan Issues

  • DID vs attendants
  • Overlapping DNs
  • Nonconsecutive DNs
  • Variable-length numbering
  • Optimized call routing
    • Toll bypass
    • TEHO
    • PSTN backup
  • Various PSTN requirements in courtiers
    • Access codes for PSTN, nation, INTL dialing
    • ISDN TON


3 Ways to detect end of dialing

  • Inter-digit timeout T302 timer default 15 sec
    • Least convenient
  • Use # Key
    • Requires User education
    • Convenient
  • Use overlap sending and overlap receiving
    • Must be supported by the PSTN
    • Complex


PSTN used for backup in case of CAC / WAN failure

Different PSTN rules

  • Dial Rules
    • Access codes
    • National Access Code
    • International access code
  • Presentation of called / calling number in and out
    • Length of number
    • ISDN number types
    • + prefix on E.164 numbers
  • Emergency dialing


Centralized H323 gatekeepers or SIP network services offer dial plan simplification

Call control discovery allows dynamic learning of dial plans.


NAT / Security Issues

  • In single site deployments
    • NAT not needed
    • Not reachable from outside
    • Not subject from attacks
  • Multisite deployments / VPN tunnels
    • Requires gateway config at each site
    • Allows only inter-site communication.
    • Blocks access to and from outside


  • Nat can open you to attached to CUCM / phones if reachable from the internet


QOS Advantages

  • Prevents jitter caused vy variable queuing delays
  • Ensures enough BW for signaling
  • Prevents packet loss caused by tail drops.


Options to reduce WAN BW

  • G729 over the WAN
  • Using RTP header compression
  • Deploying local annunciators or disabling remote ones
  • Deploy local CFB
  • Deploy local MTP if needed
  • Deploying transcoders or mixed CFB
  • Deploy local MOH
  • CAC


768k or less for Compress Headers


Codecs are specified via Regions

Codec Selection – Best codec is the one that is supported by both devices but does no exceed the BW specified by Region config.

If devices can’t agree a transcoder is invoked if available.

Disable ANN by not putting it in the MRGL of the remote site.

CFB – place as close to users as possible.

Xcode – place as close to the large side codec source as possible e.g. next to VM server and G729 across the WAN.

CUMC Xcode is HW only via DSP

Mixed HW CFB – Allows G729 / G711 streams

Multi-cast MOH from Branch Router Flash

  • MOH Multicast Server set for max of 1 hop
  • Branch router spoofs as the MOH Server via SRST which has a local WAV file in router
  • Branch router is configured as the same Multicast address / config as the MoH server.



Router MOH Server

max-ephones 1

Max-dn 1

Ip source-address


Multicast moh port 16384

Multi-cast IP:
Port: 16384
MAX TTL Hops: 1


G729 for MOH is poor quality


CAC –  is used to limit the number of calls between locations

  • Locations – Hub and Spoke TOPO
    • BW limit applicable to items within cluster
    • Includes calls to and from gateways and trunks
  • RSVP-Enabled locations
    • Special implementation of locations
    • Allows calls to flow through two routers (RSVP Agents)
  • SIP Precondition
    • Like RSVP but between SIP domains
  • Gatekeepers
    • BW calls between H323 GK zones


Availability Options

  • PSTN Backup
  • MGCP fallback
  • Fallback for IP Phones:
    • SRST
    • CME with SRST
  • CFUR – Call FW Unregistered
  • AAR and CFNB – Automated Alternate Routing (to PSTN if no WAN BW) / CF No BW
  • Mobility solutions:
    • Cisco Extension mobility
    • Cisco Device Mobility
    • Cisco Unified Mobility


MGCP Fallback application – H323 or SIP Dial Peers

SRST – Phones register to the Voice GW

CFUR – Calls from Main site routed via PSTN to Branch location

  • Could be used with IP Communicator to automatically FW to cell phone when laptop is off



  • Used to route calls over PSTN when not enough BW is available for VoIP calls
  • Alternate destination is derived from external phone number mask and prefix configured per AAR group.
  • Individual destinations can be configured per phone.


Dial Plan Solutions

  • Overlapping and nonconsecutive numbers
    • Solved by access codes and unique site codes
    • Allows routing independent of DN
    • Appropriate digit manipulation required
  • Variable length numbering
    • Dial string length determined by timeout of # key
    • Overlap sending and receiving
  • DID rangers and PSTN addressing
    • Use of IVR auto-attendants if no DID
    • DN appended to PSTN number
  • Number presentation ISDN TON
  • Least cost routing, TEHO, PSTN backup
  • Globalized call routing


Dial Plan Component IOS GW CUCM
Endpoint Addressing Ephone-dn, dynamic POTS, dial-peers DN
Call routing / path selection Dial-peer Route patterns, route groups, route lists, trans patterns, partitions, CSS
Digit manipulation Voice translation profiles, prefix, digit strip, forward-digits, num-exp Trans patterns, route patterns, route lists, sig digits, called / calling party transforms, incoming called / calling party settings
Calling privileges COR / COR lists Partitions, CSS, tech schedules, time periods, FACs
Call coverage Dial peers, call applications, ephone hunt groups Line groups, hunt lists, hunt pilots


Globalized Call routing

Called number: E.164 with + prefix (except internal destinations)

Calling number: E.164 with + prefix (except for calls from internal to infernal)

If source of calls use a different format they needed to be localized ingress to a globalized plan.

  • Applies to phones and GW
  • Applies to called and calling numbers


After the call is routed the egress device changes from globalized to localized format.


Advantages of E.164

  • One format to be used
  • Local requirements are managed at the egress device
  • Common format can be used in address books and can be exchange worldwide.
  • International dial plans are substantially simplified.



CUBE – splits calls between inside and outside call leg.

SIP / H323 support

Flow through – Signaling and RTP

Flow around – Signaling only

Only the CUBE needs outside access / inside devices do not have to be exposed to outside networks.

Other options – Trust relay points, ASA proxy


Session 2







Direct Connection to another CUCM cluster

Connection to any H323 device via gatekeeper


Connection to any SIP device


SIP Trunk Characteristics

  • Distributed Dial-plan
  • Can be connected to any device supporting SIP, IOS, CUBE, remote CUCM, SIP Proxy
  • Simple, customizable protocol
  • MTP might be needed


H323 Trunk Overview

  • Gatekeeper controlled or not Gatekeeper controlled
  • H225 legacy trunk for CUCM 3x and below
  • Gatekeeper is recommended for scalability of H323


Reduce the failover timers to speed H323 failover time.


Adding an MGCP GW

    1. Add MGCP GW
    2. Add voice modules
    3. Add VICs to modules.
    4. Add and config MGCP endpoint.
    5. Configure MGCP GW.


If CUCM is configuring MGCP only lines needed are:

Ccm-manager config server x.x.x.x

Ccm-manager config


Adding H323 GW

    1. Config IP address of H323 GW
      1. IP Address
      2. Device Pool
      3. How many significant digits
    2. Configure IOS GW for controller, dial-peers, ip address etc.


Best practice is to use a Loopback address as the H323 source address.


Non-GK controlled ICT

    1. Trunk with IP address of peer.
    2. Route patterns, route list, route group


GK controlled ICT

    1. Setup Gatekeeper
    2. Trunk pointing to GK
    3. Route patterns, route list, route group


EMCC – requires SIP trunk

Call Control Discovery

  • H323 and SIP supported


SIP Profile and SIP Security Profile must be setup before you can setup a SIP trunk.

SIP Profile – Trunk parameters, Transport type, etc.

SIP Security Profile – Use TLS or not, Digest credentials or not


Non-GK ICT- Enter IP addresses of other CUCM servers on the other side.


Setup the GK – IP address and Enabled

Select GK ICT, set name, device pool and select GK, Terminal Type (GW in case of CUCM), Tech Prefix, Zone.


Show gatekeeper endpoint – shows registered H323 endpoints.


Access / Site Codes

  • Allows routing independent of DNs
  • Solves overlapping / non-consecutive DN ranges

Implementing PSTN access

  • Simple, prioritized list of GWs for PSTN access
  • TEHO

Implementing PSTN backup

  • MGCP fallback in case of MGCP GW
  • SRST for IP Phone fallback at remote site
  • CFUR – Call forward unregistered.


Dial-plan scalability solutions

Dial plan issues can be solved by Call Control Discovery (CCD)

CCD allows dynamic exchange of call routing information utilizing a SAF(Service advertisement framework)-enabled network.


Utilize the . And use pre-dot DDI to drop access code and site code. Incoming calling number modified to add access digit and calling site code.


PSTN Access

Digit manipulation in CUCM for MGCP or GW for H323

Outgoing calls to PSTN

  • Calling number transformation
    • If no DID, transform to a DID number
    • If DID add prefix
  • Called Number transformation
    • Strip access digit

Incoming Calls from PSTN

  • Calling number transformation
    • Transform to complete PSTN number and add access code
    • Consider TON
  • Called number transformation
    • If DID strip PSTN prefix down to DN
    • If no DID route call to IVR / Auto Attendant





  • 3-digit exchange
  • 4-digit station code



  • 3-digit area code
  • 7-digit subscriber number


Variable length (11 for US numbers)

  • Country Code
  • Area Code
  • Subscriber Code


Two ways to do PSTN breakout

Gateway selection by CSS

Each site has a device specific CSS

RP -> RL -> RG -> GW

Gateway selection by local route group – Preferred Option (introduced in CUCM 7)

Match route pattern refers to system wide route list

Route list refers to standard local route group

Device pool of calling device is configure with route group to be used

This eliminates the need for multiple site specific RL, RP, Partitions and CSS


Setup Local Route Group

    1. Add Standard Local Route Group
    2. Setup Local Route list to use Standard Local route Group
    3. Setup Site specific RG with the GW resources.
    4. Assigned Site specific RG to Device Pools
    5. Point Route Patterns at Local Route List


PSTN Backup

Numbers translated to PSTN dialable numbers in event of ICT being down.


TEHO not legal is all countries / providers


TEHO without local route group

For each TEHO pattern the first entry in the route list is the TEHO location, the second the local GW

For non-TEHO destinations, there is only one entry local GW in the RL.

For N sites, N*N route patterns and route lists are required.


TEHO with local route group

Only one RP one RL for each TEHO destination.

The number of RL / RP from 20 to 5 for 5 sites.

1 RP for non-teho sites

Total number of RP and RL is reduced to n+1

Total number of partitions and CSS is reduced to 1


Globalized Call Routing

Allows one format to be used for routing to PSTN destinations

E.164 with + prefix used

Users can still type PSTN numbers in local format

Localized input is globalized at call ingress

Routing is based on numbers in + format

At call egress numbers are localized depending on the egress device

Simplifies international dial plans


Number Normalization – turning a number to E.164+

Localized E.164 – Global number in a partial format e.g. not + no country code

Change the calling number to Global E.164

Change the called to a DN format


\ – specifies to looks at the next character as what it is. \+ allows + in route pattern


911 – US

000 – AU

999 – UK


Introduce a corporate emergency number that normalizes to the local emergency number.

Localized via called-party transformation

All local emergency numbers are allowed and get translated to local emergency number.


Globalized Call Routing Benefits




Cisco Device Mobility

Cisco Extension Mobility


Called party transformations live in their own PT and CSS and can be used at the GW / Phone Device / Device Pool levels


SRST in case of WAN failure – phones

MGCP fallback – GWs – fails over to H323 / SIP dial-peer configs


Redundancy Technologies

Redundancy For MGCP GW SCCP Phones SIP Phones SCCP Phones
Delivered service IOS Dial Peers Basic telephony service Basic SIP proxy Service CUCME
ISDN Call preservation No Yes (no MGCP) Yes (no MGCP) Yes (no MGCP)
Analog / CAS call preservation Yes Yes Yes Yes
Max number of phones N/a 1500 1500 450


When to use MGCP fallback

  • Used as a standalone feature for phone locally attached to the Router
  • Is most often used with SRST
  • Provides GW functionality to IP Phones in SRST Mode
  • No call preservation for ISDN PRI / BRI interfaces – CALLS WILL DROP During Failover



  • Supports 1500 phones
  • Supports secure voice (if security is enabled)
  • Allows simple, one-time configuration for SRST
  • Only basic phone features
    • No MWI
    • No advanced features, Mobility or presence



  • Supports SRST basic features
  • Additional features can be applied globally by templates or per phone by manual config
  • All features available in CME are supported
    • Mix of pre-configured phones and automatic basic configuration phones supported


IP Phones send keep alives with CUCM

After 3 missed keep alives – phones assume WAN down and then register with SRST GW

GW queries phone for configuration and auto configures itself.


Calls using the GW during switch over survive if not MGCP

GW provides call processing during WAN outage.


Phones keep sending keep alives to CUCM. Once the phones start receiving response back they will re-register with CUCM.


SRTS Timing

  • TCP Keepalive default is 30 seconds
  • After 3 missed keepalives phone tries backup CUCM for ~60 seconds then tertiary CUCM ~60 sec – total fail time ~2.5min
  • Phone then registers to SRST Router ~10 – 20sec to register
  • WAN Restored phone gets keep alive ~30 seconds.
  • Default switch back timer is 120 seconds


MGCP GW Fallback Timing

  • MGCP GW registered with CUCM sending keep alives – Default timer is 15sec
  • If no response after 30 sec, then we try secondary server and tertiary – Missed 2
  • Falls back to H.323 or SIP local configuration
  • When the WAN is restored – TCP connection is restored.
  • Restart in progress sent to CUCM server
  • All-ready established calls will be kept up. Future calls processed by CUCM



Number of Supported SRST Phones

Platform Support Phones
800 4
1861 15
2801-2851 25-100
2901-2951 35-250
3825, 3845 350, 730
3925 – 3945E 730-1500


+Dialing is support in SRST


SRST Supports up to 5 MOH groups v8.0 SRST

  • SCCP Phones only
  • Each group is configured with a DN that should be applied to it.
  • Files cached in RAM


SRST Dial plan

CFUR used to reach phones at remote sites that are unregistered

Dialplan pattern – modifies incoming called PSTN numbers to match internally used extensions

Voice translation profiles expand the called number to PSTN format for site code dialing


CFUR limits the number of CFUR hops per call to reduce the impact of routing loops. – Service parameter

CFUR for extension mobility should always point to voicemail


CFUR should try to use local GW of device


Configure COR on router to maintain CSS configuration that was setup in CUCM.



Setup SRST / MGCP Fallback

SRST reference for the phones setup on Device Pool and System menu SRST.

MGCP fallback configured on the GW

SRST dial-plan has been setup on the GW



CUCM Config

    1. Create SRST Reference
    2. Assign to Device Pool


IOS Side – Bold = mandatory

    1. Enable SRST
    2. Define IP which SRST binds to.
    3. Define max-dn
    4. Define max-ephones
    1. Define max numbers allowed per phone type
    2. Define phone keepalive interval. – Default 30 seconds



Ip source-address port 2000

Max-ephones 10 dual-line

Max-dn 20

Limit-dn 7962 2

Keepalive 30

Translation-profile {incoming | outgoing} <name>



MGCP Fallback

SRST# configure terminal

SRST (config) # ccm-manager fallback-mgcp

SRST (config) # application

SRST (config-app) # global

SRST(config-app-global)# service alternate Default

SRST (config-app-global) # end



CFUR Setup

    1. Define a CSS for CFUR
    2. Set the max forward unregistered hops to DN service parameter. – Default is 0 (infinite) recommended 2
    3. Confg CFUR at DN number of remote phone.


Timeouts interdigit <sec>

Dialplan-pattern <tag> extension-length <length> extension-pattern <extension-pattern> = Creates a global prefix that can be used to expand or demote the internally used DN numbers.

cipt2-notes1 cipt2-notes2











CME in SRST mode

CME for small to medium sites = 450 phones

CUCM medium to large deployments = 30,000


CME Features

  • Paging
  • Intercom
  • Call Transfer, park, pickup
  • Hunt Groups
  • Extension Mobility
  • Five MoH sources
  • Support for E.164 + dialing
  • Conferencing


CME Commands

  • Telephony-service
    • Max-ephone
    • Max-dn
    • Ip source-address
    • Create cnf-files
    • Load 7965 SCCP45.9-0-2-SR1S
    • Moh
    • Multicast moh
      • port 16384
  • Ephone-dn
    • Number
  • Ephone
    • Mac-address
    • Type
    • Button
  • Dialplan-pattern


Tftp-server flash:<file-name>


CME supports only G.711 for MOH transcoders are required for G729 MoH to be used.

Only .au .wav files in G711 8bit mono format are supported.

Minimum size 100kb

Default flash drive should be used to store MoH files.

Config based on MoH groups.

Phones not configured to use one of the MoH groups will use the default MoH source.

RAM caching of MoH files can be enabled

Less CPU utilization

Higher memory consumption



voice moh-group 1


description MOH: customer services

multicast moh port 16384

extension-range 1000 to 1099

extension-range 1300 to 1399


voice moh-group 2


description MOH: marketing

multicast moh port 16384

extension-range 3000 to 3099



moh-file-buffer 5000

moh flash:default.wav

multicast moh port 16384


Phone configuration not needed in CUCME in SRST mode.

Any Combo of the following:

  • Manually configure the phones with an associated ephone-dn
  • Manually configured ephone with no associated ephone-dn, and automatic assignment enabled.
  • Manually configured ephone-dn (not associated to ephone)
  • No Manual configuration


If configured ephone and ephone-dn templates are applied to learned ephones and ephone-dns



Dynamic provision is done by SNAP protocol. (Simple Network Enabled Auto Provisioned)


When phone enters SRST Mode

  • The router searches for an existing ephone with the MAC address of the phone.
    • If found ephone must be configured with a DN, or automatic assignment must be enabled.
    • If not found, the router searches for an existing ephone-dn that matches the IP phone DN (learned by SNAP).
      • If found, an ephone is added that refers to the matched ephone-dn
      • If not found, an ephone is added that referes to a newly created ephone-dn auto configured by SNAP.
    • Whenever an ephone is added by CU SRST, the SRST ephone template is applied.
    • Whenever an ephone-dn is added by CU SRST, the SRST ephone-dn template is applied.



Srst mode auto-provision {all | dn | none}

Srst dn line-mode {dual | single} – single is the default

Srst dn template <tag>

Srst ephone template <tag>

Ephone-template <tag>

Ephone-dn-template <tag>


All – writes config to running config

DN – writes ephone-dn information into running config

None – does not include information learned from ephones or ephone-dns into running config.


Bandwidth Management

  • RTP Header Compression <768k
  • Low BW codecs
  • Local media resources CFB
  • Transcoders
  • MOH from branch router flash



LAN – high BW codecs

WAN – low BW codecs


Low BW codecs

  • Don’t do MOH quality will be low

Disable MoH for remote sites



Each region is configured with the highest permitted codec BW

Within the configured region

Toward specific other regions (manually added)

Toward all other regions (that have not been manually added)

Region is assigned to DVP

DVP is assigned to device

Codec that is actually used depends on the capabilities of the two devices:

Best codec that is supported by both devices and does not exceed codec BW permitted in Region config

If devices cannot agree on a codec, transcoder invoked – if none available the call fails

Loss type (in region config) is also considered


Where to deploy IP media resources considerations:

Number of devices at remote site and likelihood of using a feature or application requiring the resource

Ease of adding required hardware resources

Available BW toward central site


Transcoders are deployed closest the highest quality codec. Thus G729 used across the WAN then transcoded to G711 on the LAN to the other endpoint.


Adding a transcoder

Transcoder Type – IOS Enhanced for GW

Device name – whatever we want. MUST MATCH in IOS config. (all other types MTP followed by MAC)


Sccp local F0/0

Sccp ccm identifier 1 version 7.0+



Sccp ccm group 1

Associate ccm 1 priority 1

Associate profile 1 register HQ-1_XCODER


Dspfarm profile 1 transcode

Codec g711ulaw

Codec g711alaw

Codec G729ar8

Codec G729abr8

Maximum sessions 2

Associate application SCCP

No shut


To validate use – show sccp

Show sccp ccm group 1

Show dspfarm profile 1


MOH from Flash Multi-cast

Same multi-cast address / port number

Same codec (only G.711)

Same packetization period


Enable Multi-cast on the MOH server and audio sources and MRG.

Put MOH server into its own region allow phones to reach it via G711. All other inter-site calls are G729.

Deny multi-cast to the WAN at the HQ site. BR router uses the same Multi-cast address as the MOH server.

Set max hop count on MOH server to 1.


IP addresses get incremented one per codec G711a/mu G729 / wideband.

Each audio sources consumes essentially 4 IP addresses


IP address and ports can be verified via Traces on IP Voice Media streaming app.


Enable multi-cast routing


Ip multicast-routing


Under the interfaces

IP pim sparse-dense-mode



Implementing CAC

QoS cannot solve the problem of too many voice calls. (over-subscription)

Oversubscription affects all active calls.

CAC avoids this by limiting the number of voice calls.


CAC components

  • Locations
  • RSVP-enabled locations
  • AAR

CAC leaving a cluster

  • H.323 gatekeeper or SIP preconditions
  • If CAC denies a call and no other entries in a route list are left. The call fails.


Each device has one location assigned.

You limit calls by permitting a certain BW for calls coming in and going out of a location:

  • Audio BW is calculated by actual codec plus IP overhead (assuming 20ms packetization
    • EG 80Kb/s G.711, 24kb/s G.729
  • Calls within a location are unlimited.
  • BW limit of source and of destination location are check individually.

Works within a CUCM cluster

  • Trunks and GW can be put into a location allowing some control over calls leaving the cluster

Locations-based CAC is unaware of topology.

  • Works well with hub and spoke.


Set location on DVP and on the Phone.


RSVP enabled locations

Topology Aware

  • Works well with all topologies (full mesh, partial mesh, hub spoke)
  • Adapts to network changes
    • Link failures
    • Backup links
    • Load-share paths

Uses RSVP Agents

  • Devices (MTP) through which call has to flow
  • RSVP used between RSVP agents


RSVP agents inform CCM that the BW was available to setup the call.

Phones then setup the call.


Phone 1 RTP stream to RSVP agent 1 -> RSVP agent 2 -> Phone2


  • Based on CCM locations
    • Phones and rsvp agents are in the same location
    • If they are not in the same location CAC is used for THIS CALL LEG.
  • Phones have to use their RSVP agent
    • RSVP agent that is used by a certain phone should be as close as possible to the phone.
    • RSVP agent to be used by a certain phone is determined by the MRGL of the phone.
  • RSVP agent is an MTP resouce
    • Pass-through codec is support
      • No changes to RTP payload
      • Allows secure RTP to be used


RSVP Agent to RSVP Agent Call Leg

  • Based on standard IOS RSVP
  • IP network between RSVP agents is RSVP-enabled
  • Each interface is configured with maximum bandwidth to be reserved by RSVP
  • If RSVP is not enabled on any hot in the path, the appropriate link is ignored by CAC.
  • IntServ and Diffserv models are used
    • RSVP only for CAC
    • LLQ for QoS
  • Call is setup only after successful RSVP CAC



Path messages are sent out with the destination in the header.

If the router doesn’t understand RSVP it just passes the packet through.

Resv message sent back that the path has been reserved.


If the device can’t reserve the path the call be routed to a different path.


    1. Configure RSVP service parameters (Service Parameters > Cisco CallManager)
    2. Configure RSVP agents in IOS
    3. Add RSVP agents to CUCM
    4. Enable RSVP between location pairs.
    5. Config MRG
    6. Config MRGL
    7. Assign MRGL to devices



Voice-card 0


Dsp services dspfarm


sccp local FastEtherneto/0

sccp ccm identifier 1 version 7.0+



dspfarm profile 1 mtp

codec pass-through


maximum sessions software 20

associate application SCCP

No shutdown


sccp ccm group 1

associate ccm 1 priority 1

associate profile 1 register HQ-1_MTP


interface Serial0/1

description 1P—WAN

ip address

duplex auto

speed auto

ip rsvp bandwidth 160 40 (total BW and BW per call)


Show RSVP BW in use

Show ip rsvp installed


Under locations > Setup between other locations use RSVP (mandatory reservation or No reservation or Use System default…. And more)



Only goes into effect with CAC deny

Re-reoutes the call over the PSTN

Works only for CAC based locations and to internal DNs


With LRG a single AAR CSS and sing AAR group needs to be made.


AAR supports these call situations:

  • Call from IP phone in one location terminates with an IP phone in another location.
  • Incoming call on a GW within one location terminates on a device at another location.

AAR does not work with SRST:

  • Not activated in WAN failure
  • AAR requires CAC failure

Use of globalized call routing simplifies AAR for international deployments

AAR does not support CTI route points as the origin or destination of call.

AAR does not work with extension mobility with users roaming to a different sites.


AAR Configuration Procedure

    1. Configure AAR service parameters (CM service)
    2. Config partitions and CSS
    3. Config AAR Groups
    4. Configure phones for AAR
      1. Apply AAR CSS and AAR group to IP Phones
      2. Config IP Phone DN numbers:
        1. Apply destination AAR group
        2. Set individual AAR destination (CFNB)
        3. Forward to voicemail if no BW


Turn AAR on in Service parameters.

What to display on phones when CAC fails and what to say when the call is re-routed.


Phone is the Source AAR group DN is the Destination AAR group. If not set at the Phone, then DN AAR group is used.


SIP Preconditions (end to end RSVP)

Based on RFC3312

Intercluster RSVP

Supports RSVP CAC for calls over SIP turnks to:

  • CUCM
  • CUBE



  • IP address of originating RSVP agent is used.
  • RSVP is requested.

Terminating CUCM sends SESSION PROGRESS message SDP.

  • IP Address of terminating RSVP Agent
  • RSVP request is confirmed for forward direction
  • RSVP request is sent for reverse direction

After confirmation (PRACK and OK) each RSVP agent attempts RSVP reservation for it’s forward direction.

If successful, call setup is normal (RINGING, OK, ACK)


After the call is answers terminating CUCM requests renegotiation of media capabilities.


QoS fallback can be enabled to use local RSVP instead of end-to-end RSVP.

Applies only when SIP Preconditions is not supported by the far end. (not a reservation failure)

Call is reattempted without SIP Preconditions.

  • CAC reverts to local RSVP
  • RSVP policy configured for SIP Preconditions is used for local RSVP
  • Cluster-internal RSVP agents are used (Three Call Legs)
    • Originating phone to its RSVP agent
    • RSVP agent of originating phone to RSVP agent of SIP trunk
    • RSVP agent to far end


Only additional step for SIP RSVP – Configure SIP Profile for RSVP

  • RSVP Over SIP -> E2E
  • SIP Rel1xx Option -> Send PRACK if 1xx Contain SDP
  • Fall back to local RSVP


CUCM GK intercluster trunk

H.225 trunk for 3.2 CCM later

Trunks register as a GW to the GK.

H.323 ID is the trunkname+number of each call processing server in the cluster.


H323 GK – Doubles the Payload of the Codec to determine how much BW is consumed by a call.

  • G711 128k
  • G729 16k


Interzone- applies to all calls coming into and going out of a specified zone (interzone calls)

Total – applies to all calls in the specified zone (interzone and intrazone calls)

Session – applies to each call in the specified zone (specifies the max BW per call)


Example Config:


zone local ClusterA

zone local ClusterB

zone prefix ClusterA 511*

zone prefix ClusterA 521*

zone prefix ClusterB 512*

zone prefix ClusterB 522*

bandwidth interzone default 64

bandwidth interzone zone ClusterB 48

bandwidth session default 128

bandwidth total zone ClusterB 688

gw-type-prefix 1t default-technology

no shutdown


Call will be re-routed to another item in the Route List / Route group in the backup path.


    1. Configure the GK
    2. Add the GK to CUCM
    3. Add the GK controlled trunk
    4. Point RP / RL to the trunk


Extension Mobility / Device Mobility

Device Mobility

Issues with Roaming Devices

  • Region – Dynamic
  • Location – Dynamic
  • SRST reference – Dynamic
  • AAR group – Dynamic
  • CSS – Dynamic
  • MRG / MRGL – Dynamic
  • Other settings


Device mobility can be used in multisite environments with centralized call processing.

IP subnet is what allows for identification of site


Roaming Sensitive Settings

  • Local Route Group
  • Date / Time Group
  • Region
  • SRST Reference
  • MRGL
  • Location
  • Network Locale
  • Physical Locations – Used to Determine what settings for Roaming Phone
  • Device Mobility Group – Used to Determine what settings for Roaming Phone


Device Mobility related Settings

  • Device Mobility CSS
  • AAR Group
  • Calling Party Transformation CSS


Device pool of remote site is laid over onto roaming phone to apply roaming settings.


Device Mobility Info – IP Subnet associated to one or more device pools.

Physical Location – Used to tag one or more device pools

Device Mobility Group – Tag assigned to one or more device pools. Used to identify if a device is roaming within a group or between mobility groups.


If the IP address of the phone matches a configured IP subnet, one of the associated device pools is selected (load-shared)


If the selected device pool is different than the home device pool (configured on phone) these settings are checked:

  • If the Physical Location is not different, the pone config is not changed.
  • If the Physical Location is different, the roaming-sensitive settings are applied of the roaming device pool.
  • Additionally if the device mobility groups are not different, than the device mobility related settings of the roaming device pool are applied.

All other cases the home device pool is applied.


Phone must be enabled for Device Mobility.


Not applying settings related to Device Mobility might lead to suboptimal call-routing paths.


Line CSS is never modified by Device Mobility.

Device CSS is modified only when roaming between physical locations within the same device mobility group.

  • Line / device approach recommended in a roaming environment


Globalized Call routing eliminates the needs for device mobility groups


Config Steps Device Mobility

    1. Config Physical Locations
    2. Config Device Mobility Group
    3. Config Device Pools
    4. Config Device Mobility Info (Subnets)
    5. Set the Device Mobility mode using:
      1. CCM Service Parameter for default for all phones
      2. The Phone configuration window for individual phones


Extension Mobility

Extension bound to profiles

Speed dials assigned to profiles.

Services are assigned to profiles.

MWI is updated during login.


What to do for multiple logins for EM.


Dynamic Phone parameters

  • User MoH
  • Phone button template
  • Softkeys
  • Locale
  • Dnd
  • Phone service subscriptions


Different phone model from phone profile. – Only settings that apply will be applied to the target phone.

Default device profile is applied only if the phone model series is different (feature safe)

794x can share profiles

796x can share profiles

797x can share profiles


Cisco EM does not modify the device CSS.

Only the line CSS is modified.


Using local route groups is recommended for EM.


Setup Steps EM

    1. Activate Cisco EM service
    2. Set EM service parameters
    3. Add the Cisco EM service to phone service to CUCM
    4. Create default device profiles for all phone models used (optional)
    5. Create device profiles and subscribe them to Cisco EM service.
    6. Create end users and associate them to device profiles
    7. Enable Cisco EM for phones and subscribe them to Cisco EM service.


Call Control Discovery (CCD) – Service Advertisement Framework (SAF)

Taking a large deployment and setting up centralized call routing across clusters.


Scalability issues in Large Networks

Full-mesh configuration

Very complex, suitable only for small networks

Hub and spoke configuration

Scales better than full mesh

Requires redundant deployment of central services

Changes have to manually configured

PSTN backup has to implemented independently in each call routing domain.

No dynamic exchange of call-routing information and no automatic PSTN backup.


CCD introduced in CCM 8

Available on the following platforms.

  • CUCM
  • SRST
  • CUBE
  • IOS GW


CCD-enabled call agents advertise to and learn from the network.

SAF is used to distribute information (SAF client / SAF Forwarder)

SAF forwarders interact with CCD enabled call agents (SAF Clients)

  • SAF forwarder learns information from SAF client.
  • SAF forwarders exchange information with each other.
  • SAF forwarder advertises all learned information to SAF client.


SAF-FP – SAF Forwarding Protocol

SAF-CP – SAF Client Protocol


SAF Forwarder is always an IOS router

Two types of SAF Clients

  • External
    • SAF-CP is used
    • SAF client is CUCM
    • SAF client and SAF forwarder are different devices
  • Internal
    • SAF client and SAF forwarder are the same device.
    • SAF clients are CUCME, SRST, CUBE, IOS GW
    • Internal API used


SAF Header – Service ID, Metrics

  • Relevant to SAF forwarders
  • Identifies service type and unique instance
  • Used by FWDs to propagate advertisements
  • Metric used to avoid loops


SAF Service Data – IP ADDR, Port, Length

  • Relevant to SAF clients
  • Service-specific information
  • Transparent to forwarders
  • Client data depends on service type


SAF-FP – Uses features and functions like EIGRP

  • BW percent
  • Hello interval
  • Hold time
  • Split horizon
  • Authenticated updates
  • Incremental updates

Works independent of IP routing protocols in place.


Two options for Neighbor relationships:

  • Layer 2 adjacent
    • Multicast (with dynamic discovery)
    • Unicast (with static configuration)
  • Non-layer 2 adjacent
    • Static configuration


SAF client functions:

  • Register to the network
  • Publish services
  • Subscribe to services
  • Send keepalives

SAF Forwarder functions:

  • Propagate updates received from SAF clients to other forwarders
  • Send hellos to other SAF forwarders
  • Propagate updates to SAF clients


CUCM – is going to generate SAF data packet to SAF forwarder.


CCD enables call agents to exchange call-routing information:

  • Dial plan information
  • Reachability information (IP address of call agents)

Allows dynamic routing based on information learned through SAF

  • No need for full-meshed call routing config
  • No need for centralized gatekeepers
  • Only local number ranges that should be advertised must be configured

Propagated dial plan information has two parts:

  • Enterprise-owned, internally used numbers
  • Exchange (PSTN) numbers for PSTN backup

Simplifies dial plan implementation in large networks


CUCM CCD Service responsible for

  • Hosted DN ranges
  • PSTN failover information (ToDID rule) – Adds prefixes to make number fully PSTN qualified
  • Trunk Information
  • Configured with one or two trunks (SAF CCD SIP and one SAF enabled H323 ICT) – Used to determine IP and signaling protocols for call agents


CCD requesting service

  • Learning DN ranges from the SAF network
  • Exists only once per CUCM cluster
  • Configured with one or two trunks (SAF CCD SIP and one SAF enabled H323 ICT) – Used to determine IP and signaling protocols for call agents


Filters can be setup to blog received routes based on:

  • Learned pattern prefix
  • Learned pattern
  • Remote call control identity (SAF ID)
  • Remote IP

Load balancing occurs from learned routes:

  • Round robin between protocols, among local trunks (SIP / H323) and learned remote IP addresses

Partitions and CSS

  • All learned patterns are put into on configurable PT
  • All devices that should have access to learned routes need access to that partition from their CSS
  • AAR CSS is used for PSTN backup calls.


Routes are only learned via the trunk available to the SAF forwarder (E.G SIP trunk = SIP only routes)


Route marked unreachable via IP if SAF agent loses connection to SAF forwarder.

ToDID Rule used for backup.


SAF Setup

  • Configure SAF forwarders on IOS routers
    • Specify same autonomous system on all SAF forwarders
  • Implement internal SAF client
    • Configure trunk profile with IP to be used for call setup.
    • Configure DN number blocks to be advertised.
    • Configure CCD profile referring to director number blocks and trunk to be used.
    • Configure actual CCD process (channel) referring to SAF forwarder by AS number.
      • Enable advertising service by referring to call control profile.
      • Enable requesting service
    • Configure VoIP DP referring to SAF


  • Add external SAF client (CUCM) to SAF forwarder
    • Specify SAF ID, username, and password of external client
    • Map external SAF client to SAF AS
  • Add SAF forwarder (IOS Router) to SAF client (CUCM)
    • Specify SAF ID, username, and password as configured on SAF forwarder
  • Configure CCD at external SAF client:
    • Configure SAF trunks
    • Configure hosted DN patterns and hosted DN groups
    • Configure CCD advertising service
    • Configure CCD requesting service and partition for learned patterns


Configure SAF Forwarder

router eigrp SAF

service-family ipv4 autonomous-system 1

sf-interface FastEthernet0/0

topology base


external-client HQ_SAF



service-family external-client listen ipv4 5050

External-client HQ_SAF

usernarne SAFUSER



SAF digits are left to right learned.


CCD Service parameters – can be used to limit the number of learned routes.


voice service saf

profile trunk—route 1

session protocol sip interface loopback 1 transport

tcp port 5060


profile dn-block 1 alias—prefix 1972555

pattern 1 type extension 4XXX


Profile callcontrol 1


Trunk-route 1

Dn-block 1


Channel 1 vrouter SAF asystem 1

subscribe callcontrol wildcarded

publish callcontrol 1


Dial-peer voice 2045 voip

Destination-pattern .T

Session target saf


Show eigrp service-family ipv4 clients


In order to see SAF learned routes, you have to use RTMT.


Show voice saf dndb all – shows learned SAF routes on a CUCME SAF client


AAR is used by SAF for the ToDID rule

SRST uses the ToDID rule to the PSTN.

CCD IP unreachable timer is 60sec by default


Advanced configuration mode needed for Clustering over the wan, multiple SAF forwarders are setup at each site.

You can’t enable SAF on encrypted or authenticated SIP trunks

Permanent link to this article:


    • Jeff Lock on December 31, 2015 at 9:31 am
    • Reply

    Hi Tim,
    Did this exam only include multiple choice questions or are there also questions that require these configurations you are showing in your notes?

    1. Hi Jeff,

      The test is a mix of multiple choice, drag and drop and config snip analysis. No actual lab work. You will be given blocks of configuration and asked either what’s missing or which of the following would correctly finish the configuration in the example.

      Hope that helps.

Leave a Reply