You are on page 1of 848

iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol.

1) - Detailed Solutions Guide  

1 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  1:  Labs  1-­‐2  
Version  1.0  
 

2 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Table  of  Contents


 
Section  1:   Configure  and  Troubleshoot  Cisco  Collaboration  Infrastructure  ..................................................  5  
Lab  1:    CDP,  LLDP,  and  VLANs  ...........................................................................................................................  5  
Lab  2:    DHCP,  NTP,  and  TFTP  ..........................................................................................................................  27  
Section  2:   Configure  and  Troubleshoot  CUCM  and  CUCME  Endpoints  .......................................................  57  
Lab  3:    CUCM  SCCP  and  SIP  Basic  Phone  Registration  ....................................................................................  57  
Lab  4:    CUCM  SCCP  and  SIP  Basic  Configuration  ............................................................................................  74  
Lab  5:    CUCM  SCCP  and  SIP  Advanced  Phone  Configuration  ..........................................................................  98  
Lab  6:    CUCME  SCCP  Basic  Phone  Registration  .............................................................................................  116  
Lab  7:    CUCME  SIP  Basic  Phone  Registration  ................................................................................................  130  
Lab  8:    CUCME  SCCP  and  SIP  Basic  Configuration  .........................................................................................  146  
Lab  9:    CUCME  SCCP  and  SIP  Advanced  Phone  Configuration  ......................................................................  157  
Section  3:   Configure  and  Troubleshoot  Voice  Gateways  ..........................................................................   167  
Lab  10:    MGCP  Gateway  Configuration  ........................................................................................................  167  
Lab  11:    SIP  Gateway  Configuration  .............................................................................................................  183  
Lab  12:    H.323  Gateway  Configuration  .........................................................................................................  195  
Lab  13:    H.323  Trunk  Configuration  ..............................................................................................................  206  
Lab  14:    SIP  Trunk  Configuration  ..................................................................................................................  218  
Lab  15:    Cisco  Unified  Border  Element  (CUBE)  Configuration  ......................................................................  232  
Section  4:   Configuring  and  Troubleshooting  CUCM  and  CUCME  Call  Routing  ...........................................   255  
Lab  16:    Basic  Dial-­‐Plan  Configuration  ..........................................................................................................  255  
Lab  17:    Advanced  Dial-­‐Plan  Configuration  ..................................................................................................  294  
Lab  18:    Digit  Manipulations  and  Presentations  ...........................................................................................  318  
Lab  19:    Globalized  and  Localized  Dialing  .....................................................................................................  341  
Lab  20:    CUCM  Hunting  and  Queuing  ...........................................................................................................  359  
Lab  21:    Time  of  Day  Routing  Configuration  .................................................................................................  375  
Lab  22:    Device  Mobility  ...............................................................................................................................  383  
Lab  23:    Unified  Mobility  ..............................................................................................................................  391  
Lab  24:    Extension  Mobility  and  Extension  Mobility  Cross  Cluster  ...............................................................  410  
Lab  25:    URI  Dialing  .......................................................................................................................................  433  
Lab  26:    Service  Advertisement  Framework  and  Call  Control  Discovery  ......................................................  446  
Lab  27:    CUCME  Call  Routing  ........................................................................................................................  459  
Lab  28:    CUCME  Call  Hunting  Configuration  .................................................................................................  467  
Lab  29:    Basic  Automatic  Call  Distribution  (B-­‐ACD)  ......................................................................................  473  
Section  5:   Configuring  and  Troubleshooting  CUCM  and  CUCME  Media  Resources  ...................................   487  
Lab  30:    CUCM  Conferencing  Media  Resources  Configuration  ....................................................................  487  
Lab  31:    CUCM  Video  Conferencing  ..............................................................................................................  515  
Lab  32:    CUCME  Media  Resources  Configuration  .........................................................................................  536  
Section  6:   Configuring  and  Troubleshooting  Call  Admission  Control  ........................................................   546  
Lab  33:    CUCM-­‐Based  CAC  ............................................................................................................................  546  
Lab  34:    RSVP  Configuration  .........................................................................................................................  567  
Section  7:   Configuring  and  Troubleshooting  High  Availability  Features  ...................................................   582  
Lab  35:    CUCM  Automated  Alternate  Routing  ..............................................................................................  582  
Lab  36:    CUCM  High  Availability  ...................................................................................................................  594  
Section  8:   Configuring  and  Troubleshooting  Cisco  Unity  Connection  .......................................................   610  
Lab  37:    CUCM  SIP  Integration  ......................................................................................................................  610  

3 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab  38:    CUCM  SCCP  Integration  ..................................................................................................................  626  


Lab  39:    CUCME  Integration  .........................................................................................................................  642  
Lab  40:    CUC  Features  ...................................................................................................................................  651  
Lab  41:    Digital  Networking  Configuration  ...................................................................................................  665  
Section  9:    Configuring  and  Troubleshooting  Cisco  Unity  Express  .............................................................   671  
Lab  42:    CUCME  Integration  .........................................................................................................................  671  
Lab  43:    CUE  Features  ...................................................................................................................................  680  
Lab  44:    CUCM  Integration  ...........................................................................................................................  687  
Section  10:    Configuring  and  Troubleshooting  Quality  of  Service  (QoS)  .....................................................   697  
Lab  45:    Link  Efficiency  Mechanisms  ............................................................................................................  697  
Lab  46:    Classification  and  Marking  ..............................................................................................................  712  
Lab  47:    Congestion  Management  ................................................................................................................  723  
Section  11:    Configuring  and  Troubleshooting  Cisco  Unified  IM  &  Presence  ..............................................   731  
Lab  48:    CUCM  Integration  ...........................................................................................................................  731  
Lab  49:    Jabber  for  Windows  ........................................................................................................................  747  
Lab  50:    SB  Presence  and  Jabber  Configuration  ...........................................................................................  761  
Lab  51:    Federation  .......................................................................................................................................  785  
Section  12:    Configuring  and  Troubleshooting  Unified  Contact  Center              Express  ....................................   805  
Lab  52:    CUCM  Integration  ...........................................................................................................................  805  
Lab  53:    ICD  Functionality  .............................................................................................................................  822  
Lab  54:    UCCX  Script  Customization  .............................................................................................................  828  
 

4 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Section 1: Configure and Troubleshoot Cisco Collaboration Infrastructure


Lab 1: CDP, LLDP, and VLANs
Task 1.1 Use  CDP  to  determine  the  location  of  phones  on  3750  and  Etherswitch  modules.  
 
CDP  is  primarily  used  to  obtain  protocol  addresses  of  neighboring  devices  and  discover  the  platform  of  
those  devices.  CDP  can  also  be  used  to  display  information  about  the  interfaces  your  router  uses.  CDP  
is  media  and  protocol-­‐independent,  and  runs  on  all  Cisco-­‐manufactured  equipment  including  routers,  
bridges,  access  servers,  and  switches.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/guide/ffun_c/fcf015.html]    
 
CDP  is  going  to  come  in  very  handy  here  because  we  have  no  idea  where  the  phones  are  located  in  the  
current  infrastructure.  Sure,  we  have  a  nice  diagram  and  Supplementary-­‐Info.pdf  file  that  should  tell  us  
where  the  phones  are  located,  but  this  may  not  always  be  the  case.  Remember,  there  are  differences  
based  on  the  fact  that  some  phones  are  located  at  the  datacenter  that  houses  the  pods  and  some  that  
are  local  to  you  (when  using  a  Hard  VPN).  If  you  are  using  local  phones,  you  will  see  the  MAC  addresses  
of  those  phones  show  up  on  a  different  port  that  may  be  described  in  the  documentation.  That’s  why  it  
is  always  important  to  verify  the  documentation.  You  can’t  always  trust  it—so  verify  it  to  put  your  
mind  at  ease.  
 
SW1  
In  the  below  we  can  see  that  there  are  phones  connected  to  ports  Fa1/0/11,  Fa1/0/12,  Fa1/0/13,  
Fa1/0/14,  Fa1/0/15,  and  Fa1/0/22.  This  is  easy  to  identify  because  the  “Device  ID”  starts  with  the  
“SEP”  prefix.  When  matching  the  MAC  addresses  with  the  output  of  this  command,  we  can  see  that  
those  phones  in  port  Fa1/0/13  and  Fa1/0/14  correspond  to  HQ  Phone  1  and  HQ  Phone  2  (which  are  
local  to  you).  Also,  you  can  see  that  the  phone  in  port  Fa1/0/15  is  local  to  you  as  well.  This  should  serve  
as  your  PSTN  phone.  The  other  ports  which  have  phones  connected  are  described  in  the  
Supplementary-­‐Info.pdf  file.  They  are  HQ  Phone  1  (Fa1/0/11),  HQ  Phone  2  (Fa1/0/12),  and  PSTN  Phone  
(Fa1/0/22).  Obviously,  this  means  that  you  have  two  sets  of  phones  that  you  are  able  to  configure.  You  
do  not  have  to  configure  both  sets,  however.  My  advice  would  be  to  configure  the  set  of  phones  that  
are  local  to  you,  if  applicable.  
 
SW1#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID


BB Fas 1/0/24 120 R S I 2811 Fas 0/0
HQUCCX Fas 1/0/10 125 H VMware eth0
SEP189C5DB65DE7 Fas 1/0/11 157 H P IP Phone Port 1
SEP1C1D86C54015 Fas 1/0/13 120 H P IP Phone Port 1
SEP1C17D34059C7 Fas 1/0/22 156 H P IP Phone Port 1
SEP1C1D86C53FD5 Fas 1/0/15 125 H P IP Phone Port 1
SEPDC7B9477E268 Fas 1/0/14 144 H P IP Phone Port 1
HQCUC Fas 1/0/10 134 H VMware eth0
SEP0022905A788A Fas 1/0/12 165 H P IP Phone Port 1
HQIMP Fas 1/0/10 131 H VMware eth0
HQSUB Fas 1/0/10 125 H VMware eth0
HQPUB Fas 1/0/10 147 H VMware eth0
R1 Fas 1/0/1 65 R S I CISCO2911 Gig 0/0

5 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
In  the  below  we  can  see  that  there  are  phones  connected  to  ports  Gi0/2/0,  Gi0/2/1,  Gi0/2/2,  and  
Gi0/2/3.  We  have  the  same  situation  here  that  we  had  on  SW1.  Some  phones  are  directly  connected  to  
the  datacenter  rack,  while  others  are  local  to  you.  In  this  case,  Gi0/2/0  and  Gi0/2/1  are  used  as  SB  
Phone  1  and  Phone  2,  respectively.  Of  course,  if  you  do  have  local  phones,  use  those  as  your  SB  Phone  
1  and  Phone  2  (ports  Gi0/2/2  and  Gi0/2/3).  
 
R2# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID


SEPB4A4E329CFCC Gig 0/2/1 178 H M IP Phone Port 1
SEP189C5D21D0C3 Gig 0/2/0 177 H M IP Phone Port 1
SEP001EF7283385 Gig 0/2/3 131 H M IP Phone Port 1
SBCUC Gig 0/1 166 H VMware eth0
SBIMP Gig 0/1 144 H VMware eth0
SEP1C1D862F0B87 Gig 0/2/2 132 H M IP Phone Port 1
SBPUB Gig 0/1 155 H VMware eth0
R1 Ser 0/1/0.201 73 R S I CISCO2911 Ser 0/1/0.102

R3  
R3  presents  the  same  situation  as  R2.  
 
R3#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID


SEP1C1D86C58106 Gig 0/2/1 156 H M IP Phone Port 1
SEPD0574CF78944 Gig 0/2/0 140 H M IP Phone Port 1
SEP001EBE923406 Gig 0/2/2 174 H M IP Phone Port 1
SEP1C1D86C53EBF Gig 0/2/3 135 H M IP Phone Port 1
R1 Ser 0/1/0.301 78 R S I CISCO2911 Ser 0/1/0.103
 
   

6 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.2 Find  out  the  current  CDP  timer  settings  and  set  each  to  half  the  configured  time.  
 
Each  device  you  configure  for  CDP  sends  periodic  advertisements  to  a  multicast  address.  The  
advertisements  contain  hold-­‐time  information,  which  indicates  the  length  of  time  that  a  receiving  
device  should  hold  CDP  information  before  discarding  it.  You  can  configure  the  advertisement  or  
refresh  timer  and  the  hold  timer.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/guide/ffun_c/fcf015.html]    
 
The  goal  in  this  task  is  to  first  determine  how  the  CDP  timer  settings  are  currently  configured.  After  
that,  we  should  use  that  information  to  make  an  adjustment  to  the  configuration.  The  command  show
cdp  will  display  the  timer  information.  By  default  the  CDP  timer  is  set  to  60  seconds  and  the  hold  
timer  is  set  to  180  seconds.  
 
R1,  R2,  R3,  and  SW1  
SW1#show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is enabled

Now  that  we  know  the  default  timer  settings,  we  can  make  the  new  settings  changes.  Enter  global  
configuration  mode  and  enter  the  command  cdp timer 30,  which  is  exactly  half  of  the  originally  
configured  value  (60  seconds).  Next,  don’t  forget  about  the  hold  time  value!  If  we  make  a  change  to  
the  CDP  timer  itself,  we  should  also  make  that  change  to  the  hold  timer,  since  they  work  hand  in  hand  
in  determining  whether  CDP  information  is  current.  Also,  the  original  question  asked  that  we  “set  each  
to  half  the  configured  time”.  The  command  to  set  the  hold  time  is  cdp holdtime 90,  which  is  half  
of  the  originally  configured  value  of  180  seconds.  
 
R1,  R2,  R3,  and  SW1  
SW1#conf t
SW1(config)#cdp timer 30
SW1(config)#cdp holdtime 90
 
 
   

7 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.3 Find  out  the  phone  type  and  how  much  power  is  being  drawn  from  each  phone.  
 
In  addition  to  running  the  show cdp neighbors  command,  the  show cdp neighbors
<interface> detail  command  can  be  extremely  useful.  The  number  one  reason  is  because  we  
can  see  the  type  of  phone  that  is  connected  to  that  port.  We  need  to  use  this  information  when  
registering  the  phone  to  either  CUCM  or  CUCME.  In  addition,  we  can  see  the  total  power  currently  
being  drawn  by  the  IP  phone  in  question.  In  the  first  example  below,  notice  that  this  is  a  9971  phone  
with  a  total  power  draw  of  13.588  Watts.  
 
SW1  
SW1#show cdp neighbors fa1/0/13 detail
-------------------------
Device ID: SEP1C1D86C54015
Entry address(es):
Platform: Cisco IP Phone 9971, Capabilities: Host Phone
Interface: FastEthernet1/0/13, Port ID (outgoing port): Port 1
Holdtime : 136 sec

Version :
sip9971.9-4-1SR1-2

advertisement version: 2
Duplex: full
Power drawn: 13.588 Watts
Power request id: 7063, Power management id: 1
Power request levels are:13588 0 0 0 0
Management address(es):
 
SW1#show cdp neighbors fa1/0/14 detail
-------------------------
Device ID: SEPDC7B9477E268
Entry address(es):
Platform: Cisco IP Phone 7965, Capabilities: Host Phone
Interface: FastEthernet1/0/14, Port ID (outgoing port): Port 1
Holdtime : 147 sec

Version :
SCCP45.9-3-1SR1-1S

advertisement version: 2
Duplex: full
Power drawn: 12.000 Watts
Power request id: 57960, Power management id: 1
Power request levels are:12000 0 0 0 0
Management address(es):
 
SW1#show cdp neighbors fa1/0/15 detail
-------------------------
Device ID: SEP1C1D86C53FD5
Entry address(es):
IP address: 10.10.253.9
Platform: Cisco IP Phone 9971, Capabilities: Host Phone
Interface: FastEthernet1/0/15, Port ID (outgoing port): Port 1
Holdtime : 146 sec

Version :
sip9971.9-4-1SR1-2

advertisement version: 2
Duplex: full
Power drawn: 13.588 Watts
Power request id: 56273, Power management id: 1
Power request levels are:13588 0 0 0 0
Management address(es):

8 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
R2#show cdp neighbors gi0/2/2 detail
-------------------------
Device ID: SEP1C1D862F0B87
Entry address(es):
Platform: Cisco IP Phone 7965, Capabilities: Host Two-port Mac Relay
Interface: GigabitEthernet0/2/2, Port ID (outgoing port): Port 1
Holdtime : 127 sec
Second Port Status: Down

Version :
SCCP45.9-3-1SR1-1S

advertisement version: 2
Duplex: full
Power drawn: 12.000 Watts

R2#show cdp neighbors gi0/2/3 detail


-------------------------
Device ID: SEP001EF7283385
Entry address(es):
IP address: 10.10.21.249
Platform: Cisco IP Phone 7965, Capabilities: Host Two-port Mac Relay
Interface: GigabitEthernet0/2/3, Port ID (outgoing port): Port 1
Holdtime : 164 sec
Second Port Status: Down

Version :
SCCP45.9-3-1SR1-1S

advertisement version: 2
Duplex: full
Power drawn: 12.000 Watts

R3  
R3#show cdp neighbors gi0/2/2 detail
-------------------------
Device ID: SEP001EBE923406
Entry address(es):
Platform: Cisco IP Phone 7965, Capabilities: Host Two-port Mac Relay
Interface: GigabitEthernet0/2/2, Port ID (outgoing port): Port 1
Holdtime : 144 sec
Second Port Status: Down

Version :
term65.default

advertisement version: 2
Duplex: full
Power drawn: 12.000 Watts

R3#show cdp neighbors gi0/2/3 detail


-------------------------
Device ID: SEP1C1D86C53EBF
Entry address(es):
Platform: Cisco IP Phone 9971, Capabilities: Host Two-port Mac Relay
Interface: GigabitEthernet0/2/3, Port ID (outgoing port): Port 1
Holdtime : 157 sec
Second Port Status: Down

Version :
sip9971.9-4-1SR1-2

advertisement version: 2
Duplex: full
Power drawn: 13.588 Watts

9 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.4 Enable  LLDP  and  set  the  timers  to  half  of  the  default  time.  
 
To  support  non-­‐Cisco  devices  and  to  allow  for  interoperability  between  other  devices,  Cisco  supports  
the  IEEE  802.1AB  LLDP.  LLDP  is  a  neighbor  discovery  protocol  that  is  used  for  network  devices  to  
advertise  information  about  themselves  to  other  devices  on  the  network.  This  protocol  runs  over  the  
data-­‐link  layer,  which  allows  two  systems  running  different  network  layer  protocols  to  learn  about  
each  other.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/3se/int_hw_com
ponents/configuration_guide/b_int_3se_3650_cg/b_int_3se_3650_cg_chapter_0101.html]  
 
In  order  to  configure  LLDP  we  simply  need  to  use  the  configuration  command  lldp run.  This  will  
start  the  process  on  the  device  so  it  can  begin  transmitting  and  receiving  LLDP  advertisements.  
 
R1,  R2,  R3,  and  SW1  
R3#conf t
R3(config)#lldp run

In  order  to  set  the  values  for  the  timers  to  half  of  the  default  time,  we  first  need  to  know  the  default  
value.  This  can  be  accomplished  using  the  command  show lldp.  This  will  display  current  timer  
information  so  those  values  can  be  used  in  determining  what  the  new  values  should  be.  In  this  case,  
the  default  values  for  advertisements  and  hold  time  are  30  and  120  seconds,  respectively.  
 
R3#show lldp

Global LLDP Information:


Status: ACTIVE
LLDP advertisements are sent every 30 seconds
LLDP hold time advertised is 120 seconds
LLDP interface reinitialisation delay is 2 seconds

This  means  that  since  the  question  is  asking  for  those  values  to  be  half  of  the  default,  we  should  set  
them  to  15  seconds  for  the  advertisements  and  60  seconds  for  the  hold  time.  
 
R1,  R2,  R3,  and  SW1  
R3(config)#lldp timer 15
R3(config)#lldp holdtime 60
 
   

10 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.5 Use  LLDP  to  get  the  MAC  address  of  the  phone  as  well  as  the  phone  type.  
 
LLDP  can  be  used  to  retrieve  the  same  basic  information  as  CDP.  In  this  case,  we  are  looking  to  get  the  
MAC  address  and  phone  type  of  the  connected  phones.  Please  note  that  phones  connected  over  the  
Hard  VPN  will  not  be  found  using  LLDP.  This  is  because  the  Layer  2  VPN  is  only  configured  to  tunnel  the  
CDP  protocol.  To  complete  this  section,  it  is  best  to  use  the  rack  phones  to  gather  LLDP  information.  
 
Much  like  CDP,  the  show lldp neighbors  command  should  be  used  to  get  information  about  
each  device.  In  this  case,  we  need  both  the  MAC  address  and  phone  type.  So  we  will  also  need  to  run  
the  show lldp neighbors <interface> detail command  to  gather  that  information.  
 
SW1  
SW1#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID Local Intf Hold-time Capability Port ID


SEP1C17D34059C7 Fa1/0/22 180 B,T 1C17D34059C7:P1
SEP0022905A788A Fa1/0/12 180 B,T 0022905A788A:P1
R1 Fa1/0/1 60 R Gi0/0.13
R1 Fa1/0/1 60 R Gi0/0.12
SEP189C5DB65DE7 Fa1/0/11 180 B,T 189C5DB65DE7:P1
R1 Fa1/0/1 60 R Gi0/0.11
R1 Fa1/0/1 60 R Gi0/0.100
R1 Fa1/0/1 60 R Gi0/0

Total entries displayed: 8

SW1#show lldp neighbors fa1/0/11 detail

Chassis id: 10.10.11.6


Port id: 189C5DB65DE7:P1
Port Description: SW PORT
System Name: SEP189C5DB65DE7

System Description:
Cisco IP Phone 9971, V1, sip9971.9-3-2-10

Time remaining: 153 seconds


System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses:
IP: 10.10.11.6
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Other/unknown
Media Attachment Unit type: 16

MED Information:

MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory

H/W revision: 1
F/W revision: sboot9971.031610R1-9-3-2-10.sebn
S/W revision: sip9971.9-3-2-10

11 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Serial number: FCH174395UX


Manufacturer: Cisco Systems, Inc.
Model: CP-9971
Capabilities: NP, PD, IN
Device type: Endpoint Class III
Network Policy(Voice): VLAN 11, tagged, Layer-2 priority: 5, DSCP: 46
Network Policy(Voice Signal): VLAN 11, tagged, Layer-2 priority: 0, DSCP: 0
PD device, Power source: PSE, Power Priority: Unknown, Wattage: 12.3
---------------------------------------------

Total entries displayed: 1

SW1#show lldp neighbors fa1/0/12 detail

Chassis id: 0.0.0.0


Port id: 0022905A788A:P1
Port Description: SW PORT
System Name: SEP0022905A788A

System Description:
Cisco IP Phone 7965G,V4, SCCP45.9-3-1SR1-1S

Time remaining: 127 seconds


System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Media Attachment Unit type: 16

MED Information:

MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory

H/W revision: 4
F/W revision: tnp65.8-3-1-21a.bin
S/W revision: SCCP45.9-3-1SR1-1S
Serial number: FCH12309MEP
Manufacturer: Cisco Systems, Inc.
Model: CP-7965G
Capabilities: NP, PD, IN
Device type: Endpoint Class III
Network Policy(Voice): VLAN 11, tagged, Layer-2 priority: 5, DSCP: 46
Network Policy(Voice Signal): VLAN 11, tagged, Layer-2 priority: 0, DSCP: 0
PD device, Power source: Unknown, Power Priority: Unknown, Wattage: 12.0
---------------------------------------------

Total entries displayed: 1

SW1#show lldp neighbors fa1/0/22 detail

Chassis id: 10.10.253.3


Port id: 1C17D34059C7:P1
Port Description: SW PORT
System Name: SEP1C17D34059C7

System Description:
Cisco IP Phone 9971, V1, sip9971.9-4-1SR1-2

Time remaining: 152 seconds

12 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

System Capabilities: B,T


Enabled Capabilities: B,T
Management Addresses:
IP: 10.10.253.3
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Other/unknown
Media Attachment Unit type: 16

MED Information:

MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory

H/W revision: 1
F/W revision: sboot9971.031610R1-9-4-1SR1-2.se
S/W revision: sip9971.9-4-1SR1-2
Serial number: FCH141788C1
Manufacturer: Cisco Systems, Inc.
Model: CP-9971
Capabilities: NP, PD, IN
Device type: Endpoint Class III
Network Policy(Voice): VLAN 199, tagged, Layer-2 priority: 5, DSCP: 46
Network Policy(Voice Signal): VLAN 199, tagged, Layer-2 priority: 0, DSCP: 0
PD device, Power source: PSE, Power Priority: Unknown, Wattage: 11.2
---------------------------------------------

Total entries displayed: 1

R2  
R2#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID Local Intf Hold-time Capability Port ID


SEP189C5D21D0C3 Gi0/2/0 180 B,T 189C5D21D0C3:P1
SEPB4A4E329CFCC Gi0/2/1 180 B,T B4A4E329CFCC:P1

Total entries displayed: 3

R2#show lldp neighbors gi0/2/0 detail


------------------------------------------------
Chassis id: 0.0.0.0
Port id: 189C5D21D0C3:P1
Port Description: SW PORT
System Name: SEP189C5D21D0C3

System Description:
Cisco IP Phone 7962G,V15, SCCP42.9-3-1SR1-1S

Time remaining: 142 seconds


System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Media Attachment Unit type: 16
Vlan ID: - not advertised

13 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Total entries displayed: 1

R2#show lldp neighbors gi0/2/1 detail


------------------------------------------------
Chassis id: 0.0.0.0
Port id: B4A4E329CFCC:P1
Port Description: SW PORT
System Name: SEPB4A4E329CFCC

System Description:
Cisco IP Phone 7965G,V8, SCCP45.9-3-1SR1-1S

Time remaining: 179 seconds


System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Media Attachment Unit type: 30
Vlan ID: - not advertised

Total entries displayed: 1

R3  
R3#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID Local Intf Hold-time Capability Port ID


SEPD0574CF78944 Gi0/2/0 180 B,T D0574CF78944:P1
SEP1C1D86C58106 Gi0/2/1 180 B,T 1C1D86C58106:P1

Total entries displayed: 2

R3#show lldp neighbors gi0/2/0 detail


------------------------------------------------
Chassis id: 0.0.0.0
Port id: D0574CF78944:P1
Port Description: SW PORT
System Name: SEPD0574CF78944

System Description:
Cisco IP Phone 7965G,V8, SCCP45.9-3-1SR1-1S

Time remaining: 124 seconds


System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Media Attachment Unit type: 30
Vlan ID: - not advertised

Total entries displayed: 1

R3#show lldp neighbors gi0/2/1 detail


------------------------------------------------

14 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Chassis id: 10.10.31.30


Port id: 1C1D86C58106:P1
Port Description: SW PORT
System Name: SEP1C1D86C58106

System Description:
Cisco IP Phone 9971, V1, sip9971.9-4-1SR1-2

Time remaining: 157 seconds


System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses:
IP: 10.10.31.30
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Other/unknown
Media Attachment Unit type: 30
Vlan ID: - not advertised

Total entries displayed: 1


 
   

15 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.6 Define  a  Voice  VLAN  on  the  3750  switchports  and  ensure  the  Data  VLAN  is  passed  to  
the  PC/Computer  port  of  the  connected  phones.  
 
This  task  is  asking  us  to  define  a  voice  and  data  VLAN  on  the  switchport  where  the  phones  are  
connected.  If  you  are  using  local  phones,  the  configuration  should  be  done  on  those  ports.  The  voice  
VLAN  feature  enables  access  ports  to  carry  IP  voice  traffic  from  an  IP  phone.  The  data  VLAN  is  going  to  
be  assigned  to  the  data  switchport  on  the  phone,  which  will  carry  the  traffic  from  any  PCs  that  happen  
to  be  connected  to  the  phone.  
 
Using  the  information  that  we  obtained  from  CDP  and/or  LLDP  in  the  previous  tasks,  we  can  determine  
the  switchports  that  we  should  configure  with  the  voice  and  data  VLAN  information.  In  this  case,  since  
local  phones  are  being  used,  we  can  configure  those  ports.  
 
First,  the  switchport  is  configured  as  an  access  port  using  the  configuration  switchport mode
access,  since  it  will  be  connected  directly  to  an  endpoint.  Next,  data  VLAN  12  is  configured  on  the  
switchport  using  the  command  switchport access vlan 12.  Next,  the  command  
switchport voice vlan 11  is  used  to  place  the  switchport  in  voice  VLAN  11.  Note  that  the  
actual  VLANs  that  should  be  used  were  defined  in  the  Supplemental-­‐Info.pdf  file.  Finally,  the  command  
spanning-­‐tree  portfast  is  entered  to  assure  that  the  port  skips  the  spanning-­‐tree  process  of  “blocking”,  
“listening”,  and  “learning”  before  entering  the  “forwarding”  state.  
 
SW1  
SW1(config)#interface fa1/0/13
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
SW1(config-if)#switchport voice vlan 11
SW1(config-if)#spanning-tree portfast

SW1(config)#interface fa1/0/14
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
SW1(config-if)#switchport voice vlan 11
SW1(config-if)#spanning-tree portfast

Next,  it  is  important  to  verify  that  the  configuration  was  successful.  After  all,  configuring  a  VLAN  
directly  on  a  switchport  doesn’t  guarantee  that  it  is  part  of  the  VLAN  database.  We  can  use  the  show
vlan brief  command  to  ensure  that  the  configured  VLANs  are  indeed  active  and  in  the  database.  
This  command  also  lists  the  ports  that  are  a  part  of  a  specific  VLAN.  
 
SW1  
SW1#show vlan brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Fa1/0/4, Fa1/0/5, Fa1/0/6
Fa1/0/7, Fa1/0/8, Fa1/0/9
Fa1/0/16, Fa1/0/17, Fa1/0/18
Fa1/0/19, Fa1/0/20, Fa1/0/21
Gi1/0/1, Gi1/0/2
11 VLAN0011 active Fa1/0/13, Fa1/0/14
12 VLAN0012 active Fa1/0/13, Fa1/0/14
13 VLAN0013 active Fa1/0/2, Fa1/0/3, Fa1/0/10
100 VLAN0100 active Fa1/0/23
199 VLAN0199 active Fa1/0/15, Fa1/0/22
1002 fddi-default act/unsup

16 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

1003 token-ring-default act/unsup


1004 fddinet-default act/unsup
1005 trnet-default act/unsup
 
   

17 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.7 Define  a  Voice  VLAN  on  the  Etherswitch  modules  and  ensure  the  Data  VLAN  is  passed  
to  the  PC/Computer  port  of  the  connected  phones.  
 
In  much  the  same  way  that  it  was  done  on  the  3750  switch,  the  Etherswitch  modules  on  R2  and  R3  
must  be  configured  with  both  voice  and  data  VLANs  as  well.  In  this  case,  SB  VLANs  should  be  21  (Voice)  
and  22  (Data)  while  SC  VLANs  should  be  31  (Voice)  and  32  (Data).  Once  again  CDP/LLDP  information  is  
used  to  make  the  decision  on  which  ports  should  receive  the  configuration.  
 
R2  
R2(config)#interface gi0/2/2
R2(config-if)#switchport mode access
R2(config-if)#switchport access vlan 22
R2(config-if)#switchport voice vlan 21
R2(config-if)#spanning-tree portfast

R2(config)#interface gi0/2/3
R2(config-if)#switchport mode access
R2(config-if)#switchport access vlan 22
R2(config-if)#switchport voice vlan 21
R2(config-if)#spanning-tree portfast
 
R3  
R3(config-if)#interface gi0/2/2
R3(config-if)#switchport mode access
R3(config-if)#switchport access vlan 32
R3(config-if)#switchport voice vlan 31
R3(config-if)#spanning-tree portfast

R3(config-if)#interface gi0/2/2
R3(config-if)#switchport mode access
R3(config-if)#switchport access vlan 32
R3(config-if)#switchport voice vlan 31
R3(config-if)#spanning-tree portfast

As  a  next  step,  verification  that  the  VLANs  are  indeed  active  should  be  done.  On  the  Etherswitch  
modules,  the  command  is  a  little  different.  This  can  be  accomplished  using  the  show vlan-switch
brief  command.  
 
R2  
R2#sh vlan-switch brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active
21 VLAN0021 active Gi0/2/2, Gi0/2/3
22 VLAN0022 active Gi0/2/2, Gi0/2/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

R3  
R3#sh vlan-switch brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Gi0/2/0, SM1/1
31 VLAN0031 active Gi0/2/2, Gi0/2/3
32 VLAN0032 active Gi0/2/2, Gi0/2/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup  

18 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.8 Name  the  VLANs  appropriately.  


 
This  task  simply  asks  us  to  name  the  VLANs  appropriately.  This  means  that  we  should  assess  the  
purpose  of  the  VLAN  and  provide  a  name.  At  this  point,  we  are  essentially  editing  the  VLAN  database,  
so  this  configuration  will  be  done  outside  of  interface  configuration  mode.  In  this  case,  we  must  enter  
global  configuration  mode  and  issue  the  command  vlan <VLAN number>  followed  by  the  
command  name <Descriptive Name>.  
 
R2  
R2(config)#vlan 21
R2(config-vlan)#name SB-PHONES
R2(config-vlan)#vlan 22
R2(config-vlan)#name SB-DATA

R3  
R3(config)#vlan 31
R3(config-vlan)#name SC-PHONES
R3(config-vlan)#vlan 32
R3(config-vlan)#name SC-DATA

SW1  
SW1(config)#vlan 11
SW1(config-vlan)#name HQ-PHONES
SW1(config-vlan)#vlan 12
SW1(config-vlan)#name HQ-DATA
SW1(config-vlan)#vlan 13
SW1(config-vlan)#name HQ-SERVERS

Next,  verification  must  be  done  to  confirm  that  the  names  have  changed  from  the  perspective  of  the  
VLAN  database.  This  can  be  accomplished  be  entering  the  now  familiar  commands  show vlan-
switch brief  for  the  Etherswitch  modules  and  show vlan brief  command  for  the  3750  
switch.  
 
R2  
R2#show vlan-switch brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Gi0/2/0, Gi0/2/1
21 SB-PHONES active Gi0/2/2, Gi0/2/3
22 SB-DATA active Gi0/2/2, Gi0/2/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

R3  
R3#sh vlan-switch brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Gi0/2/0, Gi0/2/1, SM1/1
31 SC-PHONES active Gi0/2/2, Gi0/2/3
32 SC-DATA active Gi0/2/2, Gi0/2/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

19 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

SW1  
SW1#show vlan brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Fa1/0/4, Fa1/0/5, Fa1/0/6
Fa1/0/7, Fa1/0/8, Fa1/0/9
Fa1/0/16, Fa1/0/17, Fa1/0/18
Fa1/0/19, Fa1/0/20, Fa1/0/21
Gi1/0/1, Gi1/0/2
11 HQ-PHONES active Fa1/0/13, Fa1/0/14
12 HQ-DATA active Fa1/0/13, Fa1/0/14
13 HQ-SERVERS active Fa1/0/2, Fa1/0/3, Fa1/0/10
100 VLAN0100 active Fa1/0/23
199 VLAN0199 active Fa1/0/15, Fa1/0/22
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
 
   

20 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.9 Determine  the  number  of  ports  in  each  VLAN  on  both  the  3750  switch  and  the  
Etherswitch  module.  
 
This  task  once  again  relies  on  a  command  that  has  been  used  in  previous  sections.  The  purpose  this  
time  is  to  discover  what  ports  are  members  in  which  VLANs.  For  Etherswitch  modules,  the  command  is  
show vlan-switch brief  and  for  the  3750,  the  command  is  show vlan brief.  We  can  see  
that  in  each  case,  there  are  2  ports  in  each  data/voice  VLAN.  
 
R2  
R2#show vlan-switch brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Gi0/2/0, Gi0/2/1
21 SB-PHONES active Gi0/2/2, Gi0/2/3
22 SB-DATA active Gi0/2/2, Gi0/2/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

R3  
R3#sh vlan-switch brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Gi0/2/0, Gi0/2/1, SM1/1
31 SC-PHONES active Gi0/2/2, Gi0/2/3
32 SC-DATA active Gi0/2/2, Gi0/2/3
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

SW1  
SW1#show vlan brief

VLAN Name Status Ports


---- -------------------------------- --------- -------------------------------
1 default active Fa1/0/4, Fa1/0/5, Fa1/0/6
Fa1/0/7, Fa1/0/8, Fa1/0/9
Fa1/0/16, Fa1/0/17, Fa1/0/18
Fa1/0/19, Fa1/0/20, Fa1/0/21
Gi1/0/1, Gi1/0/2
11 HQ-PHONES active Fa1/0/13, Fa1/0/14
12 HQ-DATA active Fa1/0/13, Fa1/0/14
13 HQ-SERVERS active Fa1/0/2, Fa1/0/3, Fa1/0/10
100 VLAN0100 active Fa1/0/23
199 VLAN0199 active Fa1/0/15, Fa1/0/22
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
 
   

21 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.10 Create  an  802.1Q  trunk  interface  to  R1  for  the  purpose  of  routing  between  VLANs.    
 
Trunking  is  a  way  to  carry  traffic  from  several  VLANs  over  a  point-­‐to-­‐point  link  between  the  two  
devices.  Two  ways  in  which  Ethernet  trunking  can  be  implemented  are:    
 
• Inter  Switch  Link  (ISL  -­‐  Cisco  Proprietary)  
• 802.1Q  (IEEE  Standard)  
 
In  this  case  we  are  tasked  with  creating  an  802.1Q  trunk  between  SW1  and  R1.  The  reason  a  trunk  is  
being  configured  is  to  pass  information  for  multiple  VLANs  across  the  same  physical  link.  In  order  to  
create  the  trunk,  we’ll  first  need  to  find  out  what  port  is  connected  to  R1  in  the  first  place.  By  referring  
back  to  the  output  of  the  show cdp neighbors  command,  it  is  apparent  that  R1  is  connected  to  
SW1  port  Fa1/0/1.  
 
From  there,  we  can  now  enter  the  configuration  for  Fa1/0/1  and  define  an  encapsulation  type  for  the  
switchport.  In  order  to  properly  configure  a  trunk  port,  a  type  of  encapsulation  must  first  be  defined  
using  the  command  switchport trunk encapsulation dot1q.  At  that  point,  the  
switchport mode  command  can  be  used  to  identify  the  port  as  a  trunk.  
 
SW1  
SW1(config-if)#interface Fa1/0/1
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk

The  next  step  after  the  configuration  is  complete  is  to  verify  the  status  of  the  interface.  How  can  we  
determine  if  our  configuration  worked?  The  next  task  will  tackle  that  subject.  
 
   

22 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.11 Ensure  that  the  configured  interface  status  is  “trunking”.  
 
This  task  essentially  asks  for  verification  of  the  previous  task.  It  is  very  important  to  verify  all  
configurations  in  some  fashion—especially  something  as  fundamental  as  switchport  trunking.  If  there  
are  errors  here,  it  can  cause  major  problems  down  the  road.  On  SW1,  we  must  use  the  command  
show interfaces trunk  to  verify  the  status  of  the  trunk  that  was  created  in  the  previous  task.  
 
SW1  
SW1#show interfaces trunk

Port Mode Encapsulation Status Native vlan


Fa1/0/1 on 802.1q trunking 1
Fa1/0/24 on 802.1q trunking 1

Port Vlans allowed on trunk


Fa1/0/1 1-4094
Fa1/0/24 1-4094

Port Vlans allowed and active in management domain


Fa1/0/1 1,11-13,100,199
Fa1/0/24 1,11-13,100,199

Port Vlans in spanning tree forwarding state and not pruned


Fa1/0/1 1,11-13,100,199
Fa1/0/24 1,11-13,100,199

Upon  examining  the  output  of  the  above  command,  the  first  thing  we  should  notice  is  that  the  
interface  is  now  successfully  “trunking”.  Now  don’t  get  too  excited  yet!  There  are  still  other  things  to  
verify.  You  have  no  idea  if  there  was  some  “sneaky”  configuration  added  by  your  CCIE  proctor  to  trip  
you  up  here.  
 
For  example,  we  can  see  that  the  native  VLAN  for  the  Fa1/0/1  interface  is  set  to  1,  which  is  the  default.  
This  means  that  any  packet  that  is  sent  without  an  802.1Q  tag  (untagged)  is  a  part  of  that  native  VLAN.  
If  the  native  VLAN  had  been  changed  to  use  VLAN  11  instead,  the  configuration  on  the  other  end  of  the  
trunk  (router  in  this  case)  would  have  to  change  to  accommodate  this.  
 
In  addition  to  the  native  VLAN,  the  next  section,  “VLANs  allowed  on  trunk”  is  very  important  as  well.  If  
for  some  reason  a  malicious  configuration  is  added  to  prevent  your  voice  and  data  VLAN  from  
communicating  across  your  trunk,  it  would  be  seen  here.  In  this  case,  all  is  well,  however,  since  we  can  
see  that  VLANs  ranging  from  1  to  4094  are  allowed  on  the  trunk.  Lastly,  verify  that  both  the  voice  and  
data  VLANs  are  active  and  in  the  spanning-­‐tree  “forwarding”  state.  As  you  can  see,  this  command  is  
vitally  important  to  properly  assessing  the  status  of  your  trunk.  
 
   

23 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.12 Determine  the  allowed  VLANs  on  the  trunk.  


 
This  task  asks  to  determine,  for  the  trunk  that  was  just  created  in  the  previous  task,  what  VLANs  are  
allowed  to  traverse  it.  Once  again,  as  detailed  in  the  previous  task,  we  need  to  use  the  show
interfaces trunk  command  to  verify  what  VLANs  are  allowed.  In  the  below,  we  can  see  that  a  
range  of  VLANs  starting  with  1  and  ending  with  4094  are  allowed  to  pass  across  the  trunk.  Remember,  
this  information  is  very  important  to  verify  since  “trickiness”  in  the  CCIE  Lab  is  not  outside  the  realm  of  
possibility.  
 
SW1  
SW1#show interfaces trunk

Port Mode Encapsulation Status Native vlan


Fa1/0/1 on 802.1q trunking 1
Fa1/0/24 on 802.1q trunking 1

Port Vlans allowed on trunk


Fa1/0/1 1-4094
Fa1/0/24 1-4094

Port Vlans allowed and active in management domain


Fa1/0/1 1,11-13,100,199
Fa1/0/24 1,11-13,100,199

Port Vlans in spanning tree forwarding state and not pruned


Fa1/0/1 1,11-13,100,199
Fa1/0/24 1,11-13,100,199
 
   

24 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 1.13 Configure  routing  between  VLANs  using  a  sub  interface  on  R1,  and  VLAN  interfaces  
on  R2  and  R3  (routing  protocol  already  configured).  
 
To  configure  routing  between  VLANs  on  R1,  we  must  first  determine  the  physical  port  that  is  being  
used  to  provide  the  trunk.  Once  again,  CDP  is  your  friend  here,  since  we  can  make  that  determination  
based  on  the  neighbors  that  appear  on  each  interface.  In  this  case,  the  SW1  neighbor  appears  on  
physical  interface,  GigabitEthernet0/0.  Knowing  this  information,  we  can  now  route  multiple  VLANs  
across  the  same  interface  using  the  concept  of  sub-­‐interfaces.  This  allows  the  creation  of  multiple  
virtual  interfaces  on  the  router  that  can  provide  encapsulation  for  a  specific  VLAN.  Since  we  have  three  
VLANs  (voice,  data,  and  servers)  we  can  create  three  sub-­‐interfaces  to  provide  routed  interfaces  for  
those  networks.  
 
R1  
R1(config)#interface GigabitEthernet0/0.11
R1(config-subif)# encapsulation dot1Q 11
R1(config-subif)# ip address 10.10.11.1 255.255.255.0

R1(config-subif)#interface GigabitEthernet0/0.12
R1(config-subif)# encapsulation dot1Q 12
R1(config-subif)# ip address 10.10.12.1 255.255.255.0

R1(config-subif)#interface GigabitEthernet0/0.13
R1(config-subif)# encapsulation dot1Q 13
R1(config-subif)# ip address 10.10.13.1 255.255.255.0

Since  the  router  has  knowledge  of  all  three  networks,  it  is  possible  to  route  packets  between  the  
networks  at  this  point.  As  for  the  R2  and  R3,  switched  virtual  interfaces  (SVIs)  should  be  created  to  
provide  routed  interfaces  for  each  VLAN.  This  is  done  from  global  configuration  by  using  the  command  
interface Vlan <VLAN number>.  After  that,  an  IP  address  and  subnet  mask  should  be  
supplied  for  the  newly  created  interface.    
 
R2  
R2(config)#interface Vlan21
R2(config-if)# ip address 10.10.21.1 255.255.255.0

R2(config-if)#interface Vlan22
R2(config-if)# ip address 10.10.22.1 255.255.255.0

R3  
R3(config)#interface Vlan31
R3(config-if)# ip address 10.10.31.1 255.255.255.0

R3(config-if)#interface Vlan32
R3(config-if)# ip address 10.10.32.1 255.255.255.0
 
To  verify  that  the  configurations  were  successful,  simply  enter  the  command  show ip interface
brief  to  determine  the  status  of  the  SVI  interfaces.  If  everything  was  configured  correctly,  the  status  
should  show  as  “up/up”  when  using  this  command.  If  not,  make  sure  that  you  have  at  least  1  active  
interface  for  the  VLAN  in  question.  
 
R2  
R2#show ip interface brief | i Vlan2
Vlan21 10.10.21.1 YES manual up up
Vlan22 10.10.22.1 YES manual up up
 

25 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3  
R3#show ip interface brief | i Vlan3
Vlan31 10.10.31.1 YES manual up up
Vlan32 10.10.32.1 YES manual up up

26 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 2: DHCP, NTP, and TFTP


Task 2.1 Configure  a  DHCP  pool  on  R3  to  provide  IP  addresses  and  a  TFTP  server  (VLAN  31  
interface  IP  address)  for  the  connected  phones.  
 
As  explained  in  RFC  2131,  Dynamic  Host  Configuration  Protocol,  DHCP  provides  configuration  
parameters  to  Internet  hosts.  DHCP  consists  of  two  components,  a  protocol  for  delivering  host-­‐specific  
configuration  parameters  from  a  DHCP  Server  to  a  host  and  a  mechanism  for  allocating  network  
addresses  to  hosts.  DHCP  is  built  on  a  client/server  model,  where  designated  DHCP  Server  hosts  
allocate  network  addresses  and  deliver  configuration  parameters  to  dynamically  configured  hosts.  By  
default,  Cisco  routers  running  Cisco  IOS  software  include  DHCP  server  and  relay  agent  software.  
 
DHCP  supports  three  mechanisms  for  IP  address  allocation:  
• Automatic  allocation—DHCP  assigns  a  permanent  IP  address  to  a  client.  
• Dynamic  allocation—DHCP  assigns  an  IP  address  to  a  client  for  a  limited  period  of  time  (or  until  
the  client  explicitly  relinquishes  the  address).  
• Manual  allocation—The  network  administrator  assigns  an  IP  address  to  a  client  and  DHCP  is  
used  simply  to  convey  the  assigned  address  to  the  client.  
 
The  format  of  DHCP  messages  is  based  on  the  format  of  Bootstrap  Protocol  (BOOTP)  messages,  which  
ensures  support  for  BOOTP  relay  agent  functionality  and  interoperability  between  BOOTP  clients  and  
DHCP  Servers.  BOOTP  relay  agents  eliminate  the  need  for  deploying  a  DHCP  Server  on  each  physical  
network  segment.  BOOTP  is  explained  in  RFC  951,  Bootstrap  Protocol  (BOOTP),  and  RFC  1542,  
Clarifications  and  Extensions  for  the  Bootstrap  Protocol.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fipr_c/1cfdhcp.html]    
 
This  task  involves  configuring  an  IOS-­‐based  DHCP  server  to  provide  an  IP  address  to  the  phones  at  SC.  
In  order  to  do  this,  we  must  first  determine  the  network  address  of  the  subnet  to  which  the  phones  
should  connect.  This  can  be  done  by  first  analyzing  the  Supplementary-­‐Info.pdf  document  to  determine  
the  VLAN  on  which  the  phones  should  exist.  Based  on  the  document,  we  should  use  Vlan  31  for  the  
phone  subnet.  In  the  configuration  of  R3,  we  can  then  determine  the  subnet  mask  by  looking  at  the  
running  configuration  for  that  switched  virtual  interface  (SVI).  
 
R3  
R3#show run int vlan 31

interface Vlan31
description *** SC PHONES ***
ip address 10.10.31.1 255.255.255.0

From  the  above,  we  see  that  the  subnet  mask  is  255.255.255.0  or  “/24”.  This  means  we  have  8  host  
bits  or  255  possible  addresses  within  this  subnet.  Of  course,  we  can  further  sub-­‐divide  this  network  
into  multiple  subnets,  but  that  is  another  topic  for  another  day!  Based  on  the  current  subnet  mask  for  
the  network  in  question,  the  network  address  is  10.10.31.0  and  the  broadcast  address  is  10.10.31.255.  
All  other  addresses  within  the  range  are  available  for  use  (10.10.31.1  –  10.10.31.254).  When  
configuring  any  DHCP  server,  the  network  address  will  be  used  directly  in  the  configuration.  The  range  
consists  of  possible  IP  addresses  that  could  be  used  for  host  assignment.  

27 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
The  IOS  configuration  takes  place  within  a  user-­‐defined  DHCP  pool.  The  dhcp pool  command  is  
entered  using  some  type  of  descriptive  name.  Under  the  DHCP  configuration,  the  network  command  
is  specified  to  define  the  network  for  IP  address  assignment.  The  default-router  command  
assigns  the  default  gateway  to  hosts  in  the  DHCP  pool.  Finally,  the  option 150  command  lists  the  
TFTP  server  address  which  the  phone  will  use  to  download  the  configuration  file.  
 
R3  
R3(config)#ip dhcp pool SC
R3(dhcp-config)# network 10.10.31.0 255.255.255.0
R3(dhcp-config)# default-router 10.10.31.1
R3(dhcp-config)# option 150 ip 10.10.31.1

Remember,  this  configuration  will  not  assign  IP  addresses  to  hosts  unless  the  request  comes  from  a  
phone  connected  to  an  interface  within  the  same  subnet  as  the  DHCP  pool.  Ensure  that  your  VLANs  are  
assigned  appropriately  and  your  Vlan  31  SVI  is  configured  correctly.  
 
To  verify  IP  address  assignment,  we  can  use  the  command  show ip dhcp binding.  This  will  
provide  output  on  the  IP  addresses  that  are  currently  assigned  via  the  IOS  DHCP  server.  
 
R3  
R3#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.10.31.2 01a4.0cc3.950a.68 Oct 01 2014 03:45 PM Automatic
10.10.31.3 015c.5015.a8eb.b7 Oct 01 2014 04:07 PM Automatic
10.10.31.4 01d0.574c.f789.44 Oct 01 2014 04:50 PM Automatic
10.10.31.5 011c.1d86.c581.06 Oct 01 2014 03:18 PM Automatic

If  a  situation  arises  where  an  IP  address  is  not  being  properly  assigned,  the  command  debug ip
dhcp server events  can  be  used  troubleshoot  the  DHCP  process.  
 
R3  
R3#debug ip dhcp server events
DHCP server event debugging is on.

R3# 15:54:43.182: DHCPD: Seeing if there is an internally specified pool class:


Sep 30 15:54:43.182: DHCPD: htype 1 chaddr a40c.c395.0a68
Sep 30 15:54:43.182: DHCPD: remote id 020a00000a0a1f010202001f
Sep 30 15:54:43.182: DHCPD: circuit id 00000000
Sep 30 15:54:43.182: DHCPD: Allocated binding 3FB32A00
Sep 30 15:54:43.182: DHCPD: Adding binding to radix tree (10.10.31.2)
Sep 30 15:54:43.182: DHCPD: Adding binding to hash tree
Sep 30 15:54:43.182: DHCPD: assigned IP address 10.10.31.2 to client 01a4.0cc3.950a.68.
Sep 30 15:54:45.182: DHCPD: Sending notification of DISCOVER:
Sep 30 15:54:45.182: DHCPD: htype 1 chaddr a40c.c395.0a68
Sep 30 15:54:45.182: DHCPD: remote id 020a00000a0a1f010202001f
Sep 30 15:54:45.182: DHCPD: circuit id 00000000
Sep 30 15:54:45.182: DHCPD: Seeing if there is an internally specified pool class:
Sep 30 15:54:45.182: DHCPD: htype 1 chaddr a40c.c395.0a68
Sep 30 15:54:45.182: DHCPD: remote id 020a00000a0a1f010202001f
Sep 30 15:54:45.182: DHCPD: circuit id 00000000
Sep 30 15:54:45.218: DHCPD: Sending notification of ASSIGNMENT:
Sep 30 15:54:45.218: DHCPD: address 10.10.31.2 mask 255.255.255.0
Sep 30 15:54:45.218: DHCPD: htype 1 chaddr a40c.c395.0a68
Sep 30 15:54:45.218: DHCPD: lease time remaining (secs) = 86400

   

28 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.2 Assign  host  IP  addresses  within  a  specific  range  starting  at  .30  and  ending  at  .39.  
 
After  completing  the  previous  task,  phones  should  have  received  IP  addresses  from  the  IOS  DHCP  
server.  Most  likely,  those  addresses  were  lower  in  the  address  range;  for  example,  10.10.31.2.  This  task  
is  now  asking  us  to  define  a  specific  range  of  IP  addresses  for  the  phones  in  question.  In  this  case  
phones  should  use  10.10.31.30  through  10.10.31.39.  In  order  to  configure  this,  we  actually  need  to  
define  what  the  address  should  not  be  assigned  rather  than  what  should  be  assigned.  This  can  be  
accomplished  using  the  ip dhcp excluded-address  command.  
 
R3  
R3(config)#ip dhcp excluded-address 10.10.31.1 10.10.31.29
R3(config)#ip dhcp excluded-address 10.10.31.40 10.10.31.254

The  above  defines  two  IP  address  ranges.  In  the  first  line,  the  range  10.10.31.1  –  10.10.31.29  is  
defined.  We  are  therefore  excluding  that  range  of  addresses  from  IP  address  assignment.  The  second  
line  defines  the  IP  address  range  as  10.10.31.40  –  10.10.31.254.  Of  course,  those  addresses  are  
excluded  from  host  assignment  as  well.  Since  we  are  using  a  /24  subnet,  the  only  addresses  that  are  
possible  in  this  case  fall  within  the  range  10.10.31.30  –  10.10.31.39.  This  configuration  will  meet  the  
requirements  of  the  question.  However,  if  the  previous  task  was  just  completed,  the  IP  addresses  that  
are  actually  assigned  to  the  phones  are  still  not  correct.  We  need  to  somehow  re-­‐issue  the  new  IP  
addresses  in  order  to  make  the  IP  addresses  of  the  phones  correct.  
 
Before  we  attempt  anything  on  the  phone,  we  must  first  remove  the  bindings  that  exist  in  the  router  
for  each  MAC  address.  This  can  be  done  by  issuing  the  command  clear ip dhcp binding *.  
The  asterisk  simply  refers  to  all  automatic  bindings  in  the  system.  
 
R3  
R3#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.10.31.2 01a4.0cc3.950a.68 Oct 01 2014 03:45 PM Automatic
10.10.31.3 015c.5015.a8eb.b7 Oct 01 2014 04:07 PM Automatic
10.10.31.4 01d0.574c.f789.44 Oct 01 2014 04:50 PM Automatic
10.10.31.5 011c.1d86.c581.06 Oct 01 2014 03:18 PM Automatic

R3(config)#clear ip dhcp binding *


R3(config)#exit
R3#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name

After  the  bindings  have  cleared,  the  phone’s  network  configuration  should  be  reset.  Most  of  the  time,  
simply  unplugging  the  phone  and  plugging  it  back  in  will  not  clear  the  IP  address  that  was  previously  
received  from  DHCP.  The  phone  will  hang  on  to  that  IP  address  for  dear  life  in  most  cases!  
 
On  the  7965,  the  network  configuration  can  be  reset  by  using  the  following  procedure:    
Settings  !  Network  Configuration  !  IPv4  Configuration  !  **#  !  more  !  Erase.  
On  the  9971,  the  network  configuration  can  be  reset  by  using  the  following  procedure:    

29 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Administrator  Settings  !  Password;  either  "Cisco"  or  "cisco"  !  Reset  Settings  !  All  Settings  !  Reset.  
 
When  the  phones  re-­‐register,  re-­‐issuing  the  show ip dhcp binding  command  on  the  router  
should  show  that  the  new  IP  addresses  were  successfully  assigned.  
R3#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.10.31.30 01a4.0cc3.950a.68 Oct 01 2014 05:16 PM Automatic
10.10.31.31 015c.5015.a8eb.b7 Oct 01 2014 05:18 PM Automatic
 
   

30 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.3 Configure  a  DHCP  server  using  the  HQ  CUCM  subscriber.  It  should  provide  a  TFTP  
server  for  the  connected  phones.  Configure  the  publisher  server  as  the  secondary  
TFTP  option  and  the  subscriber  as  the  primary  option.  
 
The  CUCM  DHCP  server  is  designed  to  do  the  exact  same  thing  as  the  IOS-­‐based  DHCP  server—and  any  
other  DHCP  server  invented  for  that  matter—assign  IP  addresses  to  hosts.  I  am  confident  that  in  
running  through  this  section,  you  found  the  CUCM  DHCP  server  to  be  flaky  and  difficult  to  
troubleshoot.  If  not,  congratulations!  You  are  one  of  the  lucky  ones.  For  those  that  weren’t  so  lucky,  
we  need  to  first  take  steps  to  prevent  the  CUCM  DHCP  server  from  causing  problems.  This  is  done  by  
deactivating  the  service  that  controls  DHCP  (Cisco  DHCP  Monitor  Service)  within  Cisco  Unified  
Serviceability.  
 
Navigate  to  Cisco  Unified  Serviceability  and  click  the  Go  button.  
 

 
 
Navigate  to  Tools  !  Service  Activation.  
 

 
 
Select  the  server  that  you  would  like  to  configure  in  the  dropdown  box.  In  this  case,  we  can  deactivate  
on  both  the  publisher  (10.10.13.11)  and  the  subscriber  (10.10.13.12)  servers.  
 

31 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Uncheck  the  box  next  to  the  “Cisco  DHCP  Monitor”  service  and  click  the  Save  button.  
 

 
 
Now  that  the  service  is  deactivated  on  both  the  PUB  and  the  SUB  we  can  begin  our  DHCP  
configuration.  This  task  is  asking  us  to  configure  the  server  only  at  this  point.  The  configuration  can  be  
done  back  in  the  Cisco  Unified  CM  Administration  menu.  Once  there,  navigate  to  System  !  DHCP  !  
DHCP  Server.  Click  the  Add  New  button  and  add  the  DHCP  server  information  as  seen  in  the  below  
screenshot.  
 

 
 
Remember,  we  are  only  being  asked  to  configure  the  DHCP  server  on  the  SUB  in  the  HQ  CUCM  cluster,  
so  there  is  no  need  to  configure  the  PUB  here.  We  are  also  tasked  with  using  the  SUB  as  the  primary  
TFTP  server  and  the  PUB  as  the  secondary  option.  
 
Although  the  DHCP  server  configuration  is  complete,  do  not  activate  the  DHCP  Monitor  Service  yet!  
There  are  still  more  pieces  to  the  configuration  in  the  upcoming  tasks.  We  will  only  reactivate  the  
service  when  we  are  100%  confident  that  no  more  configurations  should  be  done.  
 
   

32 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.4 Set  the  IP  Address  Lease  Time  to  12  hours,  but  make  sure  that  the  phones  attempt  to  
renew  their  lease  after  10  hours.  
 
This  task  involves  setting  the  lease  time  to  12  hours  and  the  renewal  time  to  10  hours.  There  are  
actually  two  places  where  this  can  be  accomplished  within  the  configuration.  The  first  is  under  the  
DHCP  Server  menu  and  the  second  is  under  the  DHCP  Subnet  menu.  Based  on  the  fact  that  multiple  
subnets  can  be  associated  with  a  single  server,  we  can  assume  that  any  change  on  the  server  affects  all  
subnets  configured  for  that  server.  In  other  words,  by  setting  the  lease  time  to  12  hours  at  the  server  
level,  we  will  be  affecting  multiple  subnets  (if  configured)  with  this  configuration.  Of  course,  if  there  
are  configurations  for  the  same  fields  at  the  subnet  level,  those  will  override  the  configured  values  at  
the  server  level.  
 
For  example,  if  I  set  a  value  of  “60”  for  the  ARP  Cache  Timeout  value  at  the  server  level  and  then  set  a  
value  of  “90”  for  the  ARP  Cache  Timeout  at  the  subnet  level,  “90”  will  take  precedence  because  it  is  
specific  to  the  subnet.  
 
With  that  in  mind,  let’s  set  the  value  for  both  “IP  Address  Lease  Time(sec)”  and  “Renewal(T1)  
Time(sec)”  at  the  server  level.  See  the  below  screenshot.    
 

 
 
In  the  above,  the  lease  time  is  configured  for  43,200  seconds,  which  equals  720  minutes,  which  equals  
12  hours.  For  the  renewal  time,  we  configured  36,000,  which  is  equal  to  600  minutes  or  10  hours.  This  
means  that  the  phone  will  attempt  to  renew  the  DHCP  lease  after  10  hours  and  the  lease  will  expire  at  
12  hours.  
 
   

33 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.5 Assign  host  IP  addresses  within  a  specific  range  starting  at  .10  and  ending  at  .19.  
 
This  task  forces  the  assignment  of  host  IP  addresses  within  a  specific  range.  In  this  case,  the  range  will  
be  10.10.11.10  –  10.10.11.19.  Based  on  the  documentation,  it  was  also  determined  that  the  network  
address  and  subnet  mask  was  10.10.11.0  and  255.255.255.0,  respectively.  In  order  to  lock  down  
address  assignment  to  this  range,  we  must  first  configure  the  DHCP  subnet.  Up  to  this  point,  the  entire  
configuration  has  been  done  on  a  server  level.  Now,  we  must  add  a  subnet  to  the  server  we  just  
created.  
 
Navigate  to  System  !  DHCP  !  DHCP  Subnet  to  start  the  configuration.  
 

 
 
From  the  dropdown  box,  select  the  DHCP  Server  to  configure.  In  this  case,  it  will  be  the  SUB  at  
10.10.13.12.  If  a  server  has  not  been  configured  on  CUCM  at  this  point,  no  option  will  be  available  
here.  No  subnet  configuration  can  exist  without  first  having  a  server  configured.  
 

34 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
The  first  thing  that  is  defined  in  the  above  screenshot  is  the  network  address,  which  was  determined  to  
be  10.10.11.0.  Next,  the  IP  address  range  should  be  defined  in  the  “Primary  Start/End  IPv4  Address”  
fields.  Notice  that  this  is  the  opposite  of  how  it  is  done  in  IOS.  Here,  we  are  defining  the  specific  range,  
while  in  IOS  we  are  defining  the  excluded  range.  In  addition,  we  must  define  our  default  gateway,  
which  is  termed  “Primary  Router  IPv4  Address”  here.  Please  note  that  THIS  IS  EASY  TO  MISS  because  it  
doesn’t  have  the  asterisk  (*)  character.  Of  course,  if  you  forget  this  setting,  your  subnets  will  not  have  
connectivity.  Lastly  the  subnet  mask  must  be  configured  in  order  to  define  the  boundaries  of  the  
network  itself.  The  “IPv4  Subnet  Mask”  field  was  used  here.  
 
At  this  point,  the  configuration  requirements  have  been  met  and  we  are  finally  ready  to  re-­‐activate  the  
DHCP  Monitor  service  within  Cisco  Unified  Serviceability.  This  will  bring  our  DHCP  server  to  life  so  it  can  
start  dishing  out  IP  addresses  based  on  our  configuration.  Once  again,  we  should  be  accessing  the  
subscriber  server  at  HQ  through  the  serviceability  pages  in  order  to  re-­‐activate  this  service.  
 

 
 
   

35 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.6 Forward  DHCP  requests  from  HQ  phones  to  the  CUCM  DHCP  server.  
 
So  you’ve  configured  the  DHCP  server  in  CUCM—great!  However,  nothing  has  happened  yet.  That’s  
because  we  now  need  to  allow  the  HQ  phones  to  request  the  IP  address  from  the  CUCM  DHCP  server.  
Since  the  phones  are  not  on  the  same  subnet  as  the  server,  we  will  need  to  forward  those  DHCP  
DISCOVER  UDP  broadcast  messages  to  a  specific  IP  address—in  this  case,  the  HQ  CUCM  subscriber.  
 
DHCP  clients  need  to  use  User  Datagram  Protocol  (UDP)  broadcasts  to  send  their  initial  DHCPDISCOVER  
messages  because  they  don't  have  information  about  the  network  to  which  they  are  attached.  If  the  
client  is  on  a  network  segment  that  does  not  include  a  server,  UDP  broadcasts  normally  are  not  
forwarded  because  most  routers  are  configured  to  not  forward  broadcast  traffic.  
 
You  can  remedy  this  situation  by  configuring  the  interface  of  your  router  that  is  receiving  the  
broadcasts  to  forward  certain  classes  of  broadcasts  to  a  helper  address.  You  can  use  more  than  one  
helper  address  per  interface.  
 
When  a  router  forwards  these  address  assignment/parameter  requests,  it  is  acting  as  a  DHCP  relay  
agent.  The  Cisco  router  implementation  of  the  DHCP  relay  agent  is  provided  via  the  ip  helper-­‐address  
interface  configuration  command.  
 
In  the  below  diagram,  the  DHCP  client  broadcasts  a  request  for  an  IP  address  and  additional  
configuration  parameters  on  its  local  LAN.  Router  B,  acting  as  a  DHCP  relay  agent,  picks  up  the  
broadcast  and  generates  a  new  DHCP  message  to  send  out  on  another  interface.  As  part  of  this  DHCP  
message,  the  relay  agent  inserts  the  IP  address  of  the  interface  containing  the  ip  helper-­‐address  
command  into  the  gateway  IP  address  (giaddr)  field  of  the  DHCP  packet.  This  IP  address  enables  the  
DHCP  server  to  determine  which  subnet  should  receive  the  offer  and  identify  the  appropriate  IP  
address  range  to  offer.  The  DHCP  relay  agent  sends  the  local  broadcast,  via  IP  unicast,  to  the  DHCP  
server  address  172.16.1.2  specified  by  the  ip  helper-­‐address  interface  configuration  command.  
 

 
 
[Source:      
http://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/htdhcpre.html]    
 
Since  our  HQ  phones  are  physically  connected  to  SW1  and  the  assigned  VLAN  is  trunked  to  R1  in  a  
“router  on  a  stick”  configuration,  we  will  actually  need  to  configure  the  DHCP  relay  agent  on  the  
GigabitEthernet0/0.11  sub-­‐interface  on  R1.    
 
R1  
R1(config)#interface GigabitEthernet0/0.11
R1(config-subif)# ip helper-address 10.10.13.12

36 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  above,  all  DHCP  broadcasts  are  being  forwarded  directly  to  the  HQ  CUCM  subscriber  server  at  
10.10.13.12.  CUCM  can  then  respond  to  these  broadcasts  with  a  DHCP  offer  of  an  IP  address  within  the  
specified  range.  
 
As  for  verification  of  the  CUCM  DHCP  server,  unfortunately  there  is  really  no  way  to  see  the  IP  
addresses  that  it  has  assigned  from  a  GUI  or  CLI  perspective.  The  only  way  to  see  what  it  has  assigned  
is  on  the  endpoints  themselves.  Additionally,  you  can  at  least  see  the  assignment  from  CUCM  take  
place  via  the  debug ip dhcp server packet  command  on  the  DHCP  relay  agent,  however.  See  
the  below  for  the  example  with  R1.  
 
R1  
R1#debug ip dhcp server packet
DHCP server packet debugging is on.
R1#
Sep 30 21:19:29.727: DHCPD: client's VPN is .
Sep 30 21:19:29.727: DHCPD: No option 125
Sep 30 21:19:29.727: DHCPD: Finding a relay for client 011c.1d86.c542.d2 on interface
GigabitEthernet0/0.11.
Sep 30 21:19:29.727: DHCPD: setting giaddr to 10.10.11.1.
Sep 30 21:19:29.727: DHCPD: BOOTREQUEST from 011c.1d86.c542.d2 forwarded to 10.10.13.12.
Sep 30 21:19:29.727: DHCPD: client's VPN is .
Sep 30 21:19:29.727: DHCPD: No option 125
Sep 30 21:19:29.727: DHCPD: forwarding BOOTREPLY to client 1c1d.86c5.42d2.
Sep 30 21:19:29.727: DHCPD: no option 125
Sep 30 21:19:29.727: DHCPD: broadcasting BOOTREPLY to client 1c1d.86c5.42d2.
 
   

37 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.7 Configure  a  DHCP  server  using  the  Site  B  CUCM  cluster.  It  should  provide  a  TFTP  server  
for  the  connected  phones.  
 
We  are  performing  the  same  task  here  that  was  completed  for  the  HQ  CUCM  cluster  in  a  previous  task.  
The  only  difference  here  is  that  another  cluster  (SB)  is  being  configured.  Remember  to  first  deactivate  
the  DHCP  Monitor  service  within  Cisco  Unified  Serviceability  before  configuring  DHCP.  Obviously,  you  
should  re-­‐activate  the  service  when  your  configuration  is  complete.  
 
Navigate  to  System  !  DHCP  !  DHCP  Server  on  the  SB  CUCM  cluster  to  implement  the  required  
configuration.  
 

 
 
   

38 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.8 Set  the  IP  Address  Lease  Time  to  12  hours,  but  make  sure  that  the  phones  attempt  to  
renew  their  lease  after  10  hours.  
 
Once  again,  these  settings  were  previously  configured  for  the  HQ  cluster  as  well.  The  configuration  
should  be  performed  within  the  DHCP  Server  configuration  window.  
 
Navigate  to  System  !  DHCP  !  DHCP  Server  on  the  SB  CUCM  cluster  to  implement  the  required  
configuration.  
 

 
 
   

39 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.9 Assign  host  IP  addresses  within  a  specific  range  starting  at  .20  and  ending  at  .29.  
 
In  much  the  same  way  as  was  done  on  the  HQ  cluster,  the  DHCP  Subnet  menu  should  be  accessed  to  
configure  the  subnet  as  well  as  IP  address  range.  
 
Navigate  to  System  !  DHCP  !  DHCP  Subnet  on  the  SB  CUCM  cluster  to  implement  the  required  
configuration  for  the  10.10.21.0/24  phone  subnet.  
 

 
 
   

40 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.10 Forward  Site  B  DHCP  requests  to  the  CUCM  DHCP  server.  
 
The  IOS  DHCP  Relay  agent  should  once  again  be  used  for  this  configuration  (just  as  with  HQ/R1).  Since  
the  DHCP  discover  message  will  be  originating  from  the  Vlan  21  SVI  on  R2,  the  configuration  should  be  
placed  on  that  interface.  
 
R2  
R2(config)#interface Vlan21
R2(config-if)#ip helper-address 10.10.23.11
 
   

41 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.11 Use  the  phone  to  verify  that  DHCP  assigned  IP  address  as  configured.  
 
Since  no  verification  can  be  done  within  CUCM  to  check  the  address  assignment,  we  should  at  least  
check  to  see  whether  the  address  was  assigned  at  the  phone  level.  
 
This  can  be  done  on  the  7965  by  navigating  to  Settings  !  Network  Configuration  !  IPv4  
Configuration.  
 

 
 
On  the  9971,  this  is  done  by  navigating  to  Settings  !  Phone  Information.  
 

 
 

42 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.12 Configure  R1  to  act  as  an  NTP  server  and  source  all  traffic  from  a  loopback  address.  
 
The  Network  Time  Protocol  (NTP)  synchronizes  the  time  of  day  among  a  set  of  distributed  time  servers  
and  clients  so  that  you  can  correlate  events  when  you  receive  system  logs  and  other  time-­‐specific  
events  from  multiple  network  devices.  NTP  uses  the  User  Datagram  Protocol  (UDP)  as  its  transport  
protocol.  All  NTP  communications  use  Coordinated  Universal  Time  (UTC).  
 
An  NTP  server  usually  receives  its  time  from  an  authoritative  time  source,  such  as  a  radio  clock  or  an  
atomic  clock  attached  to  a  time  server,  and  then  distributes  this  time  across  the  network.  NTP  is  
extremely  efficient;  no  more  than  one  packet  per  minute  is  necessary  to  synchronize  two  machines  to  
within  a  millisecond  of  each  other.  
 
NTP  uses  a  stratum  to  describe  the  distance  between  a  network  device  and  an  authoritative  time  
source:      
• A  stratum  1  time  server  is  directly  attached  to  an  authoritative  time  source  (such  as  a  radio  or  
atomic  clock  or  a  GPS  time  source).  
• A  stratum  2  NTP  server  receives  its  time  through  NTP  from  a  stratum  1  time  server.  
[Source:    
 http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-­‐
os/system_management/configuration/guide/sm_nx_os_cg/sm_3ntp.html]    
 
Obviously  NTP  is  going  to  be  very  important  in  our  network.  It  will  not  only  help  us  synchronize  the  
time  when  examining  log  messages,  but  will  also  help  us  to  avoid  CUCM  database  replication  issues.  It  
also  has  the  ability  to  create  issues  if  the  synchronized  time  is  grossly  incorrect  (different  from  the  
server  itself).  In  this  case  we  are  tasked  with  configuring  R1  as  the  authoritative  time  source  for  our  
network.  Furthermore,  we  have  been  asked  to  use  a  loopback  on  the  router  for  this  type  of  
communication.  
 
From  the  global  configuration  mode  on  R1,  we  can  first  issue  the  ntp source  command.  Before  NTP  
is  essentially  “switched  on”,  this  command  is  configured  to  define  the  interface  on  which  NTP  is  going  
to  run.  The  next  command  seen  below,  ntp master,  instructs  the  router  to  act  as  an  authoritative  
NTP  server.  We  also  have  the  ability  to  add  a  “stratum”  number  at  the  end  of  the  command,  which  is  
just  essentially  just  a  value  that  describes  the  accuracy  of  the  time  source.  However,  that  is  not  
necessary  based  on  the  task  requirements.  
 
R1  
R1(config)#ntp source Loopback0
R1(config)#ntp master
 
   

43 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.13 Configure  R1  to  synchronize  its  time  with  the  BB  router  at  10.10.254.254.  
 
In  the  previous  task,  R1  was  chosen  as  the  authoritative  NTP  device  for  the  entire  network.  In  this  task,  
we  find  out  that  while  R1  may  be  authoritative  for  the  local  UC  network,  it  actually  needs  to  receive  its  
time  from  another  source.  The  other  source  in  this  case  happens  to  be  the  BB  router.  Essentially  this  
now  means  that  all  devices  that  synchronize  with  R1  will  technically  receive  the  time  indirectly  from  
BB.  
 
The  configuration  dictates  that  we  connect  to  the  BB  router’s  NTP  server  at  10.10.254.254.  This  is  
accomplished  using  the  ntp server  command.  This  command  instructs  the  IOS  device  to  
synchronize  time  as  a  client  device  of  the  address  configured  for  the  server.    
 
R1  
R1(config)#ntp server 10.10.254.254

After  a  little  time,  we  should  be  able  to  see  the  synchronization  status  of  the  NTP  service.  There  are  a  
couple  commands  that  are  very  useful  to  verify  this  information.  The  first  is  the  show ntp status  
command.  This  command  displays  a  great  deal  of  information  about  the  NTP  connection  that  is  made  
to  the  NTP  server.  The  most  important  line  is  actually  the  first  one—since  it  states  the  sync  status,  
stratum,  and  reference  IP  address.  
 
R1  
R1#show ntp status
Clock is synchronized, stratum 9, reference is 10.10.254.254
nominal freq is 250.0000 Hz, actual freq is 250.0014 Hz, precision is 2**21
ntp uptime is 3901200 (1/100 of seconds), resolution is 4000
reference time is D7D5D2A3.F5715664 (18:08:51.958 PDT Tue Sep 30 2014)
clock offset is 0.2799 msec, root delay is 1.33 msec
root dispersion is 2.69 msec, peer dispersion is 1.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000005636 s/s
system poll interval is 64, last update was 65 sec ago.

The  next  verification  command  to  use  is  the  show ntp associations  command.  This  is  more  of  
a  quick  command  that  can  show  us  pertinent  information  about  the  NTP  connection  with  the  
10.10.254.254  server.  This  is  important  because  we  can  see  the  places  to  which  R1  has  a  connection;  
this  also  will  display  the  connections  that  other  devices  have  to  R1,  when  configured.  
 
R1  
R1#sh ntp associations

address ref clock st when poll reach delay offset disp


~127.127.1.1 .LOCL. 7 6 16 377 0.000 0.000 0.232
*~10.10.254.254 127.127.7.1 8 55 64 377 1.338 0.279 4.862
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
 
   

44 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.14 Configure  other  IOS  devices  to  use  R1’s  loopback  interface  as  the  NTP  source.  
 
This  task  is  asking  for  each  IOS  device  to  now  synchronize  the  time  with  R1.  Since  this  is  every  IOS  
device,  we  need  to  include  R2,  R3,  and  SW1.  Once  again,  we  should  use  the  ntp server  command  
here.  In  this  case,  we  will  be  using  the  10.10.1.1  IP  address,  which  is  the  loopback  0  address  on  R1.  On  
each  device  we  can  use  the  commands  show ntp status  and  show ntp associations  for  
verification.  
 
R2  
R2(config)#ntp server 10.10.1.1

R2#sh ntp status


Clock is synchronized, stratum 10, reference is 10.10.1.1
nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**19
ntp uptime is 304100 (1/100 of seconds), resolution is 4000
reference time is D7D5D757.C126F54A (20:28:55.754 CDT Tue Sep 30 2014)
clock offset is -5.5656 msec, root delay is 4.52 msec
root dispersion is 7952.05 msec, peer dispersion is 2.71 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000000724 s/s
system poll interval is 64, last update was 261 sec ago.

R2#sh ntp associations

address ref clock st when poll reach delay offset disp


*~10.10.1.1 10.10.254.254 9 64 64 17 2.976 -5.565 2.713
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R3  
R3(config)#ntp server 10.10.1.1

R3#sh ntp status


Clock is synchronized, stratum 10, reference is 10.10.1.1
nominal freq is 250.0000 Hz, actual freq is 250.0035 Hz, precision is 2**19
ntp uptime is 165700 (1/100 of seconds), resolution is 4000
reference time is D7D5D868.EAED7D23 (02:33:28.917 CET Wed Oct 1 2014)
clock offset is 0.7527 msec, root delay is 3.63 msec
root dispersion is 6.81 msec, peer dispersion is 2.39 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000014055 s/s
system poll interval is 64, last update was 23 sec ago.
R3#sh ntp associations

address ref clock st when poll reach delay offset disp


*~10.10.1.1 10.10.254.254 9 25 64 377 2.277 0.752 2.398
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

SW1  
SW1(config)#ntp server 10.10.1.1

SW1#sh ntp status


Clock is synchronized, stratum 10, reference is 10.10.1.1
nominal freq is 119.2092 Hz, actual freq is 119.2108 Hz, precision is 2**18
reference time is D7D5D86C.EFDBB578 (18:33:32.936 PDT Tue Sep 30 2014)
clock offset is -0.3765 msec, root delay is 3.86 msec
root dispersion is 3.97 msec, peer dispersion is 0.24 msec

SW1#sh ntp associations

address ref clock st when poll reach delay offset disp


*~10.10.1.1 10.10.254.254 9 33 1024 377 2.5 -0.38 0.2
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
 
   

45 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.15 Configure  the  servers  to  sync  time  with  the  newly  created  IOS  NTP  server.  
 
This  task  is  asking  to  synchronize  the  time  on  each  UC  server  with  the  R1  NTP  server.  Much  like  IOS,  we  
are  simply  using  the  10.10.1.1  IP  address  to  connect  to  the  NTP  server  from  the  UC  servers.  
 
This  can  be  accomplished  using  both  the  GUI  and  the  CLI.  Using  the  GUI,  Navigate  to  Cisco  Unified  OS  
Administration  and  click  the  Go  button.  
 

 
 
After  logging  in,  navigate  to  Settings  !  NTP  Servers.  
 

 
 
At  this  point,  you  might  see  an  NTP  server  already  configured  in  the  system  (one  is  required  during  
install).  
 

 
 
Obviously,  this  may  not  be  the  same  as  the  one  necessary  for  configuration.  Let’s  see  what  happens  
when  we  try  deleting  the  existing  server  by  selecting  the  checkbox  and  clicking  the  Delete  Selected  
button.  
 

46 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Since  the  record  cannot  be  deleted,  that  means  that  we  must  add  another  server  before  deleting  the  
existing  one.  Click  the  Add  New  button  and  enter  the  new  server  IP  address.  
 

 
 
After  the  server  is  successfully  added,  we  are  now  able  to  delete  the  existing  server.  
 
We  can  also  utilize  the  command  line  to  perform  the  same  tasks.  Log  on  using  SSH  to  the  HQ  publisher  
server.  Once  logged  in,  run  the  command  utils ntp server list  to  display  the  servers  
currently  in  the  system.  
 

 
 
At  this  point  we  can  perform  the  same  actions  that  we  used  in  the  GUI.  The  NTP  server  cannot  be  
deleted  until  we  add  another  one  to  the  list.  Enter  the  utils ntp server  add  command  to  add  a  
server  to  the  list.  
 

 
 
The  original  NTP  server  can  now  be  deleted  by  issuing  the  utils ntp server delete  command.  
 

47 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Now  that  we  have  completed  the  HQ  publisher  NTP  update,  let’s  check  out  the  HQ  subscriber.  When  
navigating  to  Cisco  Unified  OS  Administration  !  Settings  !  NTP  Servers,  we  can  see  that  setting  the  
NTP  server  on  the  subscriber  server  is  not  possible,  based  on  the  fact  that  it  will  always  synchronize  its  
time  with  the  publisher  server  in  the  cluster.  
 

 
 
Next,  let’s  move  to  the  other  UC  devices  in  the  network.  Use  the  above  steps  to  synchronize  NTP  on  
the  HQ  UCCX,  HQ  CUC,  SB  PUB,  and  SB  CUC  servers.  You  may  have  noticed  that  the  HQ  and  SB  IM&P  
servers  were  conspicuously  missing  from  the  list.  That  is  because  each  server  will  eventually  
synchronize  with  each  respective  CUCM  clusters  when  configured.  IM&P  creates  a  database  
connection  to  CUCM  and  receives  network  time  through  that  connection.  Therefore,  it  is  not  possible  
to  add  an  NTP  server  on  the  IM&P  servers.  
 
   

48 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.16 Configure  time  zones  on  each  device  according  to  the  information  found  in  the  
Supplementary-­‐Info.pdf  document.  
 
In  addition  to  synchronizing  the  time  using  NTP,  it  is  also  important  to  add  a  time  offset  to  display  the  
time  in  the  correct  manner  for  the  specific  region.  Not  everyone  wants  to  do  a  mental  calculation  after  
seeing  a  time  in  UTC!  With  this  in  mind,  the  clock time zone  commands  on  the  IOS  devices  will  
be  very  useful  to  us.  According  to  the  Supplementary-­‐Info.pdf  document,  HQ  is  in  the  Pacific  time  zone  
(UTC  -­‐8),  SB  is  in  the  Central  time  zone  (UTC  -­‐6),  and  SC  is  in  the  Central  European  time  zone  (UTC  +1).  
 
R1  
R1(config)#clock timezone PST -8

R2  
R2(config)#clock timezone CST -6

R3  
R3(config)#clock timezone CET 1

SW1  
SW1(config)#clock timezone PST -8
 
   

49 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.17 HQ  and  Site  B  should  support  daylight  savings  time.  


 
We  can  also  account  for  Daylight  Savings  time  by  issuing  the  clock summer-time  command.  To  
verify  the  settings,  use  the  show clock  command.  
 
R1  
R1(config)#clock summer-time PDT recurring

R1#show clock
08:45:57.527 PDT Thu Oct 2 2014

R2  
R2(config)#clock summer-time CDT recurring

R2#show clock
10:45:58.386 CDT Thu Oct 2 2014

R3  
R3(config)#clock summer-time CET recurring

R3#show clock
17:45:59.596 CET Thu Oct 2 2014

SW1  
SW1(config)#clock summer-time PDT recurring

SW1#show clock
08:46:00.618 PDT Thu Oct 2 2014
 
   

50 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.18 Ensure  that  SIP  phones  get  the  correct  time.  
 
This  question  is  asking  to  make  sure  that  all  SIP  phones  in  the  network  will  receive  the  correct  time.  
The  only  way  for  us  to  guarantee  that  this  happens  is  to  use  a  “Phone  NTP  Reference”  in  CUCM  or  the  
ntp-server  command  under  the  voice register global  configuration  in  CUCME.  SCCP  
phones  do  not  have  this  problem  since  the  time  is  based  on  the  CUCM  time.  Each  call  agent  will,  of  
course,  be  covered  in  greater  detail  throughout  the  rest  of  the  Volume  1  Detailed  Solution  Guide.  
 
To  set  the  “Phone  NTP  Reference”  in  CUCM,  first  log  into  Cisco  Unified  CM  Administration  and  navigate  
to  System  !  Phone  NTP  Reference.  This  will  allow  us  to  enter  an  IP  address  for  the  NTP  server.  Click  
the  Add  New  button  and  enter  the  IP  address  along  with  the  Mode  from  the  dropdown  box.  
 

 
 
The  mode  command  is  the  method  by  which  CUCM  receives  the  time.  From  the  server  help  files:  
• Directed  Broadcast—If  you  choose  this  default  NTP  mode,  the  phone  accesses  date/time  
information  from  any  NTP  server  but  gives  the  listed  NTP  servers  (1st  =  primary,  2nd  =  
secondary)  priority.  For  example,  if  the  phone  configuration  contains  NTP  servers  where  A  =  
primary  NTP  server  and  B  =  secondary/backup  NTP  server,  the  phone  uses  the  broadcast  
packets  (derives  the  date/time)  from  NTP  server  A.  If  NTP  server  A  is  not  broadcasting,  the  
phone  accesses  date/time  information  from  NTP  server  B.  If  neither  NTP  server  is  broadcasting,  
the  phone  accesses  date/time  information  from  any  other  NTP  server.  If  no  other  NTP  server  is  
broadcasting,  the  phone  will  derive  the  date/time  from  the  Cisco  Unified  Communications  
Manager  200  OK  response  to  the  REGISTER  message.  
• Unicast—If  you  choose  this  mode,  the  phone  will  send  an  NTP  query  packet  to  that  particular  
NTP  server.  If  the  phone  gets  no  response,  the  phone  will  access  date/time  information  from  
any  other  NTP  server.  If  no  other  NTP  servers  respond,  the  phone  will  derive  the  date/time  
from  the  Cisco  Unified  Communications  Manager  200  OK  response  to  the  REGISTER  message.  
 
Cisco  Unified  Communications  Manager  currently  does  not  support  the  Multicast  and  Anycast  modes.  
If  you  choose  either  of  these  modes,  Cisco  Unified  Communications  Manager  will  default  to  the  
Directed  Broadcast  mode.  
 
Once  the  Phone  NTP  Reference  is  created,  this  can  be  assigned  to  a  CUCM  Date/Time  Group  and  then  
a  Device  Pool.  These  two  configuration  items  will  be  discussed  in  greater  detail  in  later  sections.  
 
As  for  CUCME,  the  configuration  takes  place  under  voice register global  and  is  seen  below.  
SIP  CUCM  configuration  will  be  covered  in  greater  detail  throughout  the  remainder  of  this  guide.  

51 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
R3  (CUCME)  
R3(config)#voice register global
R3(config-register-global)#ntp-server 10.10.1.1 mode directedbroadcast
 
   

52 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.19 Configure  the  TFTP  server  on  CUCM  to  provide  configuration  files  to  phones.  
 
The  Cisco  TFTP  service  builds  and  serves  files  that  are  consistent  with  the  Trivial  File  Transfer  Protocol  
(TFTP).  Cisco  TFTP  builds  configuration  files  and  serves  embedded  component  executables,  ringer  files,  
and  device  configuration  files.  
 
A  configuration  file  contains  a  prioritized  list  of  Cisco  Unified  Communications  Managers  for  a  device  
(phones  that  are  running  SCCP  and  phones  that  are  running  SIP  and  gateways),  the  TCP  ports  on  which  
the  device  connects  to  those  Cisco  Unified  Communications  Managers,  and  an  executable  load  
identifier.  Configuration  files  for  selected  devices  contain  locale  information  and  URLs  for  the  phone  
buttons:  messages,  directories,  services,  and  information.  Configuration  files  for  gateways  contain  all  
their  configuration  information.  
 
You  can  find  configuration  files  in  a  .cnf,  a  .cnf.xml,  or  an  .xml  format,  depending  on  the  device  type  
and  your  TFTP  service  parameter  settings.  When  you  set  the  Build  CNF  Files  service  parameter  to  Build  
All,  the  TFTP  server  builds  both  .cnf.xml  and  .cnf  format  configuration  files  for  all  devices.  When  you  
set  this  service  parameter  to  Build  None,  the  TFTP  server  builds  only  .cnf.xml  files  for  all  devices.  When  
this  parameter  is  set  to  Build  Selective,  which  is  the  default  value,  the  TFTP  server  builds  .cnf.xml  files  
for  all  devices  and,  in  addition,  builds  .cnf  files  only  for  a  select  list  of  device  types,  listed  below.  
 
Device  Type     Device  Name    
MODEL_30SPP     Cisco  30  SP+    
MODEL_12SPP     Cisco  12  SP+    
MODEL_12SP     Cisco  12  SP    
MODEL_12S     Cisco  12  S    
MODEL_30VIP     Cisco  30  VIP  or  DPA    
MODEL_IP_CONFERENCE_PHONE     Cisco  7935    
MODEL_SCCP_PHONE     SCCP  Phone    
MODEL_VEGA     Analog  Access    
MODEL_UONE     Voice  Mail  Port    
 
[Source:      
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_5_1/ccmsys/accm-­‐851-­‐
cm/a02tftp.html]    
 
This  task  is  asking  us  to  ensure  that  the  TFTP  server  on  CUCM  can  provide  configuration  files  to  phones.  
All  this  really  means  in  this  case  is  to  make  sure  that  the  TFTP  service  is  active  in  CUCM.  Of  course,  if  
the  service  is  not  activated  and  started,  the  phone  will  be  unable  to  download  a  configuration  file  from  
the  server.  We  can  choose  to  activate  the  service  on  the  publisher  server,  the  subscriber  server,  or  
both.  Both  the  HQ  and  SB  CUCM  clusters  should  be  configured  in  this  case.  

53 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Select  Cisco  Unified  Serviceability  from  the  dropdown  box  and  log  in  to  the  server.  Next,  navigate  to  
Tools  !  Service  Activation.  
 

 
 
Next,  select  a  server  from  the  dropdown  box  and  click  the  Go  button.  Ensure  that  the  Cisco  TFTP  
service  is  activated.  
 

 
 
After  doing  the  same  for  the  subscriber  server  (if  desired),  navigate  to  Tools  !  Control  Center  -­‐  
Feature  Services.  Select  the  desired  server  and  check  the  state  of  the  Cisco  TFTP  service  to  ensure  that  
it  is  up  and  running.  
 

 
 
Do  the  same  for  the  subscriber  server  (if  desired).  

 
   

54 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 2.20 Configure  the  TFTP  server  on  IOS  to  provide  configuration  files  to  phones.  
 
Nothing  needs  to  be  done  here  at  the  moment  since  there  is  no  specific  service  on  IOS  to  start  to  
control  TFTP.  Remember,  the  HQ  and  SB  phones  are  registering  to  CUCM  servers  while  the  SC  phones  
will  register  to  a  CUCME  device  (located  on  R3).  R3  will  also  function  as  a  TFTP  server  to  provide  
configuration  files  to  the  phones  at  SC  when  either  the  voice register global  (SIP)  or  the  
telephony-service  (SCCP)  processes  are  enabled  on  the  router.  As  was  stated  earlier,  more  to  
come  on  CUCME  later!  

55 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  2:  Labs  3-­‐9  
Version  1.0  

56 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 2: Configure and Troubleshoot CUCM and CUCME Endpoints  


Lab 3: CUCM SCCP and SIP Basic Phone Registration
Task 3.1 Assure  that  SCCP  phones  can  register  with  CUCM  by  checking  Unified  Serviceability  for  
any  issues.  
 
SCCP  phones  (as  well  as  SIP  phones)  rely  on  the  Cisco  CallManager  service  to  be  active  in  the  Cisco  
Unified  Serviceability  section  of  the  webpage.  If  this  service  is  not  activated,  then  the  phone  will  not  be  
able  to  register  to  the  CUCM  server  and  make  calls.  Depending  on  the  CUCM  group  that  the  phone  has  
been  placed  in,  those  corresponding  servers  should  have  the  Cisco  CallManager  service  enabled.  For  
example,  in  a  CUCM  group  that  lists  only  the  publisher  server,  the  Cisco  CallManager  service  does  not  
need  to  be  activated  on  the  subscriber  server  for  the  phone  to  successfully  register.  This  is  because  the  
phone  is  only  configured  to  register  with  the  publisher  server.  
 
Navigate  to  Cisco  Unified  Serviceability  and  click  the  Go  button.  Next,  navigate  to  Tools  !  Service  
Activation  and  select  a  server  from  the  drop  down  box.  Ensure  that  the  Cisco  CallManager  service  is  
activated.  
 

 
 
Next,  navigate  to  Tools  !  Control  Center  -­‐  Feature  Services  and  select  a  server  from  the  drop  down  
box.  Ensure  that  the  Cisco  CallManager  service  is  up  and  running.  
 

 
 
   

57 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.2 Remove  each  IP  phone’s  reliance  on  DNS  at  both  HQ  and  SB.  
 
By  default,  each  phone  is  dependent  on  DNS  to  resolve  the  hostnames  that  are  sporadically  placed  
throughout  the  CUCM  system.  If  the  phone  is  unable  to  contact  a  DNS  server  that  is  authoritative  for  
the  names  configured  in  the  system,  it  will  not  be  able  to  interact  with  the  CUCM  cluster  for  the  
intended  purpose.  With  this  in  mind,  the  solution  for  removing  this  reliance  is  to  simply  use  IP  
addresses  rather  than  hostnames.  
 
The  first  section  that  needs  to  be  updated  is  the  server  configuration  of  each  server  in  the  system.  
Navigate  to  System  !  Server  and  click  the  name  of  the  server  in  question.  The  default  configuration  
can  be  seen  below.  
 

 
 
Clearly  what  needs  to  change  here  is  the  “Host  Name/IP  Address”  field.  Instead  of  HQPUB,  enter  the  
corresponding  IP  address  of  10.10.13.11.  This  ensures  that  other  servers  that  need  to  communicate  
with  the  HQ  CUCM  cluster  publisher  can  do  so  by  using  the  IP  address.  Also,  it  is  a  good  idea  to  use  the  
description  field  to  identify  the  name  of  the  server  should  a  question  arise  about  what  server  it  is.  
 

 
 
The  next  area  of  CUCM  that  must  be  updated  is  the  identification  that  CUCM  places  on  the  server  
within  the  system.  This  is  more  for  consistency  than  necessity,  but  can  serve  as  a  good  reminder  that  
the  system  has  been  updated  to  use  IP  addresses  instead  of  hostnames.  Navigate  to  System  !  Cisco  
Unified  CM  and  click  on  the  server  in  question.  

58 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Expect  the  system  to  display  information  similar  to  what  is  seen  below  for  the  Cisco  Unified  CM  
Configuration  window.  
 

 
 
The  field  that  needs  to  be  modified  here  is  the  “Cisco  Unified  Communications  Manager  Name”.  
Replace  the  hostname  with  the  corresponding  IP  address  and  click  the  Save  button.  Once  again,  a  
description  can  be  helpful  here  as  well.  
 

 
 
The  last  part  of  the  system  that  should  be  modified  can  be  found  by  navigating  to  System  !  Enterprise  
Parameters.  About  mid-­‐way  down  the  page,  the  sections  labeled  “Phone  URL  Parameters”  and  
“Secured  Phone  URL  Parameters”  should  immediately  jump  out  as  needing  a  change  from  hostname  to  
IP  address.  
 

 
   

59 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

These  parameters  relate  to  each  individual  phone  making  a  connection  to  the  HQ  publisher  using  the  
hostname.  In  order  to  ensure  that  communication  happens  successfully,  we  must  modify  the  
hostname  to  the  corresponding  IP  address.  
 

 
 
   

60 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.3 Ensure  that  the  phones  register  to  the  subscriber  first,  then  the  publisher  where  
applicable.  
 
A  Cisco  Unified  Communications  Manager  Group  specifies  a  prioritized  list  of  up  to  three  Cisco  Unified  
Communications  Managers.  The  first  Cisco  Unified  Communications  Manager  in  the  list  serves  as  the  
primary  Cisco  Unified  Communications  Manager  for  that  group,  and  the  other  members  of  the  group  
serve  as  secondary  and  tertiary  (backup)  Cisco  Unified  Communications  Managers.  
 
Each  device  pool  has  one  Cisco  Unified  Communications  Manager  Group  that  is  assigned  to  it.  When  a  
device  registers,  it  attempts  to  connect  to  the  primary  (first)  Cisco  Unified  Communications  Manager  in  
the  group  that  is  assigned  to  its  device  pool.  If  the  primary  Cisco  Unified  Communications  Manager  is  
not  available,  the  device  tries  to  connect  to  the  next  Cisco  Unified  Communications  Manager  that  is  
listed  in  the  group,  and  so  on.  
 
Cisco  Unified  Communications  Manager  Groups  provide  important  features  for  your  system:  
• Redundancy—this  feature  enables  you  to  designate  a  primary  and  backup  Cisco  Unified  
Communications  Managers  for  each  group.  
• Call  processing  load  balancing—this  feature  enables  you  to  distribute  the  control  of  devices  
across  multiple  Cisco  Unified  Communications  Managers.  
 
For  most  systems,  you  need  to  have  multiple  groups,  and  you  need  to  assign  a  single  Cisco  Unified  
Communications  Manager  to  multiple  groups  to  achieve  better  load  distribution  and  redundancy.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmcfg/CUCM_BK_A349
70C5_00_admin-­‐guide-­‐91/CUCM_BK_A34970C5_00_admin-­‐guide-­‐91_chapter_0100.html]  
 
Phone  registration  in  CUCM  is  controlled  by  the  CUCM  group  that  is  assigned  to  the  Device  Pool  in  
which  the  phone  is  placed.  This  task  is  asking  for  the  subscriber  to  be  configured  as  the  first  option  in  
the  prioritized  list  of  servers  in  the  system.  For  this  configuration,  navigate  to  System  !  Unified  CM  
Group  and  click  the  Find  button  to  display  the  currently  configured  CUCM  Groups  in  the  system.  
 

 
 
A  CUCM  group  labeled  “Default”  should  already  exist  in  the  system.  My  suggestion  here  is  to  edit  and  
rename  it  to  a  more  descriptive  name.  That  is  usually  my  “overarching”  rule  throughout  these  labs;  any  
time  you  see  “Default”,  rename  it  to  something  more  descriptive,  so  you  know  exactly  what  it  is  that  
you  are  configuring.  It  is  much  easier  to  understand,  especially  after  hours  spent  in  the  lab!  In  this  case,  
I  have  named  it  “SUB_PUB_CMG”  since  the  subscriber  server  is  first  while  the  publisher  server  is  
second  in  the  list.  

61 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
   

62 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.4 Configure  the  phones  to  register  at  HQ  and  SB  as  described  above  and  in  the  
Supplementary-­‐Info.pdf  document.  
 
The  Supplementary-­‐Info.pdf  document  states  that  HQ  Phone  1  (9971)  should  be  registered  as  a  SIP  
phone  and  HQ  Phone  2  (7965)  should  be  registered  as  a  SCCP  phone.  Both  SB  Phone  1  and  2  (7965)  
should  be  registered  as  SCCP  phones.  All  steps  up  to  this  point  in  previous  labs  have  been  leading  up  to  
the  point  of  actually  registering  the  phones.  Just  to  review,  NTP  was  configured  in  order  to  synchronize  
time  across  all  servers  and  IOS  devices  in  the  UC  network.  Next,  CDP/LLDP  was  configured  to  locate  the  
MAC  address,  type,  and  location  of  phones  in  question.  Then,  voice  and  access  VLANs  were  configured  
on  the  phone  switch  ports  in  order  to  place  the  phone  in  the  correct  network.  From  there,  TFTP  servers  
were  configured  in  order  to  provide  configuration  files  to  phones  upon  registration.  Lastly,  DHCP  was  
configured  to  provide  an  IP  address  as  well  as  a  TFTP  server  (option  150)  for  phone  registration.  
 
Provided  that  all  of  the  above  steps  were  taken,  the  phone  can  be  registered  to  a  CUCM  cluster.  There  
a  couple  of  different  ways  that  this  can  be  accomplished—manual  or  auto  registration.  Of  course,  with  
manual  registration,  the  administrator  must  configure  the  phone  in  the  system.  With  auto  registration,  
the  system  recognizes  the  registration  attempt  from  the  phone  and  immediately  adds  the  MAC  
address  to  the  device  list  in  the  system.  
 
To  manually  register  the  phone,  navigate  to  Device  !  Phone  and  click  the  Add  New  button.  Next,  
select  the  phone  model  from  the  dropdown  box  and  click  the  Next  button.  
 

 
 
Next,  select  the  Device  Protocol  for  the  phone.  In  this  case,  each  7965  will  be  running  a  SCCP  load,  so  
that  should  be  selected  here.  
 

 
 

63 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  configure  details  about  the  phone,  such  as  the  MAC  Address  (obtained  using  the  show cdp
neighbors command),  Device  Pool,  Calling  Search  Space,  and  Device  Security  Profile  and  click  the  
Save  button.  
 

 
 
Next,  configure  the  line  that  should  be  associated  with  the  device  in  question.  This  involves  setting  the  
“Directory  Number”  (DN)  field  as  well  as  the  partition  associated  with  that  number.  A  descriptive  
calling  name  can  also  be  set  on  the  line  as  well  at  this  point.  Many  other  settings  are  available  on  the  
line  page,  but  are  not  necessary  at  this  point.  
 

 
 
After  the  line  configuration  is  complete,  please  make  sure  to  click  the  Save  and  Reset  buttons  to  make  
sure  the  configuration  is  saved  and  the  device  is  reset  to  accept  the  new  configuration.  
 

 
 
   

64 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.5 Assure  that  SIP  phones  can  register  with  CUCM  by  checking  Unified  Serviceability  for  
any  issues.  
 
SIP  phones  rely  on  the  same  service  that  SCCP  phones  do  for  registration  and  call  processing—the  
Cisco  CallManager  service.  Ensure  this  is  activated  as  was  detailed  in  Task  3.1.  
 
   

65 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.6 Remove  the  SIP  IP  phone’s  reliance  on  DNS  at  both  HQ  and  SB.  
 
Once  again,  SIP  phones  are  no  different  than  SCCP  phones  in  this  regard.  Both  rely  on  DNS  by  default,  
so  hostnames  in  the  CUCM  system  should  be  modified  to  IP  addresses  in  order  to  remove  this  reliance.  
See  the  solution  for  Task  3.2  for  more  information.  
 
   

66 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.7 Ensure  that  the  phones  register  to  the  subscriber  first,  then  the  publisher  where  
applicable.  
 
SIP  phones  still  rely  on  the  CUCM  Group  for  the  servers  to  which  they  register.  The  subscriber  server  
should  be  placed  in  the  list  first  and  the  publisher  should  be  second.  See  the  solution  to  Task  3.3  for  
more  detail  
 
   

67 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.8 Configure  the  phones  to  register  as  described  above  and  in  the  Supplementary-­‐
Info.pdf  document.  
 
This  task  is  specifically  referring  to  the  registration  of  SIP  phones  in  the  CUCM  cluster.  Task  3.4  covered  
the  manual  registration  of  SCCP  phones  to  the  CUCM  cluster.  Registration  for  SIP  phones,  as  you  may  
have  guessed,  is  no  different  than  that  of  SCCP  phones.  Details  in  the  device  and  line  configuration  
must  be  configured  just  as  with  SCCP  phones.  Check  the  solution  in  Task  3.4  for  more  details.  
 
   

68 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.9 If  supported,  enable  video  services  on  the  phone  in  order  to  place  video  calls.  
 
The  9971  phones  are  the  only  devices  on  the  CCIE  Collaboration  blueprint  (besides  the  Jabber  Client)  
that  are  capable  of  making  video  calls.  With  this  in  mind,  enabling  video  in  the  UC  network  will  most  
certainly  start  at  the  phone  level.  Enabling  video  services  can  be  accomplished  using  a  couple  different  
methods.  One  area,  as  you  may  have  guessed,  is  on  the  device  page  under  the  “Product  Specific  
Configuration  Layout”  section.  This  is  specific  to  the  phone  in  question;  it  will  only  affect  one  phone.  
The  “Common  Phone  Profile  Configuration”  is  another  way  to  enable  the  video  services  within  CUCM.  
The  difference  is  that  one  Common  Phone  Profile  can  be  assigned  to  multiple  phones,  so  the  setting  
has  the  ability  to  affect  a  large  quantity  of  devices.  
 
The  two  settings  that  must  be  enabled  are  called  “Cisco  Camera”  and  “Video  Capabilities”  (or  “Video  
Calling”  -­‐  Common  Phone  Profile).  To  change  the  settings  on  a  device  level,  navigate  to  Device  !  
Phone  and  click  on  the  phone  in  question.  Scroll  down  to  the  bottom  section  of  the  page  to  reveal  the  
“Product  Specific  Configuration  Layout”  section.  From  there,  both  the  “Cisco  Camera”  and  “Video  
Capabilities”  settings  should  be  set  to  “Enabled”  to  turn  on  the  video  calling  feature.  
 

 
 
If  applying  the  setting  for  multiple  phones,  it  may  be  a  good  idea  to  use  a  Common  Phone  Profile.  
Navigate  to  Device  !  Device  Settings  !  Common  Phone  Profile.  Click  on  the  “Standard  Common  
Phone  Profile”  and  click  the  Copy  button  to  copy  it  to  a  new  profile.  Name  the  new  profile  and  select  
the  “Enabled”  option  for  the  “Cisco  Camera”  and  the  “Video  Calling”  dropdown  boxes.  
 

 
 

 
 

 
 
To  assign  the  Common  Phone  Profile  to  a  phone,  navigate  to  Device  !  Phone  and  click  on  the  desired  
phone.  From  there,  select  the  previous  configured  profile  from  the  “Common  Phone  Profile”  
dropdown  menu.  
 

 
   

69 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 3.10 Delete  the  phones  that  were  configured  in  the  previous  tasks.  
 
All  right,  I  know  what  you’re  thinking!  Why  the  heck  am  I  deleting  the  phones  that  I  just  configured?  
Well,  in  this  case,  it’s  only  because  we  should  also  try  registering  phones  using  Auto-­‐Registration.  It  is  
definitely  something  that  can  increase  speed  when  the  time  comes  to  attempt  the  lab.  
 
To  delete  phones,  simply  navigate  to  Device  !  Phone  and  click  the  checkbox  next  to  the  phone  in  
question.  
 

 
 
Click  the  Delete  Selected  button  to  delete  the  phones.  
 
   

70 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.11 Configure  CUCM  to  auto-­‐register  any  phones  that  attempt  to  register  to  the  cluster.  
 
Auto  registration  can  be  an  extremely  useful  tool  to  register  phones  to  the  CUCM  cluster.  It  can  also  be  
a  massive  problem  if  done  incorrectly.  Understanding  all  of  the  settings  is  the  key  to  a  valuable,  
timesaving  configuration.  
 
The  first  setting  that  needs  to  be  checked,  before  anything  can  be  done,  is  to  determine  the  protocol  
that  the  phones  will  use  to  register  to  the  cluster.  For  9971  phones,  there  is  only  one  choice—SIP.  
Therefore,  the  auto  registration  phone  protocol  setting  doesn’t  have  any  effect  on  that  phone  type.  
However,  for  the  7965  phones,  this  setting  becomes  key,  since  the  phone  is  capable  of  running  both  a  
SCCP  and  SIP  load.  If  the  lab  specifically  calls  for  7965  phones  to  use  SCCP  and  SIP  is  selected  as  the  
default  auto-­‐registration  phone  protocol,  the  way  in  which  the  phone  registers  to  the  cluster  will  be  
incorrect  and  points  will  be  lost.  To  recover,  you  would  have  to  configure  the  phone  to  run  through  a  
long  “firmware  swap”  process,  whereby  the  SCCP  firmware  would  be  downloaded  to  the  phone  all  
over  again.  This  is  a  massive  time-­‐waster,  so  please  make  sure  to  check  this  setting  every  time  auto-­‐
registration  is  a  possibility.  Navigate  to  System  !  Enterprise  Parameters  and  look  for  the  setting  titled  
“Auto  Registration  Phone  Protocol”.  This  can  either  be  set  to  SCCP  or  SIP,  so  make  sure  that  you  have  
the  correct  one  selected.  
 

 
 
The  next  setting  to  be  checked  depends  upon  how  much  building  you  would  like  to  do  before  actually  
registering  the  phone.  Personally,  I  like  to  build  everything  I  possibly  can  within  the  system  before  even  
thinking  about  registering  phones.  This  includes,  but  is  not  limited  to:  
 
• CUCM  Group  
• Phone  NTP  Reference  
• Date/Time  Group  
• Region  
• Partitions  
• Calling  Search  Spaces  
• Media  Resource  Group  Lists  
• Device  Pool  
 
Some  of  the  above  items  have  not  been  discussed  to  this  point,  but  will  be  discussed  in  greater  detail  
throughout  the  Detailed  Solution  Guide.  The  important  things  to  note  for  this  section  are  the  Device  
Pool  and  the  Partition.  When  auto-­‐registration  is  configured,  the  administrator  has  the  ability  to  
configure  a  partition  that  the  new  lines  should  use  as  well  as  a  default  Device  Pool  where  phones  
should  register.  When  these  items  are  configured  ahead  of  time,  it  makes  the  auto-­‐registration  
configuration  that  much  easier.  First,  to  check  the  Device  Pool  that  the  CUCM  cluster  will  use  for  auto-­‐
registration,  navigate  to  Device  !  Device  Settings  !  Device  Defaults.  Under  the  specific  phone  models  
for  the  phones  that  will  use  auto-­‐registration,  select  the  Device  Pool  that  should  be  used.  
 

71 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  add  a  Partition  by  navigating  to  Call  Routing  !  Class  of  Control  !  Partition  and  clicking  the  Add  
New  button.  From  there,  type  a  Partition  name  that  will  contain  the  directory  numbers  on  the  cluster.  
In  my  example,  “INTERNAL_PT”  was  used.  
 

 
 
Next,  we  can  finally  configure  the  auto-­‐registration  settings  by  navigating  to  System  !  Cisco  Unified  
CM  and  clicking  on  the  server  to  which  the  phones  should  register.  For  example,  in  the  case  where  the  
subscriber  server  is  listed  as  the  first  option  in  the  CUCM  group,  it  might  make  sense  to  configure  the  
subscriber  as  the  auto-­‐registration  server.  In  this  case,  that  means  we  should  configure  the  10.10.13.12  
server  for  auto-­‐registration.    
 
Under  the  “Auto-­‐registration  Information”  section,  select  the  “Starting  Directory  Number”  and  the  
“Ending  Directory  Number”,  along  with  the  “Partition”  in  which  the  phones  should  be  placed  as  well  as  
the  “External  Phone  Number  Mask”,  if  desired.  I  usually  try  to  make  the  directory  number  range  very  
small,  to  only  include  the  ranges  of  numbers  that  should  be  configured.  Also,  I  will  only  plug  the  
phones  in  one  at  a  time,  so  that  the  phones  register  with  the  correct  directory  number  in  the  first  
place.  Obviously  if  a  Partition  was  created,  it  should  be  used  here  in  order  to  save  configuration  time  
later.  Lastly,  if  the  lab  requirements  call  for  an  External  Phone  Mask  to  be  used,  it  can  be  useful  to  
enter  that  here  as  well.  
 

 
 
Finally,  make  sure  that  the  checkbox  is  not  checked  in  order  to  enable  auto-­‐registration.  
   

72 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 3.12 Assure  that  the  phones  register  with  the  subscriber  first,  then  the  publisher.  Assure  
that  auto-­‐registration  is  disabled  after  your  phones  successfully  register.  
 
Once  again,  this  is  controlled  by  the  CUCM  Group.  See  the  solution  to  Task  3.3  for  more  detail  on  
CUCM  Group  configuration.  As  for  disabling  auto-­‐registration,  simply  ensure  that  the  checkbox  is  
checked  to  disable  the  service  within  the  Cisco  Unified  CM  Configuration  page.  
 
Navigate  to  System  !  Cisco  Unified  CM  and  click  the  server  on  which  auto-­‐registration  is  enabled.  
Mark  the  checkbox  next  to  the  “Auto-­‐registration  Disabled  on  this  Cisco  Unified  Communications  
Manager”  setting.  
 

 
 

73 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 4: CUCM SCCP and SIP Basic Configuration


Task 4.1 Assure  that  the  phones  receive  the  correct  time  and  time  zone  as  described  in  the  
Supplementary-­‐Info.pdf  document.  
 
Use  Date/Time  Groups  to  define  time  zones  for  the  various  devices  that  are  connected  to  Cisco  Unified  
Communications  Manager.  Each  device  exists  as  a  member  of  only  one  device  pool,  and  each  device  
pool  has  only  one  assigned  Date/Time  Group.  
 
Installing  Cisco  Unified  Communications  Manager  automatically  configures  a  default  Date/Time  Group  
that  is  called  CMLocal.  CMLocal  synchronizes  to  the  active  date  and  time  of  the  operating  system  on  
the  server  where  Cisco  Unified  Communications  Manager  is  installed.  After  installing  Cisco  Unified  
Communications  Manager,  you  can  change  the  settings  for  CMLocal  as  desired.  Normally,  adjust  server  
date/time  to  the  local  time  zone  date  and  time.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmcfg/CUCM_BK_A349
70C5_00_admin-­‐guide-­‐91/CUCM_BK_A34970C5_00_admin-­‐guide-­‐91_chapter_0110.html]    
 
Based  on  the  above  writing  from  cisco.com,  it  is  evident  that  a  Date/Time  Group  needs  to  be  created  
for  phones  in  the  system  to  receive  the  correct  time.  The  default  group  of  CMLocal  should  be  renamed  
to  a  more  descriptive  name  so  it  can  be  used  throughout  the  configuration.  For  the  HQ  CUCM  cluster,  
the  time  zone  should  be  defined  as  Pacific  Standard/Daylight  Time  (UTC  -­‐8).  On  the  SB  CUCM  cluster,  
the  time  zone  is  Central  Standard/Daylight  Time  (UTC  -­‐6).  
 
Navigate  to  System  !  Date/Time  Group  and  click  the  Find  button  to  reveal  the  current  groups  in  the  
system.  Click  on  the  CMLocal  group  to  edit  the  properties.  In  the  example  of  the  HQ  cluster,  rename  
the  Date/Time  group  to  something  like  “PST_DTG”  and  select  the  proper  time  zone  from  the  dropdown  
box.  Other  settings  may  be  selected  as  well  depending  on  the  requirements  of  the  question.  
 

 
 
From  the  above  screenshot,  you  may  have  noticed  the  “Phone  NTP  Reference”  section.  As  mentioned  
earlier  in  the  Detailed  Solution  Guide,  this  is  necessary  for  SIP  phones  to  synchronize  time  with  the  
referenced  NTP  server.  SCCP  phones  do  not  require  this  setting  as  that  phone  type  will  receive  the  
correct  time  from  the  CUCM  server  itself.  

74 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  configure  this  setting,  navigate  to  System  !  Phone  NTP  Reference  and  click  the  Add  New  button.  
Enter  the  IP  address  of  the  NTP  server  that  should  be  used  for  synchronization  purposes  and  click  the  
Save  button.  
 

 
 
To  add  the  Phone  NTP  Reference  to  the  Date/Time  Group,  click  the  Add  Phone  NTP  Reference  button  
within  the  Date/Time  Group  configuration  window  and  select  it  from  the  list.  Click  the  Add  Selected  
button  when  done.  
 

 
 
The  same  should  be  configured  on  the  SB  CUCM  cluster  using  the  Central  Standard/Daylight  (UTC  -­‐6)  
time  zone.  
 
   

75 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.2 Assure  that  the  date  and  time  are  formatted  in  the  mm-­‐dd-­‐yyyy  and  24  hour  formats  
for  HQ.  
 
The  format  of  the  time  that  is  displayed  on  the  phone  can  be  controlled  within  the  Date/Time  Group  
configuration.  Navigate  to  System  !  Date/Time  Group  and  click  on  the  recently  created  group.  From  
there,  ensure  that  the  dash  (-­‐)  is  selected  as  the  “Separator”,  the  “Date  Format”  is  M-­‐D-­‐Y,  and  the  
“Time  Format”  is  set  to  24-­‐hour.  
 

 
 
The  phone  will  display  the  time  in  the  specified  format  in  the  upper  left-­‐hand  corner  of  the  screen.  
 

 
 
   

76 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.3 Assure  that  the  date  and  time  are  formatted  in  the  dd/mm/yyyy  and  12  hour  formats  
for  SB.  
 
Just  as  the  date  and  time  formats  were  configured  on  the  HQ  cluster,  so  it  should  be  done  on  the  SB  
CUCM  cluster.  Navigate  to  System  !  Date/Time  Group  and  click  on  the  recently  created  group.  From  
there,  ensure  that  the  slash  (/)  is  selected  as  the  “Separator”,  the  “Date  Format”  is  D/M/Y,  and  the  
“Time  Format”  is  set  to  12-­‐hour.  
 

 
 
The  phone  will  display  the  time  in  the  specified  format  in  the  upper  left-­‐hand  corner  of  the  screen.  
 

 
 
   

77 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.4 Set  Phone  2  at  HQ  and  Phone  1  at  SB  to  Auto  Answer  incoming  calls.  
 
Auto  answer  can  be  a  useful  feature  especially  when  testing  with  remote  phones  in  the  lab.  In  order  to  
set  HQ  Phone  2  to  auto  answer,  navigate  to  Device  !  Phone  and  click  on  the  MAC  address  of  HQ  
Phone  2.  On  the  “Phone  Configuration”  page,  click  on  “Line  1”,  directory  number  1002.    
 

 
 
On  the  “Directory  Number  Configuration”  page,  under  the  “Directory  Number  Settings”  heading,  click  
the  “Auto  Answer”  dropdown  box  and  select  the  “Auto  Answer  with  Speakerphone”  option.  Click  the  
Save  button  followed  by  the  Apply  Config  button.  
 

 
 
Do  the  same  for  SB  Phone  1  on  the  SB  CUCM  cluster  (Line  1  –  2001).  
 
   

78 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.5 Assure  that  all  phones  will  not  be  able  to  access  voice  mail  at  any  time.  
 
Once  again,  this  is  a  setting  that  can  be  accomplished  at  the  “Line”  level.  Navigate  to  Device  !  Phone  
and  click  on  the  MAC  address  of  the  phone  in  question.  Click  on  the  “Line  1”  configuration  to  enter  the  
“Directory  Number  Configuration”  page.  Under  the  “Directory  Number  Settings”  section,  select  the  
“NoVoiceMail”  option  for  the  “Voice  Mail  Profile”  option.  
 

 
 
This  will  ensure  that  users  are  unable  to  access  the  voicemail  system  through  the  messages  key.  It  also  
ensures  that  in  a  situation  where  the  user  is  busy,  not  available,  or  the  phone  is  unregistered,  calls  will  
not  be  able  to  forward  to  a  voicemail  system.  I  realize  that  we  have  not  even  come  close  to  configuring  
voicemail  at  this  point,  so  this  may  seem  a  bit  confusing.  Not  to  worry,  voicemail  will  be  covered  in  
detail  throughout  this  guide.  
 
The  question  states  that  this  should  be  done  for  “all  phones”.  This  means  HQ  Phone  1  and  2  as  well  as  
SB  Phone  1  and  2  should  have  this  configuration.  
 
   

79 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.6 Assure  that  when  HQ  Phone  1  is  unregistered,  the  call  will  be  forwarded  to  HQ  Phone  
2.  
 
This  task  is  asking  us  to  configure  the  “Call  Forward  Unregistered”  settings  on  “Line  1”  for  HQ  Phone  1.  
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Phone  and  click  on  the  MAC  address  corresponding  to  
HQ  Phone  1.  Click  on  the  “Line  1”  configuration  to  enter  the  “Directory  Number  Configuration”  page.  
Under  the  “Call  Forward  and  Call  Pickup  Settings”  settings,  find  the  text  box  labeled  “Forward  
Unregistered  Internal/External”  and  type  the  number  1002  (HQ  Phone  2).  Also,  ensure  that  a  CSS  is  
assigned  that  has  access  to  the  Partition  that  contains  the  1002  DN.  
 

 
 
If  for  some  reason,  HQ  Phone  1  becomes  unregistered  to  the  cluster,  calls  will  now  automatically  
forward  to  DN  1002,  assigned  to  HQ  Phone  2.  
 
   

80 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.7 HQ  Phone  1  should  forward  to  HQ  Phone  2  when  the  call  is  not  answered  within  10  
seconds.  
 
This  task  is  asking  us  to  configure  the  “Call  Forward  No  Answer”  and  “No  Answer  Ring  Duration”  
settings  on  “Line  1”  for  HQ  Phone  1.  On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Phone  and  click  on  
the  MAC  address  corresponding  to  HQ  Phone  1.  Click  on  the  “Line  1”  configuration  to  enter  the  
“Directory  Number  Configuration”  page.  Under  the  “Call  Forward  and  Call  Pickup  Settings”  settings,  
find  the  text  box  labeled  “Forward  No  Answer  Internal/External”  and  type  the  number  1002  (HQ  Phone  
2).  Also,  ensure  that  a  CSS  is  assigned  that  has  access  to  the  Partition  that  contains  the  1002  DN.  
 

 
 
To  meet  the  next  requirement  of  the  question,  set  the  “No  Answer  Ring  Duration”  setting  to  a  value  of  
10  seconds.  This  dictates  the  amount  of  time  that  must  pass  before  the  “No  Answer”  condition  is  
detected.  
 

 
 
   

81 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.8 Assure  that  when  HQ  Phone  1  rings,  it  only  displays  a  visual  notification.    
 
Once  again,  this  task  is  looking  for  configuration  to  be  done  at  the  “Line”  level.  This  task  is  asking  us  to  
configure  HQ  Phone  1  to  display  only  a  visual  notification  when  being  called  by  another  device.  This  
means  that  we  will  need  to  disable  the  normal  ringing  of  the  phone.  On  the  HQ  CUCM  cluster,  navigate  
to  Device  !  Phone  and  click  on  the  MAC  address  corresponding  to  HQ  Phone  1.  Click  on  the  “Line  1”  
configuration  to  enter  the  “Directory  Number  Configuration”  page.  Under  the  specific  line  settings  for  
the  phone  in  question  (e.g.  “Line  1  on  Device  SEP1C1D86C54015”),  find  the  dropdown  boxes  labeled  
“Ring  Setting  (Phone  Idle/Active)”.  Select  the  “Flash  Only”  setting  for  both  cases  to  enable  only  visual  
notifications.  
 

 
 
As  always,  remember  to  click  the  Save  button  and  the  Apply  Config  button  when  complete.  To  test,  
simply  dial  line  1001  from  HQ  Phone  2  and  observe  the  behavior.    
 
   

82 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.9 For  both  HQ  and  SB  phones,  ensure  that  the  full  +E164  DID  is  displayed  in  the  top  
banner  on  the  phone  (e.g.  +14082221001).  
 
This  task  is  asking  us  to  configure  the  External  Phone  Number  Mask  setting  within  the  Line  page  of  the  
phone.  Once  configured,  this  will  not  only  display  the  full  +E.164  number  in  the  top  right  banner  on  the  
phone,  but  it  will  also  come  in  handy  for  digit  manipulation  when  traversing  Translation  Patterns  or  
Route  Patterns.  This  was  also  a  setting  that  was  discussed  briefly  in  the  auto-­‐registration  section  of  the  
previous  lab.  
 
To  configure  the  setting,  navigate  to  Device  !  Phone  and  click  on  the  MAC  address  of  the  phone  in  
question.  Click  on  the  “Line  1”  configuration  to  enter  the  “Directory  Number  Configuration”  page.  
Under  the  specific  line  settings  for  the  phone  in  question  (e.g.  “Line  1  on  Device  SEP1C1D86C54015”),  
locate  the  “External  Phone  Number  Mask”  text  box.  Enter  a  pattern  such  as  “+1408222XXXX”  in  the  
field.  This  pattern  will  take  4  digits  from  the  configured  directory  number  and  place  them  “in  line”  
within  the  string  when  displayed.  
 

 
 
For  HQ  Phone  1,  the  number  results  in  +14082221001.  It  is  also  possible  to  use  different  combinations  
of  numbers  in  the  pattern  to  achieve  different  results.  For  example,  if  the  directory  number  was  1234  
and  the  External  Phone  Number  Mask  was  +1408222X9X7,  the  resulting  pattern  would  be  
+14082221937.  
 
Ensure  that  the  External  Phone  Number  Mask  is  configured  on  each  phone  on  each  CUCM  cluster.  
 
   

83 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.10 Each  line  should  support  6  concurrent  calls  and  4  active  incoming  calls.  
 
This  task  is  asking  us  to  configure  the  phone  to  support  6  active  calls  on  “Line  1”  as  well  as  up  to  4  
incoming  calls.  In  the  case  where  there  are  5  active  calls  on  the  line,  one  more  call  can  be  made  before  
the  maximum  is  reached.  If  there  are  5  active  calls  with  4  of  those  calls  being  classified  as  incoming  
calls,  no  other  incoming  calls  will  be  accepted,  but  one  more  call  can  still  be  made  in  the  outbound  
direction.  
 
To  configure  this  parameter,  navigate  to  Device  !  Phone  and  click  on  the  MAC  address  of  the  phone  in  
question.  Click  on  the  “Line  1”  configuration  to  enter  the  “Directory  Number  Configuration”  page.  
Under  the  specific  call  waiting  settings  for  the  phone  in  question  (e.g.  “Multiple  Call/Call  Waiting  
Settings  on  Device  SEP1C1D86C54015”);  modify  the  “Maximum  Number  of  Calls”  setting  to  “6”  and  the  
“Busy  Trigger”  setting  to  “4”.  
 

 
 
Ensure  that  this  is  done  for  all  phones  on  both  the  HQ  and  SB  CUCM  clusters.  
 
   

84 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.11 Assure  that  calls  between  HQ  phones  use  the  G.711  codec  only.  This  value  should  be  
hardcoded  to  avoid  using  the  system  defaults.  Configure  the  same  for  SB.  
 
In  CUCM,  codec  negotiation  is  controlled  by  the  Region  settings.  If  specific  codecs  are  required  
between  devices  in  the  system,  the  codec  can  be  controlled  to  pinpoint  the  exact  codec  that  should  be  
used.  This  is  accomplished  by  specifying  a  maximum  amount  of  bandwidth  that  is  available  for  each  
call.  If  the  bandwidth  of  a  desired  audio  codec  exceeds  that  which  is  configured  in  the  CUCM  Region,  
that  codec  is  not  successfully  negotiated.  For  example,  if  the  Region  setting  is  “8  kbps  (G.729)”  for  calls  
between  HQ  Phone  1  and  Phone  2,  those  phones  will  not  be  able  to  use  a  higher  bandwidth  codec  such  
as  G.711  (64  kbps)  since  it  is  not  less  than  8  kbps.  In  other  words,  only  codecs  that  use  8  kbps  or  less  
bandwidth  will  be  accepted.  
 
In  addition  to  the  “normal”  Region  setting,  CUCM  9.x  added  a  new  feature  that  assists  in  negotiating  
codecs  called  the  Audio  Codec  Preference  List.  This  enhances  the  codec  selection  process  by  allowing  
the  administrator  to  select  a  codec  from  an  ordered  preference  list.  For  example,  in  earlier  versions  of  
CUCM,  simply  selecting  64  kbps  for  the  Region  setting  would  not  guarantee  that  G.711  would  be  used.  
Depending  on  the  capabilities  of  the  phone,  the  G.722  codec  would  still  be  available  for  use  ahead  of  
G.711.  This  is  still  true  in  CUCM  9.x  by  default,  but  when  an  Audio  Codec  Preference  List  is  used,  G.722  
could  be  moved  down  on  the  priority  list  to  make  G.711  the  preferred  audio  codec.  This  can  be  
configured  by  navigating  to  System  !  Region  Information  !  Audio  Codec  Preference  List.  From  there,  
one  of  the  existing  profiles  should  be  copied  so  a  new  Audio  Codec  Preference  List  can  be  created.  This  
can  be  accomplished  by  clicking  the  Copy  button  and  choosing  a  descriptive  name.  See  below  for  an  
example.  
 

85 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
The  Audio  Codec  Preference  List  can  then  be  assigned  to  a  Region  relationship  by  selecting  it  from  the  
“Audio  Codec  Preference  List”  dropdown  box  in  the  “Region  Configuration”  window.  
 

 
 
Of  course,  in  order  to  configure  calls  between  HQ  phones  to  use  only  the  G.711  codec,  we  have  to  
ensure  that  there  will  be  no  cases  where  a  codec  other  than  G.711  can  be  negotiated.  In  this  case,  that  
means  that  we  must  disable  G.722  on  a  cluster  wide  basis.  There  are  two  places  where  this  can  be  
done.  First,  navigate  to  System  !  Enterprise  Parameters  and  locate  the  setting  labeled  “Advertise  
G.722  Codec”.  In  the  dropdown  box,  select  “Disabled”  to  completely  disable  the  advertisement  of  the  
codec.  
 

 
 
Next,  we  should  also  disable  the  use  of  the  codec  in  the  system.  To  accomplish  this,  navigate  to  System  
!  Service  Parameters  !  Select  Publisher  Server  !  Select  Cisco  CallManager  Service  and  find  the  
parameter  labeled  “G.722  Codec  Enabled”.  Open  the  dropdown  box  and  select  “Disabled”  to  
deactivate  use  of  the  codec.  
 

 
 
In  addition  to  ensuring  that  calls  between  the  HQ  phones  use  the  G.711  codec,  the  requirements  of  the  
question  state  that  this  value  has  to  be  “hardcoded”.  This  means  that  we  cannot  simply  rely  on  the  
Interregion  (8  kbps,  G.729)  and  Intraregion  (64  kbps,  G.711)  default  settings,  even  though  this  would  
still  result  in  the  same  codec  being  negotiated.  Therefore,  we  must  create  a  Region  and  hardcode  the  
value  to  be  64  kbps  for  calls  within  that  region.  At  that  point,  the  Region  can  be  assigned  to  the  Device  
Pool  of  the  phones  in  question.  
 
To  create  a  Region,  navigate  to  System  !  Region  Information  !  Region  and  click  the  Add  New  button.  
Create  a  Region  to  be  assigned  to  phones  at  HQ,  named  “HQ_REG”  or  some  reasonable  equivalent.  
 

86 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  create  a  relationship  from  the  Region  that  was  just  created  to  itself,  using  64  kbps  of  bandwidth.  
 

 
 
After  the  Region  has  been  created,  assign  it  to  the  Device  Pool  that  is  associated  to  the  HQ  phones.  
Navigate  to  System  !  Device  Pool  and  click  the  Device  Pool  assigned  to  the  phones.  
 

 
 
Once  the  setting  is  correct  in  the  Device  Pool,  click  the  Save  button  and  then  the  Reset  button  to  apply  
the  configuration.  Test  the  configuration  by  making  a  call  between  phones  at  HQ.  
 
On  the  7965  phone,  double-­‐click  the  “?”  button  on  the  phone  to  display  the  call  statistics.  
 

   

87 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  9971  phone,  navigate  to  Settings  !  Administrator  Settings  !  Status  !  Call  Statistics.  
 

 
 
This  task  also  specified  that  the  configuration  to  support  intrasite  codec  selection  should  be  done  on  
the  SB  CUCM  cluster  as  well;  so  ensure  that  the  above  configuration  steps  are  followed  in  order  to  
complete  the  task.  
 
   

88 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.12 On  the  HQ  cluster,  create  a  region  for  communicating  with  SB  and  assure  that  all  
voice  calls  use  the  G.729  codec.  On  the  SB  cluster,  create  the  same  for  calls  to  HQ.  
 
Region  settings  are  going  to  be  used  again  in  this  case  to  control  codec  selection  when  HQ  phones  
communicate  with  SB  phones  and  vice  versa.  Granted,  there  is  no  method  currently  configured  in  
either  of  the  CUCM  clusters  for  these  phones  to  communicate,  so  there  will  be  nowhere  to  apply  the  
Region  and  no  way  to  test  the  configuration  once  completed.  With  this  in  mind,  the  Region  relationship  
can  still  be  configured  on  both  clusters.  
 
Navigate  to  System  !  Region  Information  !  Region  and  click  the  Add  New  button.  Create  a  Region  to  
be  assigned  to  the  eventual  link  to  SB,  named  “SB_REG”  or  some  reasonable  equivalent.  On  the  HQ  
CUCM  cluster,  ensure  that  the  Region  setting  uses  8  kbps  (G.729)  between  the  HQ_REG  (assigned  to  
phones)  and  the  newly  created  region  (SB_REG).  
 

 
 
On  the  SB  CUCM  cluster,  ensure  that  the  SB_REG  has  an  8  kbps  (G.729)  Region  relationship  with  the  
HQ_REG,  as  configured  above.  
 
   

89 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.13 Assure  that  3  lines  and  3  speed  dials  can  be  configured  on  both  HQ  and  SB  phones.  
 
Regardless  of  the  type  of  phone  that  is  being  configured  (SCCP  or  SIP),  assigning  a  Phone  Button  
Template  can  be  used  to  accomplish  the  above  task.  
 
Cisco  Unified  Communications  Manager  includes  default  templates  for  each  Cisco  Unified  IP  Phone  
model.  When  you  add  phones,  you  can  assign  one  of  these  templates  to  the  phone  or  create  a  
template  of  your  own.  
 
You  can  make  changes  to  the  custom,  nonstandard  templates  that  you  created,  and  you  can  change  
the  label  of  the  custom  phone  button  template.  You  cannot  change  the  function  of  the  buttons  in  the  
default  templates.  
 
You  can  update  a  custom,  nonstandard  phone  button  template  to  add  or  remove  features,  add  or  
remove  lines  and  speeds  dials,  or  assign  features,  lines,  and  speed  dials  to  different  buttons  on  the  
phone.  You  can  change  the  button  labels  in  the  default  phone  button  templates,  but  you  cannot  
change  the  function  of  the  buttons  in  the  default  templates.  If  you  update  a  phone  template,  be  sure  
to  inform  affected  users  of  the  changes.  
 
The  Programmable  Line  Key  (PLK)  feature  expands  the  list  of  features  that  can  be  assigned  to  the  line  
buttons  to  include  features  that  are  normally  controlled  by  softkeys;  for  example,  New  Call,  Call  Back,  
End  Call,  and  Forward  All.  
 
If  you  create  a  template  for  a  Cisco  Unified  IP  Phone,  you  can  change  the  default  template  for  that  
phone  during  auto  registration.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmcfg/CUCM_BK_A349
70C5_00_admin-­‐guide-­‐91/CUCM_BK_A34970C5_00_admin-­‐guide-­‐91_chapter_01001101.html]    
 
To  begin,  navigate  to  Device  !  Device  Settings  !  Phone  Button  Template  and  click  the  Find  button.  
Locate  the  default  template  for  the  phone  type  in  question  and  click  it  to  begin  editing.  
 

90 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Copy  button  to  create  a  custom  template  based  on  the  Standard  Template.  Give  it  a  
descriptive  name,  such  as  “Standard  7965  SCCP  -­‐  3L-­‐3S”  (3  lines,  3  speed  dials).  
 

 
 
Next,  configure  the  Phone  Button  Layout  to  include  three  lines  and  3  speed  dials,  as  required  by  the  
task.  
 

 
 
Next,  assign  the  Phone  Button  Template  to  the  phone  by  navigating  to  Device  !  Phone  and  clicking  on  
the  MAC  address  of  the  phone  in  question.  Locate  the  “Phone  Button  Template”  parameter  and  select  
the  newly  created  template  from  the  dropdown  list.  
 

 
 
Don’t  forget  to  click  the  Save  button  as  well  as  the  Reset  button  to  apply  the  configuration.  
 
In  the  same  way  as  detailed  above,  a  Phone  Button  Template  should  be  created  for  the  9971  phone  at  
HQ  with  the  same  parameters.  Also,  the  7965  phones  at  SB  should  have  a  single  Phone  Button  
Template  created  for  use  on  the  SB  CUCM  cluster.  
 
   

91 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.14 Assure  that  SB  Phone  2  is  unable  to  make  a  new  call  when  a  call  is  presently  on  hold.  
 
The  easiest  way  to  accomplish  this  task  is  to  create  a  custom  Softkey  Template  to  be  assigned  to  SB  
Phone  2  (7965).  During  the  “Hold”  state,  the  softkey  corresponding  to  new  call  creation  should  be  
removed.  
 
Softkey  template  configuration  allows  the  administrator  to  manage  softkeys  that  the  Cisco  Unified  IP  
Phones  support.  Cisco  Unified  Communications  Manager  supports  two  types  of  softkey  templates:  
standard  and  nonstandard.  Applications  that  support  softkeys  can  have  one  or  more  standard  softkey  
templates  that  are  associated  with  them;  for  example,  Cisco  Unified  Communications  Manager  has  the  
Standard  Feature  and  the  Standard  User  softkey  templates  that  are  associated  with  it.  You  cannot  
modify  standard  softkey  templates.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmcfg/CUCM_BK_A349
70C5_00_admin-­‐guide-­‐91/CUCM_BK_A34970C5_00_admin-­‐guide-­‐91_chapter_01001110.html]    
 
Navigate  to  Device  !  Device  Settings  !  Softkey  Template  and  click  the  Find  button.  Locate  the  
“Standard  User”  softkey  template  and  click  to  edit.  Click  the  Copy  button  to  create  a  new  Softkey  
Template  based  on  the  original  template.  
 

 
   

92 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Give  the  new  template  a  descriptive  name,  such  as  “Standard  User  –  NoNewCall”  and  click  on  the  Go  
button  next  to  the  dropdown  box  with  the  “Configure  Softkey  Layout”  option  selected.  Select  the  “On  
Hold”  state  by  using  the  call  state  dropdown  box.  
 

 
 
Next,  remove  the  NewCall  (NewCall)  softkey  from  the  template  by  moving  it  from  the  “Selected  
Softkeys”  to  “Unselected  Softkeys”  section.  
 

 
 
Click  the  Save  button  to  complete  the  configuration.  Next,  assign  the  newly  created  Softkey  Template  
to  the  phone  by  navigating  to  Device  !  Phone  and  clicking  on  the  MAC  address  of  SB  Phone  2.  Locate  
the  “Softkey  Template”  parameter  and  select  the  newly  created  template  from  the  dropdown  list.  
 

 
 

93 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Remember  to  click  the  Save  button  followed  by  the  Reset  button  to  apply  the  new  configuration  to  the  
phone.    
   

94 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.15 Assure  that  all  users  at  SB  are  able  to  report  quality  issues  using  the  IP  phone  in  all  
available  scenarios.  
 
Once  again,  Softkey  Templates  need  to  be  used  for  this  configuration.  End  users  can  report  quality  
issues  with  a  service  called  the  Quality  Report  Tool  (QRT),  which  is  completely  accessible  from  the  
softkeys  on  the  phone.  This  question  specifically  states  that  it  needs  to  be  available  in  all  states  and  it  
must  be  applied  to  all  SB  phones.  
 
To  accomplish  this  task,  we  must  first  modify  the  Softkey  Template  that  was  created  in  the  previous  
task  so  as  not  to  break  requirements  that  were  outlined  there.  Navigate  to  Device  !  Device  Settings  
!  Softkey  Template  and  click  the  Find  button.  Locate  the  “Standard  User  -­‐  NoNewCall”  softkey  
template  that  was  created  in  the  previous  task  and  click  to  edit.  Click  on  the  Go  button  next  to  the  
dropdown  box  with  the  “Configure  Softkey  Layout”  option  selected.    
 
Find  all  the  call  states  in  which  QRT  is  available  by  selecting  each  state  to  take  an  inventory  of  what  is  
available.  The  below  screenshot  shows  that  QRT  is  available  in  the  “On  Hook”  state.    
 

 
 
From  sifting  through  the  menus  we  find  that  QRT  is  available  in  all  of  the  following  states:  
• On  Hook  
• Connected  
• Connected  Transfer  
• Connected  Conference  
 
With  that  in  mind,  move  QRT  from  “Unselected  Softkeys”  to  “Selected  Softkeys”  within  each  of  the  
above  states.  Click  the  Apply  Config  button  to  send  the  configuration  to  phones  that  have  the  Softkey  
Template  assigned.  
 
Next,  create  a  new  Softkey  Template  specifically  for  access  to  QRT  for  the  other  phone  at  SB.  Why  can’t  
we  just  use  the  existing  Softkey  Template?  This  is  because  the  previous  task  stated  that  SB  Phone  2  
should  not  be  able  to  make  a  new  call  when  on  hold.  Therefore,  we  should  not  apply  this  requirement  
to  SB  Phone  1  as  well.  The  new  Softkey  Template  will  simply  enable  QRT  in  all  of  the  above  call  states.  
As  mentioned  before,  it  should  be  assigned  to  SB  Phone  1  and  any  other  phones  that  may  exist  at  SB  
except  SB  Phone  2.  
95 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 4.16 Create  a  speed  dial  on  button  5  on  each  HQ  phone  pointing  to  the  other.  
 
This  task  simply  involves  adding  a  speed  dial  on  each  HQ  phone  pointing  toward  the  other.  This  of  
course,  will  be  accomplished  on  the  Phone  Configuration  page  by  navigating  to  Device  !  Phone  and  
clicking  the  MAC  address  of  the  phone  in  question.  From  there,  click  on  the  “Add  a  New  SD”  link  under  
the  “Association  Information”  section  on  the  left  side  to  add  a  speed  dial.  
 

 
 
On  the  phone,  the  speed  dial  will  appear  as  pictured  below.  
 

 
 
   

96 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 4.17 Create  a  speed  dial  on  button  5  on  each  SB  phone  pointing  to  the  other.  
 
The  same  configuration  that  was  discussed  in  the  previous  task  for  the  HQ  CUCM  cluster  also  applies  to  
this  task  for  the  SB  CUCM  cluster.  See  the  below  screenshot  for  the  final  configuration.  
 

 
 

97 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 5: CUCM SCCP and SIP Advanced Phone Configuration


Task 5.1 Assure  that  users  on  HQ  and  SB  have  the  ability  to  park  and  retrieve  calls  from  any  
phone  on  the  cluster,  regardless  of  which  phone  originally  parked  the  call.  HQ  should  
use  the  range  111X  and  SB  should  use  range  222X.  
 
The  Call  Park  feature  allows  you  to  place  a  call  on  hold,  so  it  can  be  retrieved  from  another  phone  in  
the  Cisco  Unified  Communications  Manager  system  (for  example,  a  phone  in  another  office  or  in  a  
conference  room).  If  you  are  on  an  active  call  at  your  phone,  you  can  park  the  call  to  a  call  park  
extension  by  pressing  the  Park  softkey  or  the  Call  Park  button.  Someone  on  another  phone  in  your  
system  can  then  dial  the  call  park  extension  to  retrieve  the  call.  
 
You  can  define  either  a  single  directory  number  or  a  range  of  directory  numbers  for  use  as  call  park  
extension  numbers.  You  can  park  only  one  call  at  each  call  park  extension  number.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmfeat/CUCM_BK_C3E
0EFA0_00_cucm-­‐features-­‐services-­‐guide-­‐91/CUCM_BK_C3E0EFA0_00_cucm-­‐features-­‐services-­‐guide-­‐
91_chapter_0110.html]    
 
Both  users  on  each  CUCM  cluster  should  have  the  ability  to  park  calls  using  the  specified  ranges  
detailed  above.  In  order  to  start  the  configuration,  navigate  to  Call  Routing  !  Call  Park  and  click  the  
Add  New  button.  
 

 
 
Enter  a  value  number  for  the  “Call  Park  Number/Range”  field.  This  field  is  described  in  the  CUCM  help  
file  as  detailed  below:  
 
You  can  enter  literal  digits  or  the  wildcard  character  X  (the  system  allows  one  or  two  Xs).  For  
example,  enter  5555  to  define  a  single  call  park  extension  number  of  5555  or  enter  55XX  to  
define  a  range  of  call  park  extension  numbers  from  5500  to  5599.  
 
Note:    You  can  create  a  maximum  of  100  call  park  numbers  with  one  call  park  range  definition.  
Make  sure  that  the  call  park  numbers  are  unique.  
 

98 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Note:    You  cannot  overlap  call  park  numbers  between  Cisco  Unified  Communications  Manager  
servers.  Ensure  that  each  Cisco  Unified  Communications  Manager  server  has  its  own  number  
range.  
 
Note:    The  call  park  range  is  selected  from  the  list  of  servers  where  the  call  originates.  For  
example,  if  phone  A  (registered  to  node  A)  calls  phone  B  (registered  to  node  B)  and  the  phone  B  
user  presses  Park,  phone  B  requires  a  call  park  range  in  the  CSS  that  resides  on  node  A.  In  a  
multinode  environment  where  phones  and  gateways  communicate  with  various  nodes  and  
where  calls  that  originate  from  any  server  may  need  to  be  parked,  the  phones  require  a  CSS  that  
contains  call  park  ranges  from  all  servers.  
 
In  this  case,  the  range  was  provided  for  us  (111X).  Based  on  the  above  description,  this  means  that  we  
have  a  total  of  10  numbers  available  to  use  for  call  parking  purposes  within  CUCM.  Next,  select  a  
partition  that  is  reachable  by  the  Device  CSS  that  is  configured  on  the  phone  that  will  be  parking  the  
call.  Finally,  the  server  on  which  the  Call  Park  range  is  active  should  be  selected.  The  subscriber  server  
was  selected  in  this  case,  since  that  is  also  the  first  choice  for  phone  registration.  
 

 
 
Remember,  if  redundancy  were  required,  we  would  need  to  specify  another  range  to  exist  on  the  
publisher  server,  since  the  same  range  cannot  exist  on  multiple  servers.  See  the  below  screenshot  for  
the  error  received  if  attempting  this  configuration.  
 

 
 
With  the  Call  Park  Range  configured,  the  next  step  is  to  configure  softkeys  on  each  of  the  HQ  phones  to  
have  the  ability  to  park  calls.  Navigate  to  Device  !  Device  Settings  !  Softkey  Template  and  click  on  
the  “Standard  User”  softkey  template.  Select  the  “Configure  Softkey  Layout”  option  from  the  “Related  
Links”  dropdown  box  and  click  the  Go  button.  
 
Look  through  the  available  phone  states  and  determine  which  states  the  Call  Park  option  is  available.  
After  looking,  we  can  determine  that  it  is  already  enabled!  Under  the  “Connected”  state,  “Park  (Park)”  
has  already  been  selected  as  a  “Selected  Softkey”.  

99 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
After  the  above  exercise,  it  appears  that  there  is  no  more  work  to  do  at  this  point.  To  test  the  feature,  
make  a  call  between  HQ  Phone  1  and  2.  Use  HQ  Phone  2  (7965)  to  Park  the  call  by  selecting  the  “Park”  
softkey.  The  number  at  which  the  call  is  parked  is  displayed  at  the  bottom  of  the  phone.  
 

 
 
Simply  dial  the  number  from  any  phone  that  has  access  to  the  call  park  extension  to  resume  the  call.  
   

100 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now,  attempt  the  same  action  from  HQ  Phone  1  (9971).  You  will  quickly  notice  that  Call  Park  is  not  
possible  from  the  9971  in  the  current  state.  I  thought  the  softkey  had  “Park”  enabled  by  default,  
though?  Well,  in  this  case  the  9971  uses  a  different  feature  to  assign  softkeys.  It  is  called  a  “Feature  
Control  Policy”.  To  enable  HQ  Phone  1  for  Call  Park,  navigate  to  Device  !  Device  Settings  !  Feature  
Control  Policy  and  click  the  Add  New  button.  Provide  a  descriptive  name  and  make  sure  to  enable  the  
“Park”  feature.  
 

 
 
Next,  assign  the  Feature  Control  Policy  to  HQ  Phone  1  by  navigating  to  Device  !  Phone  and  clicking  
the  MAC  address  associated  with  HQ  Phone  1.  Scroll  to  about  midway  through  the  page  and  locate  the  
“Feature  Control  Policy”  parameter.  Select  the  newly  created  policy  from  the  dropdown  box  and  click  
the  Save  button.  Click  the  Apply  Config  button  when  complete.  
 

 
 
Attempts  to  park  the  call  from  HQ  Phone  1  should  now  be  possible.  Notice  that  the  system  basically  
places  the  call  on  hold  when  using  a  9971  phone.  The  Call  Park  number  can  still  be  dialed  to  retrieve  
the  parked  call.  
 

 
 

101 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  SB  CUCM  cluster,  ensure  that  the  Call  Park  Range  of  222X  is  configured  and  that  the  phones  
have  access  to  park  the  calls  by  applying  the  same  configuration  detailed  for  the  HQ  CUCM  cluster.  
   

102 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 5.2 The  call  should  be  sent  back  to  the  person  who  parked  the  call  after  37  seconds  for  all  
parked  calls  on  each  cluster.  
 
As  discussed  in  the  previous  task,  when  a  user  presses  the  “Park”  softkey,  a  call  is  parked  using  the  
specified  Call  Park  Range.  If  no  user  dials  the  call  park  number  to  pick  up  the  call,  the  Call  Park  
Reversion  Timer  (60  seconds  by  default)  can  be  used  to  route  the  call  back  to  the  user  that  originally  
parked  the  call.  To  modify  this  setting,  navigate  to  System  !  Service  Parameters  !  Select  Publisher  
Server  !  Select  Cisco  CallManager  Service,  locate  the  parameter  labeled  “Call  Park  Reversion  Timer”,  
and  change  the  value  to  37.  
 

 
 
To  test  the  setting,  make  a  test  call  between  HQ  Phone  1  and  2.  Park  the  call  from  HQ  Phone  2  and  
ensure  that  after  37  seconds,  the  call  reverts  back  to  the  phone  that  parked  the  call.  Now  try  to  park  
the  call  from  HQ  Phone  1  and  observe  the  behavior.  Notice  that  the  call  actually  reverts  after  60  
seconds  instead  of  37  seconds!  This  is  because  a  different  type  of  Call  Park  is  being  used  on  the  9971  
phones,  called  Park  Monitoring  (see  screenshot  in  previous  task).  There  is  a  separate  timer  for  this  
within  Service  Parameters  called  “Park  Monitoring  Reversion  Timer”,  which  should  be  set  to  37  
seconds  as  well.  
 

 
 
After  modifying  the  Service  Parameter,  re-­‐test  by  parking  a  call  from  HQ  Phone  1  again.  This  time,  the  
parked  call  will  be  reverted  after  37  seconds.  
 
Ensure  that  these  settings  are  updated  on  both  the  HQ  and  SB  CUCM  clusters.  
 
   

103 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 5.3 Assure  that  users  at  HQ  can  park  a  call  at  extension  1099  and  retrieve  that  call  from  
any  phone  by  dialing  a  prefix  of  “80”  followed  by  1099.  The  call  should  specifically  
revert  to  extension  1001.  
 
In  this  task,  we’re  still  working  with  Call  Park—just  a  different  type.  The  requirements  dictate  that  we  
use  Directed  Call  Park  here,  since  a  specific  number  is  being  used  to  do  the  parking.  To  configure,  
navigate  to  Call  Routing  !  Directed  Call  Park  and  click  the  Add  New  button.  
 
For  the  “Number”  field,  enter  the  specified  number  of  1099  so  users  can  park  calls  at  that  extension.  
Next,  select  the  “Partition”  where  the  number  will  reside.  Exactly  as  was  done  with  “normal”  call  park,  
make  sure  that  the  Device  CSS  of  the  phone  that  will  be  parking  the  call  has  access  to  the  partition  of  
the  Directed  Call  Park  Number.  Next,  set  the  “Reversion  Number”  to  1001  as  described  in  the  
requirements.  The  system  will  use  this  number  for  call  reversion  in  the  case  where  a  parked  call  is  not  
picked  up  within  the  configured  time  window.  Remember  to  set  a  CSS  here  as  well  (e.g.  “PHONE_CSS”),  
to  ensure  that  the  system  has  access  to  the  “Reversion  Number”.  Finally,  set  the  “Retrieval  Prefix”  to  
80  as  dictated  by  the  task.  With  this  prefix  in  place,  users  should  dial  801099  to  retrieve  a  call  that  was  
parked  using  Directed  Call  Park.  
 

 
 
To  test,  set  up  a  call  between  HQ  Phone  1  and  2.  For  Directed  Call  Park,  hit  the  Transfer  softkey  (or  
button  on  the  9971)  and  transfer  the  call  to  1099.  The  call  is  now  parked  at  extension  1099  and  can  be  
retrieved  simply  by  dialing  801099  (since  80  was  the  Retrieval  Prefix).  
 
   

104 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 5.4 Each  phone  should  have  the  ability  to  monitor  the  status  of  the  parked  call  at  1099  by  
using  a  speed  dial  button  on  each  phone.  The  phone  should  also  be  able  to  retrieve  a  
parked  call  by  pressing  a  single  button.  Use  the  last  two  available  button  slots  for  this  
purpose.  
 
Monitoring  the  Directed  Call  Park  number  on  the  HQ  CUCM  cluster  can  be  accomplished  by  creating  a  
button  on  each  phone  that  is  reserved  specifically  for  a  Busy  Lamp  Field  (BLF)  Call  Park  number.  This  
type  of  button  tracks  busy/idle  status  in  addition  to  acting  as  a  speed  dial.  Remember,  to  retrieve  a  call  
that  has  been  parked  using  Directed  Call  Park,  we  simply  dial  the  number  801099.  To  retrieve  the  
parked  call  using  a  single  button,  all  we  need  here  is  a  speed  dial  to  access  that  specific  number.  We  
will  need  to  modify  our  Phone  Button  Templates  on  both  the  7965  and  9971  phones  to  accomplish  
this.  
 
Navigate  to  Device  !  Device  Settings  !  Phone  Button  Template  and  click  on  the  “Standard  7965  SCCP  
-­‐  3L-­‐3S”  template  that  was  created  in  an  earlier  task.  Modify  the  template  to  include  a  more  
descriptive  name  for  the  new  purpose  of  the  template  (e.g.  “Standard  7965  SCCP  -­‐  3L-­‐1S-­‐1P-­‐1S”)  as  
well  as  a  Call  Park  BLF  button  in  position  5.  Click  the  Save  and  Apply  Config  buttons  to  push  the  new  
configuration  to  the  phone.  
 

 
 
Do  the  same  for  the  9971  Phone  Button  Template  as  well.  
 

 
 
   

105 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Device  !  Phone  and  click  on  the  MAC  address  of  one  of  the  phones  at  HQ.  Under  the  
“Association  Information”  section,  click  the  link  labeled  “Add  a  new  BLF  Directed  Call  Park”.  
 

 
 
In  the  popup  window,  select  the  Directory  Number  corresponding  to  the  Directed  Call  Park  number  
and  choose  a  descriptive  name  for  the  Label.  Click  the  Save  button  to  save  and  close  the  window.  
 

 
 
Next,  click  the  “Add  a  new  SD”  link  under  the  “Association  Information”  section.  Add  the  speed  dial  for  
801099  in  the  second  position  and  click  the  Save  button.  
 

 
 
Complete  this  task  on  the  other  phone  at  HQ  as  well.  When  complete,  the  display  on  the  phone  should  
appear  as  shown  below.  
 

 
 
Test  the  configuration  by  parking  a  call  on  the  1099  Directed  Call  Park  number.  On  an  active  call,  you  
may  hit  the  Transfer  key/button  and  press  the  Directed  Call  Park  BLF  button  to  park  the  call.  The  status  
should  immediately  change  on  the  button,  as  shown  below.  
 

 
 

106 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
To  retrieve  the  call  just  press  the  DCP  Retrieve  speed  dial  phone  button.  
 
Task 5.5 Assure  that  inbound  calls  to  HQ  Phone  1  can  be  answered  by  either  HQ  Phone  1  or  HQ  
Phone  2.  An  audio  and  visual  alert  should  be  displayed  on  HQ  Phone  2  after  HQ  Phone  
1  has  been  ringing  for  2  seconds.  Use  number  1212  for  this  task.  Ensure  that  both  
calling  and  called  party  information  is  displayed.  
 
This  task  is  asking  us  to  configure  the  Call  Pickup  feature.  This  feature  will  allow  phones  that  exist  in  
the  same  Call  Pickup  Group  to  answer  incoming  calls  to  any  other  phone  in  that  group.  To  configure,  
navigate  to  Call  Routing  !  Call  Pickup  Group  and  click  the  Add  New  button.  
 
Give  it  a  descriptive  name  (e.g.  “HQ_CPG”)  and  enter  the  “Call  Pickup  Group  Number”  of  1212,  as  
dictated  by  the  task.  Next,  select  a  “Partition”  from  the  dropdown  box  that  is  accessible  by  the  HQ  
phones.  
 

 
 
The  next  section  in  the  page  allows  the  configuration  of  the  other  requested  features.  Make  sure  to  
select  “Audio  and  Visual  Alert”  for  the  “Call  Pickup  Group  Notification  Policy”  and  set  the  “Call  Pickup  
Group  Notification  Timer”  to  2  seconds.  Next,  ensure  that  both  calling  and  called  party  information  is  
displayed,  by  checking  the  corresponding  checkboxes.  
 

 
 
In  addition,  softkeys  need  to  be  added  to  each  phone  in  order  to  answer  incoming  calls  for  the  Call  
Pickup  group.  To  configure,  navigate  to  Device  !  Device  Settings  !  Softkey  Template  and  click  the  
Find  button.  Click  on  the  “Standard  User”  softkey  template  and  click  the  Copy  button  to  create  a  new  
template  based  on  the  “Standard  User”  template.  Name  it  appropriately  and  click  the  Go  button  to  

107 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

“Configure  Softkey  Layout”  in  the  “Related  Links”  section.  For  both  the  On  and  Off  Hook  states,  add  the  
“Pick  Up  (PickUp)”  option  to  the  “Selected  Softkeys”  section  and  click  the  Save  button.  
 

 
 
Remember,  since  the  9971  phone  does  not  use  a  Softkey  Template,  we  must  create  a  Feature  Control  
Policy  to  accommodate  Call  Pickup.  Navigate  to  Device  !  Device  Settings  !  Feature  Control  Policy  
and  click  the  Find  button.  A  previous  policy  was  created  to  accomplish  the  Call  Park  task,  so  we  can  use  
the  existing  policy  to  add  the  Call  Pickup  feature  by  checking  the  “Call  PickUp”  checkbox  within  the  
Feature  Control  Policy  page.  Rename  the  policy  something  descriptive  (e.g.  “Call-­‐Park-­‐Pickup_FCP”)  
and  click  the  Save  button.  
 

 
 
Now  that  both  the  Softkey  Template  and  Feature  Control  Policy  have  been  created,  they  need  to  be  
assigned  to  the  phone.  Navigate  to  Device  !  Phone  and  click  the  MAC  address  of  HQ  Phone  1.  Ensure  
that  “Call-­‐Park-­‐Pickup_FCP”  is  selected  as  the  “Feature  Control  Policy”.  
 

 
 
Next,  ensure  that  HQ  Phone  2  has  the  “Standard  User  –  Pickup”  option  selected  for  the  “Softkey  
Template”  parameter.  
 

 
 
The  final  step  to  activating  Call  Pickup  is  to  assign  the  Call  Pickup  group  to  the  line  configuration.  From  
the  “Phone  Configuration”  page,  click  the  desired  “Line”  under  the  “Association  Information”  section  

108 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

to  enter  the  line  configuration.  Under  the  “Call  Forward  and  Call  Pickup  Settings”,  select  the  desired  
“Call  Pickup  Group”  and  click  the  Save  button.  
 

 
 
To  test  the  configuration,  make  a  call  to  either  HQ  phone  and  observe  the  behavior.  Ensure  that  audio  
and  visual  alerts  happen  successfully.  Also  ensure  that  calling  and  called  party  information  is  displayed  
as  well.  The  below  screenshot  happens  when  HQ  Phone  2  calls  itself.  
 

 
 
Task 5.6 Assure  that  inbound  calls  to  SB  Phone  2  can  be  answered  by  SB  Phone  1  by  pressing  
the  Group  Pickup  softkey  and  the  corresponding  group  number  (student’s  choice).  
Only  visual  alerts  are  required  here,  but  they  must  be  displayed  in  1  second  along  with  
the  calling  party  info  only.  
 
Pickup  groups  are  again  involved  in  this  configuration.  This  time,  multiple  Pickup  Groups  should  be  
created  since  it  was  specified  that  the  “Group  Pickup”  softkey  should  be  used  when  SB  Phone  1  
answers  calls  destined  to  SB  Phone  2.  Just  as  in  the  previous  task,  we  need  to  navigate  to  Call  Routing  
!  Call  Pickup  Group  and  click  the  Add  New  button.  This  time,  create  two  pickup  groups  with  the  
information  displayed  in  the  below  screenshots.  
 

 
 

109 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  create  the  necessary  Softkey  Templates  and  assign  them  to  the  devices  at  SB.  Navigate  to  Device  
!  Device  Settings  !  Softkey  Template  and  click  the  Find  button.  Modify  both  the  On  and  Off  Hook  
states  within  the  existing  templates  (“Standard  User  –  NoNewCall”  and  “Standard  User  –  QRT”)  to  
include  the  Group  Pickup  softkey  by  clicking  on  the  template  name,  using  the  “Configure  Softkey  
Layout”  option,  and  adding  “Group  Pick  Up  (GPickUp)”  to  the  “Selected  Softkeys”  section.  
 

 
 
Since  the  Softkey  templates  are  already  assigned  to  the  phones  from  previous  tasks,  all  we  need  to  do  
here  is  click  Save  and  Apply  Config.  
 
The  phone  should  display  the  GPickup  softkey  as  seen  below.  
 

 
 

110 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

From  here,  the  lines  should  be  configured  to  use  the  configured  Call  Pickup  Groups.  From  the  “Phone  
Configuration”  page,  click  the  desired  “Line”  under  the  “Association  Information”  section  to  enter  the  
line  configuration.  Under  the  “Call  Forward  and  Call  Pickup  Settings”,  select  the  desired  “Call  Pickup  
Group”  and  click  the  Save  button.  
 
For  SB  Phone  1,  select  the  SBP1_CPG.  
 

 
 
For  SB  Phone  2,  select  the  SBP2_CPG.  
 

 
 
To  test  the  configuration,  make  a  call  from  SB  Phone  2  to  itself  and  pick  it  up  using  the  GPickUp  softkey  
on  SB  Phone  1.  Keep  in  mind  that  the  Call  Pickup  Group  number  must  be  dialed  in  order  to  pick  up  calls  
for  that  group;  in  this  case,  SB  Phone  1  would  need  to  dial  2122  in  order  to  pick  up  incoming  calls  
destined  for  SB  Phone  2.      

111 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 5.7 Configure  a  speed  dial  on  HQ  Phone  2,  button  4  that  allows  the  monitoring  of  the  
status  of  the  remote  line  of  HQ  Phone  1.  Configure  the  reverse  for  HQ  Phone  1.  
Individual  phone  button  templates  cannot  be  used.  Phone  names  should  be  displayed  
on  the  speed  dial  button.  
 
This  task  involves  configuration  on  the  HQ  cluster  to  create  Busy  Lamp  Field  (BLF)  Speed  Dials  for  
monitoring  the  lines  on  each  phone.  When  BLF  Speed  Dials  are  created  we  need  to  ensure  that  phones  
have  access  to  the  partition  in  which  the  monitored  lines  exist  using  the  Subscribe  CSS.  In  addition,  the  
task  states  that  individual  templates  cannot  be  used.  This  means  that  we  must  use  Phone  Button  
Templates  to  create  this  configuration.  
 
To  create  the  Phone  Button  Templates,  navigate  to  Device  !  Device  Settings  !  Phone  Button  
Template  and  click  the  Find  button.  Both  the  “Standard  7965  SCCP  -­‐  3L-­‐1S-­‐1P-­‐1S”  and  the  “Standard  
9971  SIP  -­‐  3L-­‐1S-­‐1P-­‐1S”  templates  that  were  created  in  earlier  labs  should  be  modified  to  include  a  BLF  
Speed  Dial  on  button  4.  It  is  also  a  good  idea  to  change  the  name  to  accurately  reflect  the  buttons  that  
are  contained  within  the  template.  
 

 
 

 
 
Since  the  Phone  Button  Templates  are  already  assigned  to  the  phones,  all  that  is  necessary  after  the  
creation  of  the  template  is  to  click  the  Apply  Config  button  to  push  the  configuration  out  to  the  
phones.  
 
Next,  create  the  BLF  speed  dials  on  the  phone  by  navigating  to  Device  !  Phone  and  clicking  on  the  
MAC  address  of  the  phone  in  question.  Under  the  “Association  Information”  section,  click  the  “Add  a  
new  BLF  SD”  link.  Select  the  number  to  be  monitored  from  the  dropdown  box  as  well  as  the  label  for  
the  phone  display  and  click  the  Save  button.  
 

112 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Based  on  the  number  that  was  selected,  the  partition  in  which  the  monitored  line  exists  can  be  
determined.  In  this  example,  the  INTERNAL_PT  Partition  houses  all  DNs  in  the  system.  We  must  then  
create  a  CSS  that  contains  that  Partition  to  be  used  for  the  Subscribe  CSS.  Alternatively,  we  can  simply  
use  an  existing  CSS  that  has  access  to  that  Partition.  
 
In  the  “Device  Configuration”  page  for  the  phone,  locate  the  parameter  labeled  “SUBSCRIBE  Calling  
Search  Space”  under  the  “Protocol  Specific  Information”  heading.  Ensure  that  a  suitable  CSS  is  chosen  
from  the  dropdown  box  (e.g.  PHONES_CSS).  
 

 
 
Make  sure  that  both  HQ  Phone  1  and  2  have  BLF  speed  dials  configured  and  are  able  to  monitor  the  
line  successfully.  
 

 
 

 
 
   

113 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 5.8 Configure  a  speed  dial  on  SB  Phone  1,  button  4  that  allows  the  monitoring  of  the  
status  of  the  remote  line  of  SB  Phone  2.  Configure  the  reverse  for  SB  Phone  2.  
Individual  phone  button  templates  cannot  be  used.  Phone  names  should  be  displayed  
on  the  speed  dial  button.  
 
Basically  this  task  is  asking  us  to  repeat  the  configuration  that  was  done  on  the  HQ  CUCM  cluster  in  the  
previous  task.  On  the  SB  CUCM  cluster,  we  need  to  configure  Phone  Button  Templates,  a  BLF  Speed  
Dial,  and  a  Subscribe  CSS  in  order  to  monitor  the  line.  The  results  should  appear  as  seen  below.  
 

 
 

 
 
   

114 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 5.9 Ensure  that  presence  information  is  available  in  the  Call  History  Lists  (Missed,  Placed,  
and  Received  Calls)  for  both  HQ  and  SB  CUCM  clusters.  
 
In  order  to  enable  presence  information  in  the  call  lists,  an  Enterprise  Parameter  labeled  “BLF  For  Call  
Lists”  should  be  enabled.  In  addition,  we  still  need  to  have  the  Subscribe  CSS  assigned  to  the  phone  in  
order  to  grant  access  to  Partitions  that  contain  those  DNs  within  the  call  history.  
 
To  configure,  navigate  to  System  !  Enterprise  Parameters  and  locate  the  setting  labeled  “BLF  For  Call  
Lists”.  Select  “Enabled”  in  the  dropdown  box  and  click  the  Save  button.  You  may  need  to  restart/reset  
the  phones  for  the  change  to  take  effect.  
 

 
 
After  configuring,  phones  will  display  call  lists  similar  to  the  following  screenshot.  
 

115 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 6: CUCME SCCP Basic Phone Registration


Task 6.1 Assure  that  the  Voice  VLAN  interface  on  R3  is  used  as  the  source  address  for  CUCME  
SCCP  Phones.  
 
Cisco  Unified  CME  is  a  feature-­‐rich  entry-­‐level  IP  telephony  solution  that  is  integrated  directly  into  
Cisco  IOS  software.  Cisco  Unified  CME  allows  small  business  customers  and  autonomous  small  
enterprise  branch  offices  to  deploy  voice,  data,  and  IP  telephony  on  a  single  platform  for  small  offices,  
thereby  streamlining  operations  and  lowering  network  costs.  
 
Cisco  Unified  CME  is  ideal  for  customers  who  have  data  connectivity  requirements  and  also  have  a  
need  for  a  telephony  solution  in  the  same  office.  Whether  offered  through  a  service  provider’s  
managed  services  offering  or  purchased  directly  by  a  corporation,  Cisco  Unified  CME  offers  most  of  the  
core  telephony  features  required  in  the  small  office,  and  also  many  advanced  features  not  available  
with  traditional  telephony  solutions.  The  ability  to  deliver  IP  telephony  and  data  routing  by  using  a  
single  converged  solution  allows  customers  to  optimize  their  operations  and  maintenance  costs,  
resulting  in  a  very  cost-­‐effective  solution  that  meets  office  needs.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm/
cmeover.html]    
 
As  you  can  probably  imagine,  CUCME  can  be  used  for  both  SCCP  and  SIP  phones.  The  router  has  two  
different  processes  that  control  each  type  of  phone  registration.  For  SCCP  phones,  that  process  is  
called  telephony-service.  For  SIP  phones,  it  is  called  voice register global.  Since  this  
lab  will  be  working  exclusively  with  SCCP  phones,  it  is  safe  to  assume  at  this  point  that  we  will  be  
working  with  the  telephony-service  process  on  the  router.  
 
This  lab  will  attempt  to  step  slowly  through  the  system,  which  hopefully  will  result  in  a  solid  
understanding  of  the  concepts!  First,  in  order  to  enable  SCCP  registration  on  a  router,  the  
telephony-service  command  should  be  entered.  Next,  the  task  is  asking  us  to  configure  the  
source  IP  address  for  the  SCCP  CUCME.  This  can  be  accomplished  by  using  the  ip source-
address <IP Address>  command.  Within  the  command,  we  also  have  the  option  of  defining  a  
TCP  port  in  addition  to  the  option  of  the  strict-match  keyword.  Strict-­‐match  following  the  IP  
address  instructs  the  CUCME  system  to  reject  IP  phone  registration  attempts  if  the  IP  server  address  
used  by  the  phone  does  not  exactly  match  the  configured  source  address.  The  ip source-
address  command  is  the  first  of  the  “must  have”  commands  to  configure  SCCP  CUCME.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#ip source-address 10.10.31.1 port 2000
 
   

116 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.2 Assure  that  SCCP  phones  do  not  automatically  register  to  the  system.  
 
This  option  is  important  when  configuring  SCCP  phones  within  CUCME,  since  auto-­‐registration  is  
enabled  by  default.  This  means  that  CUCME  reserves  a  slot  for  any  phone  that  connects  to  it,  whether  
the  MAC  address  exists  in  the  configuration  or  not.  If  you  want  to  prevent  phones  from  registering  
automatically,  we  simply  must  turn  off  the  auto-­‐registration  feature.  This  is  accomplished  with  the  no
auto-reg-ephone  command  under  the  telephony-service  configuration  section.  
 
When  automatic  registration  is  blocked,  Cisco  Unified  CME  records  the  MAC  addresses  of  phones  that  
attempt  to  register  but  cannot  because  they  are  blocked.  Use  the  show ephone attempted-
registrations  command  to  view  the  list  of  phones  that  have  attempted  to  register  but  have  been  
blocked.  Use  the  clear telephony-service ephone-attempted-registrations  
command  to  clear  the  list  of  phones  that  have  attempted  to  register  but  have  been  blocked.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/command/reference/cme_cr/cme_a1
ht.html  -­‐  wp3432972036]  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#no auto-reg-ephone
 
   

117 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.3 Limit  the  amount  of  DNs  on  the  system  to  10.  
 
Since  CUCME  is  running  on  a  router,  and  not  a  dedicated  call  processing  server,  it  makes  sense  that  we  
would  want  to  limit  the  number  of  directory  numbers  that  could  be  created,  so  as  to  conserve  system  
resources  and  not  overload  the  router.  Also,  we  might  want  to  limit  the  number  of  DNs  on  the  system  
to  conserve  DSP  resources  (on  PVDM  modules)  for  other  services  like  conferencing,  transcoding,  etc.  
 
In  addition  to  the  above,  limiting  the  DNs  on  the  system  is  actually  a  required  function  to  get  CUCME  
configured  on  the  router.  Under  telephony-service,  configure  the  command  max-dn
<number>  command.  You  also  have  the  option  of  using  the  no-reg  keyword  (to  make  sure  
extensions  don’t  register  with  a  gatekeeper)  and  the  preference  keyword,  which  allows  you  to  
modify  the  preference  that  the  auto-­‐created  telephony-­‐service  dial-­‐peers  have  within  the  system.  This  
can  be  used  to  control  dial-­‐peer  selection  if  a  router  has  been  configured  to  run  SRST—more  on  that  
later!  
 
Along  with  the  ip source-address command,  the  max-dn  command  is  another  “must  have”  
for  configuring  CUCME.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#max-dn 10
 
   

118 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.4 Limit  the  amount  of  phones  that  can  be  registered  to  the  system  to  5.  
 
With  the  same  logic  that  was  applied  to  the  previous  task,  we  should  limit  the  number  of  phones  that  
can  register  to  the  CUCME  system  as  well.  This  can  be  accomplished  with  the  max-ephones
<number>  command  under  the  telephony-service  heading.  CUCME  identifies  phones  that  are  
connected  to  the  system  as  ephones.  The  ephone  command  will  also  be  used  (in  upcoming  tasks)  to  
configure  phones  on  the  CUCME  system.  
 
R3  
R3(config-telephony)#telephony-service
R3(config-telephony)#max-ephones 5

Along  with  the  ip source-address  command  and  the  max-dn  command,  the  max-ephones  
command  is  the  last  “must  have”  for  configuring  CUCME.  
 
   

119 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.5 Assure  that  all  SCCP  phones  display  the  message  “iPexpert  CCIE  Collaboration”  across  
the  bottom  of  the  screen.  
 
This  task  is  simply  adding  a  message  to  the  bottom  of  the  screen  when  phones  are  registered.  In  
CUCM,  7965  phones  display  the  message  “Your  current  options”.  Within  CUCME  the  message  “Cisco  
Unified  CME”  is  displayed  by  default.  In  order  to  change  it,  we  can  use  the  system message
<Message>  command  under  telephony-­‐service.    
 
R3  
R3(config-telephony)#telephony-service
R3(config-telephony)#system message iPexpert CCIE Collaboration

Once  the  phone  is  configured,  the  message  will  be  displayed  as  seen  below.  
 

 
 
   

120 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.6 Enable  GUI  access  to  CUCME  using  the  username  of  “admin”  and  the  password  of  
“cisco”.  Editing  DNs  and  changing  the  time  should  be  possible.  Ensure  that  the  GUI  is  
accessible  at  http://10.10.31.1/ccme.html.  
 
CUCME  has  the  ability  to  run  a  GUI  for  configuration  as  an  alternative  to  the  command  line.  Although  
this  may  sound  enticing,  it  is  definitely  not  recommended  for  CCIE  Lab  prep.  First  of  all,  the  interface  is  
clunky,  outdated,  and  can  be  difficult  to  use.  Second,  the  GUI  can  only  be  used  with  SCCP  phones,  so  if  
SIP  phones  are  required,  it  is  completely  useless.  Lastly,  there  is  no  guarantee  that  the  GUI  will  be  
accessible  in  the  lab,  so  if  you  are  used  to  configuring  the  system  through  the  GUI,  you  may  be  out  of  
luck.  
 
With  all  that  said,  this  task  is  still  asking  us  to  at  least  configure  access  to  the  GUI.  The  first  step  is  to  
locate  the  CUCME  GUI  files  within  the  flash  directory.  Typically,  I  will  search  for  the  string  “.html”  
within  the  flash  directory  to  look  for  the  files.  
 
R3  
R3#sh flash | i .html
...
378 4118 Jul 1 2014 16:12:02 +01:00 cme/gui/admin_user.html
385 6315 Jul 1 2014 16:12:06 +01:00 cme/gui/ephone_admin.html
387 3978 Jul 1 2014 16:12:08 +01:00 cme/gui/normal_user.html
392 2496 Jul 1 2014 16:12:10 +01:00 cme/gui/telephony_service.html
394 10230 Jul 1 2014 16:12:10 +01:00 cme/gui/xml-test.html

We  can  see  from  the  above  that  the  files  are  located  in  the  flash:/CME/GUI/  directory.  To  confirm,  
search  for  that  directory  in  flash.  
 
R3  
R3#sh flash | i cme/gui
377 0 Jul 1 2014 16:12:02 +01:00 cme/gui
378 4118 Jul 1 2014 16:12:02 +01:00 cme/gui/admin_user.html
379 677820 Jul 1 2014 16:12:04 +01:00 cme/gui/admin_user.js
380 1029 Jul 1 2014 16:12:04 +01:00 cme/gui/CiscoLogo.gif
381 1019 Jul 1 2014 16:12:06 +01:00 cme/gui/CME_GUI_README.TXT
382 953 Jul 1 2014 16:12:06 +01:00 cme/gui/Delete.gif
383 16344 Jul 1 2014 16:12:06 +01:00 cme/gui/dom.js
384 864 Jul 1 2014 16:12:06 +01:00 cme/gui/downarrow.gif
385 6315 Jul 1 2014 16:12:06 +01:00 cme/gui/ephone_admin.html
386 4558 Jul 1 2014 16:12:08 +01:00 cme/gui/logohome.gif
387 3978 Jul 1 2014 16:12:08 +01:00 cme/gui/normal_user.html
388 78428 Jul 1 2014 16:12:08 +01:00 cme/gui/normal_user.js
389 1347 Jul 1 2014 16:12:08 +01:00 cme/gui/Plus.gif
390 843 Jul 1 2014 16:12:10 +01:00 cme/gui/sxiconad.gif
391 174 Jul 1 2014 16:12:10 +01:00 cme/gui/Tab.gif
392 2496 Jul 1 2014 16:12:10 +01:00 cme/gui/telephony_service.html
393 870 Jul 1 2014 16:12:10 +01:00 cme/gui/uparrow.gif
394 10230 Jul 1 2014 16:12:10 +01:00 cme/gui/xml-test.html
395 3412 Jul 1 2014 16:12:12 +01:00 cme/gui/xml.template

Now  that  we  know  the  path,  we  can  use  the  ip http path  command  to  direct  the  router  to  use  
the  CUCME  GUI  files  with  the  built-­‐in  IOS  HTTP  server.  
 
R3  
R3(config)#ip http path flash:cme/gui

121 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  should  set  the  privilege  on  the  flash  files  in  the  directory  to  zero  so  IOS  authentication  does  
not  have  to  take  place  in  addition  to  the  GUI  authentication  to  access  the  files  in  the  GUI  directory.  
 
R3  
R3(config)# file privilege 0
 
Next,  we  need  to  actually  enable  the  IOS  HTTP  server  in  the  router.  Also,  if  we  don’t  have  certificates  
configured,  we  should  disable  the  IOS  HTTPS  server  as  well.  
 
R3  
R3(config)#ip http server
R3(config)#no ip http secure-server
 
Now  that  the  HTTP  configuration  has  been  completed,  CUCME  must  be  configured  to  support  the  GUI.  
Under  telephony-service,  we  must  configure  the  use  of  the  administrator  account  so  
authentication  to  the  GUI  is  possible.  This  is  done  with  the  web admin system name
<username> password <password>  command.  Next,  we  should  enable  the  adding/editing  of  
DNs  as  well  as  the  updating  of  system  time  within  the  webpage.  This  can  be  done  with  the  dn-
webedit  and  time-webedit  commands.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)# web admin system name admin password cisco
R3(config-telephony)# dn-webedit
R3(config-telephony)# time-webedit

Finally  we  are  ready  to  access  the  GUI  at  http://<Router  IP  Address>/ccme.html.  Remember  to  use  the  
credentials  created  under  telephony-service  to  log  into  the  GUI.  
 

 
 
   

122 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.7 Configure  the  SCCP  phones  to  register  with  the  settings  as  defined  in  the  
Supplementary-­‐Info.pdf  file.  Ensure  that  8  calls  per  line  are  possible.  
 
The  Supplementary-­‐Info.pdf  file  dictates  that  SC  Phone  1  should  be  a  7965  phone  and  should  use  DN  
3001.  To  accommodate  this  configuration,  we  should  first  configure  the  line  in  the  system.  Once  the  
line  is  configured,  we  should  configure  the  phone.  
 
The  line  can  be  configured  using  the  ephone-dn <number> command.  Two  different  keywords  
can  be  applied  following  the  command  dual-line  or  octo-line.  These  keywords  indicate  the  
number  of  channels  that  are  available  for  both  inbound  and  outbound  calls.  With  the  dual-line  
option,  2  channels  are  available  and  with  the  octo-line  option,  8  channels  are  available.  If  no  
keywords  are  configured,  there  will  only  be  one  channel  available  for  inbound  and  outbound  calls.  
 
R3  
R3(config)#ephone-dn 1 octo-line
R3(config-ephone-dn)#number 3001
R3(config-ephone-dn)#name SC Phone 1

The  above  configuration  sets  the  line  to  use  8  channels  using  DN  3001.  It  also  sets  the  calling  name  to  
“SC  Phone  1”.  
 
Next,  the  phone  should  be  configured  by  entering  the  ephone  command.  The  mac-address  
command  should  be  entered  to  identify  the  MAC  address  of  the  phone  that  will  register  with  the  
system.  Once  again,  this  should  be  obtained  from  the  show cdp neighbors  command  and  pasted  
into  the  configuration.  Next,  the  phone  type  is  identified  as  a  7965,  as  described  in  the  
Supplementary-­‐Info.pdf  file.  Finally,  the  button <Phone Button>:<Line Number>  command  
is  used  to  assign  the  configured  line  to  a  button  on  the  phone.  The  colon  (:)  character  is  called  a  button  
separator  and  it  specifies  “normal”  ringing.  The  below  commands  assign  ephone-dn 1  to  phone  
button  1  on  the  7965  phone  with  the  MAC  address  001E.BE92.3406.  
 
R3  
R3(config)#ephone 1
R3(config-ephone)#mac-address 001E.BE92.3406
R3(config-ephone)#type 7965
R3(config-ephone)#button 1:1

There  are  several  other  types  of  button  separators  in  addition  to  the  colon  (:),  as  described  below.  
 
• :  (colon)—Normal  ring.  For  incoming  calls  on  this  extension,  the  phone  produces  audible  
ringing,  a  flashing  icon  in  the  phone  display,  and  a  flashing  red  light  on  the  handset.  On  the  
Cisco  IP  Phone  7914  Expansion  Module,  a  flashing  yellow  light  also  accompanies  incoming  calls.  
• b—Beep  but  no  ring.  Audible  ring  is  suppressed  for  incoming  calls,  but  call-­‐waiting  beeps  are  
allowed.  Visible  cues  are  the  same  as  those  described  for  a  normal  ring.  
• c—Call  waiting.  Provides  call  waiting  for  secondary  calls  to  an  overlaid  ephone-­‐dn.  See  also  the  
o  keyword.  

123 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

• f—Feature  ring.  Differentiates  incoming  calls  on  a  special  line  from  incoming  calls  on  other  lines  
on  the  phone.  The  feature-­‐ring  cadence  is  a  triple  pulse,  as  opposed  to  a  single  pulse  for  normal  
internal  calls  and  a  double  pulse  for  normal  external  calls.  
• m—Monitor  mode  for  a  shared  line.  Visible  line  status  indicates  whether  the  line  is  in-­‐use  or  
not.  Monitored  lines  cannot  be  used  on  this  phone  for  incoming  or  outgoing  calls.  
• o—Overlay  line.  Multiple  ephone-­‐dns  share  a  single  button,  up  to  a  maximum  of  25  on  a  
button.  See  also  the  c  keyword.  
• s—Silent  ring.  Audible  ring  and  call-­‐waiting  beep  are  suppressed  for  incoming  calls.  The  only  
visible  cue  is  a  flashing  ((<  icon  in  the  phone  display.  
Note:    In  Cisco  IOS  Release  12.4(4)XC  and  later  releases,  the  silent  ringing  behavior  is  
overridden  during  active  night-­‐service  periods.  Silent  ringing  does  not  apply  during  designated  
night-­‐service  periods  when  the  s  keyword  is  used.  
• w—Watch  mode  for  all  lines  on  the  phone  for  which  this  directory  number  is  the  primary  line.  
Visible  line  status  indicates  whether  watched  phone  is  idle  or  not.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/command/reference/cme_cr/cme_b1
ht.html]  
 
We  will  see  more  applications  of  different  button  separators  throughout  the  Detailed  Solution  Guide.  
 
To  verify  that  the  phone  has  indeed  registered  with  the  router,  enter  the  command  show ephone
registered  to  display  the  current  status.  Also,  the  command  show telephony-service
dial-peer can  be  used  to  ensure  that  the  phone  has  registered.  No  virtual  POTS  dial-­‐peer  will  be  
created  until  the  ephone  actually  registers.  
 
R3#sh ephone registered

ephone-1[0] Mac:001E.BE92.3406 TCP socket:[1] activeLine:0 whisperLine:0 REGISTERED in SCCP ver 19/17
max_streams=5
mediaActive:0 whisper_mediaActive:0 startMedia:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0
debug:0 caps:9 privacy:1
IP:10.10.31.36 * 51357 7965 keepalive 0 max_line 6 available_line 6
button 1: cw:1 ccw:(0 0 0 0 0 0 0 0)
dn 1 number 3001 CH1 IDLE CH2 IDLE CH3 IDLE CH4 IDLE CH5 IDLE CH6 IDLE
CH7 IDLE CH8 IDLE
Preferred Codec: g711ulaw
Lpcor Type: none

R3#show telephony-service dial-peer

dial-peer voice 20014 pots


destination-pattern 3001$
huntstop
progress_ind setup enable 3
port 50/0/1
 
   

124 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.8 After  the  phones  have  successfully  registered,  delete  the  configuration  and  shut  down  
the  switchports  connected  to  the  phones.  
 
As  was  done  in  the  CUCM  lab,  the  configure  phone  should  now  be  deleted  so  it  can  be  reconfigured  
through  auto-­‐registration.  
 
R3  
R3(config)#no telephony-service
Skinny Deleted entries for 1 phones

R3(config)#
Oct 10 23:51:01.517: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP001EBE923406 IP:10.10.31.36 Socket:1
DeviceType:Phone has unregistered normally.

R3(config)#interface gigabitEthernet 0/2/2


R3(config-if)#shutdown
Oct 10 23:52:11.576: %LINK-5-CHANGED: Interface GigabitEthernet0/2/2, changed state to
administratively down
Oct 10 23:52:12.576: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2/2, changed
state to down
 
   

125 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.9 Configure  the  phones  to  auto  register  to  the  CUCME  system.  
 
Remember,  auto-­‐registration  is  enabled  by  default  within  telephony-service.  However,  no  lines  
will  automatically  be  assigned  to  the  phone  unless  this  is  configured  in  some  fashion.  This  can  be  done  
using  the  auto assign command.  This  command  isn’t  exactly  intuitive,  as  it  doesn’t  really  create  a  
line  for  you.  You  will  still  need  to  configure  each  ephone-dn  in  the  system.  The  command  does  
however,  allow  administrators  to  select  a  range  of  previously  configured  ephone-dns  in  the  system  
that  can  be  used  for  auto  registration.  When  configured,  the  phone  will  auto  register  with  CUCME  
(automatically  create  the  ephone)  and  then  choose  an  available  line  to  associate  with  the  phone.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#max-ephones 5
R3(config-telephony)#max-dn 10
R3(config-telephony)#ip source-address 10.10.31.1 port 2000
R3(config-telephony)#auto assign 1 to 10

R3(config-telephony)#ephone-dn 1 octo-line
R3(config-ephone-dn)#number 3001
R3(config-ephone-dn)#name SC Phone 1
 
The  above  configuration  will  assign  ephone-dns 1  through  10  to  phones  that  auto  register  with  the  
CUCME  system.  To  test,  issue  the  no shutdown  command  to  the  GigabitEthernet  0/2/2  port  to  bring  
the  7965  (SC  Phone  1)  back  up.  
 
R3(config)#interface gigabitEthernet0/2/2
R3(config-if)#no shutdown
R3(config-if)#
Oct 11 00:26:19.211: %LINK-3-UPDOWN: Interface GigabitEthernet0/2/2, changed state to up
R3(config-if)#
Oct 11 00:26:19.918: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan32, changed state to up
Oct 11 00:26:19.942: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan31, changed state to up
Oct 11 00:26:20.210: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2/2, changed
state to up
R3(config-if)#
Oct 11 00:27:25.314: %IPPHONE-6-REG_ALARM: 40: Name=SEP001EBE923406 Load= term65.default Last=DHCPv6
Timeout
Oct 11 00:27:25.350: %IPPHONE-6-REGISTER_NEW: ephone-1:SEP001EBE923406 IP:10.10.31.36 Socket:1
DeviceType:Phone has registered.
R3(config-if)#
resetting 001E.BE92.3406
R3(config-if)#
Oct 11 00:27:27.362: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP001EBE923406 IP:10.10.31.36 Socket:1
DeviceType:Phone has unregistered normally.
R3(config-if)#
Oct 11 00:28:21.533: %IPPHONE-6-REG_ALARM: 22: Name=SEP001EBE923406 Load= term65.default Last=Reset-
Reset
Oct 11 00:28:21.565: %IPPHONE-6-REGISTER: ephone-1:SEP001EBE923406 IP:10.10.31.36 Socket:1
DeviceType:Phone has registered.

Next,  we  can  see  the  automatically  generated  ephone  in  the  running  configuration.  
 
R3  
R3(config-if)#do sh run | sec ephone 1
ephone 1
device-security-mode none
mac-address 001E.BE92.3406
type 7965
button 1:1

126 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Also,  running  the  commands  show ephone registered  and  show telephony-service
dial-peer  yield  the  same  results  that  were  observed  with  manual  registration.  
 
R3#show ephone registered

ephone-1[0] Mac:001E.BE92.3406 TCP socket:[1] activeLine:0 whisperLine:0 REGISTERED in SCCP ver 19/17
max_streams=5
mediaActive:0 whisper_mediaActive:0 startMedia:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0
debug:0 caps:9 privacy:1
IP:10.10.31.36 * 51257 7965 keepalive 12 max_line 6 available_line 6
button 1: cw:1 ccw:(0 0 0 0 0 0 0 0)
dn 1 number 3001 CH1 IDLE CH2 IDLE CH3 IDLE CH4 IDLE CH5 IDLE CH6 IDLE
CH7 IDLE CH8 IDLE
Preferred Codec: g711ulaw
Lpcor Type: none

R3#show telephony-service dial-peer

dial-peer voice 20027 pots


destination-pattern 3001$
huntstop
progress_ind setup enable 3
port 50/0/1
   

127 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.10 Assure  that  the  phones  have  all  configuration  previously  mentioned.  
 
This  was  completed  in  the  previous  task  by  configuring  the  ip source-address, max-dn,  max-
ephone,  and  system message  commands  within  telephony-service.  Also,  the  ephone-dn  
and  the  ephone  were  created  for  the  auto-­‐registration  process.  
 
R3  
telephony-service
max-ephones 5
max-dn 10
ip source-address 10.10.31.1 port 2000
auto assign 1 to 10
max-conferences 8 gain -6
transfer-system full-consult

ephone-dn 1 octo-line
number 3001
name SC Phone 1

ephone 1
device-security-mode none
mac-address 001E.BE92.3406
type 7965
button 1:1
 
   

128 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 6.11 Add  the  below  configuration  to  support  UnifiedFX  PhoneView.  

telephony-service
xml user PVADMIN password ipexpert 15
url authentication
http://10.10.31.1/CCMCIP/authenticate.asp
PVUSER ipexpert
service phone webAccess 0
service phone sshAccess 0

The  above  configuration  must  be  added  to  support  phone  interaction  within  the  PhoneView  
application  on  HQ  Test  PC  1.  In  addition  to  the  above  commands,  the  below  commands  should  have  
already  been  loaded  into  the  router  in  the  default  configuration.  If  not,  please  paste  the  following  
commands  into  the  router  when  in  configuration  mode.  
 
R3  
ip http server

ixi transport http


response size 64
no shutdown
request outstanding 1

ixi application cme


no shutdown
 

129 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 7: CUCME SIP Basic Phone Registration


Task 7.1 Assure  that  the  Voice  VLAN  interface  on  R3  is  used  as  the  source  address  for  CUCME  
SIP  phones.  
 
From  the  previous  lab,  we  know  that  there  are  two  forms  of  CUCME  that  can  be  run  on  an  IOS  router.  
One  is  called  telephony-service,  which  is  specific  to  SCCP  phones,  and  one  is  called  voice
register global,  which  is  specific  to  SIP  phones.  In  this  lab,  we’ll  be  working  with  voice
register global  to  configure  SIP  phones.  In  a  similar  fashion  to  that  of  telephony-service,  
we  need  to  configure  an  IP  source  address  within  voice register global.  This  instructs  the  
router  to  receive  registration  requests  on  that  specific  address  from  SIP  phones.  
 
To  configure,  let’s  first  enter  voice register global  configuration  mode  and  type  the  “?”  key.  
We’re  looking  for  something  that  resembles  the  ip source-address  command  that  was  used  in  
telephony-service.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#?
voice register global configuration commands:
application Define application
attempted-registrations Define size of the attempted-registrations table
authenticate Define auth mode for SIP CME/SRST
bandwidth allow SIP SDP bandwidth related options
call-forward Decide call forward parameters for an SIP phone
default Set a command to its defaults
dialplan-pattern Define E.164 telephone number prefix
exit Exit from voice register global configuration mode
external-ring Set external ringing to be included into alert-info
fac Voice register global FAC setup
ip Set ip packet options
max-dn Define max number of dn
max-pool Define max number of pool
mode Define mode: CME/SRST
mwi MWI service in SRST mode
no Negate a command or set its defaults
outbound-proxy Configure an Outbound Proxy Server
overlap-signal Configure Overlap Signaling support
security-policy Configure SIP registration security policy
system Define system message
timeouts Define timeout value for sip phone
timezone Set timezone for SIP Phones

After  examining  the  above,  we  see  the  “ip”  command  available.  Type  it  and  then  type  the  “?”  key.  
 
R3  
R3(config-register-global)#ip ?
qos Set ip QoS Parameters
 
It  doesn’t  look  like  the  ip source-address  command  is  available  here!  As  it  turns  out,  there  is  no  
way  to  specify  a  source  at  this  point  because  by  default,  voice register global  is  configured  
for  SRST  mode.  Therefore,  before  we  can  do  anything  in  voice register global,  we  must  
configure  the  mode  that  is  going  to  be  used.  This  can  be  accomplished  with  the  mode  command.  
 
 

130 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3  
R3(config)#voice register global
R3(config-register-global)#mode cme

The  above  command  enabled  voice register global  for  CME  mode,  which  provides  many  
more  configuration  options.  After  entering  the  above  command,  type  the  “?”  to  examine  the  available  
options.  
 
R3  
R3(config-register-global)#?
voice register global configuration commands:
application Define application
apply-config apply config for the 99/89 phones, restart all other
sip phones
attempted-registrations Define size of the attempted-registrations table
authenticate Define auth mode for SIP CME/SRST
bandwidth allow SIP SDP bandwidth related options
bulk Define a pattern for bulk registration
call-feature-uri Define TNP SIP phone's Call Feature URI
call-forward Decide call forward parameters for an SIP phone
camera Enable camera
conference Configure conference type for adhoc
create Create profile for SIP phone
date-format Set date format for IP Phone display
default Set a command to its defaults
dialplan-pattern Define E.164 telephone number prefix
dst Enable / define daylight saving time
exit Exit from voice register global configuration mode
external-ring Set external ringing to be included into alert-info
fac Voice register global FAC setup
file Enable generation of the text profile
forwarding Decide if forwarding local is enabled for SIP phone
hold-alert Enable On-Hold alert for SIP phone
ip Set ip packet options
load Select the firmware load file
logo Define logo url that will be used by SIP phone
max-dn Define max number of dn
max-pool Define max number of pool
mode Define mode: CME/SRST
mwi Generate stutter tone for SIP mwi
network-locale Define network locale
no Negate a command or set its defaults
ntp-server Define NTP server address for TNP phones
olsontimezone Set olson timezone for IP Phones
outbound-proxy Configure an Outbound Proxy Server
overlap-signal Configure Overlap Signaling support
phone-redirect-limit Define max number of redirect per call for SIP phone
privacy Enable privacy for SIP shared-line phone
privacy-on-hold Enable privacy-on-hold for SIP shared-line phone
reset Reset all SIP phones
restart restart all SIP phone
source-address Define IP address and port for SIP CME
tftp-path Define tftp path for SIP CME
time-format Set time format for IP Phone display
timeouts Define timeout value for sip phone
timezone Set timezone for SIP Phones
upgrade Generate OS79XX.TXT for firmware upgrade
url Define SIP phone URL's
user-locale Define SIP Phone user locale
video Enable video
voicemail Set the voicemail access number called when the
messages button is pressed

As  you  can  see,  there  are  several  different  configuration  options  available,  including  one  option  called  
source-address!  This  will,  in  fact,  be  the  configuration  command  that  we  will  use  to  specify  the  IP  

131 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

source  address  for  voice register global.  The  task  dictated  that  the  Voice  VLAN  interface  
(VLAN  31)  be  used  as  the  source  address  for  SIP  phones.  Therefore  the  IP  should  be  10.10.31.1.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#source-address 10.10.31.1

Regarding  the  IP  source  address  for  SIP  phone  registration,  there  is  another  step  to  take  that  needs  to  
happen  outside  of  the  voice register global  configuration.  This  is  an  additional  step  that  was  
not  necessary  when  configuring  SCCP  phones.  We  must  enter  the  global  voice  parameters  
configuration  (voice service voip)  to  configure  global  SIP  parameters  (sip).  Specifically,  we  
need  to  bind  both  control  and  media  traffic  to  the  source  interface  that  corresponds  to  the  IP  address  
configured  within  voice register global;  in  this  case,  the  Vlan  31  SVI.  Also,  we  need  to  
configure  the  router  to  accept  incoming  SIP  Register  messages  using  the  registrar server  
command.  This  command  also  has  a  couple  options  attached:  the  max  and  min  settings.  The  max  
command  refers  to  the  maximum  registration  expiration  time  whereas  the  min  command  refers  to  the  
minimum  registration  expiration  time.  The  default  is  3600  seconds  maximum  (600  is  recommended)  
and  60  seconds  minimum.  If  SIP  Register  message  requests  are  for  a  shorter  expiration  time  than  what  
is  set  with  this  command,  the  SIP  Register  message  expiration  time  is  used  instead  of  the  configured  
value.  
 
R3  
R3(config)#voice service voip
R3(conf-voi-serv)#sip
R3(conf-serv-sip)#bind control source-interface Vlan31
R3(conf-serv-sip)#bind media source-interface Vlan31
R3(conf-serv-sip)#registrar server

At  this  point,  the  router  can  accept  incoming  registration  requests  to  IP  address  of  10.10.31.1  (Vlan  
31).  
 
   

132 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.2 Limit  the  amount  of  DNs  on  the  system  to  10.  
 
Just  as  was  done  with  SCCP  phones  in  telephony-service,  we  have  the  ability  to  limit  the  
amount  of  DNs  that  can  be  configured  on  the  system.  This  can  be  accomplished  by  using  the  max-dn
<number>  command—the  same  syntax  that  was  used  for  SCCP  phones!  Just  as  in  telephony-
service,  this  is  also  a  required  command  within  voice register global  to  ensure  that  SIP  
phones  register  in  CUCME.  In  this  case,  the  maximum  number  of  DNs  allowed  on  this  system  is  10,  as  
configured  below.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#max-dn 10

 
   

133 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.3 Limit  the  amount  of  phones  that  can  be  registered  to  the  system  to  5.  
 
Once  again,  this  configuration  is  very  similar  to  what  was  done  in  telephony-service.  We  simply  
need  to  limit  the  number  of  phones  that  can  register  with  the  router.  In  this  case,  the  syntax  is  a  little  
different  than  what  was  seen  with  SCCP  phones.  Use  the  max-pool <number>  command  to  specify  
the  maximum  number  of  phones  that  can  register  with  the  voice register global  process  on  
the  router.  This  command  is  mandatory  for  registering  SIP  phones.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#max-pool 5
 
   

134 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.4 Assure  that  the  phone  displays  text  in  English  but  uses  progress  tones  compatible  with  
Germany.  
 
This  requirement  can  be  implemented  with  the  use  of  locales.  There  are  two  possible  locale  types  that  
can  be  configured  user-locale  and  network-locale.  
 
The  user-locale  command  within  voice register global  is  used  to  define  languages  for  
display  on  the  phone  itself.  The  network-locale  command  within  voice register global  
is  used  to  select  a  geographically  specific  set  of  tones  and  cadences.  In  this  case,  the  requirements  of  
the  question  dictate  that  we  should  modify  only  the  progress  tones  using  the  network-locale  
command.  Since  the  phone  should  continue  to  display  text  in  English,  the  user-locale  should  not  
be  modified.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#network-locale DE

Keep  in  mind  that  changing  the  network-locale  for  a  9971  requires  a  file  to  be  placed  on  the  
router  as  well.  When  the  phone  attempts  to  register  (which  hasn’t  been  covered  in  this  guide  yet),  it  
will  look  for  a  file  associated  with  the  configured  locale.  In  order  to  see  the  name  of  the  file  for  which  
the  phone  is  searching,  run  the  debug tftp events  command  on  the  router  for  more  detail.  
 
R3  
R3#debug tftp events
TFTP Event debugging is on
Oct 11 05:52:59.768: TFTP: Looking for CTLSEP1C1D86C53EBF.tlv
Oct 11 05:52:59.924: TFTP: Looking for ITLSEP1C1D86C53EBF.tlv
Oct 11 05:53:00.072: TFTP: Looking for ITLFile.tlv
Oct 11 05:53:00.276: TFTP: Looking for SEP1C1D86C53EBF.cnf.xml
Oct 11 05:53:00.276: TFTP: Opened system:/cme/sipphone/SEP1C1D86C53EBF.cnf.xml, fd 8, size 4621 for
process 482
Oct 11 05:53:00.556: TFTP: Finished system:/cme/sipphone/SEP1C1D86C53EBF.cnf.xml, time 00:00:00 for
process 482
Oct 11 05:53:08.924: TFTP: Looking for SIP_English_United_States/gd-sip.jar
Oct 11 05:53:09.132: TFTP: Looking for Germany/g4-tones.xml
Oct 11 05:53:09.464: TFTP: Looking for featurePolicyDefault.xml
Oct 11 05:53:09.464: TFTP: Opened system:/cme/sipphone/featurePolicyDefault.xml, fd 8, size 824 for
process 482
Oct 11 05:53:09.516: TFTP: Finished system:/cme/sipphone/featurePolicyDefault.xml, time 00:00:00 for
process 482

We  can  see  from  the  above  that  the  phone  is  looking  for  the  “g4-­‐tones.xml”  file  in  the  “Germany”  
directory.  If  that  file  does  not  exist,  only  the  tones  associated  with  the  default  network-locale  will  
be  played.  It  is  evident  that  this  is  the  case  in  the  example  above,  since  there  are  no  more  messages  
related  to  the  “g4-­‐tones.xml”  filename  after  the  “Looking  for”  line  is  displayed.  
 
To  fix  the  issue,  download  the  locale  file  from  cisco.com.  After  the  file  is  downloaded,  load  it  into  the  
proper  directory  and  make  sure  that  it  is  accessible  on  the  TFTP  server  by  issuing  the  tftp-server  
command  from  global  configuration  mode.    
   

135 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3  
R3(config)#tftp-server flash:Germany/g4-tones.xml

Once  the  file  is  accessible  via  TFTP,  the  phone  will  download  the  file  without  incident.  Check  the  
debug tftp events  output  for  confirmation.  
 
R3  
R3#debug tftp events
TFTP Event debugging is on
Oct 11 07:12:00.187: TFTP: Looking for CTLSEP1C1D86C53EBF.tlv
Oct 11 07:12:00.351: TFTP: Looking for ITLSEP1C1D86C53EBF.tlv
Oct 11 07:12:00.487: TFTP: Looking for ITLFile.tlv
Oct 11 07:12:00.687: TFTP: Looking for SEP1C1D86C53EBF.cnf.xml
Oct 11 07:12:01.039: TFTP: Opened system:/cme/sipphone/SEP1C1D86C53EBF.cnf.xml, fd 8, size 4621 for
process 482
Oct 11 07:12:01.315: TFTP: Finished system:/cme/sipphone/SEP1C1D86C53EBF.cnf.xml, time 00:00:00 for
process 482
Oct 11 07:12:08.039: TFTP: Looking for featurePolicyDefault.xml
Oct 11 07:12:08.039: TFTP: Opened system:/cme/sipphone/featurePolicyDefault.xml, fd 8, size 824 for
process 482
Oct 11 07:12:08.095: TFTP: Finished system:/cme/sipphone/featurePolicyDefault.xml, time 00:00:00 for
process 482
Oct 11 07:12:08.439: TFTP: Looking for SIP_English_United_States/gd-sip.jar
Oct 11 07:12:08.643: TFTP: Looking for Germany/g4-tones.xml
Oct 11 07:12:08.643: TFTP: Opened flash0:Germany/g4-tones.xml, fd 8, size 1814
for process 482
Oct 11 07:12:08.751: TFTP: Finished flash0:Germany/g4-tones.xml, time 00:00:00 for process 482

In  making  a  test  call  with  the  9971,  it  will  be  evident  that  the  progress  tones  are  different  than  
normally  heard  on  the  phone.  Phone  registration  will  be  covered  later  in  this  lab.  
 
   

136 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.5 Ensure  that  the  DTMF  mechanism  is  set  to  RFC  2833.  
 
This  task  is  asking  us  to  modify  the  DTMF-­‐relay  method  to  RFC  2833.  This  is  just  one  of  four  possible  
types  that  the  phone  is  able  to  run.  See  the  table  below  for  more  information  on  each  method.  
 
DTMF-­‐Relay  Method   In-­‐Band/Out-­‐of-­‐Band   Details  
RFC  2833  (RTP-­‐NTE)   In-­‐Band   Forwards  DTMF  tones  by  using  RTP  with  the  
Named  Telephone  Event  (NTE)  payload  
type  
SIP-­‐KPML   Out-­‐of-­‐Band   Sent  as  INVITE  messages  with  “kpml”  in  the  
Allow-­‐Events  header  
SIP-­‐Notify   Out-­‐of-­‐Band   Forwards  DTMF  tones  using  SIP  NOTIFY  
messages  
Cisco-­‐RTP   In-­‐Band   Forwards  DTMF  tones  by  using  Real-­‐Time  
Transport  Protocol  (RTP)  with  a  Cisco  
proprietary  payload  type  
 
In  SIP  CUCME,  the  DTMF-­‐relay  method  is  configured  at  the  phone  level.  Since  phones  have  not  been  
configured  in  this  lab  yet,  there  is  nowhere  to  implement  the  requested  configuration  at  the  moment.  
The  details  regarding  phone  registration/configuration  will  be  covered  later  within  this  document,  but  
for  now,  let’s  at  least  examine  the  placement  of  the  dtmf-relay  command.    
 
Based  on  the  above,  we  know  that  this  configuration  is  done  at  the  phone  level,  which  means  it  will  
need  to  be  configured  within  a  “pool”  for  SIP  CUCM—specifically  a  voice register pool.  The  
voice register pool <number>  command  is  basically  the  SIP  equivalent  of  the  ephone  
command  in  telephony-service  for  SCCP  CUCME.  Under  the  voice register pool  
section,  the  command  dtmf-relay <method>  should  be  entered  to  select  the  proper  method.  
Multiple  methods  can  be  selected,  if  desired,  by  simply  adding  the  method  name  to  the  end  of  the  
string.  
 
R3  
R3(config-register-pool)#dtmf-relay rtp-nte
 
   

137 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.6 Use  the  authentication  username  of  “scpx”  where  x  is  the  number  of  the  phone  (e.g.  
scp2)  and  password  of  “cisco”  where  necessary  in  phone  registration.  
 
This  task  can  get  a  little  tricky,  especially  since  we  have  not  gone  through  the  phone  registration  
process  yet.  But  hey—that’s  the  CCIE  for  you,  there’s  always  a  trick  somewhere!  In  this  case,  this  task  is  
asking  us  to  modify  the  current  authentication  mechanism  being  used  by  voice register
global.  Before  we  modify,  however,  let’s  attempt  to  understand  the  way  in  which  SIP  CUCME  
authenticates  clients  by  default.  
 
Think  back  to  the  IP  source  address  that  was  configured  for  the  voice register global  process  
on  the  router.  The  Vlan  31  SVI  was  used  (10.10.31.1)  in  this  case.  Remembering  this  fact  is  very  
important,  because  this  is  the  first  point  of  reference  in  understanding  voice register global  
authentication.    
 
When  a  phone  attempts  to  register  with  CUCME,  it  presents  the  router  with  its  IP  Address  and  MAC  
address.  The  router  then  takes  the  IP  address  that  was  received  from  the  phone  and  broadcasts  an  
Address  Resolution  Protocol  (ARP)  request.  An  ARP  message  is  essentially  asking  the  network,  “What  
MAC  address  has  this  IP  address?”  The  host  that  is  currently  configured  with  the  IP  address  in  question  
will  then  respond  with  the  corresponding  MAC  address.  The  router  will  then  compare  the  MAC  address  
from  the  ARP  response  and  the  MAC  address  that  was  presented  by  the  phone  to  ensure  that  they  
match.  If  they  do  match,  the  phone  is  allowed  to  register  with  the  SIP  CUCME  server.  If  not,  the  
registration  request  is  rejected.    
 
They  key  thing  to  understand  here  is  that  this  mechanism  completely  relies  on  ARP  to  authenticate  the  
phone.  This  means  that  if  the  phone  is  not  on  the  same  broadcast  domain  as  the  configured  IP  source  
address  within  voice register global,  this  mechanism  will  not  work.  For  example,  if  the  
source  address  within  voice register global  was  configured  on  a  Loopback  interface  on  the  
router,  the  default  authentication  mechanism  would  not  work,  since  the  phones  would  be  on  a  
different  network  subnet,  or  broadcast  domain.  
 
In  order  to  fix  this  issue,  we  can  enter  a  command  under  the  voice register global  
configuration,  called  authenticate register,  which  will  change  the  authentication  mechanism  
to  a  username/password  model  instead  of  the  ARP  method.  This  means  that  we  must  configure  a  
username  and  password  at  the  phone  level  under  the  voice register pool  section  as  well.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#authenticate register

R3(config-register-global)#voice register pool 1


R3(config-register-pool)#username scp2 password cisco
 
Once  these  commands  are  entered,  the  phone  will  authenticate  with  the  username  and  password  
rather  than  the  MAC  address  when  challenged  by  the  SIP  CUCME  server.  
 
   

138 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.7 Ensure  that  the  maximum  registration  time  is  set  to  600  and  the  minimum  is  set  to  60.  
 
The  registrar server  command  was  discussed  in  an  earlier  section.  As  you  recall,  we  need  this  
command  in  order  to  configure  the  router  to  accept  incoming  SIP  registration  requests.  By  default,  the  
maximum  registration  time  is  3600  seconds  and  the  minimum  is  60  seconds.    
 
R3  
R3(config)#voice service voip
R3(conf-voi-serv)#sip
R3(conf-serv-sip)#registrar server expires max 600 min 60
 
As  previously  mentioned,  if  the  SIP  Register  message  requests  are  for  a  shorter  expiration  time  than  
what  is  set  with  this  command,  the  SIP  Register  message  expiration  time  is  used  instead  of  the  
configured  value.  
 
   

139 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.8 Configure  the  SIP  phones  to  register  with  the  settings  as  defined  in  the  
Supplementary-­‐Info.pdf  file.  
 
Finally  we  are  at  the  point  where  we  can  register  our  phones!  We  laid  the  foundation  in  previous  tasks  
with  the  source-address,  max-dn,  and  max-pool  commands  under  the  voice register
global  section.  In  addition,  we’ve  configured  the  registrar server,  authenticate
register,  dtmf-relay,  and  a  network-locale  to  support  German  progress  tones.  
 
Next,  we  need  to  configure  DNs  to  be  assigned  to  the  phones  in  the  system.  This  can  be  accomplished  
by  using  the  voice register dn <number>  command.    
 
R3  
R3(config)#voice register dn 1
R3(config-register-dn)#number 3002
R3(config-register-dn)#name SC Phone 2
 
The  above  configuration  has  assigned  the  number  3002  to  voice register dn 1  in  the  system.  It  
has  also  assigned  a  name  of  “SC  Phone  2”,  which  will  be  used  as  the  calling  name  once  associated  with  
a  phone.  
 
Next,  we  can  create  the  phone  configuration  by  using  the  voice register pool <number>  
command.  In  the  configuration  of  the  pool,  the  MAC  address  must  be  entered  with  the  id mac
<MAC Address>  command.  The  type  of  phone  must  be  entered  as  well.  As  always,  both  pieces  of  
information  should  have  been  obtained  from  CDP.  Next,  the  DN  should  be  assigned  to  the  pool  by  
using  the  number <Phone Button Number> dn <DN Number>  command.  The  dtmf-
relay  and  username  commands  were  already  specified  in  previous  sections.  
 
R3  
R3(config-register-dn)#voice register pool 1
R3(config-register-pool)#id mac 1C1D.86C5.3EBF
R3(config-register-pool)#type 9971
R3(config-register-pool)#number 1 dn 1
R3(config-register-pool)#dtmf-relay rtp-nte
R3(config-register-pool)#username scp2 password cisco

After  this  configuration  has  been  made,  it  is  very  important  to  return  to  the  voice register
global  configuration  section  and  issue  the  command,  create profile.  This  will  build/re-­‐build  
the  configuration  file  for  the  phone  based  on  what  is  currently  configured  in  the  system.  This  command  
should  be  entered  every  time  a  configuration  change  is  made!  
 
R3  
R3(config)#voice register global
R3(config-register-global)#create profile
 
The  phone  should  now  register  to  the  SIP  CUCME  server  on  the  router.  We  can  verify  this  by  running  
the  show voice register pool 1 brief  command.  Also,  just  as  with  telephony-
service,  voice register global  generates  a  dial-­‐peer  for  each  registered  phone—a  virtual  
VoIP  dial-­‐peer  in  this  case.  We  can  determine  whether  or  not  this  dial-­‐peer  was  created  by  running  the  
command  show voice register dial-peers.    

140 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
R3  
R3#show voice register pool 1 brief
Pool ID IP Address Ln DN Number State
==== =============== =============== == === ==================== ============
1 1C1D.86C5.3EBF 10.10.31.34 1 1 3002$ REGISTERED

R3#show voice register dial-peers


Dial-peers for Pool 1:

dial-peer voice 40001 voip


destination-pattern 3002$
session target ipv4:10.10.31.34:50737
session protocol sipv2
dtmf-relay rtp-nte
digit collect kpml
voice-class codec 1
after-hours-exempt FALSE

One  thing  that  you  should  immediately  notice  from  the  above  is  the  main  difference  between  
telephony-service  and  voice register global.  Telephony-service  uses  virtual  
POTS  dial-­‐peers  while  voice register global  uses  virtual  VoIP  dial  peers.  This  means  that  SIP  
phones  have  more  options  that  can  be  configured  directly  on  the  phone  (e.g.  Codec  selection,  DTMF-­‐
relay,  etc.).  
 
   

141 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.9 Ensure  that  SIP  phones  are  able  to  call  each  other  as  well  as  SCCP  phones.  SIP  phone  
should  have  the  option  of  using  either  G711  or  G729  as  the  voice  codec.  
 
By  default,  SIP  phones  should  have  no  problem  calling  other  locally  registered  SCCP  phones.  This  is  
because,  from  the  perspective  of  the  router,  the  communication  is  happening  between  dial-­‐peers;  a  
(virtual)  VoIP  dial-­‐peer  for  the  SIP  phone  and  a  (virtual)  POTS  dial-­‐peer  for  the  SCCP  phone.  The  router  
will  never  reject  a  connection  that  is  being  made  from  any  protocol  towards  a  POTS  dial-­‐peer  and  vice  
versa.  It  will,  however,  have  issues  when  connecting  between  VoIP  dial-­‐peers,  regardless  of  whether  
they  are  running  SIP  or  H.323.  
 
With  this  in  mind,  SIP  phones  will  not  be  able  to  call  other  SIP  phones  because  SIP  to  SIP  
communication  is  disallowed  within  IOS  by  default.  To  remedy  the  situation,  we  will  need  to  enter  
voice service voip  and  use  the  allow-connections  command  to  explicitly  allow  this  type  
of  communication.  The  allow-connections  command  can  support  four  different  types  of  
communication:  SIP  to  SIP,  SIP  to  H.323,  H.323  to  SIP,  and  H.323  to  H.323.  Clearly,  we  must  configure  
the  allow-connections sip to sip  command  to  meet  the  requirements  of  the  question.  In  
addition,  although  it  could  technically  be  considered  “over-­‐configuration”,  we  should  enter  the  
allow-connections  commands  for  the  other  three  communication  types  at  this  point.  This  will  
ensure  that  no  calls  will  be  denied  by  the  router  for  this  reason,  which  can  be  a  great  thing  for  the  CCIE  
Collaboration  lab!    
 
R3  
R3(config)#voice service voip
R3(conf-voi-serv)#allow-connections h323 to h323
R3(conf-voi-serv)#allow-connections h323 to sip
R3(conf-voi-serv)#allow-connections sip to h323
R3(conf-voi-serv)#allow-connections sip to sip
 
In  addition  to  being  able  to  make  calls  between  other  registered  devices  on  the  CUCME  server,  we  also  
need  to  configure  the  phone  to  have  the  option  of  communicating  using  either  the  G.711  or  G.729  
codecs.  As  was  previously  mentioned,  voice register pool  configurations  generate  virtual  VoIP  
dial  peers  on  the  router.  With  that  in  mind,  it  makes  sense  that  we  have  the  ability  to  configure  codec  
settings  directly  on  the  phone.    
 
In  this  case,  we  need  to  configure  the  voice class codec <number> command  within  the  
global  configuration  on  the  router  to  control  codec  selection.  Following  that,  we  can  assign  the  
configured  voice class codec  to  the  voice register pool.  This,  of  course,  is  in  contrast  
to  simply  defining  a  codec  directly  on  the  voice register pool.  If  the  codec  were  defined  as  
such,  the  phone  would  only  have  the  ability  to  run  a  single  codec.  
 
R3  
R3(config)#voice class codec 1
R3(config-class)#codec preference 1 g711ulaw
R3(config-class)#codec preference 2 g729r8

R3(config)#voice register pool 1


R3(config-register-pool)#voice-class codec 1

R3(config-register-pool)#voice register global


R3(config-register-global)#create profile

142 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3(config-register-global)#voice register pool 1


R3(config-register-pool)#reset

The  above  configuration  will  now  allow  the  SIP  phone  to  negotiate  using  either  the  G.711  or  G.729  
codec.  Of  course,  G.711  is  listed  as  the  first  preference,  so  if  it  is  supported  by  the  other  endpoint,  
G.711  will  be  successfully  negotiated.  If  the  other  endpoint  does  not  support  G.711,  the  second  
preference  of  G.729  will  be  used.    
 
PLEASE  NOTE:    If  you  are  using  a  VPN  connection,  packets  between  the  phone  and  its  connected  
interface  (within  the  pod)  are  going  to  be  fragmented.  As  a  result,  UDP  traffic  from  the  9971  SIP  phone  
on  CUCME  may  not  behave  appropriately.  If  you  notice  any  strange  dialing  behavior  from  this  phone,  
including  not  being  able  to  make  outbound  calls,  issue  the  session-transport tcp command  
under  the  voice register pool  of  your  phone.  This  should  clear  up  any  dialing  problems  that  
you  may  have.    
 
   

143 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 7.10 Add  the  below  configuration  to  support  UnifiedFX  PhoneView.  
 
voice register global
url authentication
http://10.10.31.1/CCMCIP/authenticate.asp
 
The  above  configuration  must  be  added  to  support  phone  interaction  within  the  PhoneView  
application  on  HQ  Test  PC  1.  In  addition  to  the  above  commands,  the  below  commands  should  have  
already  been  loaded  into  the  router  in  the  default  configuration.  If  not,  please  paste  the  following  
commands  into  the  router  when  in  global  configuration  mode.    
 
R3  
ip http server

ixi transport http


response size 64
no shutdown
request outstanding 1

ixi application cme


no shutdown
 
The  full  voice register  configuration  on  R3  should  appear  as  follows.  
 
R3  
voice register global
mode cme
source-address 10.10.31.1 port 5060
max-dn 10
max-pool 5
authenticate register
url authentication http://10.10.31.1/CCMCIP/authenticate.asp
create profile sync 0216371300518923
network-locale DE

voice register dn 1
number 3002
name SC Phone 2

voice register pool 1


id mac 1C1D.86C5.3EBF
session-transport tcp
type 9971
number 1 dn 1
dtmf-relay rtp-nte
voice-class codec 1
username scp2 password cisco
 

144 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Once  registered  and  configured  with  the  above  commands,  the  phone  should  be  accessible  from  
PhoneView  as  shown  below:  
 

145 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 8: CUCME SCCP and SIP Basic Configuration


Task 8.1 Assure  that  the  time  zone  is  set  correctly  for  both  SCCP  and  SIP  phones  as  defined  in  
the  Supplementary-­‐Info.pdf  file.  
 
Given  that  NTP  was  already  configured  in  a  previous  lab,  we  can  assume  that  the  time  is  correct  on  the  
router.  From  there,  we  can  set  the  time  zone  for  the  phones  within  either  telephony-service  or  
voice register global.    
 
Within  telephony-service,  enter  the  time-zone  command  to  display  a  list  of  options.  There  is  
no  need  to  enter  the  UTC  offset  as  was  done  with  the  clock  command  in  global  configuration  mode;  
just  select  the  number  corresponding  to  the  correct  offset  from  the  list.  The  Supplementary-­‐Info.pdf  
file  states  that  the  time  zone  on  R3  should  be  configured  for  Central  European  Time  (UTC  +1),  however,  
the  listed  CET  option  states  +120  (minutes).  In  this  case,  disregard  the  name  of  the  time  zone  and  
select  the  correct  offset—that’s  what  really  matters  anyway.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#time-zone ?
<1-56> select timezone name used by IP phones (offset in minutes)
1 Dateline Standard Time -720
...
22 Greenwich Standard Time +0
23 W. Europe Standard/Daylight Time +60
24 GTB Standard/Daylight Time +60
25 Egypt Standard/Daylight Time +120
26 E. Europe Standard/Daylight Time +120
27 Romance Standard/Daylight Time +120
28 Central Europe Standard/Daylight Time +120
...
56 Pacific SA Standard Time -240

R3(config-telephony)#time-zone 24

The  same  must  be  done  for  voice register global  as  well.  In  addition  to  setting  the  time  
zone,  however,  we  must  also  set  voice register global  to  use  an  NTP  server,  since  SIP  phones  
require  the  use  of  NTP  in  order  to  receive  the  correct  time.  For  this  configuration,  we  can  use  the  same  
IP  address  that  was  configured  in  earlier  labs  to  synchronize  NTP  (the  Loopback  0  address  on  R1).    
 
R3  
R3(config)#voice register global
R3(config-register-global)#ntp-server 10.10.1.1
 
With  the  NTP  server  set,  enter  the  time zone  command  (notice  that  it  is  not  the  time-zone  
command  used  in  telephony-service)  with  the  same  option  as  was  selected  within  
telephony-service.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#time zone 24
   

146 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.2 Assure  that  the  date  and  time  formats  are  dd/mm/yyyy  and  24-­‐hour,  respectively.  
 
Just  as  with  CUCM,  the  date  format  can  be  changed  for  phone  display.  Once  again,  since  we  are  
running  both  SCCP  and  SIP  phones,  this  should  be  done  within  both  telephony-service  and  
voice register global.  The  phones  should  be  reset  to  apply  the  new  settings.  Make  sure  that  
the  command  create profile  is  entered  within  voice register global  to  ensure  that  the  
configuration  file  is  created  for  the  SIP  phone.    
 
R3  
R3(config)#telephony-service
R3(config-telephony)#date-format ?
dd-mm-yy Set date to dd-mm-yy format
mm-dd-yy Set date to mm-dd-yy format
yy-dd-mm Set date to yy-dd-mm format
yy-mm-dd Set date to yy-mm-dd format

R3(config-telephony)#date-format dd-mm-yy

R3(config-telephony)#time-format ?
12 Set time to 12Hrs(AM/PM) format
24 Set time to 24Hrs format

R3(config-telephony)#time-format 24

R3(config)#voice register global


R3(config-register-global)#date-format ?
D/M/Y Set date to D/M/Y format
M/D/Y Set date to M/D/Y format
Y-M-D Set date to Y-M-D format
Y/D/M Set date to Y/D/M format
Y/M/D Set date to Y/M/D format
YY-M-D Set date to YY-M-D format

R3(config-register-global)#date-format D/M/Y

R3(config-register-global)#time-format ?
12 Set time to 12Hrs(AM/PM) format
24 Set time to 24Hrs format

R3(config-register-global)#time-format 24

 
   

147 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.3 Each  SCCP  line  should  support  6  concurrent  calls  and  4  active  incoming  calls.  
 
Much  like  the  Directory  Number  configuration  in  CUCM,  the  number  of  total  calls  and  incoming  calls  
can  be  limited  on  a  phone.  The  max-calls-per-button  command  will  limit  the  total  number  of  
calls  that  can  be  active  on  a  line  at  one  time.  The  busy-trigger-per-button  will  limit  the  total  
number  of  incoming  calls  on  a  line.  These  commands  are  specific  to  the  SCCP  phone  itself,  which  
means  that  they  must  be  entered  within  the  ephone  configuration.  This  also  means  that  every  line  
that  is  assigned  to  the  phone  will  inherit  these  settings.    
 
R3  
R3(config)#ephone 1
R3(config-ephone)#max-calls-per-button 6
R3(config-ephone)#busy-trigger-per-button 4
 
   

148 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.4 Each  SIP  line  should  support  4  active  incoming  calls.  
 
Just  as  with  SCCP  CUCME,  we  can  set  the  total  number  of  calls  that  are  allowed  inbound  to  the  phone.  
Once  again,  this  is  specific  to  the  phone  and  therefore  must  be  placed  under  the  voice register
pool  configuration.  Notice  that  the  main  difference  between  SCCP  and  SIP  phones  here  is  that  we  
cannot  define  maximum  calls  per  line  like  we  could  with  SCCP  phones.    
 
R3  
R3(config)#voice register pool 1
R3(config-register-pool)#busy-trigger-per-button 4

149 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.5 Assure  that  the  +E164  number  is  displayed  across  the  top  header  bar  on  the  SCCP  and  
SIP  phones.  
 
Much  like  the  External  Phone  Number  Mask  within  CUCM,  the  banner  can  be  set  on  each  phone  in  
both  SIP  and  SCCP  CUCME.  Please  note,  however,  that  the  number  in  CUCME  is  not  usable  for  digit  
manipulation  purposes  as  it  is  within  CUCM.  For  example,  in  CUCM,  an  option  exist  called  “Use  Calling  
Party’s  External  Phone  Number  Mask”  in  the  Calling  Party  Transformations  section  of  Route  Patterns,  
Route  Lists,  and  Calling  Party  Transformation  Patterns.  You  can  then  further  manipulate  the  calling  
number,  if  desired.  You  can  think  of  the  banner  in  CUCME  as  simply  cosmetic.    
 
With  that  said,  the  command  itself  is  not  intuitive  whatsoever.  The  phone  banner  is  implemented  using  
the  description  command.  Please  note  that  for  SCCP  phones,  the  banner  display  is  controlled  
within  the  ephone-dn  configuration,  while  SIP  phones  set  this  parameter  within  the  voice
register pool.  
 
R3  
R3(config)#ephone-dn 1
R3(config-ephone-dn)#description +49894443001

R3(config)#voice register pool 1


R3(config-register-pool)#description +49894443002

R3(config-register-pool)#voice register global


R3(config-register-global)#create profile
R3(config-register-global)#reset
 
   

150 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.6 SC  Phone  2  should  forward  to  SC  Phone  1  when  the  call  is  not  answered  within  10  
seconds.  
 
Here  we  are  setting  the  “Call  Forward”  settings  on  the  line  for  the  registered  SIP  phone.  This  option  is  
most  useful  for  voice  mail  forwarding,  when  configured,  but  can  come  in  handy  for  other  purposes,  like  
forwarding  to  other  phones  or  Voice  Hunt  Groups.  In  this  case,  we  are  configuring  the  forwarding  
settings  to  specifically  forward  to  the  registered  SCCP  phone  on  the  CUCME  router.  
 
To  configure,  enter  the  voice register dn  configuration  for  the  line  in  question.  To  satisfy  the  
requirements,  use  the  call-forward b2bua  command.  The  “b2bua”  in  this  configuration  refers  
to  the  “Back-­‐to-­‐Back  User  Agent”  running  within  the  SIP  CUCME  service  on  the  router.  Remember,  a  
back-­‐to-­‐back  user  agent  can  act  as  both  a  User  Agent  Server  (handling  incoming  SIP  requests)  and  a  
User  Agent  Client  (originating  SIP  requests  to  other  endpoints).  In  this  case,  it  makes  sense,  since  the  
SIP  CUCME  is  receiving  the  SIP  call  and  then  forwarding  it  out  to  another  destination.  
 
R3  
R3(config)#voice register dn 1
R3(config-register-dn)#call-forward b2bua noan 3001 timeout 10
 
In  the  above,  we  have  specified  “noan”  for  the  “No  Answer”  call  forward  settings,  “3001”  as  the  
destination  number,  and  10  seconds  as  the  timeout  value.  
 
   

151 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.7 Assure  that  the  users  are  unable  to  initiate  conferences  using  SCCP  phones.  Do  not  
configure  a  conference  bridge  yet!  
 
In  order  to  ensure  that  users  are  unable  to  initiate  conferences  using  SCCP  phones,  we  must  modify  
the  softkeys  to  remove  the  option.  In  configuring  the  solution  to  this  task,  we  must  think  about  the  
different  ways  that  users  can  initiate  conferences.  After  analyzing  the  possibilities,  the  “Confrn”  and  
“Join”  softkeys  are  the  only  ones  that  stand  out.  To  remove  the  softkeys,  we  will  need  to  create  an  
ephone-template  and  apply  that  template  to  the  ephone.  In  all  possible  softkey  states,  we  must  
ensure  that  the  template  is  configured  to  remove  all  conferencing  options.  The  question  mark  (?)  can  
once  again  be  your  friend  here  as  it  can  help  you  to  determine  where  the  configuration  needs  to  be  
placed.  Also,  you  can  verify  the  current  softkey  options  that  are  set  by  using  the  phone  to  test.  
 
In  addition  to  removing  softkeys,  we  need  to  make  sure  that  we  retain  the  current  default  softkey  
options  that  are  listed  on  the  phone.  In  other  words,  if  you  modify  a  state,  make  sure  to  also  configure  
the  softkeys  that  are  already  enabled  by  default.  
 
R3  
R3(config)#ephone-template 1
R3(config-ephone-template)#softkeys ?
alerting Softkey order for alerting (ring out) state
connected Softkey order for connected state
hold Softkey order for HOLD state
idle Softkey order for IDLE state
remote-in-use Softkey order for REMOTE-IN-USE state
ringing Softkey order for ringing state
seized Softkey order for seized state

R3(config-ephone-template)#softkeys alerting ?
Acct Account Code
CallBack Call back
Endcall End call

R3(config-ephone-template)#softkeys connected ?
Acct Account Code
ConfList List all participants in conference
Confrn Conference
Endcall End call
Flash Hook Flash
HLog HLog
Hold Hold
Join Join established call to conference
LiveRcd Enable live recording on the current call
Mobility Mobility SNR
Park Call Park
RmLstC Remove last conference participant
Select Select call to join in conference
TrnsfVM Select call to transfer to voice mail
Trnsfer Call Transfer

R3(config-ephone-template)#softkeys hold ?
Join Join established call to conference
Newcall New call
Resume Resume
Select Select call to join in conference

R3(config-ephone-template)#softkeys idle ?
Cfwdall Call forward all
ConfList List all participants in conference
Dnd Do not Disturb
Gpickup Group Call Pick Up
HLog HLog
Join Join established call to conference

152 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Login Login
Mobility Mobility SNR
Newcall New call
Pickup Call Pick Up
Redial Redial
RmLstC Remove last conference participant

R3(config-ephone-template)#softkeys remote-in-use ?
CBarge CBarge
Newcall New call

R3(config-ephone-template)#softkeys ringing ?
Answer Answer
Dnd Do not Disturb
HLog HLog

R3(config-ephone-template)#softkeys seized ?
CWOff Cancel Call Waiting
CallBack Call back
Cfwdall Call forward all
Endcall End call
Gpickup Group Call Pick Up
HLog HLog
MeetMe MeetMe Conference
Pickup Call Pick Up
Redial Redial

R3(config-ephone-template)#softkeys connected Hold Endcall Trnsfer Acct

R3(config-ephone-template)#ephone 1
R3(config-ephone)#ephone-template 1
CNF file update complete for phone-1

The ephone template tag has been changed under this ephone, please restart or reset ephone to take
effect.

In  the  above,  we  only  modified  one  state,  “Connected”.  Notice  that  the  “Confrn”  and  “Join”  options  
exist  in  other  states  (“Hold”  and  “Idle”),  but  verification  on  the  phone  confirms  that  they  are  not  active  
on  the  phone  by  default.  The  last  step,  as  shown  above,  is  to  assign  the  ephone-template to  the  
phone  to  apply  the  configuration.  Verify  the  configuration  by  making  a  test  call  and  examining  the  
softkey  options  available  in  each  state.  
 

 
 
 

153 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.8 Assure  that  users  cannot  create  a  new  call  when  on  hold  for  both  SC  Phone  1  and  2.  
 
Once  again,  we  can  use  softkeys  to  accomplish  this  task.  We  simply  must  remove  the  “NewCall”  
softkey  as  an  option  within  the  “Hold”  state.  This  time,  we  must  create  templates  for  both  SIP  and  
SCCP  phones  to  modify  the  softkeys.  The  previous  task  already  created  an  ephone-template  to  
implement  the  configuration,  so  we  can  modify  that  further  to  include  the  softkeys  needed  for  the  
“Hold”  state.    
 
R3  
R3(config)#ephone-template 1
R3(config-ephone-template)#softkeys hold Resume
 
Make  sure  to  restart  the  phone  when  completed.  Verify  by  placing  a  call  on  hold  from  the  SCCP  phone.  
 

 
 
Next,  we  must  examine  the  options  that  are  available  in  the  “Hold”  state  on  the  9971  phone.  In  this  
case,  as  seen  below,  “NewCall”  is  not  an  active  default  option  in  the  “Hold”  state.  Therefore  a  voice
register template  does  not  need  to  be  created  an  assigned  to  the  voice register pool.  
 

 
 

154 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.9 Assure  that  both  the  Calling  Name  and  Number  are  displayed  when  calling  between  
phones  at  SC.  
 
In  order  to  send  a  calling  name  when  placing  calls,  the  name  command  must  be  entered  under  the  
ephone-dn  section  (SCCP  phones)  or  the  voice register dn  section  (SIP  phones).  
 
R3  
R3(config)#ephone-dn 1
R3(config-ephone-dn)#name SC Phone 1

R3(config)#voice register dn 1
R3(config-register-dn)#name SC Phone 2
 
   

155 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 8.10 Create  a  speed  dial  on  each  phone  pointing  to  the  other.  
 
Speed  dials  can  be  configured  for  SCCP  and  SIP  phones  that  are  registered  to  CUCME.  This  can  be  
accomplished  with  the  speed-dial  command  under  the  ephone  (SCCP  phones)  or  the  voice
register pool  (SIP  phones)  section.  
 
R3  
R3(config)#ephone 1
R3(config-ephone)#speed-dial 1 3002 label "SC Phone 2"

R3(config)#voice register pool 1


R3(config-register-pool)#speed-dial 1 3001 label "SC Phone 1"
 
The  above  commands  configure  speed  dials  pointing  to  the  opposite  phone  in  the  CUCME  system.  Take  
note  that  there  is  no  place  to  specify  the  exact  button  on  which  the  speed  dial  exists.  All  that  can  be  
done  is  to  define  the  index  number  of  the  speed  dial  in  the  system.  Also,  ensure  that  the  label  uses  
quotes  if  it  contains  spaces.    
 

 
 

156 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 9: CUCME SCCP and SIP Advanced Phone Configuration


Task 9.1 Assure  that  when  SC  Phone  1  receives  an  inbound  call,  the  phone  rings  using  a  triple  
pulse  rather  than  the  “normal”  single  pulse.  Visual  notifications  should  remain  the  
same.  
 
In  CUCME,  the  option  exists  to  change  the  type  of  ring  used  for  all  incoming  calls  into  configured  SCCP  
DNs  in  the  system.  This  is  accomplished  using  the  ring  command  under  the  ephone-dn.  
 
This  command  allows  you  to  select  one  of  the  three  ring  styles  supported  by  SCCP—internal,  external,  
or  feature  ring.  The  ring  pattern  is  used  for  all  types  of  incoming  calls  to  this  directory  number,  on  all  
phones  on  which  the  directory  number  appears.  If  the  phone  is  already  in  use,  an  incoming  call  is  
presented  as  a  call-­‐waiting  call  and  uses  the  distinctive  call-­‐waiting  beep.  
 
If  the  primary  or  secondary  keyword  is  used,  the  distinctive  ring  is  used  only  if  the  incoming  called  
number  matches  the  primary  number  or  secondary  number  defined  for  the  ephone-­‐dn.  If  there  is  no  
secondary  number  defined  for  the  ephone-dn,  the  secondary  keyword  has  no  effect.  
 
By  default,  Cisco  Unified  CME  uses  the  internal  ring  pattern  for  calls  between  local  IP  phones  and  uses  
the  external  ring  pattern  for  all  other  types  of  calls.  
 
You  can  associate  the  feature  ring  pattern  with  a  specific  button  on  a  phone  by  using  the  button  f  
command.  This  command  assigns  the  ring  pattern  to  the  button  on  the  phone  so  that  different  phones  
that  share  the  same  directory  number  can  use  a  different  ring  style.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/command/reference/cme_cr/cme_r1
ht.html  -­‐  wp3570505817]  
 
With  this  in  mind,  to  set  the  ringing  style  for  inbound  calls  to  use  a  triple  pulse,  we  must  employ  the  
“feature”  ring  on  the  DN,  as  shown  below.  You  may  test  the  configuration  by  calling  SC  Phone  1  from  
SC  Phone  2  and  observing  the  behavior.    
 
R3  
R3(config)#ephone-dn 1
R3(config-ephone-dn)#ring feature primary
 
   

157 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 9.2 Configure  lines  3011  and  3012,  and  assure  that  both  lines  ring  on  button  2  of  SC  Phone  
1.  
 
Both  lines  that  are  mentioned  in  this  task  have  not  yet  been  created  in  the  system.  With  that  in  mind,  
the  first  thing  we’ll  need  to  do  is  create  them.  Since  the  task  specifically  mentions  SC  Phone  1,  we  
know  that  this  is  involving  the  SCCP  CUCME.  We  can  therefore  safely  assume  that  the  lines  should  be  
created  as  ephone-dns.  The  type  of  line  (single/dual/octo)  is  not  specified  here,  so  there  is  no  harm  
in  using  a  single  line.    
 
R3  
R3(config)#ephone-dn 2
R3(config-ephone-dn)#number 3011
R3(config-ephone-dn)#ephone-dn 3
R3(config-ephone-dn)#number 3012

Now  that  the  directory  numbers  have  been  configured  in  the  system,  they  must  be  assigned  to  a  
phone.  Since  the  task  is  looking  for  both  lines  to  ring  on  the  same  button,  we  must  use  an  overlay  
button  separator.  The  different  types  of  button  separators  were  mentioned  in  Lab  6,  but  just  as  a  
refresher,  here  is  a  description  of  the  overlay  button  (and  also  the  overlay  with  call  waiting  button).  
 
• o  –  Overlay  line.  Multiple  ephone-dns  share  a  single  button,  up  to  a  maximum  of  25  on  a  
button.  See  also  the  c  keyword.  
• c—Call  waiting.  Provides  call  waiting  for  secondary  calls  to  an  overlaid  ephone-dn.  See  also  
the  o  keyword.  
 
Based  on  this  information  we  need  to  use  the  “o”  button  separator  to  assign  ephone-dns  2  and  3  to  
a  button  on  the  phone.  
 
R3  
R3(config)#ephone 1
R3(config-ephone)#button 2o2,3
 
To  test  the  configuration,  make  calls  into  both  3011  and  3012  and  observe  the  behavior.  
 
   

158 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 9.3 Ensure  that  calls  can  be  parked  and  retrieved  by  any  phone  registered  to  R3.  Create  2  
park  slots  using  numbers  3097  and  3098.  Ensure  that  the  call  will  get  reverted  to  the  
user  who  parked  the  call  after  14  seconds.  If  that  user  is  busy,  the  call  should  be  
routed  to  extension  3002.  
 
This  task  is,  of  course,  asking  us  to  configure  Call  Park  on  the  R3  CUCME  router.    
 
The  Call  Park  feature  allows  a  phone  user  to  place  a  call  on  hold  at  a  special  extension  so  it  can  be  
retrieved  from  any  other  phone  in  the  system.  A  user  parks  the  call  at  the  extension,  known  as  the  call-­‐
park  slot,  by  pressing  the  Park  softkey.  Cisco  Unified  CME  chooses  the  next  available  call-­‐park  slot  and  
displays  that  number  on  the  phone.  A  user  on  another  phone  can  then  retrieve  the  call  by  dialing  the  
extension  number  of  the  call-­‐park  slot.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm/
cmepark.html]    
 
The  Call  Park  feature  can  be  accessed  by  both  SCCP  and  SIP  phones,  but  must  be  configured  within  the  
ephone-dn  configuration.  Although  the  ephone  commands  refer  specifically  to  SCCP  phones,  SIP  
phones  can  still  take  advantage  of  these  park  slots.  
 
R3  
R3(config)#ephone-dn 5
R3(config-ephone-dn)#number 3097
R3(config-ephone-dn)#park-slot timeout 14 limit 2 recall alternate 3002

R3(config-ephone-dn)#ephone-dn 6
R3(config-ephone-dn)#number 3098
R3(config-ephone-dn)#park-slot timeout 14 limit 2 recall alternate 3002

The  above  commands  first  create  two  single-­‐line  ephone-dns  with  numbers  3097  and  3098,  as  
defined  by  the  task  requirements.  Next,  the  park-slot  command  is  used  to  define  the  ephone-dn  
as  an  available  park-slot  in  the  system.  Next,  a  timeout  of  14  seconds  is  set  in  order  to  force  the  
call  to  revert  to  a  specific  extension  after  that  time.  The  limit  command  defines  the  number  of  
“timeout”  cycles  in  the  system  before  the  call  is  disconnected.  This  was  not  a  requirement  of  the  
question,  but  does  limit  the  caller  to  waiting  a  total  of  28  seconds  after  being  parked.  The  recall  
command  dictates  that  the  call  should  be  forwarded  back  to  the  user  that  originally  parked  the  call  
after  the  timeout  period.  The  alternate  command  allows  the  system  to  revert  the  caller  to  a  
specific  extension,  should  the  user  that  originally  parked  the  call  become  unavailable.  With  this  one  
command,  we’ve  met  several  requirements  already!    
 
Another  piece  of  configuration  that  needs  to  happen  is  to  set  a  system-­‐level  parameter  related  to  call  
park  within  telephony-service.  This  parameter  will  actually  enable  Call  Park  within  CUCME.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#call-park system application
 

159 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  last  thing  that  needs  to  happen  is  to  enable  both  the  SCCP  and  SIP  phones  to  park  the  call  using  
the  available  park  slots.  This  can  be  done  using  an  ephone-template  (SCCP  phones)  and  a  voice
register template  (SIP  phones).  The  configuration  for  ephone-template 1  was  already  
created  in  a  previous  task,  so  in  this  case,  we  just  have  to  modify  it.    
 
R3  
R3(config-ephone)#ephone-template 1
R3(config-ephone-template)#softkeys hold Resume
R3(config-ephone-template)#softkeys connected Hold Endcall Trnsfer Acct Park

Notice  that  the  only  modification  that  was  done  here  was  to  the  “Connected”  state.  In  the  same  state  
on  the  9971  phone,  you  will  notice  that  the  “Park”  softkey  is  already  enabled  by  default.  Once  again,  
there  is  no  need  to  configure  a  voice register template  for  this  task.  
 
To  test,  make  a  call  between  SC  Phone  1  and  2.  Park  the  call  on  either  phone,  then  retrieve  the  call  by  
dialing  the  number  on  which  the  call  was  parked;  either  3097  or  3098.  
 
   

160 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 9.4 Configure  R3  such  that  calls  can  be  parked  on  extension  3099  by  any  R3  phone  and  
retrieved  by  any  SCCP  phone  using  the  prefix  of  *#  followed  by  3099.  
 
This  task  is  asking  us  to  configure  Directed  Call  Park  this  time.  Take  note;  the  task  states  that  any  R3  
phone  should  be  able  to  park  a  call  on  extension  3099,  but  only  SCCP  phones  technically  need  to  be  
able  to  retrieve  it,  using  the  stated  prefix  and  number.    
 
Just  as  with  basic  Call  Park,  slots  will  need  to  be  created  where  calls  can  be  parked.  In  this  case,  we  only  
need  one  slot  that  corresponds  to  number  3099.    
 
R3  
R3(config)#ephone-dn 7
R3(config-ephone-dn)#number 3099
R3(config-ephone-dn)#park-slot directed
 
The  command  call-park system application  was  enabled  in  the  previous  task,  so  there  is  
no  need  to  enter  the  command  again.  Take  note,  though,  that  it  must  be  enabled  for  Directed  Call  Park  
to  function  properly.  
 
Next,  phones  need  some  way  to  retrieve  calls  that  were  parked  directly  to  extension  3099.  In  order  to  
set  this  up,  we  must  define  Feature  Access  Codes  (FAC)  in  the  system  to  allow  the  call  to  be  retrieved.  
There  are  two  options  within  telephony-service: fac custom  and  fac standard.  Let’s  
enable  FAC  standard  and  see  what  we  get.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#fac standard
fac standard is set!

R3#show telephony-service fac


telephony-service fac standard
callfwd all **1
callfwd cancel **2
pickup local **3
pickup group **4
pickup direct **5
park **6
dnd **7
redial **8
voicemail **9
ephone-hunt join *3
ephone-hunt cancel #3
ephone-hunt hlog *4
ephone-hunt hlog-phone *5
trnsfvm *6
dpark-retrieval *0
cancel call waiting *1

From  the  show telephony-service fac  command,  we  can  see  that  the  Directed  Call  Park  
retrieval  code  is  “*0”  (dpark-retrieval *0).  This  means  that  a  call  can  be  retrieved  by  dialing  
*03099  from  any  phone  in  the  system.  This  does  not,  however,  meet  the  requirements  of  the  question;  
the  task  states  that  the  retrieval  code  should  be  *#.  In  order  to  change  the  code,  we  need  to  use  the  
fac custom  command  under  telephony-service.  To  do  this,  we  must  first  remove  fac

161 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

standard  from  the  configuration.  Following  that,  we  can  enter  the  fac custom dpark-
retrieval code  command.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#no fac standard
fac standard has been disabled!

R3(config-telephony)#fac custom dpark-retrieval *#


fac dpark-retrieval code has been configurated to *#!
 
Now  we  can  test  the  configuration  by  using  Directed  Call  Park  to  park  a  call  into  slot  3099.  This  is  done  
by  pressing  the  “Transfer”  softkey/hard  key  on  the  phone  and  transferring  the  call  to  extension  3099.  
From  there,  SCCP  phones  at  SC  should  be  able  to  retrieve  the  call  by  dialing  *#3099.  
 
Please  note,  that  you  will  not,  in  fact,  be  able  to  retrieve  a  “Directed  Call  Park”  call  from  the  SIP  phone  
in  this  case.  This  is  due  to  the  fact  that  the  standard  FAC  is  not  being  used  in  this  configuration.  Had  we  
kept  the  fac standard  command  in  the  configuration,  there  would  have  been  no  problem  with  the  
SIP  phone  retrieving  the  call.  We  could  have  also  used  the  command  fac custom dpark-
retrieval *0  and  that  would  have  worked  for  the  SIP  phone  as  well.  In  re-­‐reading  the  question,  
we  now  know  why  only  SCCP  phones  should  be  able  to  retrieve  these  calls.  
 
   

162 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 9.5 Configure  paging  on  R3  such  that  either  phone  can  dial  extension  3020  and  
successfully  page  all  phones  on  the  system.  
 
A  paging  number  can  be  defined  to  relay  audio  pages  to  a  group  of  designated  phones.  When  a  caller  
dials  the  paging  number  (ephone-dn),  each  idle  IP  phone  that  has  been  configured  with  the  paging  
number  automatically  answers  using  its  speakerphone  mode.  Displays  on  the  phones  that  answer  the  
page  show  the  caller  ID  that  has  been  set  using  the  name  command  under  the  paging  ephone-­‐dn.  
When  the  caller  finishes  speaking  the  message  and  hangs  up,  the  phones  are  returned  to  their  idle  
states.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm/
cmepage.html]    
 
In  order  to  configure  paging  in  the  system,  we  must  first  create  a  paging  DN.  Since  this  feature  is  built  
within  SCCP  CUCME,  it  must  be  configured  within  an  ephone-dn,  not  a  voice register dn.  
 
R3  
R3(config)#ephone-dn 8
R3(config-ephone-dn)#number 3020
R3(config-ephone-dn)#paging
 
Once  the  DN  is  created,  it  is  simply  a  matter  of  assigning  that  DN  as  a  “paging  dn”  to  other  phones  in  
the  system—including  SIP  phones!  Yes,  for  purposes  of  paging,  voice register pools  can  
recognize  the  ephone-dn  configuration.  
 
R3  
R3(config)#ephone 1
R3(config-ephone)#paging-dn 8

R3(config-ephone)#voice register pool 1


R3(config-register-pool)#paging-dn 8
 
In  order  to  test  the  configuration,  simply  dial  extension  3020  from  any  phone  in  the  system,  including  
the  PSTN  phone  when  configured.  
 
   

163 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 9.6 Configure  a  BLF  speed  dial  on  button  5  of  each  phone  to  the  other  phone.  
 
In  order  to  create  a  Busy  Lamp  Field  (BLF)  speed  dial,  we  need  to  make  configuration  changes  to  the  
voice register pool  as  well  as  the  ephone.  The  command  we  need  to  use  is  called  blf-
speed-dial.  The  index  number  for  the  blf-speed-dial  within  the  ephone  configuration  will  
actually  make  a  difference  in  the  button  positioning  of  the  speed  dial.  However,  within  the  voice
register pool,  the  index  number  makes  no  difference.  This  means  that  we  cannot  control  speed  
dial  button  placement  on  SIP  phones.  With  this  in  mind,  the  blf-speed-dial  index  on  the  ephone  
is  set  to  a  value  of  2  so  that  it  can  take  an  overall  position  of  5  on  the  phone.  
 
R3  
R3(config-ephone)#voice register pool 1
R3(config-register-pool)#blf-speed-dial 1 3001 label "SC Phone 1 BLF"

R3(config)#ephone 1
R3(config-ephone)#blf-speed-dial 2 3002 label "SC Phone 2 BLF"
 
Of  course,  the  BLF  speed  dials  allow  the  phone  to  monitor  the  status  of  the  line  to  which  the  speed  dial  
is  configured.  In  order  to  accomplish  this,  the  settings  on  the  line  need  to  be  configured  to  allow  that  
monitoring  to  happen.  In  this  case,  the  allow watch  command  on  both  the  ephone-dn  and  
voice register dn  takes  care  of  that  for  us.  
 
R3  
R3(config)#ephone-dn 1
R3(config-ephone-dn)#allow watch

R3(config-ephone-dn)#voice register dn 1
R3(config-register-dn)#allow watch
 
Lastly,  we  must  enable  presence  globally  in  order  for  the  above  configurations  to  take  effect.  This  is  
done  within  the  global  SIP  user-­‐agent  (SIP-­‐UA)  by  entering  the  presence enable  command.  
 
R3  
R3(config)#sip-ua
R3(config-sip-ua)#presence enable

At  this  time,  it  should  be  possible  to  monitor  the  presence  status  on  the  configured  speed  dials  on  both  
phones.  
 

 
 

 
 
   

164 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 9.7 Assure  that  users  are  able  to  retrieve  line  status  of  phones  registered  to  R3  in  the  
missed,  placed,  and  received  calls  menus  of  each  phone.  
 
When  sifting  through  the  missed/placed/received  calls  directory  on  each  phone,  it  can  be  useful  to  
determine  the  presence  status  of  a  line  to  see  whether  or  not  that  user  is  available  for  a  callback.  In  
order  to  enable  the  feature,  we  can  leverage  our  existing  presence  configuration  and  build  on  top  of  
that.  
 
Just  to  review,  the  allow watch  command  was  placed  on  the  lines  of  the  phones  that  need  to  be  
monitored.  Also,  the  command  presence enable  was  entered  within  the  sip-ua  configuration  
to  enable  presence  globally.  In  addition  to  the  above  commands,  we  must  also  enable  the  presence
call-list  feature  on  the  ephone,  voice register pool,  and  under  the  global  presence  
configuration  in  the  router  (presence).  
 
R3  
R3(config)#ephone 1
R3(config-ephone)#presence call-list

R3(config-ephone)#voice register pool 1


R3(config-register-pool)#presence call-list

R3(config)#presence
R3(config-presence)#presence call-list

The  phone  should  then  display  presence  status  as  shown  below.  
 

 
 

165 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  3:  Labs  10-­‐15  
Version  1.0  

166 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 3: Configure and Troubleshoot Voice Gateways


Lab 10: MGCP Gateway Configuration
Task 10.1 Configure  the  T1  controller  on  R1  according  to  the  information  found  in  the  
Supplementary-­‐Info.pdf  document  and  enable  it  for  use  with  MGCP.  
 
MGCP  (defined  under  RFC  2705)  is  a  master/slave  protocol  that  allows  a  call  control  device  (such  as  
Cisco  CallManager)  to  take  control  of  a  specific  port  on  a  gateway.  This  has  the  advantage  of  
centralized  gateway  administration  and  provides  for  largely  scalable  IP  Telephony  solutions.  With  this  
protocol,  the  Cisco  CallManager  knows  and  controls  the  state  of  each  individual  port  on  the  gateway.  It  
allows  complete  control  of  the  dial  plan  from  Cisco  CallManager,  and  gives  CallManager  per-­‐port  
control  of  connections  to  the  public  switched  telephone  network  (PSTN),  legacy  PBX,  voice  mail  
systems,  plain  old  telephone  service  (POTS)  phones,  and  so  forth.  This  is  implemented  with  the  use  of  a  
series  of  plain-­‐text  commands  sent  over  User  Datagram  Protocol  (UDP)  port  2427  between  the  Cisco  
CallManager  and  the  gateway.  A  concept  relevant  to  the  MGCP  implementation  with  Cisco  
CallManager  is  PRI  Backhaul.  This  occurs  when  Cisco  CallManager  takes  control  of  the  Q.931  signaling  
data  used  on  an  ISDN  PRI.  
[Source:    
 http://www.cisco.com/c/en/us/support/docs/voice/media-­‐gateway-­‐control-­‐protocol-­‐mgcp/44130-­‐
understanding-­‐mgcp.html]    
 
This  task  is  asking  us  to  configure  a  T1  controller  on  R1  and  enable  it  for  MGCP.  The  Supplementary-­‐
Info.pdf  document  dictates  that  PRI  signaling,  ESF  framing,  and  B8ZS  line  coding  must  be  used.  Also,  
the  ISDN  switch  type  must  be  set  to  Primary-­‐NI  and  the  T1  should  only  use  timeslots  1  –  3.    
 
The  first  thing  that  must  be  done  is  to  verify  the  type  of  card  that  is  being  used  to  create  the  T1  PRI  
connection.  We  can  check  by  issuing  the  show inventory  command  from  enable  mode  on  the  R1  
router.  
 
R1  
R1#show inventory
NAME: "CISCO2911/K9", DESCR: "CISCO2911/K9 chassis, Hw Serial#: FTX1718AL6V, Hw Revision: 1.0"
PID: CISCO2911/K9 , VID: V07 , SN: FTX1718AL6V

NAME: "VWIC3-1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1 on Slot 0 SubSlot 0", DESCR: "VWIC3-
1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1"
PID: VWIC3-1MFT-T1/E1 , VID: V01 , SN: FOC1752534Y

NAME: "WAN Interface Card - HWIC Serial 2T on Slot 0 SubSlot 1", DESCR: "WAN Interface Card - HWIC
Serial 2T"
PID: HWIC-2T , VID: V05 , SN: FOC17383EV1

NAME: "PVDM3 DSP DIMM with 128 Channels on Slot 0 SubSlot 4", DESCR: "PVDM3 DSP DIMM with 128
Channels"
PID: PVDM3-128 , VID: V01 , SN: FOC18013HAA

NAME: "C2911 AC Power Supply", DESCR: "C2911 AC Power Supply"


PID: PWR-2911-AC , VID: V05 , SN: DCA1708R1DY

We  can  see  from  the  above  output  that  a  VWIC3-­‐1MFT-­‐T1/E1  card  is  available  in  slot  0,  sub-­‐slot  0  of  
R1.  This  type  of  card  has  the  ability  to  terminate  either  a  T1  or  an  E1  depending  upon  the  configuration  

167 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

within  the  router.  In  this  case,  we  were  asked  to  configure  a  T1  PRI,  so  we  must  then  tell  the  router  to  
use  the  T1  functionality  of  the  VWIC3  card.  This  can  be  done  with  the  card type  command.  
 
R1  
R1(config)#card type t1 0 0

The  above  configuration  enables  slot  0,  sub-­‐slot  0  as  a  T1  controller.  With  the  command  entered,  IOS  
will  now  allow  the  configuration  of  t1 controller 0/0/0  in  R1.  Before  the  controller  is  actually  
configured,  however,  additional  global-­‐level  commands  should  be  entered.  The  network-clock-
participate  command  is  used  here  in  order  to  allow  T1  ports  on  the  VWIC  card  to  use  the  network  
for  timing.  This  is  a  mandatory  step  for  successful  use  of  the  PRI  for  voice  traffic.  IOS  will  actually  
disallow  the  configuration  of  the  controller  until  this  step  is  taken.  
 
R1  
R1(config)#network-clock-participate wic ?
<0-3> Slot Number (physical)

R1(config)#network-clock-participate wic 0

Next,  the  network-clock-select  command  should  be  used  in  order  to  choose  a  source  for  
network  timing.  Without  this  command,  the  local  router  does  not  select  a  source  for  timing,  making  
the  T1  PRI  prone  to  errored  and/or  slipped  seconds.  The  below  output  shows  the  state  of  the  T1  before  
the  network-clock-select  command  was  entered.  
 
R1  
R1#show controllers t1 0/0/0
T1 0/0/0 is up.
Applique type is Channelized T1
Cablelength is long 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info FPGA Rev: 08121917, FPGA Type: PRK1
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (381 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
3 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
3 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in Interval 1:
0 Line Code Violations, 0 Path Code Violations
6 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
6 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in Interval 2:
0 Line Code Violations, 0 Path Code Violations
6 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
6 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
...
 

168 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

As  you  can  see  from  the  above,  this  T1  is  receiving  slipped  and  errored  seconds  due  to  the  lack  of  a  
network  clock  selection.  This  can  cause  poor  audio  quality  and  even  dropped  calls.  The  show
network clocks  command  also  shows  that  only  the  “Backplane”  clock  source  is  being  used.  
 
R1  
R1#show network-clocks
Network Clock Configuration
---------------------------
Priority Clock Source Clock State Clock Type

10 Backplane GOOD PLL

Current Primary Clock Source


---------------------------
Priority Clock Source Clock State Clock Type

10 Backplane GOOD PLL

Now,  let’s  enter  the  network-clock-select  command  with  a  priority  of  1,  clear  the  interface  
counters,  and  see  what  happens.    
 
R1  
R1(config)#network-clock-select 1 t1 0/0/0

Oct 15 01:03:17.580: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to


priority 1

R1#sh controllers t1 0/0/0


T1 0/0/0 is up.
Applique type is Channelized T1
Cablelength is long 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info FPGA Rev: 08121917, FPGA Type: PRK1
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (123 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in Interval 1:
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in Interval 2:
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

R1#sh network-clocks
Network Clock Configuration
---------------------------
Priority Clock Source Clock State Clock Type

1 T1 0/0/0 GOOD T1
10 Backplane GOOD PLL

Current Primary Clock Source


---------------------------
Priority Clock Source Clock State Clock Type

1 T1 0/0/0 GOOD T1
 

169 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

As  you  can  see  from  the  above  output,  the  T1  is  no  longer  receiving  any  errors  or  slips  and  is  being  
used  as  the  primary  clock  source.  
 
Now  that  the  network  timing  set  up  has  been  configured,  we  must  define  the  global  switch  type.  In  this  
case,  the  requirements  have  dictated  that  this  must  be  an  ISDN  Primary-­‐NI  switch  type.  This  can  be  
defined  on  a  global  level  within  IOS.  
 
R1  
R1(config)#isdn switch-type primary-ni
 
At  this  point,  we  are  finally  ready  to  configure  the  T1  controller.  Remember,  the  requirements  stated  
that  ESF  framing  and  B8ZS  line  coding  should  be  used.  That  means,  in  this  case,  nothing  needs  to  be  
done  at  all!  That  is  because  the  default  T1  configuration  uses  the  same  framing  and  line  coding  types  as  
required  in  the  question.  The  only  thing  left  now  is  to  configure  the  controller  as  a  PRI  using  the  pri-­‐
group  command.  We  must  also  define  only  timeslots  1  –  3,  as  defined  by  the  requirements.  
 
R1  
R1(config)#controller t1 0/0/0
R1(config-controller)#pri-group timeslots 1-3 service mgcp

When  this  command  is  entered,  it  automatically  generates  a  Serial  interface  and  a  voice-­‐port  to  be  
used  for  ISDN  D-­‐Channel  signaling,  as  shown  below.    
 
R1  
R1#sh run int s0/0/0:23
Building configuration...

Current configuration : 164 bytes


!
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
end

R1#sh run | sec voice-port


voice-port 0/0/0:23
 
The  Serial  interface  will  serve  as  a  configuration  point  to  activate  the  Q.931  backhaul  to  the  call-­‐agent  
(CUCM).  This  means  that  all  Q.931  signaling  that  would  normally  be  received  by  the  router  would  
instead  be  forwarded  directly  to  CUCM.  Remember,  MGCP  is  a  client/server  protocol  with  the  gateway  
acting  as  the  client  and  CUCM  performing  the  server  roles.  All  dial-­‐plan  intelligence,  therefore,  is  
located  on  the  CUCM  server.  With  that  said,  it  logically  makes  sense  that  all  calls  should  first  be  
forwarded  to  the  “brains”  of  the  operation  as  the  first  step.  This  communication  happens  on  TCP  port  
2428.    
 
To  configure  the  backhaul,  enter  the  configuration  for  the  generated  Serial  interface  (e.g.  Serial  
0/0/0:23)  and  use  the  isdn bind-l3  command,  as  shown  below.  
 
 

170 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R1  
R1(config)#interface Serial0/0/0:23
R1(config-if)#isdn bind-l3 ccm-manager
 
The  above  is  just  the  first  part  of  the  MGCP  backhaul  configuration.  Next,  we  must  issue  some  basic  
MGCP  commands  within  global  configuration  mode.  The  mgcp call-agent  command  sets  the  IP  
address  of  the  primary  CUCM  server.  In  this  case,  the  HQ  CUCM  subscriber  is  the  primary  option.  Next,  
the  “Call  Manager  Application”  must  be  enabled  to  use  MGCP  by  entering  the  ccm-manager mgcp  
command.  Lastly,  we  must  activate  MGCP  by  issuing  the  mgcp  command.  
 
R1  
R1(config)#mgcp call-agent 10.10.13.12
R1(config)#ccm-manager mgcp
R1(config)#mgcp

At  this  point,  we  should  be  able  to  check  the  status  on  the  connection  between  the  gateway  and  the  
CUCM  server.  Obviously,  we  should  expect  to  see  the  connection  in  a  “Registering”  state  because  no  
configuration  has  been  done  on  the  CUCM  server  at  this  time.  To  check  the  status  of  the  connection  to  
CUCM,  issue  the  show ccm-manager  command.  
 
R1  
R1#show ccm-manager
MGCP Domain Name: R1
Priority Status Host
============================================================
Primary Registering with CM 10.10.13.12
First Backup None
Second Backup None

Current active Call Manager: None


Backhaul/Redundant link port: 2428
Failover Interval: 30 seconds
Keepalive Interval: 15 seconds
...

We  can  also  check  the  status  of  the  T1  PRI  from  the  router  as  well  by  issuing  the  show isdn
status command.  Notice  that  the  output  explicitly  states  that  Q.931  is  backhauled  to  CUCM.  The  
most  important  part  of  the  command  output  here  is  the  Layer  2  Status.  In  this  case,  it  is  listed  as  
TEI_ASSIGNED,  which  means  that  the  PRI  is  currently  not  exchanging  Layer  2  frames  with  the  PSTN  
switch.  This  is  expected  at  this  time,  since  we  don’t  have  a  connected  CUCM  server  to  control  the  R1  
gateway.  
 
R1#sh isdn status
Global ISDN Switchtype = primary-ni

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN Serial0/0/0:23 interface


dsl 0, interface ISDN Switchtype = primary-ni
L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000007

171 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Number of L2 Discards = 0, L2 Session ID = 3


Total Allocated ISDN CCBs = 0

At  this  time,  we  are  now  ready  to  connect  the  gateway  to  the  HQ  CUCM  cluster.  This  can  be  configured  
by  navigating  to  Device  !  Gateway  within  Cisco  Unified  CM  Administration.  Click  the  Add  New  button  
and  select  the  “Gateway  Type”  from  the  dropdown  box.  Based  on  the  show inventory  command  
that  was  run  a  little  bit  earlier  in  the  task,  we  can  see  that  this  is  a  Cisco  2911  gateway.  Click  the  Next  
button  to  continue.  
 

 
 
Next,  select  the  protocol  that  will  be  running  on  the  gateway  (MGCP).  
 

 
 
After  clicking  the  Next  button,  the  “Gateway  Configuration”  page  will  appear.  From  there,  enter  the  
“Domain  Name”  in  the  textbox.  The  value  in  this  field  is  derived  from  the  router’s  hostname  (e.g.  R1)  
and  the  ip domain-name  configured  on  the  router.  In  this  case,  there  is  not  an  ip domain-name  
configured  at  this  time,  so  just  the  hostname  of  “R1”  can  be  entered  here.  One  trick  that  I  use  is  to  
simply  issue  the  show ccm-manager  command  on  the  router  in  question  and  copy/paste  the  
“MGCP  Domain  Name”  that  appears.  This  is  very  accurate  since  this  is  the  exact  name  that  the  gateway  
will  use  to  register.  Also,  copy/pasting  prevents  the  inevitable  “fat  finger”  accident  in  typing!  
 
R1  
R1#sh ccm
MGCP Domain Name: R1

 
 
Next,  specify  the  “Cisco  Unified  Communications  Manager  Group”  that  should  be  used  for  gateway  
registration.  In  this  case,  the  HQ  CUCM  subscriber  server  (10.10.13.12)  was  used  in  the  R1  MGCP  

172 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

gateway  configuration  as  the  primary  server,  so  we  should  select  a  CUCM  group  with  the  subscriber  
server  configured.  
 

 
 
At  this  point,  we  must  configure  the  endpoint  information  for  the  gateway.  Once  again,  the  show  
inventory  command  can  be  very  useful  in  determining  the  exact  card  model  and  slot  location  on  the  
router.  In  this  case,  it  is  a  VWIC3-­‐1MFT-­‐T1/E1  located  on  slot  0,  sub-­‐slot  0.  
 
R1  
R1#show inventory
...
NAME: "VWIC3-1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1 on Slot 0 SubSlot 0", DESCR: "VWIC3-
1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1"
PID: VWIC3-1MFT-T1/E1 , VID: V01 , SN: FOC1752534Y
...

For  the  “Module  in  Slot  0”  dropdown  box,  select  the  “NM-­‐4VWIC-­‐MBRD”  option  (the  only  option)  and  
click  the  Save  button  to  continue  the  configuration.  
 

 
 
Next,  select  the  correct  card  type  for  the  “Subunit  0”  dropdown  box  and  click  the  Save  button.  
 

 
 
Next,  click  the  port  icon  next  to  the  dropdown  box  for  the  recently  configured  VWIC3  card  to  edit  the  
configuration  for  the  PRI.  
 

 
 

173 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  next  page,  select  the  “Device  Protocol”  from  the  dropdown  box.  In  this  case,  “Digital  Access  
PRI”  should  be  selected,  since  a  PRI  is  being  configured.  Click  the  Next  button  when  complete.  
 

 
 
Next,  the  “Gateway  Configuration”  page  appears.  Here,  we  must  configure  the  “Device  Pool”  setting  
from  the  dropdown  box.  An  appropriate  Device  Pool  should  be  selected.  It  may  benefit  you  in  the  CCIE  
Lab  to  create  a  separate  Device  Pool  here  to  give  you  maximum  flexibility,  but  that  will  be  up  to  you!  
Click  the  Save  and  Apply  Config  buttons  to  complete  the  configuration.  
 
On  the  “Gateway  Configuration”  page  in  CUCM,  you  should  now  see  that  R1  has  successfully  registered  
to  the  CUCM  subscriber  server.  
 

 
 
You  can  verify  this  on  the  gateway  by  issuing  the  show ccm-manager  command.  
 
R1  
R1#sh ccm
MGCP Domain Name: R1
Priority Status Host
============================================================
Primary Registered 10.10.13.12
First Backup None
Second Backup None

Use  the  show isdn status  command  on  the  R1  router  to  verify  that  the  PRI  is  up  and  running.  In  
this  case,  the  Layer  2  status  should  display  MULTIPLE_FRAME_ESTABLISHED.  
 
R1  
R1#sh isdn status
Global ISDN Switchtype = primary-ni

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN Serial0/0/0:23 interface


dsl 0, interface ISDN Switchtype = primary-ni
L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000007
Number of L2 Discards = 0, L2 Session ID = 5
Total Allocated ISDN CCBs = 0

174 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 10.2 Ensure  that  redundancy  is  configured  using  the  HQ  subscriber  as  the  primary  option  
with  the  HQ  publisher  acting  as  backup.  
 
This  task  is  now  asking  us  to  modify  the  MGCP  configuration  that  was  created  in  the  previous  task.  We  
must  configure  the  HQ  CUCM  subscriber  server  as  the  primary  option  with  the  HQ  publisher  as  the  
backup.  In  this  case,  the  first  part  of  the  task  has  been  done  for  us  already.  The  HQ  subscriber  server  is  
already  the  primary  option  in  MGCP  based  on  the  mgcp call-agent 10.10.13.12  command  
on  the  R1  gateway.  In  order  to  add  the  publisher  server  (10.10.13.11)  as  the  secondary  option,  we  
must  use  the  ccm-manager redundant-host command  within  global  configuration  mode.  Up  
to  two  servers  can  be  specified  here,  but  only  one  should  be  used  in  this  case  to  accomplish  the  
required  task.  
 
R1  
R1(config)#ccm-manager redundant-host 10.10.13.11
 
After  the  above  command  has  been  entered,  use  the  show ccm-manager  command  to  verify  that  
the  status  is  reflected  appropriately.  
 
R1  
R1#sh ccm
MGCP Domain Name: R1
Priority Status Host
============================================================
Primary Registered 10.10.13.12
First Backup Backup Ready 10.10.13.11
Second Backup None
 
   

175 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 10.3 Assure  that  R1  uses  the  loopback  interface  as  the  source  for  control  and  media  
packets.  
 
The  next  task  is  asking  to  ensure  that  R1  will  use  the  10.10.1.1  address  as  the  source  for  all  
communication  with  the  HQ  CUCM  cluster.  This  can  be  accomplished  with  the  MGCP  bind  commands  
for  both  control  and  media.  
 
R1  
R1(config)#mgcp bind control source-interface loopback 0
R1(config)#mgcp bind media source-interface loopback 0

With  the  above  commands  entered  the  source  address  for  MGCP  changes  and  should  be  reflected  in  
CUCM.    
 

 
 
Also,  check  the  show come-manager  and  show isdn status  command  outputs  on  R1  for  any  
noticeable  changes.  
 
R1  
R1#sh ccm
MGCP Domain Name: R1
Priority Status Host
============================================================
Primary Registered 10.10.13.12
First Backup Backup Ready 10.10.13.11
Second Backup None

R1#sh isdn status


Global ISDN Switchtype = primary-ni

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN Serial0/0/0:23 interface


dsl 0, interface ISDN Switchtype = primary-ni
L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000007
Number of L2 Discards = 0, L2 Session ID = 7
Total Allocated ISDN CCBs = 0

176 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Please  note:    There  is  a  great  possibility  that  these  bind  commands  will  cause  the  PRI  to  fall  back  into  
the  TEI_ASSIGNED  state.  If  this  happens,  remove  both  bind statements  and  re-­‐add  them  to  the  
configuration.  Then,  issue  a  no mgcp  followed  by  an  mgcp  command.  You  will  find  that  this  will  fix  
the  issue  95%  of  the  time.  Bottom  line,  these  bind  commands  have  the  ability  to  wreak  havoc  on  your  
CCIE  Lab  attempt  if  you’re  not  careful.  
 
   

177 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 10.4 Ensure  that  the  router  uses  the  fully  qualified  domain  name  of  
<hostname>.ipexpert.com  to  register  with  the  HQ  CUCM  cluster.  
 
The  next  task  has  specified  the  requirement  for  the  R1  MGCP  gateway  to  register  with  the  HQ  CUCM  
cluster  using  the  fully  qualified  domain  name  (FQDN)  of  “R1.ipexpert.com”.  In  the  current  state,  based  
on  the  show ccm-manager  command  output,  “R1”  is  the  current  name  being  used  for  registration.  
 
R1  
R1#sh ccm
MGCP Domain Name: R1
...
 
To  ensure  that  the  router  uses  the  FQDN,  we  must  add  the  ip domain-name  command  to  the  
global  configuration  on  R1.  Please  note  that  this  name  does  not  need  to  be  resolvable  in  DNS.  The  only  
requirement  is  that  the  hostnames  match  in  both  the  gateway  and  the  CUCM  server.  
 
R1  
R1(config)#ip domain-name ipexpert.com
 
After  the  ipexpert.com  domain  name  has  been  added  to  the  configuration,  issue  the  show ccm-
manager  command  again  to  observe  the  changes  to  the  registration  name.  
 
R1  
R1#sh ccm
MGCP Domain Name: R1.ipexpert.com
Priority Status Host
============================================================
Primary Registering with CM 10.10.13.12
First Backup Backup Ready 10.10.13.11
Second Backup None
...

Notice  that  the  status  for  the  “Primary”  CUCM  server  shows  “Registering”.  This  is  because  the  
hostname  needs  to  be  updated  within  CUCM  as  well.  Navigate  to  Device  !  Gateway  and  click  the  Find  
button.  Click  the  “R1”  gateway  and  change  the  name  from  “R1”  to  “R1.ipexpert.com”.  Make  sure  to  
click  the  Apply  Config  and/or  Reset  buttons  to  apply  the  configuration.  
 

 
 
   

178 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  issue  the  show ccm-manager  command  and  show isdn status  commands  to  ensure  
that  the  gateway  is  registered  and  the  ISDN  PRI  is  up  and  running.  
 
R1  
R1#sh ccm
MGCP Domain Name: R1.ipexpert.com
Priority Status Host
============================================================
Primary Registered 10.10.13.12
First Backup Backup Ready 10.10.13.11
Second Backup None
R1#sh isdn status
Global ISDN Switchtype = primary-ni

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN Serial0/0/0:23 interface


dsl 0, interface ISDN Switchtype = primary-ni
L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000007
Number of L2 Discards = 0, L2 Session ID = 16
Total Allocated ISDN CCBs = 0
 
   

179 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 10.5 Users  should  receive  10-­‐digit  DNIS  from  the  PSTN  provider.  Assure  that  the  call  is  
able  to  ring  the  IP  phones  on  HQ.    
 
Now  that  the  MGCP  gateway  is  successfully  registered  and  the  ISDN  PRI  is  in  the  
MULTIPLE_FRAME_ESTABLISHED  state,  we  can  start  making  some  test  calls  from  the  PSTN  into  the  
phones  at  HQ.  The  task  states  that  the  PSTN  provider  is  sending  a  10-­‐digit  number  as  the  called  
number.  With  this  in  mind,  there  are  a  couple  ways  that  we  can  attack  the  routing  of  inbound  calls.  
 
First  of  all,  we  must  remember  that  no  digit  manipulation  can  be  done  on  the  R1  gateway,  since  it  is  
registered  to  the  HQ  CUCM  cluster  using  MGCP.  That  leaves  us  with  a  couple  options  on  the  CUCM  
server  as  the  call  is  routed  inbound.  The  first  option  is  to  use  the  “Significant  Digits”  dropdown  box  on  
the  “Gateway  Configuration”  page  for  the  MGCP  gateway.  The  second  option  is  to  use  a  Translation  
Pattern  to  accept  a  10-­‐digit  number  and  strip  it  down  to  4-­‐digits.  By  far,  the  easiest  option  in  this  case  
is  the  “Significant  Digits”  method.  
 
To  configure  this  feature,  navigate  to  Device  !  Gateway  and  click  on  the  “R1.ipexpert.com”  MGCP  
gateway.  Click  on  the  T1  PRI  port  (0/0/0)  to  enter  the  “Gateway  Configuration”  page.  Scroll  down  to  
the  “Call  Routing  Information  -­‐  Inbound  Calls”  section  and  select  the  number  of  “Significant  Digits”  
from  the  dropdown  box.  This  field  analyzes  the  digits  from  right  to  left,  so  a  setting  of  “2”  would  
indicate  that  only  the  last  two  digits  of  the  number  should  be  retained.  For  example,  if  a  number  of  
4082221001  arrive  at  CUCM  via  the  MGCP  gateway  and  the  “Significant  Digits”  field  is  set  to  “4”,  the  
resulting  number  would  be  1001.  The  value  of  “4”  is  actually  what  should  be  used  in  our  case  as  well,  
since  the  HQ  phones  are  using  4-­‐digit  extensions.  
 

 
 
In  addition  to  the  “Significant  Digits”  setting,  we  must  also  not  forget  to  set  the  “Calling  Search  Space”  
field  so  that  inbound  calls  from  the  PSTN  have  access  to  the  internal  DNs  in  the  system.  This  example  
uses  the  “GW_TRUNK_CSS”,  but  use  whatever  CSS  gives  you  the  proper  access  in  your  design.  
 

 
   
   

180 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  inbound  calls  section  configured,  let’s  make  some  test  calls  into  the  system.  From  the  PSTN  
phone,  pick  up  the  line  corresponding  to  the  HQ  PSTN  phone  in  San  Jose,  CA  (+14086131218).  From  
this  line,  we  can  make  7-­‐digit  calls  into  the  phones  at  HQ  (e.g.  2221001).  Dial  the  number  2221001  and  
ensure  that  HQ  Phone  1  rings.  We  can  observe  the  dialed  digits  (inbound  and  outbound)  using  one  of  
the  greatest  debug  commands  in  the  history  of  Cisco  voice—debug isdn q931!  As  the  call  is  made  
from  the  PSTN  phone  to  HQ  Phone  1,  the  following  output  is  displayed  on  the  router.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 15 07:58:08.606: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x0081


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'HQ PSTN Phone'
Calling Party Number i = 0x4181, '6131218'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '4082221001'
Plan:ISDN, Type:Subscriber(local)
Oct 15 07:58:08.618: ISDN Se0/
0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8081
Channel ID i = 0xA98381
Exclusive, Channel 1
Oct 15 07:58:08.706: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x8081
Progress Ind i = 0x8088 - In-band info or appropriate now available

Oct 15 07:58:12.954: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x8081


Display i = 'HQ Phone 1'
Oct 15 07:58:12.970: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0081

In  the  above  debug  output,  we  can  see  both  the  inbound  calling  and  called  numbers  in  addition  to  the  
ISDN  Plan  and  Type.  This  output  is  extremely  useful  when  troubleshooting  digit  manipulation  
scenarios.  
 
In  addition  to  dialing  from  the  HQ  PSTN,  we  can  also  use  the  SB  PSTN  phone  in  Chicago,  IL  
(+13123332001)  by  dialing  an  11-­‐digit  number  (14082221001)  or  the  SC  PSTN  phone  in  Munich,  BY  
(+49307128788)  by  dialing  a  13-­‐digit  number  (0014082221001).  
 
   

181 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 10.6 Ensure  that  both  calling  name  and  number  can  be  sent  to  the  PSTN.  Also,  ensure  
that  if  the  redirecting  number  field  is  populated,  the  information  will  not  be  
dropped.  
 
This  task  is  asking  us  to  configure  the  gateway  to  send  both  the  Calling  Name  and  Number  in  the  
display  when  making  calls  out  to  the  PSTN.  The  Redirecting  Number  should  also  be  accommodated,  
should  it  exist.  This  can  be  configured  within  the  “Gateway  Configuration”  page  of  the  MGCP  T1  PRI  
port.  Keep  in  mind  that  we  will  not  be  able  to  test  this  configuration  at  the  moment  since  no  Route  
Patterns/Route  Lists/Route  Groups  exist  yet.  Of  course,  that  topic  will  be  heavily  covered  in  other  
sections  within  the  Detailed  Solution  Guide.  
 
To  configure  this  feature,  navigate  to  Device  !  Gateway  and  click  on  the  “R1.ipexpert.com”  MGCP  
gateway.  Click  on  the  T1  PRI  port  (0/0/0)  to  enter  the  “Gateway  Configuration”  page.  Scroll  down  to  
the  “PRI  Protocol  Type  Specific  Information”  section.  There  are  two  settings  that  must  be  configured  
here  to  meet  the  requirements  of  the  question.  The  first  is  the  “Display  IE  Delivery”  checkbox.  
Selecting  this  option  will  ensure  that  the  Calling  Name  is  sent  out  to  the  PSTN  within  the  “Display”  
information  element  of  the  Q.931  protocol.  The  second  option  that  must  be  selected  is  the  
“Redirecting  Number  IE  Delivery  –  Outbound”  field.  This  field  will  ensure  that  if  a  redirecting  number  is  
sent  to  the  PSTN  (to  accommodate  voicemail  perhaps)  it  will  be  sent  within  the  “Redirecting  Number”  
information  element  within  Q.931.  
 

 
 
As  stated  above,  this  task  cannot  be  verified  yet,  since  no  CUCM  dial  plan  exists  at  the  moment.  After  
the  dial  plan  is  configured,  make  test  calls  and  use  the  debug isdn q931  command  to  view  the  
activity  on  the  gateway.  

182 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 11: SIP Gateway Configuration


Task 11.1 Configure  the  T1  controller  on  R2  according  to  the  information  found  in  the  
Supplementary-­‐Info.pdf  document  and  enable  it  for  use  as  a  SIP  gateway.  
 
This  task  is  asking  us  to  configure  a  T1  controller  on  R2  and  enable  it  for  use  as  a  SIP  gateway.  The  
Supplementary-­‐Info.pdf  document  dictates  that  PRI  signaling,  ESF  framing,  and  B8ZS  line  coding  must  
be  used.  Also,  the  ISDN  switch  type  must  be  set  to  Primary-­‐NI  and  the  T1  should  only  use  timeslots  1  –  
3.  This  is  the  same  information  that  we  were  asked  to  configure  in  the  previous  lab.  
 
The  below  configuration  should  be  entered  on  the  R2  router,  just  as  it  was  done  on  R1  in  the  previous  
lab.  For  explanations  regarding  the  use  of  the  commands,  please  see  the  previous  lab.  
 
R2  
R2#sh inventory
...
NAME: "VWIC3-1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1 on Slot 0 SubSlot 0", DESCR: "VWIC3-
1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1"
PID: VWIC3-1MFT-T1/E1 , VID: V01 , SN: FOC17502A4V
...

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#card type t1 0 0
R2(config)#network-clock-participate wic 0
R2(config)#network-clock-select 1 t1 0/0/0

Oct 15 20:47:48.857: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to


priority 1

R2(config)#isdn switch-type primary-ni

At  this  point,  we  can  configure  the  T1  controller.  Just  as  stated  in  the  previous  lab,  the  default  T1  
configuration  uses  the  same  framing  (ESF)  and  line  coding  (B8ZS)  types  as  required  in  the  question,  so  
nothing  needs  to  be  configured  to  implement  those  settings.  The  only  thing  left  now  is  to  configure  the  
controller  as  a  PRI  using  the  pri-group  command.  We  must  also  utilize  only  timeslots  1  –  3,  as  
defined  by  the  requirements.  In  this  case,  we  do  not  need  to  use  the  service mgcp  command,  
since  MGCP  will  not  be  used  to  control  this  gateway.  
 
R2  
R2(config)#controller t1 0/0/0
R2(config-controller)#pri-group timeslots 1-3

Just  as  with  MGCP,  after  entering  the  pri-group  command,  a  Serial  interface  and  a  voice-­‐port  are  
automatically  generated  to  be  used  for  ISDN  D-­‐Channel  signaling,  as  shown  below.  
   

183 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
R2#sh run int s0/0/0:23
Building configuration...

Current configuration : 138 bytes


!
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
end
R2#sh run | sec voice-port
voice-port 0/0/0:23

Since  this  PRI  is  not  enabled  for  MGCP,  it  is  now  locally  controlled  on  the  R2  gateway.  With  that  in  
mind,  we  can  issue  the  show isdn status  command  to  ensure  its  operability.  
 
R2  
R2#show isdn status
Global ISDN Switchtype = primary-ni
ISDN Serial0/0/0:23 interface
dsl 0, interface ISDN Switchtype = primary-ni
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000007
Number of L2 Discards = 0, L2 Session ID = 1
Total Allocated ISDN CCBs = 0

This  first  thing  that  we  should  notice  about  the  above  output  is  the  MULTIPLE_FRAME_ESTABLISHED  
message  at  Layer  2.  This  means  that  the  PRI  is  active  and  ready  to  handle  inbound  and  outbound  calls.  
Also,  take  note  that  we  no  longer  have  a  Q.931  backhaul  at  layer  3,  since  MGCP  is  not  being  used  in  
this  case.  
 
   

184 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 11.2 Integrate  the  gateway  with  SB  CUCM  cluster  and  assure  that  R2  uses  the  loopback  
interface  as  the  source  for  signaling  packets.  
 
Now  that  the  T1  PRI  is  configured,  we  can  set  up  the  communication  path  so  that  inbound  calls  can  be  
routed  to  the  SB  CUCM  server.  The  previous  task  specified  that  we  must  enable  R2  as  a  SIP  gateway,  so  
let’s  begin  with  that  configuration.  
 
On  R2,  we  must  first  configure  the  global  voice  configuration  under  voice service voip.  In  that  
section,  there  are  a  couple  of  commands  that  we  must  enter  every  time  that  either  a  SIP  or  H.323  
gateway  is  configured.  
 
The  first  command  is  to  actually  disable  a  feature  in  the  router  called  Toll  Fraud  Prevention.  Beginning  
with  IOS  release  15.1(2)T,  toll-­‐fraud  prevention  has  been  enabled  by  default.  This  feature  blocks  all  
calls  from  “unknown”  endpoints  unless  the  router  is  properly  configured  to  trust  these  sources.  If  the  
source  IP  address  is  not  configured  within  the  ip address trusted list  or  in  the  session
target  command  of  a  dial-peer,  the  router  will  not  accept  the  call.  Therefore,  for  the  purposes  
of  the  CCIE  lab,  it  is  best  to  simply  disable  the  feature  altogether  using  the  no ip address
trusted authenticate  command.  
 
R2  
R2(config)#voice service voip
R2(conf-voi-serv)#no ip address trusted authenticate
 
Next,  we  should  allow  connections  to  be  made  by  the  router  for  VoIP-­‐to-­‐VoIP  calls  that  traverse  the  
router.  Without  these  commands  in  place,  VoIP-­‐to-­‐VoIP  calls  would  not  be  permitted.  With  that  said,  
take  note  that  these  commands  aren’t  really  necessary  in  this  case  because  the  connection  will  be  
made  from  the  ISDN  PRI  (non-­‐VoIP  source)  to  CUCM  via  SIP.  It  is,  however,  a  good  idea  to  enter  these  
commands  on  every  router  so  as  to  never  have  a  call  denied  for  this  reason.  
 
R2  
R2(config)#voice service voip
R2(conf-voi-serv)#allow-connections h323 to h323
R2(conf-voi-serv)#allow-connections h323 to sip
R2(conf-voi-serv)#allow-connections sip to h323
R2(conf-voi-serv)#allow-connections sip to sip

Next,  we  should  set  the  source  address  for  all  SIP  connections  in  the  global  SIP  configuration  section  
under  voice service voip  to  use  the  loopback  0  address,  as  defined  in  the  task  requirements.  
As  you  may  recall,  this  command  was  necessary  in  the  registration  of  SIP  phones  in  CUCME  as  well,  
because  it  sets  the  source  address  for  all  SIP  communication  (both  control  and  media)  on  the  router.  
 
R2  
R2(config)#voice service voip
R2(conf-voi-serv)#sip
R2(conf-serv-sip)#bind control source-interface Loopback0
R2(conf-serv-sip)#bind media source-interface Loopback0
 
At  this  point,  we  are  ready  to  create  the  connection  from  the  R2  router  to  the  SB  CUCM  server.  This  
will  be  done  with  the  use  of  dial-peers.  We  will  need  two  dial-peers  in  this  case;  one  to  

185 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

accept  the  incoming  call  from  the  PSTN  (POTS),  and  one  to  forward  the  call  to  the  SB  CUCM  server  
(VoIP).    
 
As  the  call  enters  the  router,  inbound  dial-peer  matching  is  performed  based  on  the  DNIS,  ANI,  or  
both.  The  following  rules  apply  to  inbound  dial-peer selection  in  both  POTS  and  VoIP  dial-
peers:  
 
1. Called  number  matching  using  the  DNIS  is  performed,  based  on  the  most  explicit  match.  The  
incoming called-number  command  is  used.  
2. If  there  is  no  match,  calling  number  matching  using  the  ANI  is  performed,  based  on  the  most  
explicit  match.  The  answer-address  command  is  used.  
3. If  there  is  still  no  match,  calling  number  matching  using  the  ANI  is  performed,  based  on  the  
most  explicit  match.  The  destination-pattern  command  is  used.    
4. If  no  match  exists,  the  dial-peer  port  it  is  associated  with  is  used  (POTS  dial-peers  
only).  The  port  command  is  used.  If  multiple  dial-peers  have  the  same  port,  the  dial-
peer  added  to  the  configuration  first  breaks  the  tie.  
5. If  nothing  matches,  default  dial-peer 0  is  used.    
 
The  first  dial-peer  that  needs  to  be  created  is  for  the  POTS  connection.  In  the  below,  the  
incoming called-number  command  is  used  along  with  the  “.”  character.  This  means  that  any  
digit,  zero  through  nine,  will  match.  Also,  by  default,  any  number  of  digits  that  are  dialed  will  match  the  
dial-peer  as  well  (unless  the  terminating  character  of  “$”  were  used  in  the  configuration).  Next,  
the  command  direct-inward-dial  is  necessary  to  prevent  two-­‐stage  dialing  behavior.  Without  
this  command,  the  router  will  play  secondary  dial  tone  when  the  dial-peer  is  matched,  instead  of  
accepting  the  call  and  forwarding  it  to  the  destination.  
 
R2  
R2(config)#dial-peer voice 1 pots
R2(config-dial-peer)#incoming called-number .
R2(config-dial-peer)#direct-inward-dial

The  next  dial-peer  that  must  be  created  is  for  the  VoIP  connection  to  the  SB  CUCM  server.  The  
destination-pattern  command  will  be  used  to  match  the  10-­‐digit  pattern  that  is  coming  in  from  
the  PSTN.  Next,  the  session protocol  and  session target  commands  define  the  protocol  
(SIP)  and  IP  address  (10.10.23.11)  to  which  the  VoIP  connection  should  be  made.  Next,  a  codec  should  
always  be  defined  on  a  dial-peer  in  some  fashion.  By  default,  all  VoIP  dial-peers  use  the  G.729  
codec,  but  we  can  configure  it  to  run  another  codec  instead,  or  even  have  the  ability  to  negotiate  
multiple  codecs.  This  can  be  done  with  the  voice-class codec  command  on  the  dial-peer.  
This  references  a  codec  class  that  was  previously  configured  on  the  router  to  negotiate  a  set  of  codecs.  
In  this  case,  the  voice class  allows  the  use  of  G.711  as  the  first  preference  and  G.729  as  the  
second  preference.  Next,  DTMF-­‐relay  is  another  feature  that  should  be  configured  on  the  dial-peer  
every  time.  In  this  case,  the  configuration  specifies  that  the  acceptable  methods  are  either  RTP-­‐NTE  or  
SIP-­‐NOTIFY.  Lastly,  Voice  Activity  Detection  (VAD)  should  be  disabled.  Why,  you  ask?  It  is  simply  
because  VAD  is  bad.  In  all  seriousness,  though,  there  is  no  need  for  the  features  that  VAD  provides  
(silence  suppression,  etc.)  in  modern  VoIP  networks.  

186 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
R2(config)#voice class codec 1
R2(config-class)# codec preference 1 g711ulaw
R2(config-class)# codec preference 2 g729r8

R2(config)#dial-peer voice 2000 voip


R2(config-dial-peer)#destination-pattern 3123332...$
R2(config-dial-peer)#session protocol sipv2
R2(config-dial-peer)#session target ipv4:10.10.23.11
R2(config-dial-peer)#voice-class codec 1
R2(config-dial-peer)#dtmf-relay rtp-nte sip-notify
R2(config-dial-peer)#no vad

At  this  point,  the  router  is  able  to  receive  calls  from  the  PSTN  and  forward  those  calls  to  the  SB  CUCM  
server.  Now  we  must  configure  the  CUCM  server  to  accept  the  connection  from  the  R2  router.  This  is  
done  by  logging  in  to  Cisco  Unified  CM  Administration  on  the  SB  CUCM  server  and  navigating  to  Device  
!  Trunk  in  the  system.  Notice  that  with  SIP  gateways,  we  must  configure  a  trunk  within  CUCM  instead  
of  a  gateway,  as  would  normally  be  done  with  either  MGCP  or  H.323.    
 

 
 
Click  the  Add  New  button  and  select  the  “Trunk  Type”  and  “Device  Protocol”  from  the  dropdown  
boxes  and  click  the  Next  button.  
 

 
 
On  the  “Trunk  Configuration”  page,  specify  a  “Device  Name”  in  the  text  box.  This  is  just  a  cosmetic  
name  and  does  not  have  to  specify  the  source  IP  address  of  SIP  traffic.  In  this  case,  the  name  
“R2_SIP_TRUNK”  was  used.    
 

 
 
Next,  select  an  appropriate  “Device  Pool”  from  the  dropdown  box.  Once  again,  it  makes  sense  to  
create  a  separate  “Device  Pool”  for  each  gateway  or  trunk  in  order  to  provide  maximum  configuration  
flexibility  down  the  road.  In  this  case,  the  “SB_PHONE_DP”  was  selected.  Keep  in  mind  also,  that  the  
CUCM  servers  that  are  configured  within  the  CUCM  group  assigned  to  the  selected  “Device  Pool”  will  

187 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

dictate  the  IP  source  address  of  the  trunk  in  question  as  well  as  the  IP  address  that  other  devices  use  to  
communicate  with  the  trunk.    
 

 
 
Next,  under  the  “SIP  Information”  section  for  the  “Destination  Address”  field,  ensure  that  the  IP  
address  of  the  R2  Loopback  0  address  (10.10.2.2)  is  entered  in  order  to  communicate  with  the  R2  
gateway.  This  is  not  only  important  for  outbound  calls,  but  also  for  accepting  inbound  calls  from  that  
specific  source  IP  address.    
 

 
 
Next,  under  the  same  section,  select  the  “SIP  Trunk  Security  Profile”  and  “SIP  Profile”  settings  from  the  
dropdown  box.  These  parameters  can  be  used  to  fine-­‐tune  the  SIP  connection,  but  in  this  case,  the  pre-­‐
configured  system  default  profiles  of  “Non  Secure  SIP  Trunk  Profile”  and  “Standard  SIP  Profile”  can  be  
selected  for  each  field,  respectively.  
 

 
 
At  this  point,  the  trunk  has  been  configured  to  communicate  with  the  R2  gateway.  Click  the  Save  and  
Reset  buttons  on  the  SIP  trunk  to  apply  the  configuration.  Please  take  note  that  there  will  not  be  any  
registration  status  available  in  CUCM,  since  the  SIP  gateway  will  not  register  with  CUCM.  
 
   

188 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 11.3 Users  should  receive  10-­‐digit  DNIS  from  the  PSTN  provider.  Assure  that  the  call  is  
able  to  ring  the  IP  phones  on  SB.    
 
As  configured  in  the  previous  task,  a  dial-peer  with  a  10-­‐digit  destination-pattern  was  
created  in  order  to  route  calls  toward  the  SB  CUCM  cluster.  However,  at  this  time,  SB  phones  are  still  
unreachable  when  dialing  from  the  PSTN.  This  is  due  to  the  fact  that  the  SB  phones  are  using  4-­‐digit  
extensions  and  10-­‐digits  are  being  sent  from  R2  to  the  SB  CUCM  cluster.  
 
R2  
dial-peer voice 2000 voip
destination-pattern 3123332...$
session protocol sipv2
session target ipv4:10.10.23.11
voice-class codec 1
dtmf-relay rtp-nte sip-notify
no vad
 
With  this  in  mind,  we  must  manipulate  the  dialed  digits  to  a  4-­‐digit  number  rather  than  keeping  the  10-­‐
digit  number  format.  There  are  three  different  ways  in  which  this  can  be  done.  
 
1. Manipulate  the  digits  within  IOS  on  the  R2  gateway  before  the  call  is  presented  to  CUCM.  
2. Manipulate  the  digits  within  CUCM  using  the  “Significant  Digits”  field  on  the  gateway.  This  was  
done  in  the  previous  lab  with  MGCP.  
3. Manipulate  the  digits  within  CUCM  using  a  Translation  Pattern  accessible  from  the  CSS  assigned  
to  the  gateway.  
 
Probably  the  best  choice  in  this  case  would  be  option  1.  The  gateway  can  house  all  digit  manipulation  
and  formatting  so  that  if  for  some  reason,  the  CUCM  server  is  not  accessible  and  the  site  falls  into  SRST  
mode,  nothing  will  change  in  the  way  calls  are  presented.  This  would  involve  translation  rules  and  
profiles  to  modify  the  number  to  a  4-­‐digit  number  in  this  case.  Since  we’ll  cover  these  topics  in  later  
labs,  I’d  like  to  avoid  the  above  option  and  use  option  2  for  this  example.  
 
Since  we  are  using  option  2,  this  means  that  the  number  will  be  in  a  10-­‐digit  format  when  presented  to  
CUCM.  Therefore,  the  modification  from  10  to  4-­‐digits  must  take  place  within  CUCM.  To  change  the  
“Significant  Digits”  field,  navigate  to  Device  !  Trunk  and  click  on  the  SIP  trunk  that  was  created  to  
connect  to  the  R2  gateway  (e.g.  “R2_SIP_TRUNK”).  Under  the  “Inbound  Calls”  section,  select  a  value  of  
“4”  from  the  dropdown  box  in  the  “Significant  Digits”  field.  In  addition,  make  sure  that  the  “Calling  
Search  Space”  is  set  to  use  an  option  that  provides  access  to  the  internal  DNs  in  the  system  (e.g.  
“GW_TRUNK_CSS”).    
 

 
 

189 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

At  this  point,  inbound  calls  to  SB  phones  should  be  possible.  Pick  up  the  SB  PSTN  line  (+13127764016)  
on  the  PSTN  phone  and  dial  one  of  the  phones  at  SB  (e.g.  3332001).  The  call  should  go  through  
successfully.  To  verify  that  the  call  is  reaching  the  router  from  the  PSTN,  use  the  debug isdn q931  
command.    
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.
Oct 16 07:25:38.615: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x0089
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'SB PSTN Phone'
Calling Party Number i = 0x4181, '7764016'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '3123332001'
Plan:ISDN, Type:Subscriber(local)
Oct 16 07:25:38.619: ISDN Se0/0/0:23 Q931: Received SETUP callref = 0x8089 callID = 0x0005 switch =
primary-ni interface = User
Oct 16 07:25:38.627: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8089
Channel ID i = 0xA98381
Exclusive, Channel 1
Oct 16 07:25:38.639: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x8089

Based  on  the  above  output,  we  know  that  the  call  is  getting  to  the  R2  router  (in  10-­‐digit  called  number  
format).  Next,  we  can  check  that  the  call  is  actually  being  sent  to  CUCM  as  well.  Of  course,  this  
connection  uses  SIP,  which  exchanges  messages  between  endpoints  as  described  in  the  following  two  
diagrams.    
 
The  following  is  a  “Delayed  Offer”  SIP  exchange,  where  media  capabilities  are  negotiated  (using  the  
SDP)  after  the  initial  set  up  has  taken  place.  
 

 
 
The  following  is  an  “Early  Offer”  SIP  exchange,  where  media  capabilities  are  sent  (using  the  SDP)  in  the  
original  INVITE  message.  The  SDP  response  is  either  contained  in  a  “183  Session  Progress”  message  or  
a  “200  OK”  message.  

190 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
With  these  diagrams  in  mind,  let’s  take  a  look  at  the  SIP  messaging  between  the  R2  and  SB  CUCM  
endpoints.  The  best  way  to  view  the  messages  is  to  enter  the  greatest  debug  command  in  the  history  
of  debug  commands,  debug ccsip messages!  In  all  seriousness,  this  is  an  excellent  command  for  
SIP  troubleshooting.    
 
R2  
R2#debug ccsip messages
SIP Call messages tracing is enabled

Oct 16 07:31:46.994: //12/51C98E568007/SIP/Msg/ccsipDisplayMsg:


Sent:
INVITE sip:3123332001@10.10.23.11:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.2.2:5060;branch=z9hG4bK526B4
Remote-Party-ID: "SB PSTN Phone" <sip:+13127764016@10.10.2.2>;party=calling;screen=yes;privacy=off
From: "SB PSTN Phone" <sip:+13127764016@10.10.2.2>;tag=2F836DE4-11E8
To: <sip:3123332001@10.10.23.11>
Date: Thu, 16 Oct 2014 07:31:46 GMT
Call-ID: 51CA2B16-543D11E4-8025DB1E-B082E409@10.10.2.2
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1372163670-1413288420-2147951849-3009744432
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1413444706
Contact: <sip:+13127764016@10.10.2.2:5060>
Call-Info: <sip:10.10.2.2:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 273

v=0
o=CiscoSystemsSIP-GW-UserAgent 9606 4460 IN IP4 10.10.2.2
s=SIP Call
c=IN IP4 10.10.2.2
t=0 0
m=audio 16394 RTP/AVP 0 18 101
c=IN IP4 10.10.2.2
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

191 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

a=fmtp:101 0-16

Oct 16 07:31:46.994: //12/51C98E568007/SIP/Msg/ccsipDisplayMsg:


Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.2.2:5060;branch=z9hG4bK526B4
From: "SB PSTN Phone" <sip:+13127764016@10.10.2.2>;tag=2F836DE4-11E8
To: <sip:3123332001@10.10.23.11>
Date: Thu, 16 Oct 2014 07:31:46 GMT
Call-ID: 51CA2B16-543D11E4-8025DB1E-B082E409@10.10.2.2
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0

Oct 16 07:31:47.006: //12/51C98E568007/SIP/Msg/ccsipDisplayMsg:


Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.2.2:5060;branch=z9hG4bK526B4
From: "SB PSTN Phone" <sip:+13127764016@10.10.2.2>;tag=2F836DE4-11E8
To:<sip:3123332001@10.10.23.11>;tag=34~fc58ca36-8b61-4fd9-a79e-d7aa6b8571b0-30886186
Date: Thu, 16 Oct 2014 07:31:46 GMT
Call-ID: 51CA2B16-543D11E4-8025DB1E-B082E409@10.10.2.2
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Call-Info: <sip:10.10.23.11:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "SB Phone 1" <sip:2001@10.10.23.11>
Remote-Party-ID: "SB Phone 1" <sip:2001@10.10.23.11>;party=called;screen=yes;privacy=off
Contact: <sip:3123332001@10.10.23.11:5060>
Content-Length: 0

Oct 16 07:31:55.937: //12/51C98E568007/SIP/Msg/ccsipDisplayMsg:


Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.2.2:5060;branch=z9hG4bK526B4
From: "SB PSTN Phone" <sip:+13127764016@10.10.2.2>;tag=2F836DE4-11E8
To: <sip:3123332001@10.10.23.11>;tag=34~fc58ca36-8b61-4fd9-a79e-d7aa6b8571b0-30886186
Date: Thu, 16 Oct 2014 07:31:46 GMT
Call-ID: 51CA2B16-543D11E4-8025DB1E-B082E409@10.10.2.2
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Call-Info: <sip:10.10.23.11:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Require: timer
P-Asserted-Identity: "SB Phone 1" <sip:2001@10.10.23.11>
Remote-Party-ID: "SB Phone 1" <sip:2001@10.10.23.11>;party=called;screen=yes;privacy=off
Contact: <sip:3123332001@10.10.23.11:5060>
Content-Type: application/sdp
Content-Length: 175

v=0
o=CiscoSystemsCCM-SIP 34 1 IN IP4 10.10.23.11
s=SIP Call
c=IN IP4 10.10.21.25
b=TIAS:64000
b=AS:64
t=0 0
m=audio 16560 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20

Oct 16 07:31:55.945: //12/51C98E568007/SIP/Msg/ccsipDisplayMsg:


Sent:
ACK sip:3123332001@10.10.23.11:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.2.2:5060;branch=z9hG4bK623C6

192 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

From: "SB PSTN Phone" <sip:+13127764016@10.10.2.2>;tag=2F836DE4-11E8


To: <sip:3123332001@10.10.23.11>;tag=34~fc58ca36-8b61-4fd9-a79e-d7aa6b8571b0-30886186
Date: Thu, 16 Oct 2014 07:31:46 GMT
Call-ID: 51CA2B16-543D11E4-8025DB1E-B082E409@10.10.2.2
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

From  the  above  debug  output,  we  can  see  that  this  in  an  “Early  Offer”  type  of  SIP  exchange,  due  to  the  
presence  of  an  SDP  in  the  original  INVITE  message.  This  now  confirms  what  we  already  know—inbound  
calls  from  the  PSTN  to  the  SB  CUCM  server  are  possible.  
 
   

193 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 11.4 Ensure  that  both  calling  name  and  number  can  be  sent  to  the  PSTN.  Also,  ensure  
that  if  the  redirecting  number  field  is  populated  the  information  will  not  be  dropped.  
 
This  task  is  asking  us  to  configure  the  gateway  to  send  both  the  Calling  Name  and  Number  in  the  
display  when  making  calls  out  to  the  PSTN.  The  Redirecting  Number  should  also  be  accommodated,  
should  it  exist.  This  can  be  configured  within  the  “Trunk  Configuration”  page  of  the  “R2_SIP_TRUNK”.  
Keep  in  mind  that  we  will  not  be  able  to  test  this  configuration  at  the  moment  since  no  Route  
Patterns/Route  Lists/Route  Groups  exist  yet.  Of  course,  that  topic  will  be  heavily  covered  in  other  
sections  within  the  Detailed  Solution  Guide.    
 
Navigate  to  Device  !  Trunk  and  click  on  the  “R2_SIP_TRUNK”  to  make  changes.  In  the  “Outbound  
Calls”  section,  locate  the  “Calling  Name  Presentation”  field  and  ensure  that  the  “Default”  option  is  
selected.  By  default,  the  calling  name  is  allowed  here.  If  you  are  unsure  what  the  default  setting  is,  feel  
free  to  change  this  option  to  “Allowed”.  Next,  to  accommodate  the  requirement  to  pass  the  
“Redirecting  Number”  field,  ensure  that  the  “Redirecting  Diversion  Header  Delivery  –  Outbound”  box  is  
checked.  Make  sure  to  click  the  Save  and  Reset  buttons  on  the  trunk  to  apply  the  configuration.  
 

 
 
In  addition  to  the  above  CUCM  settings,  we  must  also  make  a  change  on  the  R2  gateway  to  ensure  that  
the  Calling  Name  and  Redirecting  Number  will  be  displayed  once  sent  to  the  PSTN.  Under  the  auto-­‐
generated  serial  interface  for  the  ISDN  D-­‐Channel  (Serial  0/0/0:23),  the  isdn outgoing
display-ie  and  isdn outgoing ie redirecting-number  commands  must  be  entered  in  
order  to  properly  allow  the  information  contained  within  those  fields  to  be  passed.  
 
R2  
R2(config)#int s0/0/0:23
R2(config-if)#isdn outgoing display-ie
R2(config-if)#isdn outgoing ie redirecting-number

194 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 12: H.323 Gateway Configuration


Task 12.1 Configure  the  E1  controller  on  R3  according  to  the  information  found  in  the  
Supplementary-­‐Info.pdf  document  and  enable  it  for  use  as  a  H.323  gateway.  
 
This  task  is  asking  us  to  configure  an  E1  controller  on  R3  and  enable  it  for  use  as  a  H.323  gateway.  The  
first  caveat  here  is  that  this  gateway  will  not  be  connected  to  a  CUCM  cluster,  since  it  will  be  serving  
the  CUCME  on  R3.  This  means  that  the  R3  gateway  will  basically  be  protocol-­‐agnostic  in  terms  of  
gateway  signaling.  With  that  said,  part  of  this  guide  will  highlight  the  steps  necessary  to  connect  an  
H.323  gateway  to  CUCM  for  future  reference,  even  though  it  will  not  be  used  in  this  lab.  
 
The  Supplementary-­‐Info.pdf  document  dictates  that  E1  PRI  signaling,  CRC4  framing,  and  HDB3  line  
coding  must  be  used.  Also,  the  ISDN  switch  type  must  be  set  to  Primary-­‐Net5  and  the  E1  should  only  
use  timeslots  1  –  3.  
 
Just  as  was  done  in  previous  labs,  the  first  thing  that  should  be  done  here  is  to  issue  the  show
inventory command.  This  will  allow  a  glimpse  into  the  hardware  that  is  being  used  in  the  router  so  
we  can  configure  it  appropriately.  Next,  configure  the  card type,  network-clock-
participate,  network-clock-select,  and  isdn switch-type  commands  using  the  same  
logic  as  the  previous  two  labs.  The  only  difference  here  is  that  the  controller  that  is  created  will  be  an  
E1.  
 
R3  
R3#sh inventory
...
NAME: "VWIC3-1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1 on Slot 0 SubSlot 0", DESCR: "VWIC3-
1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1"
PID: VWIC3-1MFT-T1/E1 , VID: V01 , SN: FOC1750870L
...

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#card type e1 0 0
R3(config)#network-clock-participate wic 0
R3(config)#network-clock-select 1 e1 0/0/0

Oct 16 18:54:49.044: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to


priority 1

R3(config)#isdn switch-type primary-net5

At  this  point,  we  can  configure  the  E1  controller  that  was  just  created.  For  an  E1,  the  default  framing  
(CRC4)  and  line  coding  (HDB3)  are  the  same  values  required  by  the  task,  so  nothing  needs  to  be  
configured  to  implement  those  settings.  The  only  thing  left  now  is  to  configure  the  controller  as  a  PRI  
using  the  pri-group  command.  We  must  also  utilize  only  timeslots  1  –  3,  as  defined  by  the  
requirements.  
 
R3  
R3(config)#controller e1 0/0/0
R3(config-controller)#pri-group timeslots 1-3

195 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

As  seen  in  the  previous  two  labs,  after  entering  the  pri-group  command,  a  Serial  interface  and  a  
voice-­‐port  are  automatically  generated  to  be  used  for  ISDN  D-­‐Channel  signaling,  as  shown  below.  
Notice  that  the  serial  interface  in  this  case  uses  “:15”  as  the  suffix  instead  of  “:23”.  This  is  because  the  
D-­‐Channel  configuration  uses  timeslot  16  (counting  the  zero  timeslot)  instead  of  the  last  timeslot  (T1).  
 
R3  
R3#sh run int s0/0/0:15
Building configuration...

Current configuration : 140 bytes


!
interface Serial0/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
no cdp enable
end

R3#sh run | sec voice-port


voice-port 0/0/0:15
 
Since  this  PRI  is  now  locally  controlled  on  the  R3  gateway,  we  can  issue  the  show isdn status  
command  to  ensure  its  operability.  
 
R3  
R3#sh isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000007
Number of L2 Discards = 0, L2 Session ID = 1
Total Allocated ISDN CCBs = 0

This  first  thing  that  we  should  notice  about  the  above  output  is  the  MULTIPLE_FRAME_ESTABLISHED  
message  at  Layer  2.  This  means  that  the  PRI  is  active  and  ready  to  handle  inbound  and  outbound  calls.    
 
   

196 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 12.2 Assure  that  R3  uses  the  loopback  interface  as  the  source  for  signaling  packets.  
 
This  task  requires  us  to  configure  the  Loopback  0  interface  as  the  H.323  signaling  source.  Since  we  are  
not  connecting  to  CUCM,  this  command  is  not  required  in  this  case.  No  H.323  configuration  is  actually  
required  unless  connecting  to  another  VoIP  endpoint  such  as  another  gateway  or  CUCM  server.  Since  
the  E1  PRI  is  being  terminated  on  R3,  the  call  can  be  routed  directly  to  CUCME  without  intervention  
from  any  other  protocol.  
 
With  that  in  mind,  if  we  are  connecting  to  another  endpoint,  setting  the  source  interface  for  H.323  
protocol  communication  is  a  very  common  requirement.  This  is  because  the  communication  should  be  
anchored  to  a  specific  IP  address  so  configurations  on  devices  that  connect  to  the  gateway  can  
consistently  use  the  same  connection  information.  To  set  the  source  IP  address  for  H.323  
communication,  we  must  enter  the  configuration  for  the  interface  to  be  used  as  the  source  (e.g.  
Loopback  0).  Following  that,  the  h323-gateway voip bind srcaddr <IP Address>  
command  should  be  entered  to  set  the  source  address.  
 
R3  
R3(config)#int loopback0
R3(config-if)#h323-gateway voip bind srcaddr 10.10.3.3
 
Once  configured,  all  other  H.323  endpoints  can  communicate  with  R3  using  the  10.10.3.3  address.  In  
addition,  we  should  enter  the  “standard”  allow-connections  commands  within  voice
service voip  here.  Once  again,  these  are  not  required,  but  are  a  great  idea  to  avoid  future  
situations  where  a  call  may  be  blocked  for  this  reason.  
 
R3  
R3(config)#voice service voip
R3(conf-voi-serv)#allow-connections h323 to h323
R3(conf-voi-serv)#allow-connections h323 to sip
R3(conf-voi-serv)#allow-connections sip to h323
R3(conf-voi-serv)#allow-connections sip to sip
 
   

197 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 12.3 Users  should  receive  9-­‐digit  DNIS  from  the  PSTN  provider.  Assure  that  the  call  is  able  
to  ring  the  IP  phones  on  SC.    
 
This  task  is  simply  asking  us  to  ensure  that  inbound  calls  can  reach  the  phones  registered  to  both  the  
SIP  and  SCCP  CUCME  servers  running  on  R3.  The  E1  PRI  has  already  been  configured,  so  dial-peers  
are  now  the  only  requirement  to  enabling  this  communication.  In  this  case,  we  only  need  one  dial-
peer.  This  is  because  the  dial-peers  for  each  phone  were  already  created  for  us;  a  virtual  POTS  
dial-peer  for  each  SCCP  phone  and  a  virtual  VoIP  dial-peer  for  each  SIP  phone.    
 
R3  
R3(config)#dial-peer voice 1 pots
R3(config-dial-peer)#incoming called-number .
R3(config-dial-peer)#direct-inward-dial
 
In  this  case,  a  POTS  dial-­‐peer  was  created,  just  as  was  done  with  the  SIP  gateway  in  the  previous  lab.  
The  incoming called-number  command  was  used  to  match  all  calls  from  PSTN  sources,  
regardless  of  the  called  number.  The  direct-inward-dial  command  was  used  here  to  avoid  two-­‐
stage  dialing  behavior.  
 
Now,  let’s  attempt  to  call  a  SC  phone  from  the  PSTN  phone  and  see  what  happens.  Pick  up  the  SC  PSTN  
line  (+49307128788)  and  dial  one  of  the  phones  at  SC  (e.g.  894443002).  Use  the  debug isdn q931  
command  to  view  the  details  of  the  call  upon  entering  the  router.  
 
Note:    To  dial  SC  phones  from  the  HQ  and  SB  PSTN  lines,  dial  01149894443XXX.  
 
R3  
R3#debug isdn q931
debug isdn q931 is ON.
R3#
Oct 16 23:48:50.479: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x008D
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'SC PSTN Phone'
Calling Party Number i = 0x1181, '307128788'
Plan:ISDN, Type:International
Called Party Number i = 0xA1, '894443002'
Plan:ISDN, Type:National
Oct 16 23:48:50.479: ISDN Se0/0/0:15 Q931:
R3# Received SETUP callref = 0x808D callID = 0x0003 switch = primary-net5 interface = User
Oct 16 23:48:50.487: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x808D
Channel ID i = 0xA98381
Exclusive, Channel 1
Oct 16 23:48:50.487: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x808D
Cause i = 0x8081 - Unallocated/unassigned number
Oct 16 23:48:50.503: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x008D
Oct 16 23:48:50.503: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP
R3#pd = 8 callref = 0x808D

198 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

We  can  see  that  the  call  does  not  go  through  successfully  based  on  the  “Unallocated/unassigned  
number”  message  in  the  debug  output.  This  is  because  the  number  is  arriving  at  the  router  in  9-­‐digit  
format  and  the  DNs  assigned  to  the  phones  are  4-­‐digits  in  length.  Based  on  this  fact,  we  must  
manipulate  the  digits  in  order  to  access  the  phones  registered  to  CUCME.  In  this  case,  we  must  utilize  
translation  rules  and  profiles.    
 
In  order  to  understand  translation  rules,  we  must  understand  the  regular  expressions  that  will  be  used  
in  matching  number  strings.  The  following  are  examples  of  regular  expressions  that  may  be  used:    
 
• Period  (.)  –  Match  any  single  digit.  
• 0  to  9,  *,  #  -­‐  Match  the  specific  character  entered.  
• [0-­‐9]  –  Match  a  range  of  characters.  
• Asterisk  (*)  –  Match  none  or  more  occurrences  of  the  previous  character.  
• Plus  (+)  –  Match  one  or  more  occurrences  of  the  previous  character.  
• Question  Mark  (?)  –  Match  none  or  one  occurrence  of  the  previous  character.  
• Backslash  (\)  –  Escape  the  special  meaning  of  the  next  character.  
• Parentheses  (or)  –  Groups  regular  expressions.  
• Forward  Slash  (/)  –  Marks  the  start  and  end  of  both  matching  replacement  strings.  
• Caret  (^)  –  Match  the  expression  at  the  start  of  a  line.  
 
Next,  let’s  examine  the  format  of  a  voice translation-rule.  For  each  rule,  there  is  a  
“matching  set”  and  a  “replacing  set”.  Both  of  these  sets  are  bookended  by  the  “forward  slash”  
character  (e.g.  rule 1 // //).  For  example,  let’s  match  a  string  that  starts  with  “9”  followed  by  any  
number  of  digits.  From  there,  make  sure  that  the  “9”  is  dropped  and  replaced  with  “88”  for  the  
resulting  number.  This  can  be  accomplished  with  the  rule  specified  below:  
 
rule 1 /^9\(.*\)/ /88\1/
 
Based  on  the  above  rule,  an  input  number  of  91234  would  result  in  a  replacement  number  of  881234.  
In  the  match  string,  the  caret  (^)  dictates  that  the  number  must  start  with  “9”.  Next,  the  backslash  (\)  
indicates  that  the  special  meaning  of  the  next  character  should  be  ignored.  The  “left”  parentheses  
character  starts  the  definition  of  a  “subset”  within  the  translation  rule.  Subsets  are  grouped  inside  sets  
of  parentheses  and  are  identified  in  the  “replacing  set”  by  the  order  they  are  introduced  in  the  
“matching  set”.  So  the  first  subset  is  identified  as  “\1”,  the  second  subset  is  identified  by  “\2”  and  so  
forth.  Next,  the  period  (.)  character  matches  any  single  digit  and  the  asterisk  (*)  character  specifies  that  
none  or  more  occurrences  of  the  previous  character  could  occur.  This  essentially  means  “none  or  more  
occurrences  of  any  digit”.  Finally,  the  backslash  and  “right”  parentheses  closes  the  first  subset  in  the  
“matching  set”.  The  “replacing  set”  inserts  “88”  followed  by  whatever  numbers  are  contained  within  
the  first  subset,  which  as  mentioned  above,  was  “none  or  more  occurrences  of  any  digit”.  
 
   

199 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  that  said,  we  must  create  a  voice translation-rule  in  order  to  modify  the  9-­‐digit  string  
as  it  enters  the  router.  An  example  of  the  string  we  are  trying  to  manipulate  is  “894443002”.  
 
R3  
R3(config)#voice translation-rule 1
R3(cfg-translation-rule)# rule 1 /^89444\(3...$\)/ /\1/
 
The  above  defines  the  voice translation-rule  as  number  “1”  in  the  system.  Within  this  
voice translation-rule,  up  to  100  rules  can  be  defined.  For  rule  1,  anything  that  starts  with  
“894443”  will  be  matched.  In  the  first  subset,  any  four-­‐digit  number  starting  with  3  has  been  defined.  
In  the  “replacing  set”,  only  the  first  subset  is  used.  This  means  that  the  resulting  output  would  be  
“3002”,  based  on  the  example  input.  
 
The  next  piece  of  the  puzzle  is  to  apply  this  rule  to  either  a  called,  calling,  or  redirecting  number  and  
specify  a  direction  (incoming  or  outgoing).  This  is  done  with  a  voice translation-profile.  
 
R3  
R3(config)#voice translation-profile TRANSLATE-PSTN-INBOUND
R3(cfg-translation-profile)#translate called 1
 
In  the  above,  a  descriptive  name  for  the  profile  is  essential  (e.g.  “TRANSLATE-­‐PSTN-­‐INBOUND”).  Once  
that  has  been  defined,  we  must  determine  the  number  that  is  being  translated.  In  this  case,  we  want  
to  translate  the  called  number  as  it  enters  the  router.  The  “1”  that  is  listed  in  the  profile  corresponds  to  
the  number  of  the  voice translation-rule  that  was  created.  Essentially  this  command  will  
accomplish  the  translation  of  the  called  number  according  to  voice translation-rule 1.  
 
The  last  thing  to  do  is  to  specify  a  direction  for  the  rules  to  be  applied.  This  is  done  by  assigning  the  
voice translation-profile  to  a  dial-peer  or  to  the  auto-­‐generated  voice-port.  If  
assigning  the  profile  to  the  voice-port,  all  calls,  regardless  of  digits  dialed,  are  affected  by  the  
contents  of  the  rule.  If  applying  the  profile  at  a  dial-peer  level,  only  those  calls  that  match  the  
dial-peer  would  be  affected  by  the  profile.  In  this  case,  the  two  options  are  one  in  the  same  
because  the  incoming called-number command  within  dial-peer voice 1 pots  
matches  every  POTS  call  that  enters  the  router.  
 
R3  
R3(config)#dial-peer voice 1 pots
R3(config-dial-peer)#translation-profile incoming TRANSLATE-PSTN-INBOUND
 
The  above  command  specifies  that  the  profile  should  take  effect  on  incoming  calls  only.  When  we  put  
it  all  together,  this  configuration  now  dictates  that  any  “called  number”  entering  the  router  that  
matches  this  dial-peer  and  starts  with  “894443”  should  be  translated  to  3XXX.  Running  the  debug
isdn q931  command  and  making  another  test  call  confirms  the  success  of  the  above  commands.  
 
   

200 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3  
R3#debug isdn q931
debug isdn q931 is ON.
Oct 17 00:52:29.529: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x008E
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'SC PSTN Phone'
Calling Party Number i = 0x1181, '307128788'
Plan:ISDN, Type:International
Called Party Number i = 0xA1, '894443002'
Plan:ISDN, Type:National
Oct 17 00:52:29.529: ISDN Se0/0/0:15 Q931:
R3# Received SETUP callref = 0x808E callID = 0x0004 switch = primary-net5 interface = User
Oct 17 00:52:29.541: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x808E
Channel ID i = 0xA98381
Exclusive, Channel 1
Oct 17 00:52:29.625: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x808E

 
   

201 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 12.4 Ensure  that  both  calling  name  and  number  can  be  sent  to  the  PSTN.  
 
This  task  is  asking  us  to  configure  the  gateway  to  send  both  the  Calling  Name  and  Number  in  the  
display  when  making  outbound  calls  to  the  PSTN.  We  must  make  a  change  on  the  R3  gateway  under  
the  auto-­‐generated  serial  interface  for  the  ISDN  D-­‐Channel  (Serial  0/0/0:15).  The  isdn outgoing
display-ie  command  must  be  entered  in  order  to  properly  allow  the  information  contained  within  
the  field  to  be  passed.  
 
R3  
R3(config)#int s0/0/0:15
R3(config-if)#isdn outgoing display-ie
   

202 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Addendum:    Connecting  an  H.323  Gateway  with  CUCM  


This  previous  sections  detailed  the  R3  gateway  configuration  to  support  CUCME  phones.  If  tasked  with  
configuring  an  H.323  gateway  that  will  connect  to  CUCM,  the  following  commands  (as  detailed  above)  
must  be  entered.  
 
R3  
R3(config)#card type e1 0 0
R3(config)#network-clock-participate wic 0
R3(config)#network-clock-select 1 e1 0/0/0

Oct 16 18:54:49.044: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to


priority 1

R3(config)#isdn switch-type primary-net5

R3(config)#controller e1 0/0/0
R3(config-controller)#pri-group timeslots 1-3

R3(config)#int loopback0
R3(config-if)#h323-gateway voip bind srcaddr 10.10.3.3

R3(config)#voice translation-rule 1
R3(cfg-translation-rule)# rule 1 /^89444\(3...$\)/ /\1/

R3(config)#voice translation-profile TRANSLATE-PSTN-INBOUND


R3(cfg-translation-profile)#translate called 1

R3(config)#dial-peer voice 1 pots


R3(config-dial-peer)#translation-profile incoming TRANSLATE-PSTN-INBOUND
R3(config-dial-peer)#incoming called-number .
R3(config-dial-peer)#direct-inward-dial

Next,  we  would  need  to  create  a  dial-peer  for  the  translated  4-­‐digit  number  to  send  the  call  to  
CUCM.  In  this  example,  let’s  just  say  that  the  SB  CUCM  server  is  being  used.  Just  as  was  configured  on  
R2  for  the  SB  SIP  gateway,  we  can  configure  a  voice class codec  for  codec  selection  as  well  as  a  
dial-peer  (4-­‐digits)  pointing  toward  the  SB  CUCM  publisher  (10.10.23.11).    
 
R3  
R3(config)#voice class codec 1
R3(config-class)#codec preference 1 g711ulaw
R3(config-class)#codec preference 2 g729r8

R3(config)#dial-peer voice 3000 voip


R3(config-dial-peer)#destination-pattern 3...$
R3(config-dial-peer)#session target ipv4:10.10.23.11
R3(config-dial-peer)#voice-class codec 1
R3(config-dial-peer)#dtmf-relay h245-alphanumeric
R3(config-dial-peer)#no vad
   

203 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  log  into  CUCM  and  create  the  H.323  gateway  by  navigating  to  Device  !  Gateway.  Click  
the  Add  New  button  and  select  “H.323  Gateway”  from  the  dropdown  list.    
 

 
 
Enter  the  “Device  Name”  as  the  IP  Address  of  the  H.323  source  address  on  the  R3  gateway  (10.10.3.3).  
The  IP  address  must  be  used  here.  
 

 
 
Next,  select  an  appropriate  “Device  Pool”  from  the  dropdown  list.  
 

 
 
Next,  under  the  “Call  Routing  Information  -­‐  Inbound  Calls”  section,  select  a  “Calling  Search  Space”  that  
has  access  to  the  internal  DNs  in  the  system  (e.g.  “GW_TRUNK_CSS”).  The  “Significant  Digits”  field  can  
be  left  at  the  default  setting  of  “All”  in  this  case  since  the  number  is  already  in  4-­‐digit  format.  
 

 
 
   

204 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Under  the  “Call  Routing  Information  -­‐  Outbound  Calls”  section,  ensure  that  the  “Display  IE  Delivery”  
and  “Redirecting  Number  IE  Delivery  –  Outbound”  checkboxes  are  selected  to  pass  the  information  
contained  in  those  fields  to  the  gateway.    
 

 
 
Lastly,  make  sure  to  click  the  Save  and  Reset  buttons  to  apply  the  configuration.  
 

205 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 13: H.323 Trunk Configuration


Task 13.1 Create  a  Non-­‐Gatekeeper  Controlled  Intercluster  Trunk  (ICT)  to  support  calling  
between  the  HQ  CUCM  Cluster  and  the  SB  CUCM  Cluster.  
 
We’ve  spent  the  last  few  labs  focusing  on  different  gateway  configurations  to  support  PSTN  
connectivity.  In  this  task  we’re  going  to  create  a  link  between  clusters  called  an  Intercluster  Trunk  (ICT)  
for  the  purposes  of  routing  calls.  We  have  the  option  of  creating  either  a  SIP  trunk  or  an  H.323  trunk  
between  clusters.  The  “Non-­‐Gatekeeper  Controlled”  ICT  is  a  type  of  trunk  that  runs  the  H.323  protocol.  
To  create  the  trunk,  we  will  have  to  configure  both  the  HQ  and  SB  CUCM  clusters.  
 
After  logging  in  to  Cisco  Unified  CM  Administration  on  the  HQ  CUCM  cluster,  navigate  to  Device  !  
Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  Type”  as  an  “Inter-­‐Cluster  Trunk  (Non-­‐
Gatekeeper  Controlled)”  type  and  click  the  Next  button.  
 

 
 
Enter  a  descriptive  “Device  Name”  for  the  trunk  (e.g.  “SB_H323_ICT_TRUNK”).    
 

 
 
Next,  select  a  “Device  Pool”  from  the  dropdown  box  (e.g.  “SB_H323_ICT_DP”).  My  advice  would  be  to  
create  a  separate  Device  Pool  for  each  trunk  or  gateway  created  in  the  system  in  order  to  gain  
maximum  flexibility  in  configuration.  Keep  in  mind  that  the  CUCM  group  assigned  to  the  selected  
Device  Pool  will  determine  the  servers  that  will  be  used  for  the  connection.  For  example,  if  there  are  
two  servers  configured  in  the  CUCM  group  assigned  to  the  Device  Pool,  one  of  those  servers  could  be  
used  as  the  source  address  for  signaling  traffic  as  it  exits  the  CUCM  cluster.  Either  of  these  servers  
could  also  be  used  as  destination  addresses  when  accepting  connections  from  remote  systems.    
 

 
 
Next,  scroll  down  to  the  “Inbound  Calls”  section  and  set  a  value  for  the  “Calling  Search  Space”  
dropdown  box  (e.g.  “GW_TRUNK_CSS”).  Assign  a  CSS  that  has  access  to  the  internal  DNs  in  the  system.  
 

206 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

There  is  also  an  option  to  set  the  “Significant  Digits”  field  as  well,  but  it  is  not  recommended  here.  It  is  
better  to  pass  all  numbers  across  the  trunk  to  accommodate  future  scenarios  like  Tail-­‐End  Hop-­‐Off  
(TEHO),  where  the  numbers  traversing  the  trunk  may  be  more  than  4-­‐digits  in  length.  
 

 
 
Next,  enter  the  destination  IP  address  (10.10.23.11)  that  will  be  used  by  the  trunk  to  connect  to  the  
other  CUCM  system.    
 

 
 
Complete  these  steps  on  the  SB  CUCM  cluster  as  well,  pointing  toward  the  HQ  CUCM  cluster.    
 

 
 

 
 

 
 
   

207 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 13.2 Ensure  that  the  calling  name,  calling  number,  and  redirecting  number  fields  are  
passed  from  the  SB  cluster  to  the  HQ  cluster.  Calls  from  HQ  to  SB  should  restrict  
calling  name  information  from  being  displayed  on  SB  phones.  
 
This  task  specifies  that  the  calling  name,  calling  number  and  redirecting  number  fields  should  be  
passed  from  SB  to  HQ.  In  the  opposite  direction,  calling  name  information  should  be  restricted.  
 
On  the  SB  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  on  the  “HQ_H323_ICT_TRUNK”  that  was  
created  in  the  previous  task.  Under  the  “Outbound  Calls”  section,  make  sure  to  select  the  “Display  IE  
Delivery”  checkbox  in  order  to  pass  the  calling  name  in  addition  to  the  number  across  the  H.323  ICT.  
Check  the  “Redirecting  Number  IE  Delivery  -­‐  Outbound”  checkbox  in  order  to  support  the  passing  of  
the  redirecting  number  field  as  well.  
 

 
 
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  on  the  “SB_H323_ICT_TRUNK”  that  was  
created  in  the  previous  task.  Under  the  “Inbound  Calls”  section,  select  the  “Redirecting  Number  IE  
Delivery  –  Inbound”  checkbox  to  accept  the  Redirecting  Number  field  as  it  is  passed  from  the  SB  CUCM  
cluster.    
 

 
 
Under  the  “Outbound  Calls”  section,  ensure  that  the  “Display  IE  Delivery”  checkbox  is  unchecked  so  as  
to  not  send  the  calling  name  display  from  HQ  to  SB  across  the  trunk.  
 

 
 
When  the  ability  to  make  calls  has  been  configured  in  the  system,  make  test  calls  to  ensure  that  
everything  is  working  as  designed.  
 
   

208 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  below  is  the  display  on  a  SB  phone  for  a  call  that  was  received  from  HQ.  No  calling  name  was  
presented.  
 

 
 
The  below  is  the  display  on  an  HQ  phone  for  a  call  that  was  received  from  SB.  The  calling  name  was  
presented.  
 

 
 
   

209 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 13.3 Assure  that  the  trunk  on  the  HQ  CUCM  cluster  will  not  fail  if  one  of  the  subscribers  is  
unavailable.  
 
To  ensure  that  the  ICT  does  not  fail  if  one  if  the  subscribers  is  unavailable,  we  must  configure  a  couple  
settings,  one  on  each  cluster.  On  the  HQ  CUCM  cluster,  we  must  ensure  that  the  CUCM  group  assigned  
to  the  Device  Pool  associated  with  the  trunk  is  configured  for  redundancy.  If  there  is  only  one  server  in  
the  group,  and  that  server  fails,  the  other  server  will  not  be  utilized  in  that  case.    
 
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  the  Find  button.  In  the  list,  locate  the  
“SB_H323_ICT_TRUNK”  and  click  on  the  “Device  Pool”  associated  with  that  trunk  (e.g.  
“SB_H323_ICT_DP”).    
 

 
 
On  the  “Device  Pool”  configuration  page,  locate  the  “Cisco  Unified  Communications  Manager  Group”  
setting  and  take  note  of  it  (e.g.  “SUB_PUB_CMG”).  Now  navigate  to  System  !  Cisco  Unified  CM  Group  
and  locate  the  “SUB_PUB_CMG”.  Click  on  it  to  view  the  details.  Ensure  that  both  available  servers  are  
selected  as  options.  This  will  ensure  that  redundancy  is  available  in  the  event  that  one  of  the  servers  
goes  down.  
 

 
 
Another  option  is  to  navigate  to  Device  !  Trunk  and  click  on  the  “SB_H323_ICT_TRUNK”.  In  the  “Trunk  
Configuration”  page,  select  the  “Run  On  All  Active  Unified  CM  Nodes”  checkbox.  This  essentially  
accomplishes  the  same  thing  as  adding  all  available  servers  to  the  CUCM  group,  because  it  will  ensure  
that  the  trunk  will  not  become  unavailable  unless  the  entire  CUCM  cluster  crashes.  
 
   

210 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  next  step  in  ensuring  HQ  redundancy  actually  happens  on  the  SB  CUCM  cluster.  We  must  add  the  
publisher  server  to  the  list  of  server  connections  on  the  “HQ_H323_ICT_TRUNK”.  Once  again,  navigate  
to  Device  !  Trunk  and  select  the  ICT.  Scroll  down  to  the  “Remote  Cisco  Unified  Communications  
Manager  Information”  section  and  add  the  other  HQ  CUCM  server  to  the  list  (e.g.  10.10.13.11).  
 

 
 
   

211 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 13.4 Calls  between  clusters  should  use  the  G.729  codec  over  the  H.323  Trunk.  
 
This  task  is  asking  us  to  configure  G.729  as  the  audio  codec  between  clusters.  This  is  where  separate  
Device  Pools  (if  you  created  them)  can  come  in  very  handy.  Since  the  codec  selection  process  is  
controlled  by  the  Region  settings  in  CUCM,  we  can  simply  create  a  Region  specifically  for  the  ICT  on  
both  clusters  and  force  a  G.729  relationship  between  the  phones  on  each  cluster.    
 
To  begin,  navigate  to  System  !  Region  Information  !  Region  on  the  HQ  CUCM  cluster  and  click  the  
Add  New  button.  Give  the  Region  a  descriptive  name  and  click  the  Save  button.    
 

 
 
No  manually  created  Region  relationships  are  necessary  here  since  the  default  inter-­‐region  relationship  
is  to  use  the  G.729  codec.  We  should  keep  in  mind  however,  that  for  this  specific  call  flow  across  the  
H.323  ICT,  the  “HQ_REG”  (HQ  Phones)  is  communicating  with  the  “SB_H323_ICT_REG”  (H.323  ICT).    
 

 
 
Next,  we  must  assign  the  newly  created  Region  to  the  Device  Pool  that  is  assigned  to  the  H.323  ICT.  
Navigate  to  System  !  Device  Pool  and  click  on  the  “SB_H323_ICT_DP”.  Select  the  appropriate  
“Region”  from  the  dropdown  box  and  click  the  Save  button.  
 

 
 

212 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  HQ  CUCM  cluster,  HQ  phones  are  now  configured  to  use  the  G.729  codec  across  the  H.323  ICT.  
We  must  configure  the  same  settings  on  the  SB  CUCM  cluster  as  well  to  complete  the  configuration.  
 

 
 

 
 
This  means  that  the  “SB_REG”  (SB  Phones)  is  communicating  with  the  “HQ_H323_ICT_REG”  (H.323  ICT)  
using  the  G.729  codec.  
 
This  can  be  verified  on  the  7965  by  double-­‐clicking  the  “?”  button  on  the  phone.    
 

 
 

213 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  9971,  navigate  to  Settings  Button  !  Administrator  Settings  !  Status  !  Call  Statistics  to  view  
the  codec  in  use.  
 

 
 
   

214 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 13.5 Calls  from  HQ  should  use  a  prefix  of  2  when  calling  SB.  For  example,  to  call  extension  
2001,  HQ  should  dial  22001.  
 
This  task  is  finally  asking  us  to  make  calls  across  the  ICT!  This  means  that  we  need  to  create  a  little  bit  
of  routing  structure  in  order  to  accommodate  the  requested  dial  plan.  It  is  always  a  good  idea  to  
create  a  Route  Group  and  Route  List  as  soon  as  either  a  gateway  or  trunk  is  created  in  the  system.  This  
is  to  help  you  avoid  the  temptation  of  simply  assigning  the  device  directly  to  a  Route  Pattern.  Sure,  this  
is  possible,  but  it  is  a  horrible  idea.    
 
For  example,  let’s  say  that  you  have  a  Route  Pattern  configured  that  has  this  H.323  ICT  directly  
assigned  to  it.  Later  in  the  lab,  you  might  be  asked  to  send  calls  to  the  H.323  ICT  as  the  first  option,  
with  the  second  option  being  the  R1  MGCP  gateway.  For  that  configuration  to  work,  you  must  have  a  
Route  List  with  multiple  options.  However,  since  the  H.323  ICT  is  assigned  directly  to  the  Route  
Pattern,  you  will  not  able  to  add  it  to  a  Route  Group  and  Route  List.  You  must  first  remove  the  ICT  
assignment  on  the  Route  Pattern  in  this  case.  This  can  get  very  messy,  very  fast.  So  please,  always  add  
a  Route  Group  and  Route  List.  
 
To  add  the  Route  Group,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  Group  and  click  the  Add  
New  button.  Enter  a  descriptive  name  for  the  Route  Group  (e.g.  “SB_H323_ICT_RG”).  A  “Distribution  
Algorithm”  can  be  selected  here,  but  it  is  not  necessary  since  there  is  only  one  option  in  the  Route  
Group.    
 

 
 
Next,  select  the  H.323  ICT  from  the  “Available  Devices”  list  and  click  the  Add  to  Route  Group  button.  
 

 
 
Next,  create  a  Route  List  to  contain  the  newly  created  Route  Group  by  navigating  to  Call  Routing  !  
Route/Hunt  !  Route  List  and  clicking  the  Add  New  button.  Enter  a  descriptive  name  for  the  Route  List  
(e.g.  “SB_H323_ICT_RL”)  and  select  a  CUCM  group  on  which  the  Route  List  should  run.  Click  the  Save  
button  when  complete.    
 

215 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Add  Route  Group  button  and  select  the  “SB_H323_ICT_RG”  that  was  previously  created.  Click  
the  Save  button  when  complete.  
 

 
 
At  this  point,  the  Route  List/Route  Group  structure  has  been  created,  so  the  Route  Pattern  can  now  be  
configured.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  
Enter  the  “Route  Pattern”  to  accommodate  the  task  requirements  of  5-­‐digit  dialing  (prefix  of  “2”).  In  
this  case,  “2.2XXX”  is  the  pattern  that  was  entered.  Select  a  “Partition”  to  be  assigned  to  the  Route  
Pattern  as  well.  I  prefer  to  create  a  separate  Partition  for  different  points  of  egress  in  the  system.  In  
this  case,  the  selected  Partition  was  “SB_H323_ICT_PT”.  Obviously,  this  Partition  should  exist  in  the  CSS  
of  all  devices  that  should  have  access.    
 

 
 
Next,  select  the  “Gateway/Route  List”  to  be  used  to  route  the  call  to  the  destination.  In  this  case,  the  
“SB_H323_ICT_RL”  that  was  just  created  should  be  used.  
 

 
 
Lastly,  we  need  to  strip  the  leading  “2”  from  the  dialed  number  in  order  to  send  only  4  digits  across  the  
trunk.  This  is  done  by  setting  the  “Discard  Digits”  parameter  to  “PreDot”  to  strip  every  digit  preceding  
the  “dot”  character  in  the  “Route  Pattern”  field.  
 

 
 
At  this  point,  calls  from  HQ  phones  to  SB  phones  should  be  possible.  The  next  task  will  configure  calls  in  
the  reverse  direction.    
 
   

216 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 13.6 Calls  from  SB  should  not  use  any  prefix  when  calling  HQ;  4-­‐digit  dial  is  expected.  
 
The  same  configuration  that  was  done  on  the  HQ  CUCM  cluster  should  be  repeated  on  the  SB  CUCM  
cluster.  We  must  create  a  Route  Group,  Route  List,  and  Route  Pattern  to  successfully  configure  call  
routing  to  the  HQ  cluster.  
 

 
 

 
 

 
 
At  this  point,  calls  should  be  possible  in  both  directions.    

217 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 14: SIP Trunk Configuration


Task 14.1 Create  a  SIP  ICT  to  support  calling  between  the  HQ  CUCM  Cluster  and  the  SB  CUCM  
Cluster.  
 
The  previous  lab  focused  on  creating  an  H.323  ICT  between  clusters.  This  task  is  now  asking  us  to  
configure  an  Intercluster  Trunk  between  HQ  and  SB  using  another  protocol,  SIP.  Once  again,  both  the  
HQ  and  SB  CUCM  clusters  must  be  configured.    
 
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  
Type”  as  “SIP  Trunk”  and  “Device  Protocol”  as  “SIP”  from  the  dropdown  boxes  and  click  the  Next  
button.    
 

 
 
Enter  a  descriptive  “Device  Name”  for  the  trunk  (e.g.  “SB_SIP_ICT_TRUNK”)  and  select  an  appropriate  
“Device  Pool”  from  the  dropdown  box  (e.g.  “SB_SIP_ICT_DP”).  You  may  want  to  create  a  Device  Pool  
specifically  for  use  with  this  trunk  for  maximum  flexibility.  
 

 
 
Next,  under  the  “Inbound  Calls”  section,  ensure  that  an  appropriate  “Calling  Search  Space”  is  selected  
(e.g.  “GW_TRUNK_CSS”).  The  CSS  must  have  access  to  the  Partition  that  is  assigned  to  the  internal  DNs  
in  the  system.  It  is  recommended  to  leave  the  “Significant  Digits”  field  at  the  default  setting  of  “All”  to  
support  future  call  routing  scenarios.  
 

 
 
Next,  under  the  “SIP  Information”  section,  ensure  that  the  “Destination  Address”  (10.10.23.11)  and  
“Destination  Port”  (5060)  are  entered  for  the  remote  cluster  (SB).  Also,  ensure  that  the  “SIP  Trunk  

218 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Security  Profile”  and  “SIP  Profile”  are  using  the  system  defaults  of  “Non  Secure  SIP  Trunk  Profile”  and  
“Standard  SIP  Profile”.    
 

 
 
Next,  perform  the  above  steps  on  the  SB  CUCM  cluster  as  well.  
 

 
 

 
 

 
 
Remember  to  Save  and  Reset  the  trunk  when  the  configuration  is  completed.  
 

219 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 14.2 Ensure  that  both  the  calling  name  and  calling  number  are  passed  from  the  HQ  
cluster  to  the  SB  cluster.  Calls  from  SB  to  HQ  should  restrict  this  information.  
 
As  you  recall  from  the  previous  lab,  we  were  tasked  with  restricting  the  calling  name  display  from  the  
HQ  CUCM  cluster  to  the  SB  CUCM  cluster  over  the  H.323  ICT.  This  time,  we  must  restrict  the  calling  
name  and  number  display  for  calls  from  SB  to  HQ  and  allow  the  calling  name  to  traverse  the  newly  
created  SIP  ICT  for  all  HQ  to  SB  calls.  
 
This  configuration  should  be  performed  within  the  “Trunk  Configuration”  page  on  each  cluster  for  the  
SIP  ICT.  For  the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  the  “SB_SIP_ICT_TRUNK”.  
Under  the  “Outbound  Calls”  section,  ensure  that  the  “Calling  Line  ID  Presentation”  and  “Calling  Name  
Presentation”  parameters  are  set  to  use  the  “Default”  option.  Alternatively,  you  could  set  this  value  to  
“Allowed”  if  you  are  unsure  what  the  default  setting  entails.    
 

 
 
On  the  SB  CUCM  cluster  under  the  “Outbound  Calls”  section  of  the  “HQ_SIP_ICT_TRUNK”,  we  must  
ensure  that  the  “Calling  Line  ID  Presentation”  and  “Calling  Name  Presentation”  is  set  to  a  value  of  
“Restricted”.  This  will  ensure  that  the  calling  name  and  number  are  not  sent  across  the  SIP  ICT  from  SB  
to  HQ.  
 

 
 
   

220 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

When  all  tasks  in  the  lab  are  complete,  make  a  call  from  an  HQ  phone  to  a  SB  phone.  The  display  on  
the  SB  phone  should  reflect  that  of  the  screenshot  below  (Calling  Name/Number  Displayed).  
 

 
 
When  SB  phones  call  HQ  phones,  the  display  on  the  HQ  phone  should  reflect  the  screenshot  below  
(Calling  Name/Number  Restricted).  
 

 
 
   

221 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 14.3 Assure  that  the  trunk  on  the  HQ  CUCM  cluster  will  not  fail  if  one  of  the  subscribers  is  
unavailable.  
 
To  ensure  that  the  SIP  ICT  does  not  fail  if  one  if  the  subscribers  is  unavailable,  we  must  configure  a  
couple  settings,  one  on  each  cluster.  On  the  HQ  CUCM  cluster,  we  must  ensure  that  the  CUCM  group  
assigned  to  the  Device  Pool  associated  with  the  trunk  is  configured  for  redundancy.  If  there  is  only  one  
server  in  the  group,  and  that  server  fails,  the  other  server  will  not  be  utilized  in  that  case.    
 
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  the  Find  button.  In  the  list,  locate  the  
“SB_SIP_ICT_TRUNK”  and  click  on  the  “Device  Pool”  associated  with  that  trunk  (e.g.  “SB_SIP_ICT_DP”).    
 

 
 
On  the  “Device  Pool”  configuration  page,  locate  the  “Cisco  Unified  Communications  Manager  Group”  
setting  and  take  note  of  it  (e.g.  “SUB_PUB_CMG”).  Now  navigate  to  System  !  Cisco  Unified  CM  Group  
and  locate  the  “SUB_PUB_CMG”.  Click  on  it  to  view  the  details.  Ensure  that  both  available  servers  are  
selected  as  options.  This  will  ensure  that  redundancy  is  available  in  the  event  that  one  of  the  servers  
fails.  
 

 
 
Another  option  is  to  navigate  to  Device  !  Trunk  and  click  on  the  “SB_SIP_ICT_TRUNK”.  In  the  “Trunk  
Configuration”  page,  select  the  “Run  On  All  Active  Unified  CM  Nodes”  checkbox.  This  essentially  
accomplishes  the  same  thing  as  adding  all  available  servers  to  the  CUCM  group,  because  it  will  ensure  
that  the  trunk  will  not  become  unavailable  unless  the  entire  CUCM  cluster  crashes.  
 

 
 
   

222 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  next  step  in  ensuring  HQ  redundancy  actually  happens  on  the  SB  CUCM  cluster.  We  must  add  the  
publisher  server  to  the  list  of  server  connections  on  the  “HQ_SIP_ICT_TRUNK”.  Once  again,  navigate  to  
Device  !  Trunk  and  select  the  ICT.  Scroll  down  to  the  “SIP  Information”  section  and  add  the  other  HQ  
CUCM  server  IP  address  and  port  to  the  list  (e.g.  10.10.13.11,  5060).  
 

 
 
   

223 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 14.4 Calls  between  clusters  should  use  the  iLBC  codec  over  the  SIP  trunk.  
 
This  task  is  asking  us  to  configure  iLBC  as  the  audio  codec  between  clusters  when  using  the  SIP  trunk.  
Once  again,  separate  Device  Pools  (if  you  created  them)  can  come  in  very  handy  here.  Since  the  codec  
selection  process  is  controlled  by  the  Region  settings  in  CUCM,  we  can  simply  create  a  Region  
specifically  for  the  SIP  ICT  on  both  clusters  and  force  an  iLBC  relationship  between  the  phones  on  each  
cluster.    
 
To  begin,  navigate  to  System  !  Region  Information  !  Region  on  the  HQ  CUCM  cluster  and  click  the  
Add  New  button.  Give  the  Region  a  descriptive  name  (e.g.  “SB_SIP_ICT_REG”)  and  click  the  Save  
button.    
 

 
 
In  contrast  to  the  Region  configuration  for  the  H.323  ICT,  a  manually  configured  Region  relationship  is  
necessary  here;  we  cannot  just  use  the  inter-­‐region  default  codec  (G.729).  The  call  flow  dictates  that  
the  “HQ_REG”  (HQ  Phones)  should  have  an  iLBC  inter-­‐region  relationship  with  the  “SB_SIP_ICT_REG”  
(SIP  ICT).    
 

 
 
Next,  we  must  assign  the  newly  created  Region  to  the  Device  Pool  that  is  assigned  to  the  SIP  ICT.  
Navigate  to  System  !  Device  Pool  and  click  on  the  “SB_SIP_ICT_DP”.  Select  the  appropriate  “Region”  
from  the  dropdown  box  and  click  the  Save  button.  
 

 
 
   

224 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  HQ  CUCM  cluster,  HQ  phones  are  now  configured  to  use  the  iLBC  codec  across  the  SIP  ICT.  We  
must  configure  the  same  settings  on  the  SB  CUCM  cluster  as  well  to  complete  the  configuration.  
 

 
 

 
 
This  means  that  the  “SB_REG”  (SB  Phones)  is  communicating  with  the  “HQ_SIP_ICT_REG”  (SIP  ICT)  
using  the  iLBC  codec.  
 
This  can  be  verified  on  the  7965  by  double-­‐clicking  the  “?”  button  on  the  phone.    
 

 
 

225 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  9971,  navigate  to  Settings  Button  !  Administrator  Settings  !  Status  !  Call  Statistics  to  view  
the  codec  in  use.  
 

 
 
   

226 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 14.5 Calls  from  SB  should  use  a  prefix  of  1  when  calling  HQ.  For  example,  to  call  extension  
1001,  HQ  should  dial  11001.  
 
We  have  now  come  the  point  where  we  can  make  calls  across  the  SIP  ICT.  Once  again,  we  must  create  
the  routing  structure  using  Route  Groups  and  Route  Lists  in  order  to  accommodate  the  requested  dial  
plan.  As  stated  in  the  previous  lab,  make  sure  that  you  always  create  a  Route  Group  and  Route  List  as  
soon  as  either  a  gateway  or  trunk  is  created  in  the  system.  This  is  to  help  you  avoid  the  temptation  of  
simply  assigning  the  device  directly  to  a  Route  Pattern.    
 
To  add  a  Route  Group  on  the  SB  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  Group  
and  click  the  Add  New  button.  Enter  a  descriptive  name  for  the  Route  Group  (e.g.  “HQ_SIP_ICT_RG”).  
A  “Distribution  Algorithm”  can  be  selected  here,  but  it  is  not  necessary  since  there  is  only  one  option  in  
the  Route  Group.    
 

 
 
Next,  select  the  SIP  ICT  from  the  “Available  Devices”  list  and  click  the  Add  to  Route  Group  button.  
 

 
 
Next,  create  a  Route  List  to  contain  the  newly  created  Route  Group  by  navigating  to  Call  Routing  !  
Route/Hunt  !  Route  List  and  clicking  the  Add  New  button.  Enter  a  descriptive  name  for  the  Route  List  
(e.g.  “HQ_SIP_ICT_RL”)  and  select  a  CUCM  group  on  which  the  Route  List  should  run.  Click  the  Save  
button  when  complete.    
 

 
 
   

227 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Add  Route  Group  button  and  select  the  “HQ_SIP_ICT_RG”  that  was  previously  created.  Click  
the  Save  button  when  complete.  
 

 
 
At  this  point,  the  Route  List/Route  Group  structure  has  been  created,  so  the  Route  Pattern  can  now  be  
configured.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  
Enter  the  “Route  Pattern”  to  accommodate  the  task  requirements  of  5-­‐digit  dialing  to  HQ  (prefix  of  
“1”).  In  this  case,  “1.1XXX”  is  the  pattern  that  was  entered.  Select  a  “Partition”  to  be  assigned  to  the  
Route  Pattern  as  well.  I  prefer  to  create  a  separate  Partition  for  different  points  of  egress  in  the  
system.  In  this  case,  the  selected  Partition  was  “HQ_SIP_ICT_PT”.  Obviously,  this  Partition  should  exist  
in  the  CSS  of  all  devices  that  should  have  access.    
 

 
 
Next,  select  the  “Gateway/Route  List”  to  be  used  to  route  the  call  to  the  destination.  In  this  case,  the  
“HQ_SIP_ICT_RL”  that  was  just  created  should  be  used.  
 

 
 
Lastly,  we  need  to  strip  the  leading  “1”  from  the  dialed  number  in  order  to  send  only  4  digits  across  the  
trunk.  This  is  done  by  setting  the  “Discard  Digits”  parameter  to  “PreDot”  to  strip  every  digit  preceding  
the  “dot”  character  in  the  “Route  Pattern”  field.  
 

 
 
At  this  point,  calls  from  SB  phones  to  HQ  phones  should  be  possible.  The  next  task  will  configure  calls  in  
the  reverse  direction.    
 
   

228 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 14.6 Calls  from  HQ  should  not  use  any  prefix  when  calling  SB;  4-­‐digit  dial  is  expected.  
 
Just  as  was  done  in  the  previous  task,  we  must  create  a  Route  Group,  Route  List,  and  Route  Pattern  to  
accomplish  this  task.  Configure  the  HQ  cluster  as  seen  in  the  screenshots  below.  
 

 
 

 
 

 
 
Calls  from  the  HQ  to  SB  CUCM  cluster  should  now  be  routed  successfully.  
 
   

229 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 14.7 Assure  that  the  SIP  communication  happens  on  port  5088.  
 
In  order  to  change  the  default  port  on  which  the  SIP  protocol  operates,  we  must  make  a  change  in  
both  the  inbound  and  outbound  directions  of  the  SIP  trunk.    
 
To  ensure  that  both  SIP  trunks  accept  connections  on  port  5088,  we  must  change  the  default  port  in  
the  “SIP  Trunk  Security  Profile”  on  both  the  HQ  and  SB  CUCM  clusters.  Without  making  a  change  here,  
the  SIP  trunk  will  only  be  prepared  to  receive  signaling  traffic  on  port  5060,  since  it  is  the  default  port.  
Navigate  to  System  !  Security  !  SIP  Trunk  Security  Profile  and  click  the  Find  button.  Locate  the  “Non  
Secure  SIP  Trunk  Profile”  and  click  it  to  make  changes.  
 

 
 
Immediately  click  the  Copy  button  to  create  a  profile  based  on  the  “Non  Secure  SIP  Trunk  Profile”  so  as  
to  not  make  modifications  to  the  default  profile.  Changing  settings  on  the  default  profile  may  cause  
unintended  effects  on  other  trunks  in  the  system!  To  help  in  remembering  the  purpose  of  the  profile,  
make  sure  to  name  the  profile  appropriately  (e.g.  “Non  Secure  SIP  Trunk  Profile  -­‐  SB_SIP_ICT”).  Change  
the  “Incoming  Port”  setting  from  “5060”  to  “5088”  and  click  the  Save  button.  
 

 
 
Now  that  the  profile  is  created,  we  can  assign  it  to  the  “SB_SIP_ICT_TRUNK”.  Navigate  to  Device  !  
Trunk  and  click  on  the  SIP  ICT.  Under  the  “SIP  Information”  section,  select  the  “Non  Secure  SIP  Trunk  
Profile  -­‐  SB_SIP_ICT”  from  the  “SIP  Trunk  Security  Profile”  dropdown  box.  This  will  assign  the  newly  
created  profile  to  the  trunk.  
 
   

230 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  to  modify  the  outbound  setting  to  use  port  5088,  we  must  simply  change  the  port  from  “5060”  to  
“5088”  in  the  “Destination”  section  of  the  SIP  trunk.  This  will  ensure  that  all  SIP  requests  that  are  
initiated  from  this  trunk  will  use  port  5088.  
 

 
 
Remember  to  make  the  above  modifications  on  the  SB  CUCM  cluster  as  well  and  make  test  calls  
between  the  clusters  to  verify.    

231 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 15: Cisco Unified Border Element (CUBE) Configuration


Task 15.1 Create  a  SIP  trunk  on  both  the  HQ  CUCM  and  SB  CUCM  to  connect  to  the  CUBE,  
which  should  be  configured  on  R1.  
 
Cisco  Unified  Border  Element  (CUBE)  is  network  border  element  that  can  terminate  and  originate  
signaling  (H.323  and  SIP)  and  media  streams  (RTP  and  RTCP).  
 
Session  Border  controller  (SBC)  was  used  by  service  providers  (SP)  to  enable  full  billing  capabilities  
within  VoIP  networks.  CUBE  provides  the  extended  functionality  of  interconnecting  VoIP  networks,  
especially  on  the  enterprise  side.  
 
CUBE  functionality  is  implemented  on  devices  using  a  special  IOS  feature  set,  which  allows  CUBE  to  
route  a  call  from  one  VoIP  dial  peer  to  another.  As  VoIP  dial  peers  can  be  handled  by  either  SIP  or  
H.323,  CUBE  can  be  used  to  interconnect  VoIP  networks  of  different  signaling  protocols.  VoIP  
internetworking  is  achieved  by  connecting  an  inbound  dial  peer  with  an  outbound  dial  peer.  A  standard  
Cisco  IOS  gateway  without  CUBE  functionality  cannot  allow  VoIP-­‐to-­‐VoIP  connections.  
 
Protocol  internetworking  is  possible  for  the  following  combinations:  
 
• H.323-­‐to-­‐SIP  internetworking  
• H.323-­‐to-­‐H.323  internetworking  
• SIP-­‐to-­‐SIP  internetworking  
 
CUBE  is  used  by  enterprise  and  small  and  medium-­‐sized  organizations  to  interconnect  SIP  PSTN  access  
with  SIP  and  H.323  enterprise  unified  communications  networks.  
 
A  CUBE  interoperates  with  several  different  network  elements  including  voice  gateways,  IP  phones,  
and  call-­‐control  servers  in  many  different  application  environments,  from  advanced  enterprise  voice  
and/or  video  services  with  Cisco  Unified  Communications  Manager  or  Cisco  Unified  Communications  
Manager  Express,  as  well  as  simpler  toll  bypass  and  voice  over  IP  (VoIP)  transport  applications.  The  
CUBE  provides  organizations  with  all  the  border  controller  functions  integrated  into  the  network  layer  
to  interconnect  unified  communications  voice  and  video  enterprise-­‐to-­‐service-­‐provider  architectures.  
[Source:      
http://www.cisco.com/c/en/us/td/docs/ios-­‐xml/ios/voice/cube_fund/configuration/15-­‐mt/cube-­‐fund-­‐
15-­‐mt-­‐book/voi-­‐cube-­‐overview.html]    
 
This  task  is  asking  us  to  create  a  SIP  trunk  on  both  the  HQ  and  SB  CUCM  clusters  to  connect  to  the  Cisco  
Unified  Border  Element  (CUBE).  As  the  task  dictates,  however,  we  must  configure  CUBE  on  R1  as  our  
first  step.    
 
To  begin  the  configuration  of  R1,  we  must  dictate  that  the  router  be  used  as  a  CUBE.  This  can  be  
accomplished  by  using  the  mode border-element  command  under  the  global  VoIP  configuration  
(voice service voip)  on  the  router.  This  command  provides  access  to  the  different  media  

232 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

commands  available  in  the  router.  Review  the  command  reference  at  
http://www.cisco.com/c/en/us/td/docs/ios/voice/command/reference/vr_book/vr_m3.html-­‐
wp1396382  for  more  information.  Notice  that  it  is  necessary  to  reload  the  router  in  order  to  have  the  
configuration  take  effect.    
 
R1  
R1(config)#voice service voip
R1(conf-voi-serv)#mode border-element

You need to save and reload the router for this configuration change to be effective.
 
Next,  we  must  bind  an  interface  to  the  global  SIP  process  under  voice service voip  (where  the  
CUCM  servers  will  connect)  in  order  to  allow  R1  to  accept  SIP  connections  on  a  specific  interface.  This  
is  the  same  process  that  was  done  for  registering  SIP  phones  and  connecting  SIP  gateways  to  CUCM.  Of  
course,  we  must  select  an  interface  for  this  configuration.  Since  there  is  none  specified  in  the  task,  
select  any  interface  that  makes  sense.  In  this  case,  the  GigabitEthernet0/0.11  interface  was  selected.  
 
R1  
R1(config)#voice service voip
R1(conf-voi-serv)#sip
R1(conf-serv-sip)#bind control source-interface GigabitEthernet0/0.11
R1(conf-serv-sip)#bind media source-interface GigabitEthernet0/0.11

After  the  configuration  is  completed  in  IOS  on  R1,  begin  the  configuration  on  the  CUCM  clusters.  On  
the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  
Type”  as  “SIP  Trunk”,  “Device  Protocol”  as  “SIP”,  and  the  “Trunk  Service  Type”  as  “None(Default)”  and  
click  the  Next  button.    
 

 
 
Next,  enter  a  descriptive  “Device  Name”  for  the  SIP  trunk  that  should  be  configured  to  CUBE  (e.g.  
“CUBE_SIP_TRUNK”).  As  always,  a  specific  “Device  Pool”  is  suggested  here  for  maximum  configuration  
flexibility  (e.g.  “CUBE_SIP_DP”).    
 

 
 
Next,  under  the  “Inbound  Calls”  section,  ensure  that  a  “Calling  Search  Space”  is  configured  so  inbound  
calls  can  be  routed  to  the  cluster.  Typically,  this  would  be  a  CSS  that  allows  access  to  Partitions  that  are  
assigned  to  internal  DNs  in  the  system  (e.g.  “GW_TRUNK_CSS”).  

233 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  under  the  “SIP  Information”  section,  the  “Destination  Address”  must  be  defined.  This  will  be  the  
IP  address  corresponding  to  the  interface  that  was  used  for  the  bind  configuration  on  R1  (Gi0/0.11).  
Also,  we  can  select  the  system  default  “SIP  Trunk  Security  Profile”  and  “SIP  Profile”  from  the  dropdown  
boxes  to  complete  the  configuration.  
 

 
 
Click  the  Save  and  Reset  buttons  when  complete.  Make  sure  to  duplicate  the  above  configuration  on  
the  SB  CUCM  cluster  as  well.  
 
   

234 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.2 Assure  that  if  the  subscriber  goes  down,  the  publisher  will  take  over  call  processing  
duties  on  the  HQ  cluster.  
 
Of  course,  we  know  by  this  point  that  server  selection  in  CUCM  is  controlled  by  the  CUCM  group,  which  
is  assigned  to  the  Device  Pool  of  the  associated  device.  In  this  case,  the  devices  in  each  CUCM  cluster  
are  SIP  trunks.  Therefore,  we  must  make  sure  that  the  Device  Pool  assigned  to  each  SIP  trunk  has  a  
CUCM  group  that  contains  both  the  subscriber  and  the  publisher  servers,  in  that  order.    
 
To  confirm,  navigate  to  Device  !  Trunk  and  click  the  Find  button.  Locate  the  SIP  trunk  that  was  
created  in  the  previous  task  (e.g.  “CUBE_SIP_TRUNK”)  and  click  on  the  “Device  Pool”  listed  on  that  
page  (e.g.  “CUBE_SIP_DP”).  
 

 
 
Take  note  of  the  CUCM  Group  that  is  selected  within  the  “Device  Pool  Configuration”  page  (e.g.  
“SUB_PUB_CMG”).    
 

 
 
Navigate  to  System  !  Cisco  Unified  CM  Group  and  click  the  Find  button.  Click  on  the  “SUB_PUB_CMG”  
to  view  the  details  of  the  configuration.  In  this  case,  we  can  see  that  the  configuration  is  correct.  The  
subscriber  (10.10.13.12)  is  listed  as  the  first  option  where  the  publisher  (10.10.13.11)  is  listed  as  the  
second  option.    
 

 
 
This  configuration  ensures  that  the  publisher  server  will  take  over  when  the  subscriber  server  fails.  
Later  in  this  lab,  we  will  reinforce  this  redundancy  when  configuring  dial-peers  on  CUBE.  
 

235 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.3 Assure  that  all  control  and  media  packets  sent  from  CUBE  to  the  HQ  and  SB  CUCM  
uses  the  voice  interface  (Gi0/0.11)  on  R1.  
 
This  task  is  asking  us  to  configure  the  bind  command  under  the  sip  configuration  of  voice
service voip  on  R1.  This  configuration  was  already  completed  during  the  first  task,  when  we  had  
the  freedom  to  select  any  R1  interface  for  SIP  control  and  media  traffic.  If  you  happened  to  use  the  
GigabitEthernet0/0.11  interface  for  your  configuration  in  that  task,  good  for  you!  You  will  not  have  to  
change  the  binding  that  was  previously  configured.  If  you  did,  however,  set  the  bind  commands  to  
use  a  different  interface,  make  sure  that  the  change  is  made  at  this  point  to  use  the  proper  interface.  
 
R1  
R1(config)#voice service voip
R1(conf-voi-serv)#sip
R1(conf-serv-sip)#bind control source-interface GigabitEthernet0/0.11
R1(conf-serv-sip)#bind media source-interface GigabitEthernet0/0.11

Make  sure  to  change  the  “Destination  Address”  in  the  “CUBE_SIP_TRUNK”  on  both  CUCM  clusters  if  
you  made  a  change  to  R1  during  the  configuration  of  this  task!  
 

 
 
   

236 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.4 R1  should  allow  inter-­‐communication  between  SIP  streams,  H.323  streams,  and  
between  both  protocols.  
 
In  order  to  ensure  that  the  CUBE  allows  all  signal  interworking,  we  need  to  enter  the  voice
service voip  configuration  and  use  the  allow-connections  commands  to  explicitly  allow  this  
type  of  communication.  The  allow-connections  command  can  support  four  different  types  of  
communication:  SIP  to  SIP,  SIP  to  H.323,  H.323  to  SIP,  and  H.323  to  H.323.  This  will  ensure  that  the  
router  will  not  deny  VoIP  calls  between  or  within  protocols.    
 
R3  
R1(config)#voice service voip
R1(conf-voi-serv)#allow-connections h323 to h323
R1(conf-voi-serv)#allow-connections h323 to sip
R1(conf-voi-serv)#allow-connections sip to h323
R1(conf-voi-serv)#allow-connections sip to sip
 
As  mentioned  in  previous  labs,  it  is  important  to  copy/paste  these  configuration  commands  on  each  
router,  unless  explicitly  disallowed  in  the  lab.  
 
   

237 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.5 When  a  user  on  the  HQ  cluster  calls  a  user  on  the  SB  cluster,  the  user  should  first  
dial  a  5,  followed  by  the  4  digit  extension  (e.g.  52002).    
 
Now  that  the  communication  between  both  CUCM  clusters  and  the  CUBE  (R1)  has  been  configured,  we  
should  create  Route  Groups/Route  Lists  to  contain  the  previously  created  trunks  on  both  clusters.  
Route  patterns  can  then  be  created  to  accomplish  the  task  requirements.  
 
To  add  a  Route  Group  on  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  
Group  and  click  the  Add  New  button.  Enter  a  descriptive  name  for  the  Route  Group  (e.g.  
“CUBE_SIP_RG”).  A  “Distribution  Algorithm”  can  be  selected  here,  but  it  is  not  necessary  since  there  is  
only  one  option  in  the  Route  Group.    
 

 
 
Next,  select  the  CUBE  SIP  Trunk  from  the  “Available  Devices”  list  and  click  the  Add  to  Route  Group  
button.  
 

 
 
Next,  create  a  Route  List  to  contain  the  newly  created  Route  Group  by  navigating  to  Call  Routing  !  
Route/Hunt  !  Route  List  and  clicking  the  Add  New  button.  Enter  a  descriptive  name  for  the  Route  List  
(e.g.  “CUBE_SIP_RL”)  and  select  a  CUCM  group  on  which  the  Route  List  should  run.  Click  the  Save  
button  when  complete.    
 

 
 
   

238 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Add  Route  Group  button  and  select  the  “CUBE_SIP_RG”  that  was  previously  created.  Click  the  
Save  button  when  complete.  
 

 
 
At  this  point,  the  Route  List/Route  Group  structure  has  been  created,  so  the  Route  Pattern  can  now  be  
configured.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  
Enter  the  “Route  Pattern”  to  accommodate  the  task  requirements  of  5-­‐digit  dialing  to  SB  (prefix  of  
“5”).  In  this  case,  “52XXX”  is  the  pattern  that  was  entered.  Select  a  “Partition”  to  be  assigned  to  the  
Route  Pattern  as  well.  I  prefer  to  create  a  separate  Partition  for  different  points  of  egress  in  the  
system.  In  this  case,  the  selected  Partition  was  “CUBE_SIP_PT”.  Obviously,  this  Partition  should  exist  in  
the  CSS  of  all  devices  that  should  have  access.    
 

 
 
Next,  select  the  “Gateway/Route  List”  to  be  used  to  route  the  call  to  the  destination.  In  this  case,  the  
“CUBE_SIP_RL”  that  was  just  created  should  be  used.  
 

 
 
In  this  example,  I  have  not  added  any  digit  stripping  to  the  Route  Pattern.  This  means  that  it  must  be  
done  on  either  the  CUBE  or  on  the  SB  CUCM  cluster  as  the  call  is  routed  inbound.    
 
The  next  step  is  to  configure  dial-peers  on  R1  to  accept  the  calls  inbound  and  forward  the  calls  
outbound.  As  mentioned  in  previous  labs,  the  standard  inbound  dial-peer  selection  process  is  used  
to  determine  what  dial-peer  will  be  used—whether  it  is  a  manually  configured  dial-peer  or  
default  dial-peer 0.  
 
The  following  rules  apply  to  inbound  dial-peer selection  in  both  POTS  and  VoIP  dial-peers.  
 
1. Called  number  matching  using  the  DNIS  is  performed,  based  on  the  most  explicit  match.  The  
incoming called-number  command  is  used.  
2. If  there  is  no  match,  calling  number  matching  using  the  ANI  is  performed,  based  on  the  most  
explicit  match.  The  answer-address  command  is  used.  

239 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

3. If  there  is  still  no  match,  calling  number  matching  using  the  ANI  is  performed,  based  on  the  
most  explicit  match.  The  destination-pattern  command  is  used.    
4. If  no  match  exists,  the  dial-peer  port  it  is  associated  with  is  used  (POTS  dial-peers  
only).  The  port  command  is  used.  If  multiple  dial-peers  have  the  same  port,  the  dial-
peer  added  to  the  configuration  first  breaks  the  tie.  
5. If  nothing  matches,  default  dial-peer 0  is  used.    
 
In  this  case,  the  inbound  dial-peer  peer  match  is  being  explicitly  defined  on  the  R1  router  within  
dial-peer voice 2000 voip.  The  incoming called-number  command  (rule  1  from  
above)  is  being  used  to  match  the  dial-peer  as  it  is  routed  into  the  CUBE.  Note  that  the  “$”  
character  within  the  incoming called-number  command  is  used  to  specify  the  end  of  the  dialed  
string.  At  this  time,  the  only  additional  setting  that  has  been  defined  is  to  disable  VAD.    
 
R1  
R1(config)#dial-peer voice 2000 voip
R1(config-dial-peer)#incoming called-number 52...$
R1(config-dial-peer)#no vad

Next,  we  must  define  the  outbound  dial-peer  on  R1.  For  calls  to  52XXX,  the  destination  will  be  the  
SB  CUCM  cluster.  This  is  configured  by  entering  the  destination-pattern  command  under  the  
dial-peer.  Once  again,  the  “$”  character  is  used  to  mark  the  end  of  the  dialed  string.  Next,  we  must  
define  a  protocol  and  target  to  use  when  routing  the  call.  Using  the  session protocol  and  
session target  commands  successfully  accomplishes  the  requirement.  Finally,  VAD  has  been  
disabled  here  as  well.  
 
R1  
R1(config)#dial-peer voice 52001 voip
R1(config-dial-peer)#destination-pattern 52...$
R1(config-dial-peer)#session protocol sipv2
R1(config-dial-peer)#session target ipv4:10.10.23.11
R1(config-dial-peer)#no vad

Take  note  that  we  could  have  used  a  single  dial-peer  for  both  inbound  and  outbound  call  legs  in  
this  case.  We  could  have  simply  added  the  incoming called-number  command  under  dial-
peer voice 52001 voip.  Both  inbound  and  outbound  calls  would  use  the  same  dial-peer  
when  calling  SB  from  any  other  location.  Also,  please  remember  that  G.729  is  the  default  codec  used  
on  all  VoIP  dial-­‐peers,  so  unless  we  modify  it  using  the  codec  command,  that  is  the  codec  that  will  be  
used  to  communicate  with  SB  phones.  
 
After  configuring  CUBE,  the  next  step  is  to  ensure  that  the  SB  CUCM  cluster  is  able  to  route  the  call  
inbound.  Based  on  the  configuration  that  was  already  done,  it  looks  like  the  SB  cluster  will  be  receiving  
a  5-­‐digit  number  instead  of  the  4-­‐digit  number  associated  with  the  configured  DNs.  This  means  that  
we’ll  need  to  perform  some  digit  manipulation  on  the  SB  CUCM  cluster  when  the  call  is  received.    
 
As  you  may  recall  from  the  gateway  configuration  section,  we  have  the  ability  to  use  the  “Significant  
Digits”  field  under  the  “Inbound  Calls”  section  on  the  “CUBE_SIP_TRUNK”.  If  we  navigate  to  Device  !  
Trunk  and  click  the  “CUBE_SIP_TRUNK”,  we  can  set  the  “Significant  Digits”  field  to  “4”.  

240 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Remember  to  click  the  Save  and  Reset  buttons  when  complete.    
 
After  the  above  is  configured,  we  are  ready  to  make  a  test  call  between  the  HQ  and  SB  phones  and  
observe  the  behavior.  You  will  find  that  the  call  will  ring  successfully,  but  will  fail  with  a  fast  busy  tone  
upon  answering!  Why,  you  ask?  We  can  check  the  debug ccsip messages  output  to  see  what  
happens.  First,  let’s  once  again  examine  the  two  major  types  of  SIP  calls  and  understand  the  call  flow.    
 
Delayed  Offer  (DO)  SIP  Calls  (No  SDP  in  INVITE)  
 

 
   

241 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Early  Offer  (EO)  SIP  Calls  (SDP  in  INVITE)  

 
 
The  example  call  that  we’re  going  to  see  in  the  below  debug  output  is  a  DO  call,  which  will  turn  out  to  
be  a  major  contributing  factor  in  its  failure.  In  the  below  call  from  HQ  to  SB  through  the  CUBE,  the  SB  
CUCM  cluster  responds  with  a  “200  OK”  message  containing  an  SDP  that  looks  like  the  following:  
 
R1  
R1#debug ccsip messages
SIP Call messages tracing is enabled

Received:
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 232

v=0
o=CiscoSystemsCCM-SIP 109 1 IN IP4 10.10.23.11

s=SIP Call
c=IN IP4 10.10.21.25
b=TIAS:8000
b=AS:8
t=0 0
m=audio 27070 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

We  can  see  from  the  above  that  G.729  will  be  the  codec,  based  upon  the  a=rtpmap:18  line.  But  
what  flavor  of  G.729  is  it?  This  may  be  a  difficult  thing  to  notice,  but  we  are  missing  the  FMTPs  (format  
specific  parameters)  that  describe  the  codec  in  the  SDP.  We  are  looking  for  an  “a=”  line  that  looks  
something  like  this:  a=fmtp:18 annexb=no.  When  this  “a=”  line  is  present,  it  specifically  refers  to  
the  use  of  the  G.729r8  codec,  which  is  the  same  codec  that  is  configured  by  default  on  an  IOS  dial-
peer.  Since  that  line  is  missing  from  the  above  output,  we  know  that  the  SB  CUCM  cluster  wants  to  
use  the  G.729br8  codec  instead,  since  annexb=yes  is  the  default  value  if  no  “a=”  line  is  present.  This  
causes  a  codec  mismatch  between  G.729r8  (IOS)  and  G.729br8  (CUCM),  which  causes  the  “fast  busy”  
tone  that  was  heard  upon  answering  the  call.    

242 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
We  can  fix  this  issue  a  couple  of  different  ways.  The  first  method  is  to  use  the  configuration  described  
in  a  task  found  later  in  this  lab—the  codec transparent  command.  We  will  work  through  that  
option  later.  For  now,  the  other  way  that  we  can  fix  this  issue  is  to  change  the  type  of  SIP  call  from  DO  
to  EO.  In  this  case,  the  INVITE  message  contains  the  SDP  instead  of  waiting  for  the  remote  end  to  
respond  with  the  SDP.  To  configure,  we  must  enter  the  early offer forced  command  within  
the  global  sip  configuration  under  voice service voip.  This  means  that  CUBE  will  send  an  EO  
to  the  SIP  destination  regardless  of  whether  or  not  the  call  that  it  received  was  a  DO  or  EO  call.    
 
R1  
R1(config)#voice service voip
R1(conf-voi-serv)#sip
R1(conf-serv-sip)#early-offer forced
 
   

243 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Let’s  examine  the  debug  output  again  after  running  the  early-offer forced  command.  
 
R1  
R1#debug ccsip messages
SIP Call messages tracing is enabled

Sent:
INVITE sip:52001@10.10.23.11:5060 SIP/2.0
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264

v=0
o=CiscoSystemsSIP-GW-UserAgent 6784 5602 IN IP4 10.10.11.1
s=SIP Call
c=IN IP4 10.10.11.1
t=0 0
m=audio 16426 RTP/AVP 18 101
c=IN IP4 10.10.11.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Received:
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 252

v=0
o=CiscoSystemsCCM-SIP 87 1 IN IP4 10.10.23.11
s=SIP Call
c=IN IP4 10.10.21.27
b=TIAS:8000
b=AS:8
t=0 0
m=audio 26382 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
 
The  first  line  is  the  EO  INVITE  message  that  is  being  sent  from  the  CUBE  to  the  SB  CUCM  cluster.  As  you  
can  see,  since  the  EO  is  generated  from  the  CUBE  (IOS  dial-peer),  the  G.729r8  codec  is  used  
(a=fmtp:18 annexb=no).  This  time,  we  can  see  that  the  “200  OK”  response  that  is  received  from  
the  SB  CUCM  cluster  contains  the  FMTP  we  were  looking  for—a=fmtp:18 annexb=no.  This  means  
that  the  G.729r8  codec  was  successfully  negotiated  between  the  HQ  and  SB  CUCM  clusters  through  
CUBE  with  the  assistance  of  the  early-offer forced  command.  
 
   

244 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

HQ  users  now  have  the  ability  to  call  SB  users  through  the  CUBE  on  R1.  You  may  run  the  show call
active voice command  on  R1  to  show  details  about  the  call.  
 
R1  
R1#sh call active voice br
...
0 : 19 1207311040ms.1 (18:27:31.533 PDT Mon Oct 20 2014) +2360 pid:2000 Answer 1001 active
dur 00:01:09 tx:3448/68960 rx:3449/68980 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 10.10.11.14:20116 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 TextRelay: off
Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a

0 : 20 1207311050ms.1 (18:27:31.543 PDT Mon Oct 20 2014) +2340 pid:52001 Originate 52001 active
dur 00:01:09 tx:3449/68980 rx:3448/68960 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 10.10.21.27:17552 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 TextRelay: off
Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a

Telephony call-legs: 0
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
 
   

245 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.6 When  a  user  on  the  SB  cluster  calls  a  user  on  the  HQ  cluster,  the  user  should  first  
dial  a  5,  followed  by  the  4  digit  extension  (e.g.  51002).    
 
For  this  task,  we  need  to  repeat  the  same  configuration  that  was  done  in  the  previous  task.  This  time,  
we  will  be  supporting  calls  from  SB  to  HQ  through  R1.  Just  as  was  done  previously,  we  must  create  a  
Route  Group,  Route  List,  and  Route  Pattern  to  utilize  the  “CUBE_SIP_TRUNK”  on  the  SB  CUCM  cluster.  
When  that  is  complete,  we  must  configure  CUBE  to  support  5-­‐digit  dialing  from  SB  to  HQ  with  dial-
peers.  Finally,  we  need  to  configure  the  HQ  CUCM  cluster  to  route  calls  to  4-­‐digit  DNs  by  setting  the  
“Significant  Digits”  field  to  “4”  under  the  “Inbound  Calls”  section  on  the  “CUBE_SIP_TRUNK”.  
Below  is  the  configuration  on  the  SB  CUCM  cluster.  
 

 
 

 
 

 
 

246 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  IOS  configuration  on  R1,  one  key  difference  is  the  number  of  dial-peers  configured  to  route  
to  the  HQ  CUCM  cluster.  In  this  case,  there  are  two—one  for  each  call-­‐processing  server.  They  are  
created  with  the  same  destination-pattern  and  session protocol,  but  are  using  different  
IP  destination  addresses.  Also,  the  preference  command  is  being  used  to  determine  which  dial-
peer  should  be  used  first  (lowest  wins).  
 
R1  
R1(config)#dial-peer voice 51001 voip
R1(config-dial-peer)#preference 1
R1(config-dial-peer)#destination-pattern 51...$
R1(config-dial-peer)#session protocol sipv2
R1(config-dial-peer)#session target ipv4:10.10.13.12
R1(config-dial-peer)#no vad

R1(config-dial-peer)#dial-peer voice 51002 voip


R1(config-dial-peer)#preference 2
R1(config-dial-peer)#destination-pattern 51...$
R1(config-dial-peer)#session protocol sipv2
R1(config-dial-peer)#session target ipv4:10.10.13.11
R1(config-dial-peer)#no vad

R1(config-dial-peer)#dial-peer voice 1000 voip


R1(config-dial-peer)#incoming called-number 51...$
R1(config-dial-peer)#no vad
 
Below  is  the  configuration  for  the  HQ  CUCM  cluster.  
 

 
 
After  the  above  configuration  is  complete,  SB  users  should  be  able  to  call  HQ  users.  Remember,  this  is  
possible  at  the  moment  due  to  the  use  of  the  early-offer forced  command.  
 
   

247 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.7 CUBE  should  be  configured  so  that  the  endpoints  on  the  HQ  and  SB  clusters  can  
negotiate  the  codec  freely.  Assure  that  the  G.729  codec  is  used  to  communicate  
between  endpoints.  
 
To  begin,  remove  the  early-offer forced  command  that  was  needed  to  complete  calls  between  
clusters  in  the  previous  two  tasks.  
 
R1  
R1(config)#voice service voip
R1(conf-voi-serv)#sip
R1(conf-serv-sip)#no early-offer forced
 
As  stated  earlier,  the  default  codec  being  used  is  G.729r8  due  to  that  fact  that  IOS  is  being  used  for  call  
routing.  G.729  is  actually  the  desired  codec  based  on  the  task  requirements,  so  we’re  done  right?  Well,  
not  exactly.  We  have  not  satisfied  the  task  requirement  that  the  codec  should  be  negotiated  “freely”  
between  the  endpoints.  As  it  stands  right  now,  the  codec  is  being  negotiated  between  the  HQ  CUCM  
and  CUBE  and  between  CUBE  the  SB  CUCM.  In  other  words,  each  CUCM  server  is  negotiating  with  the  
dial-peers  configured  on  CUBE.    
 
To  configure  the  system  to  negotiate  the  codec  freely,  we  must  use  the  codec transparent  
command.  This  command  basically  allows  the  “transparent”  passing  of  codecs  offered  in  the  SDP  
through  the  CUBE  to  the  destination.  The  signaling  communication  for  the  endpoints  still  happens  with  
the  assistance  of  CUBE,  but  without  intervention  when  it  comes  to  codec  negotiation.  In  other  words,  
whatever  CUBE  receives,  it  sends  right  back  out  to  the  destination  without  contributing  to  the  contents  
of  the  message.  We  can  add  the  codec transparent  command  to  a  voice class  to  offer  
greater  flexibility  in  codec  negotiation  as  well,  if  desired.  For  example,  if  transparent  negotiation  of  the  
codec  is  not  possible,  another  codec  could  be  available  for  use  at  that  point.  We  would  then  need  to  
apply  the  voice class  to  both  inbound  and  outbound  dial-peers  on  R1.  
 
R1  
R1(config)#voice class codec 1
R1(config-class)#codec preference 1 transparent

R1(config)#dial-peer voice 51001 voip


R1(config-dial-peer)#voice-class codec 1

R1(config-dial-peer)#dial-peer voice 51002 voip


R1(config-dial-peer)#voice-class codec 1

R1(config-dial-peer)#dial-peer voice 52001 voip


R1(config-dial-peer)#voice-class codec 1

R1(config-dial-peer)#dial-peer voice 1000 voip


R1(config-dial-peer)#voice-class codec 1

R1(config-dial-peer)#dial-peer voice 2000 voip


R1(config-dial-peer)#voice-class codec 1

The  codec  should  still  be  negotiated  as  G.729r8  at  this  point,  but  it  will  now  be  happening  using  the  
codec transparent  command.  Of  course,  Regions  need  to  be  configured  on  CUCM  to  enable  the  
use  of  the  G.729  codec  between  HQ  and  SB  as  well,  which  was  discussed  in  a  previous  lab.  
Let’s  examine  the  debug ccsip messages  output  for  a  “transparent”  call  between  HQ  and  SB.  

248 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
R1  
R1#debug ccsip messages
SIP Call messages tracing is enabled
...

Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4521CB
From: "HQ Phone 1" <sip:1001@10.10.11.1>;tag=49AC5F6C-FA

To: <sip:52001@10.10.23.11>;tag=115~fc58ca36-8b61-4fd9-a79e-d7aa6b8571b0-30886307
...
Content-Type: application/sdp
Content-Length: 232

v=0
o=CiscoSystemsCCM-SIP 115 1 IN IP4 10.10.23.11

s=SIP Call
c=IN IP4 10.10.21.25
b=TIAS:8000
b=AS:8
t=0 0
m=audio 30154 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.13.12:5060;branch=z9hG4bK2f9035d68e44
From: "HQ Phone 1" <sip:1001@10.10.13.12>;tag=38056~50386a8c-f53c-499c-b7b5-9b86cf06aed7-33683429
To: <sip:52001@10.10.11.1>;tag=49AC5F88-1B07
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 209

v=0
o=CiscoSystemsSIP-GW-UserAgent 8687 7166 IN IP4 10.10.11.1
s=SIP Call
c=IN IP4 10.10.11.1
t=0 0
m=audio 16442 RTP/AVP 18
c=IN IP4 10.10.11.1
a=rtpmap:18 G729/8000

a=fmtp:18 annexb=yes
a=ptime:20

Received:
ACK sip:52001@10.10.11.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.13.12:5060;branch=z9hG4bK2f91731a23e0
From: "HQ Phone 1" <sip:1001@10.10.13.12>;tag=38056~50386a8c-f53c-499c-b7b5-9b86cf06aed7-33683429
To: <sip:52001@10.10.11.1>;tag=49AC5F88-1B07
...
Content-Type: application/sdp
Content-Length: 199

v=0
o=CiscoSystemsCCM-SIP 38056 1 IN IP4 10.10.13.12
s=SIP Call
c=IN IP4 10.10.11.13

b=TIAS:8000
b=AS:8
t=0 0

249 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

m=audio 26760 RTP/AVP 18


a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no

Sent:
ACK sip:52001@10.10.23.11:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK461E1F
From: "HQ Phone 1" <sip:1001@10.10.11.1>;tag=49AC5F6C-FA
To: <sip:52001@10.10.23.11>;tag=115~fc58ca36-8b61-4fd9-a79e-d7aa6b8571b0-30886307
...
Content-Type: application/sdp
Content-Length: 208

v=0
o=CiscoSystemsSIP-GW-UserAgent 2656 9523 IN IP4 10.10.11.1
s=SIP Call
c=IN IP4 10.10.11.1
t=0 0
m=audio 16444 RTP/AVP 18
c=IN IP4 10.10.11.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=ptime:20

We  can  see  from  the  above  that  the  SB  CUCM  cluster  sends  a  “200  OK”  message  in  response  to  the  
INVITE.  The  response  is  then  forwarded  by  CUBE  to  the  HQ  CUCM  cluster  without  sending  a  message  
to  the  SB  CUCM  cluster.  The  “ACK”  message  is  then  received  from  HQ  and  forwarded  by  the  CUBE  to  
SB.  We  can  see  here  that  CUBE  has  essentially  taken  itself  out  of  the  “media  negotiation”  conversation.  
Also,  we  can  see  that  based  on  the  presence  of  an  SDP  in  the  “ACK”  response,  that  this  is  a  DO  call.  
 
   

250 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.8 All  signaling  and  media  traffic  should  flow  through  the  CUBE.  
 
This  task  is  asking  us  to  ensure  that  all  signaling  and  media  traffic  flows  through  the  CUBE.  This  step  has  
actually  already  been  done  for  us!  Anytime  the  CUBE  is  acting  as  a  call  routing  device  between  two  or  
more  endpoints,  it  is  carrying  signaling  information.  With  this  in  mind,  we  know  that  signaling  will  
always  flow  through  the  CUBE.  Media  is  a  different  story,  however.  We  have  the  ability  to  run  CUBE  in  
either  a  “flow  through”  or  “flow  around”  methodology.  Of  course,  if  we  are  using  “flow  through”,  
which  is  the  default,  media  is  actually  terminated  on  the  CUBE  itself.  In  “flow  around”  scenarios,  the  
signaling  still  utilizes  the  CUBE,  but  the  media  flows  between  endpoints,  just  as  it  would  in  a  “normal”  
scenario.  
 
   

251 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 15.9 Use  a  SIP  profile  to  change  the  calling  name  display  of  HQ  Phone  2  to  “SIP  PROFILE  
HQP2”  when  presented  to  SB  phones.  
 
Protocol  translation  and  repair  is  a  key  Cisco  Unified  Border  Element  (CUBE)  function.  CUBE  can  be  
deployed  between  two  devices  that  support  the  same  VoIP  protocol  (For  example.  SIP),  but  do  not  
interwork  because  of  differences  in  how  the  protocol  is  implemented  or  interpreted.  CUBE  can  
customize  the  SIP  messaging  on  either  side  to  what  the  devices  in  that  segment  of  the  network  expects  
to  see  by  normalizing  the  SIP  messaging  on  the  network  border,  or  between  two  non-­‐interoperable  
devices  within  the  network.  
 
Service  providers  may  have  policies  for  which  SIP  messaging  fields  should  be  present  (or  what  
constitutes  valid  values  for  the  header  fields)  before  a  SIP  call  enters  their  network.  Similarly,  
enterprises  and  small  businesses  may  have  policies  for  the  information  that  can  enter  or  exit  their  
networks  for  policy  or  security  reasons  from  a  service  provider  SIP  trunk.  
[Source:    
 http://www.cisco.com/c/en/us/td/docs/ios-­‐xml/ios/voice/cube_fund/configuration/xe-­‐3s/cube-­‐fund-­‐
xe-­‐3s-­‐book/voi-­‐sip-­‐param-­‐mod.html]    
 
This  task  is  asking  us  to  use  a  SIP  profile  on  CUBE  to  modify  the  calling  name  display  of  HQ  Phone  2  as  
presented  to  other  phones  when  calling  through  CUBE.  In  order  to  accomplish  the  task,  we  must  
modify  the  “Remote-­‐Party-­‐ID”  field  in  the  SIP  messaging.  Where  should  we  make  the  modifications,  
you  ask?  If  you  think  about  it,  there  are  several  places  that  we  might  want  to  make  a  change.  For  
example,  if  HQ  Phone  2  calls  an  SB  phone,  we  would  want  to  modify  the  INVITE  message  as  well  as  the  
RE-­‐INVITE  message,  since  that  will  hold  the  initial  call  setup  information.  On  the  other  hand,  if  an  SB  
phone  calls  an  HQ  phone,  we  would  need  to  modify  the  “200  OK”  message  as  well,  so  as  to  send  the  
proper  calling  name  in  response.    
 
The  necessary  commands  for  proper  SIP  profile  configuration  exist  within  the  voice class  
structure  in  IOS  using  the  voice class sip-profiles  command.  From  there,  we  can  specify  
either  a  “request”  or  a  “response”.  At  that  point,  addition,  deletion,  or  modification  of  all  SIP  message  
types  is  available  for  either  the  SIP  or  SDP  header.  
 
R1  
R1(config)#voice class sip-profiles 1
R1(config-class)#request INVITE sip-header Remote-Party-ID modify "HQ Phone 2" "SIP PROFILE HQP2"
R1(config-class)#request REINVITE sip-header Remote-Party-ID modify "HQ Phone 2" "SIP PROFILE HQP2"
R1(config-class)#response 200 sip-header Remote-Party-ID modify "HQ Phone 2" "SIP PROFILE HQP2"
 
The  above  command  matches  the  string,  “HQ  Phone  2”  and  replaces  it  with  “SIP  PROFILE  HQP2”  in  the  
INVITE,  RE-­‐INVITE,  and  200  SIP  message  headers.  Next,  we  must  assign  the  SIP  Profile  to  either  voice
service voip  (affects  all  dial-peers)  or  a  dial-peer  (specific  to  one  dial-peer).  In  this  
case,  we  can  configure  this  setting  globally.  
 
R1  
R1(config)#voice service voip
R1(conf-voi-serv)#sip-profiles 1
 

252 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

We  can  then  run  the  debug ccsip messages  command  to  view  the  configuration  in  action  when  
making  a  test  call.  The  first  test  call  takes  place  from  HQ  Phone  2  to  SB  Phone  1.  We  can  see  the  
modification  in  the  INVITE  message.  
R1  
R1#debug ccsip messages
SIP Call messages tracing is enabled
...

Sent:
INVITE sip:52001@10.10.23.11:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK51489
Remote-Party-ID: "SIP PROFILE HQP2" <sip:1002@10.10.11.1>;party=calling;screen=yes;privacy=off

The  next  test  call  takes  place  from  SB  Phone  1  to  HQ  Phone  2.  We  can  see  the  modification  in  the  “200  
OK”  message.  

R1  
R1#debug ccsip messages
SIP Call messages tracing is enabled
...

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.23.11:5060;branch=z9hG4bK4a260657fe
From: "SB Phone 1" <sip:2001@10.10.23.11>;tag=128~fc58ca36-8b61-4fd9-a79e-d7aa6b8571b0-30886331
To: <sip:51002@10.10.11.1>;tag=49D11BB0-2411
Date: Tue, 21 Oct 2014 10:06:21 GMT
Call-ID: e6ca5200-4461301d-14-b170a0a@10.10.23.11
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event
Remote-Party-ID: "SIP PROFILE HQP2" <sip:1002@10.10.11.1>;party=called;screen=yes;privacy=off
 
Of  course,  the  phone  also  displays  the  modified  calling  name  display.  
 

 
 

253 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Four:  Labs  16-­‐29  
Version  1.0  

254 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 4: Configuring and Troubleshooting CUCM and CUCME Call


Routing
Lab 16: Basic Dial-Plan Configuration
Task 16.1 If  you  haven’t  already  done  so  in  previous  sections,  create  partitions  for  directory  
numbers,  PSTN  route  patterns,  CUCM  translation  patterns,  calls  to  SB,  and  calls  to  SC  
on  the  HQ  cluster.  
 
Basic  dial-­‐plan  logic  has  been  “sprinkled  in”  the  previous  labs  in  order  to  complete  some  of  the  call  
routing  tasks.  Partitions  and  Calling  Spaces  are  both  fundamental  building  blocks  of  the  CUCM  dial  plan  
and  have  been  discussed  at  length  as  the  mechanism  by  which  CUCM  controls  access  to  certain  areas  
of  the  system.  PTs  and  CSSs  also  help  to  organize  patterns  in  the  system  so  that  the  purpose  is  easily  
understood.  If  you  don’t  have  a  clear  purpose  for  your  configured  PT  or  CSS,  it  might  make  a  problem  
more  difficult  to  troubleshoot  in  the  end.  For  example,  let’s  say  that  you  created  a  CSS  labeled  
“INBOUND_CSS”  in  the  beginning  of  the  lab.  Then,  several  hours  later,  after  configuring  other  areas  of  
the  system,  you  are  troubleshooting  a  trunk  with  that  CSS  assigned.  By  that  point,  it  is  fair  to  say  that  
you  may  have  forgotten  the  reason  that  the  CSS  was  created  in  the  first  place.  Simply  using  a  better  
name  would  have  been  very  helpful  in  this  case,  so  the  purpose  could  be  better  understood  (e.g.  
“SB_TEHO_INBOUND_CSS”).  
 
With  that  said,  it  can  be  a  good  idea  to  configure  several  standard  PTs  within  CUCM  that  you  should  
expect  to  use  every  time.  This  task  is  actually  suggesting  some  call  types  for  which  it  is  a  good  idea  to  
create  PTs.  On  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  
the  Add  New  button.  Enter  the  PT  names  that  meet  the  above  requirements.  Obviously,  you  can  use  
whatever  names  make  sense  to  you.  The  below  PTs  were  configured  to  complete  the  task.  
 
• Directory  Numbers  =  INTERNAL_PT  
• PSTN  Route  Patterns  =  PSTN_PT  
• CUCM  Translation  Patterns  =  TRANSLATE_PT  
• Calls  to  SB  =  SB_PT  
• Calls  to  SC  =  SC_PT  
 

 
 
These  PTs  can  then  be  assigned  to  patterns/DNs  and  be  used  within  CSSs  to  control  access  to  cluster  
resources  appropriately.  Remember  to  click  the  Save  button  when  complete.      

255 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.2 If  you  haven’t  already  done  so  in  previous  sections,  create  partitions  for  directory  
numbers,  PSTN  route  patterns,  CUCM  translation  patterns,  calls  to  HQ,  and  calls  to  
SC  on  the  SB  cluster.  
 
This  task  is  asking  for  the  same  configuration  on  the  SB  CUCM  cluster.  To  meet  the  requirements,  the  
below  PTs  were  configured.  
 
• Directory  Numbers  =  INTERNAL_PT  
• PSTN  Route  Patterns  =  PSTN_PT  
• CUCM  Translation  Patterns  =  TRANSLATE_PT  
• Calls  to  HQ  =  HQ_PT  
• Calls  to  SC  =  SC_PT  
 

 
 
Remember  to  click  the  Save  button  when  complete.  
 
   

256 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.3 On  both  the  HQ  and  SB  clusters,  create  calling  search  spaces  where  appropriate  to  
support  intracluster  and  intercluster  calls.  
 
Now  that  PTs  have  been  created,  it  makes  sense  to  create  CSSs  to  control  access  to  those  partitions.  To  
support  intracluster  calls,  we  must  create  a  CSS  to  be  assigned  to  the  user  endpoints.  Without  a  CSS  
assigned  to  the  phone,  no  calls  are  possible  to  patterns  or  DNs  with  PTs  assigned.  To  support  
intercluster  calls,  we  must  be  able  to  accept  calls  as  they  enter  the  CUCM  cluster  and  forward  them  to  
the  correct  destination.  This  means  that  we’ll  need  a  CSS  assigned  to  both  trunks  and  gateways  to  
support  inbound  calls.  
 
For  the  phones,  we  have  a  couple  options  on  where  the  CSS  can  be  placed—either  the  line  or  device.  
The  line  CSS  takes  precedence  over  the  device  CSS  when  routing  calls.  In  the  following  example,  
“LINE_CSS”  is  assigned  to  the  line  and  “DEVICE_CSS”  is  assigned  to  the  device.    
 
• LINE_CSS  
o D_PT  
" 1XXX  
o E_PT  
" 22XX  
o F_PT  
" 333X  
• DEVICE_CSS  
o A_PT  
" 11XX  
o B_PT  
" 2XXX  
o C_PT  
" 3XXX  
 
The  resulting  list  of  PTs  in  this  configuration  would  be  as  shown  below.  
 
• D_PT  
• E_PT  
• F_PT  
• A_PT  
• B_PT  
• C_PT  
 
As  you  can  see,  the  partition  order  starts  with  the  line  CSS  when  concatenated  with  the  device  CSS.  
This  still  does  not,  however,  override  the  longest  match  algorithm  for  CUCM  call  routing.  For  example,  
if  the  user  above  dials  the  number  “1102”,  which  pattern  is  matched?  In  this  case,  it  will  be  the  “11XX”  
pattern  in  the  “A_PT”  even  though  the  “1XXX”  pattern  in  the  “D_PT”  Partition  is  listed  first.  
 

257 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  that  in  mind,  it  is  not  really  typical  to  need  both  the  line  and  device  CSSs  in  a  configuration  for  
CCIE  study.  In  the  “real  world”  the  line/device  approach  is  used  most  often  to  employ  different  classes  
of  service  for  users.  For  example,  the  device  CSS  might  provide  access  to  all  patterns  in  the  system,  but  
the  line  CSS  would  deny  access  to  certain  patterns  based  on  the  user  class  of  service.  In  this  case,  we  
can  simply  assign  the  CSS  to  the  device  to  keep  things  simple!  
 
On  the  HQ  CUCM  cluster,  configure  CSSs  as  shown  below  to  complete  this  task.  Navigate  to  Call  
Routing  !  Class  of  Control  !  Calling  Search  Space  and  click  the  Add  New  button.  Name  the  CSS  
appropriately  and  select  Partitions  from  the  list.  When  complete,  click  the  Save  button.  
 
• PHONE_CSS  
 

 
 
• GW_TRUNK_CSS  
 

 
 
Perform  the  same  steps  on  the  SB  CUCM  cluster  by  adding  the  below  configuration.  
 
• PHONE_CSS  
 

 
 
• GW_TRUNK_CSS  
 

 
 
   

258 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.4 Assure  that  all  gateways  and  trunks  are  assigned  to  a  route  group  and  a  route  list.  
 
It  is  always  a  good  idea  to  create  a  Route  Group  and  Route  List  as  soon  as  either  a  gateway  or  trunk  is  
created  in  the  system.  This  is  to  help  you  avoid  the  temptation  of  simply  assigning  the  device  directly  
to  a  Route  Pattern.  Sure,  this  is  possible,  but  it  is  a  horrible  idea.    
 
For  example,  let’s  say  that  you  have  a  Route  Pattern  configured  that  has  the  R1  MGCP  gateway  directly  
assigned  to  it.  Later  in  the  lab,  you  might  be  asked  to  send  calls  to  an  ICT  as  the  first  option,  with  the  
second  option  being  the  MGCP  gateway.  For  that  configuration  to  work,  you  must  have  a  Route  List  
with  multiple  options.  However,  since  the  R1  MGCP  gateway  is  assigned  directly  to  the  Route  Pattern,  
you  will  not  able  to  add  it  to  a  Route  Group  and  Route  List.  You  must  first  remove  the  MGCP  gateway  
assignment  on  the  Route  Pattern  in  this  case.  This  can  get  very  messy,  very  fast.  So  please,  always  add  
a  Route  Group  and  Route  List  when  a  gateway  or  trunk  is  created.  
 
Route  Groups  and  Route  Lists  were  added  to  the  configuration  in  previous  tasks  for  the  SIP  and  H.323  
ICTs  as  well  as  the  CUBE  SIP  trunk,  but  we  now  must  add  Route  Groups/Route  Lists  for  the  R1  MGCP  
gateway  (HQ)  and  the  R2  SIP  gateway  (SB).  For  clarification  purposes,  the  entire  routing  structure  is  
located  in  the  “Route/Hunt”  menu.  You  can  view  the  options  by  navigating  to  Call  Routing  !  
Route/Hunt.  
 

 
 
On  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  Group  and  click  the  Add  
New  button.  Enter  a  descriptive  “Route  Group  Name”  (e.g.  “R1_MGCP_RG”)  and  select  a  “Distribution  
Algorithm”.  Keep  in  mind  that  no  matter  what  algorithm  is  selected  here,  it  won’t  make  a  difference  
until  more  than  one  device  is  added  to  the  Route  Group.  
 

 
 

259 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  click  the  Add  to  Route  Group  button  to  add  the  R1  MGCP  Gateway,  identified  by  the  
“S0/SU0/DS1-­‐0@R1.ipexpert.com”  name.    
 

 
 
Click  the  Save  button  when  finished  with  the  configuration.  
 
Next,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Enter  a  
descriptive  name  for  the  new  Route  List,  select  the  desired  CUCM  group,  and  click  the  Save  button.  
 

 
 
Click  the  Add  Route  Group  button  and  select  the  “R1_MGCP_RG”  that  was  configured  in  the  previous  
task.  Click  the  Save  button  when  complete.  
 

 
 
   

260 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  SB  CUCM  cluster,  we  must  also  add  a  Route  Group  and  Route  List  for  the  R2  SIP  gateway.  
 

 
 

 
 

 
 
   

261 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.5 On  the  HQ  and  SB  clusters,  use  the  local  route  group  feature  unless  otherwise  
specified.  HQ  phones  should  use  the  R1  MGCP  gateway  and  SB  phones  should  use  
the  R2  SIP  gateway.  
 
The  Local  Route  Group  feature  helps  reduce  the  complexity  and  maintenance  efforts  of  provisioning  in  
a  centralized  Cisco  Unified  Communications  Manager  deployment  that  uses  a  large  number  of  
locations.  The  fundamental  breakthrough  in  the  Local  Route  Group  feature  comprises  decoupling  the  
location  of  a  PSTN  gateway  from  the  route  patterns  that  are  used  to  access  the  gateway.  
 
Cisco  Unified  Communications  Manager  uses  a  special  Local  Route  Group  that  can  be  bound  to  a  
provisioned  route  group  differently  based  on  the  Local  Route  Group  device  pool  setting  of  the  
originating  device.  Devices,  such  as  phones,  from  different  locales  can  therefore  use  identical  route  
lists  and  route  patterns,  but  Cisco  Unified  Communications  Manager  selects  the  correct  gateway(s)  for  
their  local  end.  
[Source:  
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmfeat/fsgd-­‐712-­‐
cm/fslrg.html  -­‐  wpxref71119]    
 
The  Local  Route  Group  feature  in  CUCM  is  a  requirement  of  this  task.  This  essentially  involves  assigning  
the  Route  Groups  created  in  the  previous  task  to  the  Device  Pool  of  the  phones  that  will  be  placing  
calls  that  utilize  those  gateways.    
For  the  HQ  CUCM  cluster,  we  will  assign  the  “R1_MGCP_RG”  Route  Group  to  the  “HQ_PHONE_DP”  
Device  Pool  so  that  when  phones  dial  a  Route  Pattern  that  utilizes  the  “Standard  Local  Route  Group”  
feature,  the  “R1_MGCP_RG”  Route  Group  will  be  used.  
 
Navigate  to  System  !  Device  Pool  and  click  the  Find  button.  Click  on  the  “HQ_PHONE_DP”  and  locate  
the  parameter  labeled  “Local  Route  Group”.  Select  the  “R1_MGCP_RG”  and  click  the  Save  button.  Click  
the  Reset  button  to  apply  the  configuration.  
 

 
 
   

262 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  need  to  create  the  Route  List  that  will  invoke  the  Local  Route  Group  feature.  Navigate  to  Call  
Routing  !  Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Enter  a  descriptive  name  (e.g.  
“LOCAL_RL”)  and  select  the  desired  CUCM  group.  
 

 
 
In  the  “Route  List  Configuration”  page,  click  the  Add  Route  Group  button  and  select  the  “Standard  
Local  Route  Group”  option.    
 

 
 
When  the  time  comes  to  configure  Route  Patterns  that  should  utilize  the  Standard  Local  Route  Group,  
simply  select  “LOCAL_RL”  as  the  Route  List  option.  
 
Just  as  done  above  for  the  HQ  cluster,  the  SB  CUCM  cluster  should  assign  the  “R2_SIP_RG”  Route  
Group  to  the  “SB_PHONE_DP”  Device  Pool  so  that  when  phones  dial  a  route  pattern  that  utilizes  the  
“Standard  Local  Route  Group”  feature,  the  “R2_SIP_RG”  Route  Group  will  be  used.  
 

 
 
Next,  configure  a  Route  List  to  utilize  the  “Standard  Local  Route  Group”.  

263 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
At  this  point,  both  clusters  should  be  configured  and  ready  to  route  calls  using  the  Standard  Local  
Route  Group.  
 
   

264 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.6 Configure  the  HQ  and  SB  clusters  to  support  emergency  dialing  using  patterns  of  
both  911  and  9911.  Send  a  10-­‐digit  ANI  and  Calling  Name,  using  a  calling  party  type  
of  “Subscriber”.  A  called  party  number  type  of  “Subscriber”  should  also  be  sent.  As  
soon  as  the  pattern  is  matched,  the  call  should  be  routed  immediately.  Do  not  send  
a  calling  name  for  SB  phones.  
 
For  this  task,  we  are  beginning  our  PSTN  call  routing  configuration  on  both  the  HQ  and  SB  CUCM  
clusters.  This  task  is  specifically  asking  for  Emergency  Services  dialing  to  both  “911”  and  “9911”  to  
operate  successfully  on  both  clusters.  There  are  very  specific  requirements  for  this  type  of  call  as  well;  
including  ANI  formatting  and  ISDN  number  type/plan  formatting.  To  make  sense  of  this  information,  it  
sometimes  helps  to  create  a  table  that  highlights  the  different  digit  manipulation  requirements  that  
need  to  happen  per  pattern.  Once  this  table  is  in  place,  the  configuration  becomes  pretty  
straightforward.    
 
Digit  Manipulation  Table  
Route  Pattern   911  and  9911  
ANI  Digits  Required   10  
DNIS  Digits  Required   3  (911)  
Calling  Party  Number  Type   N/A  
Called  Party  Number  Type   Subscriber  
Special  Requirements   No  Calling  Name  for  SB  Phones  
 
To  complete  the  requirements  on  the  HQ  CUCM  cluster,  we  can  start  by  navigating  to  Call  Routing  !  
Route/Hunt  !  Route  Pattern  and  clicking  the  Add  New  button.  Enter  the  Route  Pattern  in  question.  In  
this  case,  we  will  configure  the  “911”  pattern  first.  Ensure  that  a  Partition  is  selected  that  is  accessible  
by  all  phones  in  the  cluster  (e.g.  “PSTN_PT”).  
 

 
 
Next,  select  the  “Gateway/Route  List”  from  the  dropdown  box  to  ensure  that  the  pattern  uses  the  
Standard  Local  Route  Group  (e.g.  “LOCAL_RL”).  
 

 
 
   

265 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Since  this  an  Emergency  Services  Route  Pattern,  we  should  get  in  the  habit  of  checking  the  “Urgent  
Priority”  checkbox.  This  option  exists  to  ensure  that  the  user  will  not  have  to  wait  for  the  default  
interdigit  timeout  value  to  expire  before  the  call  is  routed  when  there  are  overlapping  patterns.  For  
example,  if  another  pattern  exists,  such  as  91XXX,  the  default  behavior  would  be  for  CUCM  to  wait  for  
more  digits.  With  “Urgent  Priority”,  it  routes  the  call  as  soon  as  the  pattern  is  matched,  without  
waiting.  
 

 
 
Next,  we  can  use  the  different  digit  manipulation  options  built  into  the  Route  Pattern  to  accomplish  
the  task  requirements.  First,  to  set  the  proper  number  of  digits  for  the  ANI,  we  can  take  advantage  of  
the  External  Phone  Number  Mask  that  is  configured  on  the  DN  of  the  phone  (+1408222XXXX)  by  
checking  the  “Use  Calling  Party's  External  Phone  Number  Mask”  checkbox  under  the  “Calling  Party  
Transformations”  section.  That  setting  will  force  the  ANI  into  +E164  format.  From  there,  we  can  set  the  
“Calling  Party  Transform  Mask”  to  a  value  of  “XXXXXXXXXX”  so  only  the  rightmost  10  digits  are  used.    
 

 
 
Next,  we  must  fulfill  the  requirements  for  the  “Called  Party  Number  Type/Plan”  under  the  “Called  
Party  Transformations”  section.  In  this  case,  a  “Called  Party  Number  Type”  of  “Subscriber”  and  “Called  
Party  Number  Plan”  of  “ISDN”  are  required.  
 

 
 
Click  the  Save  button  when  completed.    
   

266 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Since  we  were  also  tasked  with  creating  the  “9911”  pattern  above,  it  is  a  good  idea  at  this  point  to  click  
the  Copy  button  to  create  a  new  pattern  with  the  same  settings  as  above.  Enter  the  new  pattern  in  the  
“Route  Pattern”  field  as  “9.911”  to  support  the  requirement.    
 

 
 
Next,  make  sure  that  the  “Discard  Digits”  dropdown  box  is  set  to  “PreDot”  in  order  to  drop  the  leading  
“9”  in  the  dialed  string.    
 

 
 
In  order  to  test  the  configuration,  make  a  call  from  an  HQ  phone  to  both  the  911  and  9911  numbers.  
Use  the  debug isdn q931  command  on  the  gateway  to  ensure  that  the  call  is  routed  to  the  
destination  successfully.  
 
R1  
911  is  dialed  from  HQ  Phone  2  
 
R1#debug isdn q931
debug isdn q931 is ON.

Oct 22 07:38:24.067: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0003


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x4181, '4082221002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
Oct 22 07:38:24.103: ISDN Se0/0/0:23
R1#Q931: RX <- CALL_PROC pd = 8 callref = 0x8003
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 07:38:24.227: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8003

   

267 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

9911  is  dialed  from  HQ  Phone  2  


 
R1#debug isdn q931
debug isdn q931 is ON.

Oct 22 07:44:54.557: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0005


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x4181, '4082221002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
Oct 22 07:44:54.593: ISDN Se0/0/0:23
R1#Q931: RX <- CALL_PROC pd = 8 callref = 0x8005
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 07:44:55.225: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8005
R1#
Oct 22 07:44:59.237: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8005
Oct 22 07:44:59.241: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0005

On  the  SB  CUCM  cluster,  the  procedure  is  very  similar.  The  only  difference  lies  in  the  logic  by  which  
digits  are  manipulated.  Since  the  R2  gateway  is  running  SIP,  we  have  two  possible  entities  in  the  call  
flow  that  can  perform  the  required  manipulations—the  SB  CUCM  cluster  and  the  R2  gateway.  In  this  
case,  it  makes  sense  to  choose  the  gateway  to  accomplish  this  task.  This  is  because  we  want  the  
gateway  to  retain  all  call-­‐routing  settings  (including  digit  manipulation)  if  the  gateway  ever  loses  
communication  with  the  SB  CUCM  server  (in  SRST  perhaps).  The  CUCM  configuration  will  remain  the  
same  as  was  done  on  the  HQ  CUCM  cluster,  but  there  will  be  no  digit  manipulation  done  until  it  
reaches  the  gateway.  With  that  in  mind,  see  the  below  screenshot  for  the  CUCM  configuration.  
 

 
 
Next,  we  must  configure  the  R2  gateway  to  accept  the  incoming  VoIP  call  from  the  SB  CUCM  cluster  
and  route  the  call  to  the  PSTN  using  an  outbound  POTS  dial-peer.  In  this  configuration,  the  

268 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

incoming called-number  command  was  added  to  the  existing  VoIP  dial-peer  used  to  route  
the  calls  from  the  PSTN  to  the  SB  CUCM  cluster.  This  will  serve  as  the  inbound  dial-peer  as  well.    
 
R2  
R2#sh run | sec dial-peer voice 2000

dial-peer voice 2000 voip


destination-pattern 3123332...$
session protocol sipv2
session target ipv4:10.10.23.11
voice-class codec 1
dtmf-relay rtp-nte sip-notify
no vad

R2(config)#dial-peer voice 2000 voip


R2(config-dial-peer)#incoming called-number .

For  the  outbound  call  routing,  we  must  configure  two  POTS  dial-peers—one  for  “911”  and  one  for  
“9911”.  The  destination-pattern  will,  of  course,  provide  a  match  for  the  dialed  digits  on  both  
dial-peers.  Remember,  with  a  POTS  dial-peer,  any  digits  that  are  explicitly  configured  within  
the  destination-pattern  are  automatically  dropped  when  sent  to  the  PSTN.  In  this  case,  that  
means  that  since  911  and  9911  are  explicitly  configured,  the  called  number  being  sent  to  the  PSTN  will  
be  a  blank  number!    
 
Obviously,  we  must  fix  this  issue  by  using  either  the  prefix  command  (prefix 911)  or  the  
forward-digits  command  (forward-digits all).  Next,  we  must  specify  the  port  that  is  
being  used  for  the  PSTN  connection.  In  this  case,  port 0/0/0:23  is  used,  which  corresponds  to  the  
interface  number  of  the  auto-­‐generated  voice-port.  Lastly,  to  meet  the  requirements  of  the  
question,  the  dial-peer  should  be  configured  to  strip  the  calling  name,  as  this  was  required  at  SB.  
 
R2  
R2(config)#dial-peer voice 911 pots
R2(config-dial-peer)#translation-profile outgoing TRANSLATE-EMER-OUTBOUND
R2(config-dial-peer)#destination-pattern 911
R2(config-dial-peer)#forward-digits all
R2(config-dial-peer)#port 0/0/0:23
R2(config-dial-peer)#clid strip name

R2(config-dial-peer)#dial-peer voice 9911 pots


R2(config-dial-peer)#translation-profile outgoing TRANSLATE-EMER-OUTBOUND
R2(config-dial-peer)#destination-pattern 9911
R2(config-dial-peer)#forward-digits all
R2(config-dial-peer)#port 0/0/0:23
R2(config-dial-peer)#clid strip name

   

269 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  addition  to  the  dial-peers,  we  must  create  voice translation-rules  and  voice
translation-profiles  to  manipulate  the  digits  before  sending  to  the  PSTN.  We  will  need  two  
sets  of  rules  to  accommodate  both  the  calling  and  called  number.  As  shown  below,  voice
translation-rule 1  manipulates  the  calling  number  while  voice translation-rule 2  is  
designated  for  use  with  the  called  number.  The  calling  number  will  be  translated  to  a  10-­‐digit  number  
with  the  ISDN  Subscriber  type.  The  called  number  will  remain  “911”,  but  will  use  the  ISDN  Subscriber  
type  as  well.  The  voice translation-profile TRANSLATE-EMER-OUTBOUND  is  very  
descriptive  for  its  function  and  serves  to  tie  both  rules  together.  This  profile  can  then  be  assigned  to  both  POTS  
dial-peers.  
 
R2  
R2(config)#voice translation-rule 1
R2(cfg-translation-rule)#rule 1 /^\(2...$\)/ /312333\1/ type any subscriber plan any isdn

R2(cfg-translation-rule)#voice translation-rule 2
R2(cfg-translation-rule)#rule 1 /^911/ /\0/ type any subscriber plan any isdn
R2(cfg-translation-rule)#rule 2 /^9911/ /911/ type any subscriber plan any isdn

R2(config)#voice translation-profile TRANSLATE-EMER-OUTBOUND


R2(cfg-translation-profile)#translate calling 1
R2(cfg-translation-profile)#translate called 2

R2(config)#dial-peer voice 911 pots


R2(config-dial-peer)#translation-profile outgoing TRANSLATE-EMER-OUTBOUND

R2(config-dial-peer)#dial-peer voice 9911 pots


R2(config-dial-peer)#translation-profile outgoing TRANSLATE-EMER-OUTBOUND

To  test  the  configuration,  make  a  test  call  from  an  SB  phone  to  both  “911”  and  “9911”  and  run  the  
debug isdn q931  command  on  the  R2  gateway.  
 
R2  
Dialing  911  from  SB  Phone  1  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 22 09:20:12.265: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x4 0x1, Calling num
3123332001
Oct 22 09:20:12.265: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0084 callID = 0x8005 switch =
primary-ni interface = User
Oct 22 09:20:12.265: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0084
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusiv
R2#e, Channel 3
Calling Party Number i = 0x4181, '3123332001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
Oct 22 09:20:12.305: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8084
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 09:20:12.421: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8084
R2#
Oct 22 09:20:16.761: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8084
Oct 22 09:20:16.761: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0084

270 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Dialing  9911  from  SB  Phone  1  


R2#debug isdn q931
debug isdn q931 is ON.

Oct 22 09:22:08.209: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x4 0x1, Calling num
3123332001
Oct 22 09:22:08.209: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0085 callID = 0x8006 switch =
primary-ni interface = User
Oct 22 09:22:08.209: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0085
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusiv
R2#e, Channel 3
Calling Party Number i = 0x4181, '3123332001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
Oct 22 09:22:08.245: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8085
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 09:22:08.365: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8085
R2#
Oct 22 09:22:11.901: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8085
Oct 22 09:22:11.901: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0085
 
   

271 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.7 Configure  the  HQ  and  SB  clusters  to  support  local  calls.  The  user  should  dial  a  9  first,  
followed  by  any  digit  from  2  to  9,  followed  by  any  6  digits.  Send  a  7-­‐digit  ANI  and  
Calling  Name  using  the  calling  party  type  of  “Subscriber”.  Send  a  7-­‐digit  DNIS  and  
use  the  called  party  type  of  “Subscriber”.    
 
This  task  is  asking  us  to  configure  7-­‐digit  local  dialing  for  both  the  HQ  and  SB  CUCM  clusters.  Create  the  
Digit  Manipulation  Table  to  organize  the  information  in  a  “clean”  format  and  begin  the  configuration.    
 
Digit  Manipulation  Table  
Route  Pattern   9[2-­‐9]XXXXXX  
ANI  Digits  Required   7  
DNIS  Digits  Required   7  
Calling  Party  Number  Type   Subscriber  
Called  Party  Number  Type   Subscriber  
Special  Requirements   N/A  
 
To  complete  the  requirements  on  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  
Route  Pattern  and  click  the  Add  New  button.  Enter  the  Route  Pattern  of  “9.[2-­‐9]XXXXXX”.  Ensure  that  
a  Partition  is  selected  that  is  accessible  by  all  phones  in  the  cluster  (e.g.  “PSTN_PT”).  
 

 
 
Next,  select  the  “Gateway/Route  List”  from  the  dropdown  box  to  ensure  that  the  pattern  uses  the  
Standard  Local  Route  Group  (e.g.  “LOCAL_RL”).  
 

 
 
   

272 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  to  set  the  proper  number  of  digits  for  the  ANI,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  checkbox  under  the  “Calling  Party  Transformations”  section.  Then  set  the  “Calling  Party  
Transform  Mask”  to  a  value  of  “XXXXXXX”  so  only  the  rightmost  7  digits  are  used.  Also,  make  sure  to  
set  the  “Calling  Party  Number  Type/Plan”  to  “Subscriber/ISDN”  for  the  calling  number.    
 

 
 
Next,  set  the  “Discard  Digits”  dropdown  box  to  “PreDot”  and  the  “Called  Party  Number  Type/Plan”  to  
“Subscriber”  and  “ISDN”  under  the  “Called  Party  Transformations”  section.  
 

 
 
Click  the  Save  button  when  completed.    
 
To  test  the  configuration,  make  a  call  from  an  HQ  phone  to  the  local  HQ  PSTN  number  (96131218).  Use  
the  debug isdn q931  command  on  the  gateway  to  ensure  that  the  call  is  routed  to  the  destination  
successfully.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 22 09:54:23.060: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0006


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x4181, '2221002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '6131218'

273 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Plan:ISDN, Type:Subscriber(local)
Oct 22 09:54:23.100: ISDN Se0/0/0:23
R1# Q931: RX <- CALL_PROC pd = 8 callref = 0x8006
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 09:54:23.236: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8006

On  the  SB  CUCM  cluster,  configure  call  routing  in  a  similar  fashion.  Once  again,  no  digit  manipulation  is  
done  until  it  reaches  the  gateway.  See  the  below  screenshot  for  the  CUCM  configuration.  
 

 
 
Just  as  was  done  in  the  previous  task,  configure  the  R2  gateway  to  route  the  call  to  the  PSTN  using  an  
outbound  POTS  dial-peer.  
 
R2  
R2(config)#dial-peer voice 7 pots
R2(config-dial-peer)#destination-pattern 9[2-9]......$
R2(config-dial-peer)#port 0/0/0:23
 
Next,  create  the  necessary  voice translation-rules  and  voice translation-
profiles  to  manipulate  the  digits  before  sending  to  the  PSTN.  Once  completed,  assign  the  
translation-profile  to  the  dial-peer.    
 
R2  
R2(config)#voice translation-rule 3
R2(cfg-translation-rule)#rule 1 /^\(2...$\)/ /333\1/ type any subscriber plan any isdn

R2(cfg-translation-rule)#voice translation-rule 4
R2(cfg-translation-rule)#rule 1 /^9\([2-9]......\)$/ /\1/ type any subscriber plan any isdn

R2(config)#voice translation-profile TRANSLATE-LOCAL-OUTBOUND


R2(cfg-translation-profile)#translate calling 3
R2(cfg-translation-profile)#translate called 4

R2(config)#dial-peer voice 7 pots


R2(config-dial-peer)#translation-profile outgoing TRANSLATE-LOCAL-OUTBOUND

   

274 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  test  the  configuration,  make  a  call  from  an  SB  phone  to  the  local  number  by  dialing  “97764016”.  
Run  the  debug isdn q931  command  on  the  R2  gateway  to  view  the  call  details.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 22 10:22:19.696: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x4 0x1, Calling num
3332001
Oct 22 10:22:19.696: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0086 callID = 0x8007 switch =
primary-ni interface = User
Oct 22 10:22:19.696: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0086
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive,
R2#Channel 3
Display i = 'SB Phone 1'
Calling Party Number i = 0x4181, '3332001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '7764016'
Plan:ISDN, Type:Subscriber(local)
Oct 22 10:22:19.740: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8086
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 10:22:19.856: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8086
 
   

275 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.8 Configure  the  HQ  and  SB  clusters  to  support  long  distance  calls.  The  user  should  dial  
a  9  first,  followed  by  1,  followed  by  any  digit  from  2  to  9,  followed  by  any  2  digits,  
followed  by  any  digit  from  2  to  9,  followed  by  any  6  digits.  Send  a  10-­‐digit  ANI  and  
Calling  Name  using  the  calling  party  type  of  “National”.  Send  a  10-­‐digit  DNIS  and  use  
the  called  party  type  of  “National”.    
 
This  task  is  asking  us  to  configure  11-­‐digit  long  distance  dialing  for  both  the  HQ  and  SB  CUCM  clusters.  
Create  the  Digit  Manipulation  Table  to  organize  the  information  in  a  “clean”  format  and  begin  the  
configuration.    
 
Digit  Manipulation  Table  
Route  Pattern   91[2-­‐9]XX[2-­‐9]XXXXXX  
ANI  Digits  Required   10  
DNIS  Digits  Required   10  
Calling  Party  Number  Type   National  
Called  Party  Number  Type   National  
Special  Requirements   N/A  
 
To  complete  the  requirements  on  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  
Route  Pattern  and  click  the  Add  New  button.  Enter  the  Route  Pattern  of  “91.[2-­‐9]XX[2-­‐9]XXXXXX”.  
Ensure  that  a  Partition  is  selected  that  is  accessible  by  all  phones  in  the  cluster  (e.g.  “PSTN_PT”).  Next,  
select  the  “Gateway/Route  List”  from  the  dropdown  box  to  ensure  that  the  pattern  uses  the  Standard  
Local  Route  Group  (e.g.  “LOCAL_RL”).  
 

 
 
   

276 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  to  set  the  proper  number  of  digits  for  the  ANI,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  checkbox  under  the  “Calling  Party  Transformations”  section.  Then  set  the  “Calling  Party  
Transform  Mask”  to  a  value  of  “XXXXXXXXXX”  so  only  the  rightmost  10  digits  are  used.  Also,  make  sure  
to  set  the  “Calling  Party  Number  Type/Plan”  to  “National/ISDN”  for  the  calling  number.    
 

 
 
Next,  set  the  “Discard  Digits”  dropdown  box  to  “PreDot”  and  the  “Called  Party  Number  Type/Plan”  to  
“National”  and  “ISDN”  under  the  “Called  Party  Transformations”  section.  
 

 
 
Click  the  Save  button  when  completed.    
 
To  test  the  configuration,  make  a  call  from  an  HQ  phone  to  a  long  distance  PSTN  number  
(913127764016).  Use  the  debug isdn q931  command  on  the  gateway  to  ensure  that  the  call  is  
routed  to  the  destination  successfully.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 22 22:25:10.268: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0008


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x2181, '4082221001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '3127764016'
Plan:ISDN, Type:National
Oct 22 22:25:10.304: ISDN Se0/0/0:23 Q931: RX <-
R1# CALL_PROC pd = 8 callref = 0x8008

277 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 22:25:10.432: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8008
Oct 22 22:25:11.464: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8008
Oct 22 22:25:11.472: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0008

On  the  SB  CUCM  cluster,  configure  call  routing  in  a  similar  fashion.  Once  again,  no  digit  manipulation  is  
done  until  it  reaches  the  gateway.  See  the  below  screenshot  for  the  CUCM  configuration.  
 

 
 
Just  as  was  done  in  the  previous  task,  configure  the  R2  gateway  to  route  the  call  to  the  PSTN  using  an  
outbound  POTS  dial-peer.  
 
R2  
R2(config)#dial-peer voice 10 pots
R2(config-dial-peer)#destination-pattern 91[2-9]..[2-9]......$
R2(config-dial-peer)#port 0/0/0:23

Next,  create  the  necessary  voice translation-rules  and  voice translation-


profiles  to  manipulate  the  digits  before  sending  to  the  PSTN.  Once  completed,  assign  the  
translation-profile  to  the  dial-peer.    
 
R2  
R2(config)# voice translation-rule 5
R2(cfg-translation-rule)#rule 1 /^\(2...$\)/ /312333\1/ type any national plan any isdn

R2(cfg-translation-rule)#voice translation-rule 6
R2(cfg-translation-rule)#rule 1 /^91\([2-9]..[2-9]......\)$/ /\1/ type any national plan any isdn

R2(config)#voice translation-profile TRANSLATE-NATL-OUTBOUND


R2(cfg-translation-profile)#translate calling 5
R2(cfg-translation-profile)#translate called 6

R2(config)#dial-peer voice 10 pots


R2(config-dial-peer)#translation-profile outgoing TRANSLATE-NATL-OUTBOUND

   

278 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  test  the  configuration,  make  a  call  from  an  SB  phone  to  a  long  distance  number  by  dialing  
“914086131218”.  Run  the  debug isdn q931  command  on  the  R2  gateway  to  view  the  call  details.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 22 22:31:25.035: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num
3123332001
Oct 22 22:31:25.035: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0088 callID = 0x8009 switch =
primary-ni interface = User
Oct 22 22:31:25.035: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0088
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusiv
R2#e, Channel 3
Display i = 'SB Phone 1'
Calling Party Number i = 0x2181, '3123332001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '4086131218'
Plan:ISDN, Type:National
Oct 22 22:31:25.071: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8088
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 22:31:25.207: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8088
R2#
Oct 22 22:31:27.531: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8088
Oct 22 22:31:27.531: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0088
 
   

279 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.9 Configure  the  HQ  and  SB  clusters  to  support  international  calls.  The  user  should  dial  
a  9  first,  followed  by  011,  followed  by  any  number  of  digits.  Send  +E164  ANI  and  
Calling  Name  using  the  calling  party  type  of  “International”.  Send  the  full  
international  number  (without  011  prefix)  as  DNIS  and  use  the  called  party  type  of  
“International”.    
 
This  task  is  asking  us  to  configure  international  dialing  for  both  the  HQ  and  SB  CUCM  clusters.  Create  
the  Digit  Manipulation  Table  to  organize  the  information  in  a  “clean”  format  and  begin  the  
configuration.    
 
Digit  Manipulation  Table  
Route  Pattern   9011!  
ANI  Digits  Required   +E164    
DNIS  Digits  Required   All  digits,  no  “011”  prefix  
Calling  Party  Number  Type   International  
Called  Party  Number  Type   International  
Special  Requirements   N/A  
 
To  complete  the  requirements  on  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  
Route  Pattern  and  click  the  Add  New  button.  Enter  the  Route  Pattern  of  “9011.!”.  Ensure  that  a  
Partition  is  selected  that  is  accessible  by  all  phones  in  the  cluster  (e.g.  “PSTN_PT”).  Next,  select  the  
“Gateway/Route  List”  from  the  dropdown  box  to  ensure  that  the  pattern  uses  the  Standard  Local  
Route  Group  (e.g.  “LOCAL_RL”).  
 

 
 
   

280 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  to  set  the  proper  number  of  digits  for  the  ANI,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  checkbox  under  the  “Calling  Party  Transformations”  section  in  order  to  use  the  entire  
+E164  number.  Also,  make  sure  to  set  the  “Calling  Party  Number  Type/Plan”  to  “International/ISDN”  
for  the  calling  number.    
 

 
 
Next,  set  the  “Discard  Digits”  dropdown  box  to  “PreDot”  and  the  “Called  Party  Number  Type/Plan”  to  
“International”  and  “ISDN”  under  the  “Called  Party  Transformations”  section.  
 

 
 
Click  the  Save  button  when  completed.    
 
To  test  the  configuration,  make  a  call  from  an  HQ  phone  to  an  international  PSTN  number  
(9011689220420).  Use  the  debug isdn q931  command  on  the  gateway  to  ensure  that  the  call  is  
routed  to  the  destination  successfully.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 22 22:40:47.183: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000A


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x1181, '+14082221001'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '689220420'
Plan:ISDN, Type:International
Oct 22 22:40:47.223: ISDN Se0/0/0:23

281 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R1#Q931: RX <- CALL_PROC pd = 8 callref = 0x800A


Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 22:40:47.399: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800A
R1#
Oct 22 22:40:52.443: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x800A
Oct 22 22:40:52.447: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x000A

On  the  SB  CUCM  cluster,  configure  call  routing  in  a  similar  fashion.  Once  again,  no  digit  manipulation  is  
done  until  it  reaches  the  gateway.  See  the  below  screenshot  for  the  CUCM  configuration.  
 

 
 
Just  as  was  done  in  the  previous  task,  configure  the  R2  gateway  to  route  the  call  to  the  PSTN  using  an  
outbound  POTS  dial-peer.  
 
R2  
R2(config)#dial-peer voice 9011 pots
R2(config-dial-peer)#destination-pattern 9011T
R2(config-dial-peer)#port 0/0/0:23

Next,  create  the  necessary  voice translation-rules  and  voice translation-


profiles  to  manipulate  the  digits  before  sending  to  the  PSTN.  Once  completed,  assign  the  
translation-profile  to  the  dial-peer.    
 
R2  
R2(config)# voice translation-rule 7
R2(cfg-translation-rule)#rule 1 /^\(2...$\)/ /+1312333\1/ type any international plan any isdn

R2(cfg-translation-rule)#voice translation-rule 8
R2(cfg-translation-rule)#rule 1 /^9011\(.*\)$/ /\1/ type any international plan any isdn

R2(config)#voice translation-profile TRANSLATE-INTL-OUTBOUND


R2(cfg-translation-profile)#translate calling 7
R2(cfg-translation-profile)#translate called 8

R2(config)#dial-peer voice 9011 pots


R2(config-dial-peer)#translation-profile outgoing TRANSLATE-INTL-OUTBOUND

To  test  the  configuration,  make  a  call  from  an  SB  phone  to  an  international  number  by  dialing  
“9011689220420”.  Run  the  debug isdn q931  command  on  the  R2  gateway  to  view  the  call  details.  
 

282 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 22 22:48:20.773: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num
+13123332001
Oct 22 22:48:20.773: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0089 callID = 0x800A switch =
primary-ni interface = User
Oct 22 22:48:20.773: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0089
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclus
R2#ive, Channel 3
Display i = 'SB Phone 1'
Calling Party Number i = 0x1181, '+13123332001'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '689220420'
Plan:ISDN, Type:International
Oct 22 22:48:20.813: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8089
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 22:48:20.949: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8089
R2#
Oct 22 22:48:23.937: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8089
Oct 22 22:48:23.937: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0089
 
   

283 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.10 Ensure  that  the  interdigit  timeout  value  is  set  to  half  the  default  to  support  quicker  
international  dialing.  
 
The  interdigit  timeout  value  is  controlled  by  the  T.302  timer  and  has  a  default  value  of  15000  
milliseconds  (15  seconds).  The  task  is  asking  us  to  configure  the  timer  to  half  of  the  normally  
configured  value.  This  means  that  we  must  locate  the  T.302  timer  parameter  and  set  the  value  to  7500  
milliseconds.  
 
On  the  HQ  CUCM  cluster,  navigate  to  System  !  Service  Parameters  !  10.10.13.11  !  Cisco  
CallManager.  
 

 
 
Locate  the  parameter  labeled  “T302  Timer”  under  the  “Clusterwide  Parameters  (Device  -­‐  General)”  
heading  and  set  it  to  a  value  of  “7500”.  
 

 
 
Click  the  Save  button  when  complete.  Make  sure  to  follow  the  above  steps  for  the  SB  CUCM  cluster  as  
well.  
 
   

284 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.11 Ensure  that  the  user  can  force  the  interdigit  timeout  period  to  end  by  pressing  the  #  
key  after  dialing  the  proper  amount  of  digits.  
 
This  task  is  asking  us  to  use  the  “#”  character  to  terminate  the  interdigit  timeout  period  for  
international  calls  on  both  clusters.  The  simplest  way  to  configure  this  requirement  is  to  copy  the  
existing  international  pattern  (9011!)  to  create  a  Route  Pattern  based  on  those  settings.  At  that  point,  
we  simply  need  to  change  the  pattern  to  “9011!#”  in  order  to  support  the  dialing  of  the  terminating  
character.  Once  again,  create  the  Digit  Manipulation  Table  to  organize  the  information  in  a  “clean”  
format  and  begin  the  configuration.    
 
Digit  Manipulation  Table  
Route  Pattern   9011!#  
ANI  Digits  Required   +E164    
DNIS  Digits  Required   All  digits,  no  “011”  prefix  
Calling  Party  Number  Type   International  
Called  Party  Number  Type   International  
Special  Requirements   N/A  
 
To  complete  the  requirements  on  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  
Route  Pattern  and  click  the  Find  button.  Click  on  the  previously  created  “9011.!”  pattern  to  enter  the  
“Route  Pattern  Configuration”  page.  Click  the  Copy  button  to  create  a  new  Route  Pattern  based  on  the  
existing  pattern.  Enter  the  Route  Pattern  of  “9011.!#”.  Ensure  that  a  Partition  is  selected  that  is  
accessible  by  all  phones  in  the  cluster  (e.g.  “PSTN_PT”).  Next,  select  the  “Gateway/Route  List”  from  the  
dropdown  box  to  ensure  that  the  pattern  uses  the  Standard  Local  Route  Group  (e.g.  “LOCAL_RL”).  
 

 
 
Next,  to  set  the  proper  number  of  digits  for  the  ANI,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  checkbox  under  the  “Calling  Party  Transformations”  section  in  order  to  use  the  entire  
+E164  number.  Also,  make  sure  to  set  the  “Calling  Party  Number  Type/Plan”  to  “International/ISDN”  
for  the  calling  number.    

285 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  set  the  “Discard  Digits”  dropdown  box  to  “PreDot  Trailing-­‐#”  to  ensure  that  the  “#”  is  stripped  
before  sending  to  the  PSTN.  Also,  set  the  “Called  Party  Number  Type/Plan”  to  “International”  and  
“ISDN”  under  the  “Called  Party  Transformations”  section.  
 

 
 
Click  the  Save  button  when  completed.    
 
To  test  the  configuration,  make  a  call  from  an  HQ  phone  to  an  international  PSTN  number  
(9011689220420#).  Use  the  debug isdn q931  command  on  the  gateway  to  ensure  that  the  call  is  
routed  to  the  destination  successfully.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 22 23:06:40.474: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000C


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x1181, '+14082221001'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '689220420'
Plan:ISDN, Type:International
Oct 22 23:06:40.510: ISDN Se0/0/0:23
R1#Q931: RX <- CALL_PROC pd = 8 callref = 0x800C
Channel ID i = 0xA98383
Exclusive, Channel 3

286 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Oct 22 23:06:40.646: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800C


Oct 22 23:06:41.766: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x800C
Oct 22 23:06:41.770: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x000C

On  the  SB  CUCM  cluster,  configure  call  routing  in  a  similar  fashion.  Once  again,  no  digit  manipulation  is  
done  until  it  reaches  the  gateway.  See  the  below  screenshot  for  the  CUCM  configuration.  
 

 
 
In  this  case,  the  R2  gateway  is  already  configured  to  route  the  call  to  the  PSTN!  This  is  because  the  
dial-peer  was  created  in  the  previous  task  (dial-peer voice 9011 pots).  In  IOS,  the  “#”  is  
the  default  terminating  digit,  so  there  is  no  need  to  strip  it  from  the  dialed  string.  Also,  since  the  
destination-pattern  uses  the  “T”  character,  it  is  expecting  the  terminating  digit  at  any  time.  
The  dial-peer  is  shown  below  for  your  reference.  
 
R2  
R2#sh run | sec dial-peer voice 9011
dial-peer voice 9011 pots
translation-profile outgoing TRANSLATE-INTL-OUTBOUND
destination-pattern 9011T
port 0/0/0:23
 
   

287 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  test  the  configuration,  make  a  call  from  an  SB  phone  to  an  international  number  by  dialing  
“9011689220420#”.  Run  the  debug isdn q931  command  on  the  R2  gateway  to  view  the  call  
details.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 22 23:11:14.389: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num
+13123332001
Oct 22 23:11:14.389: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x008A callID = 0x800B switch =
primary-ni interface = User
Oct 22 23:11:14.389: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x008A
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclus
R2#ive, Channel 3
Display i = 'SB Phone 1'
Calling Party Number i = 0x1181, '+13123332001'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '689220420'
Plan:ISDN, Type:International
Oct 22 23:11:14.433: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x808A
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 22 23:11:14.565: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808A
R2#
Oct 22 23:11:16.461: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x808A
Oct 22 23:11:16.465: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x008A
 
   

288 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.12 Configure  the  HQ  and  SB  clusters  to  support  toll-­‐free  calls.  The  user  should  dial  a  9  
first,  followed  by  1866,  followed  by  any  7  digits.  Send  +E164  ANI  and  Calling  Name.  
Send  a  10-­‐digit  DNIS  with  a  called  party  type  of  “National”.    
 
This  task  is  asking  us  to  configure  toll-­‐free  dialing  for  both  the  HQ  and  SB  CUCM  clusters.  Create  the  
Digit  Manipulation  Table  to  organize  the  information  in  a  “clean”  format  and  begin  the  configuration.    
 
Digit  Manipulation  Table  
Route  Pattern   91866XXXXXXX  
ANI  Digits  Required   +E164  
DNIS  Digits  Required   10  
Calling  Party  Number  Type   N/A  
Called  Party  Number  Type   National  
Special  Requirements   N/A  
 
To  complete  the  requirements  on  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Route/Hunt  !  
Route  Pattern  and  click  the  Add  New  button.  Enter  the  Route  Pattern  of  “91.866XXXXXXX”.  Ensure  that  
a  Partition  is  selected  that  is  accessible  by  all  phones  in  the  cluster  (e.g.  “PSTN_PT”).  Next,  select  the  
“Gateway/Route  List”  from  the  dropdown  box  to  ensure  that  the  pattern  uses  the  Standard  Local  
Route  Group  (e.g.  “LOCAL_RL”).  
 

 
 
   

289 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  to  set  the  proper  number  of  digits  for  the  ANI,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  checkbox  under  the  “Calling  Party  Transformations”  section.  Then  set  the  “Calling  Party  
Transform  Mask”  to  a  value  of  “XXXXXXXXXX”  so  only  the  rightmost  10  digits  are  used.  Also,  make  sure  
to  set  the  “Calling  Party  Number  Type/Plan”  to  “National/ISDN”  for  the  calling  number.    
 

 
 
Next,  set  the  “Discard  Digits”  dropdown  box  to  “PreDot”  and  the  “Called  Party  Number  Type/Plan”  to  
“National”  and  “ISDN”  under  the  “Called  Party  Transformations”  section.  
 

 
 
Click  the  Save  button  when  completed.    
 
To  test  the  configuration,  make  a  call  from  an  HQ  phone  to  a  toll-­‐free  PSTN  number  (918662258064).  
Use  the  debug isdn q931  command  on  the  gateway  to  ensure  that  the  call  is  routed  to  the  
destination  successfully.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 23 00:05:41.201: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000D


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x2181, '+14082221001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '8662258064'
Plan:ISDN, Type:National
Oct 23 00:05:41.245: ISDN Se0/0/0:23 Q931: RX

290 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R1#<- CALL_PROC pd = 8 callref = 0x800D


Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 23 00:05:41.393: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800D
Oct 23 00:05:42.449: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x800D
Oct 23 00:05:42.453: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x000D

On  the  SB  CUCM  cluster,  configure  call  routing  in  a  similar  fashion.  Once  again,  no  digit  manipulation  is  
done  until  it  reaches  the  gateway.  See  the  below  screenshot  for  the  CUCM  configuration.  
 

 
 
Just  as  was  done  previously,  configure  the  R2  gateway  to  route  the  call  to  the  PSTN  using  an  outbound  
POTS  dial-peer.  
 
R2  
R2(config)#dial-peer voice 866 pots
R2(config-dial-peer)#destination-pattern 91866.......$
R2(config-dial-peer)#port 0/0/0:23
R2(config-dial-peer)#forward-digits all

Next,  create  the  necessary  voice translation-rules  and  voice translation-


profiles  to  manipulate  the  digits  before  sending  to  the  PSTN.  Once  completed,  assign  the  
translation-profile  to  the  dial-peer.    
 
R2  
R2(config)#voice translation-rule 9
R2(cfg-translation-rule)#rule 1 /^\(2...$\)/ /+1312333\1/ type any national plan any isdn

R2(cfg-translation-rule)#voice translation-rule 10
R2(cfg-translation-rule)# rule 1 /^91\(866.......$\)/ /\1/ type any national plan any isdn

R2(config)#voice translation-profile TRANSLATE-TOLL-OUTBOUND


R2(cfg-translation-profile)#translate calling 9
R2(cfg-translation-profile)#translate called 10

R2(config)#dial-peer voice 866 pots


R2(config-dial-peer)#translation-profile outgoing TRANSLATE-TOLL-OUTBOUND
 
To  test  the  configuration,  make  a  call  from  an  SB  phone  to  a  toll-­‐free  number  by  dialing  
“918662258064”.  Run  the  debug isdn q931  command  on  the  R2  gateway  to  view  the  call  details.  

291 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 23 00:11:46.549: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num
+13123332001
Oct 23 00:11:46.549: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x008B callID = 0x800C switch =
primary-ni interface = User
Oct 23 00:11:46.549: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x008B
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclus
R2#ive, Channel 3
Display i = 'SB Phone 1'
Calling Party Number i = 0x2181, '+13123332001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '8662258064'
Plan:ISDN, Type:National
Oct 23 00:11:46.589: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x808B
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 23 00:11:46.721: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808B
R2#
Oct 23 00:11:47.845: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x808B
Oct 23 00:11:47.845: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x008B
 
   

292 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 16.13 All  calls  to  premium  numbers  (9-­‐1-­‐900,  plus  any  number  of  digits)  should  be  blocked.  
The  error  message  played  back  to  the  caller  should  be  “The  precedence  used  is  not  
authorized  for  your  line”.  Do  not  create  another  route  pattern  to  accomplish  this.  
 
The  final  task  in  this  lab  requires  that  we  block  calls  to  “premium”  numbers  that  use  the  “91900”  
pattern.  It  also  states  that  we  should  not  create  a  route  pattern  to  accomplish  the  task.  This  means  
that  we  must  create  a  translation  pattern  instead  for  the  blocking  of  these  calls.  
 
Navigate  to  Call  Routing  !  Translation  Pattern  and  click  the  Add  New  button.  In  the  “Translation  
Pattern”  field,  enter  the  pattern  in  question.  In  this  case,  the  number  must  start  with  a  “9”  followed  by  
“1900”  and  contain  any  number  of  digits.  Therefore,  the  pattern  must  be  entered  as  “91900!”.  Place  
this  pattern  inside  a  Partition  that  is  accessible  by  phones  on  the  cluster  (e.g.  “TRANSLATE_PT”).    
 

 
 
Next,  make  sure  that  the  proper  option  is  selected  for  the  “Route  Option”  setting.  In  this  case,  we  
should  use  the  “Block  This  Pattern”  checkbox.  Also,  we  should  specify  the  reason  as  “Precedence  Level  
Exceeded”  in  the  dropdown  box  to  meet  the  requirements  of  the  question.  
 

 
 
Click  the  Save  button  when  complete.  Make  sure  that  this  configuration  is  completed  on  the  SB  CUCM  
cluster  as  well.  

293 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 17: Advanced Dial-Plan Configuration


Task 17.1 When  a  phone  on  the  HQ  cluster  dials  a  number  in  the  312  area  code  (local  to  SB)  
ensure  that  the  call  is  routed  out  of  the  SB  gateway  as  a  local  call.  Send  a  10-­‐digit  
ANI  along  with  a  calling  party  number  type  of  national.  The  call  should  fall  back  to  
use  the  local  gateway  if  the  SB  gateway  is  unavailable.    
 
This  task  is  asking  us  to  configure  a  Tail  End  Hop  Off  (TEHO)  scenario  in  which  HQ  phones  utilize  the  
gateway  resources  on  the  SB  CUCM  cluster  to  make  calls  without  incurring  long  distance  charges  from  
the  PSTN  provider.  In  addition,  we  are  tasked  with  providing  a  backup  routing  option  if  the  call  should  
fail  to  successfully  traverse  the  SB  gateway  resource  (R2  SIP  GW).    
 
The  first  step  in  this  configuration  is  to  choose  a  trunk  that  will  be  used  to  route  the  call  from  the  HQ  to  
SB  CUCM  cluster.  Since  they  were  configured  previously,  we  have  the  option  to  use  either  the  SIP  or  
H.323  ICT.  In  this  case,  the  SIP  ICT  was  chosen  to  route  the  TEHO  calls.    
 
Next,  we  must  create  a  Route  List  to  contain  both  routing  options.  Navigate  to  Call  Routing  !  
Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Use  a  descriptive  name  to  label  the  Route  List  
(e.g.  “SB_SIP_ICT-­‐R1_MGCP_RL”).  Based  on  the  name,  we  know  that  the  SIP  ICT  to  SB  is  the  first  
routing  option  with  the  R1  MGCP  gateway  at  HQ  acting  as  the  backup.  Click  the  Save  button  to  go  to  
the  “Route  List  Configuration”  page.  
 

 
 
Add  the  “SB_SIP_ICT_RG”  and  “R1_MGCP_RG”  to  the  Route  List  (in  that  order)  by  clicking  the  Add  
Route  Group  button.  Click  the  Save  button  when  complete.  
 

 
 
   

294 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  Route  List  has  been  created,  we  must  create  a  Route  Pattern  for  calls  to  the  “312”  area  
code.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  Enter  
the  “Route  Pattern”  as  “91.312[2-­‐9]XXXXXX”  and  assign  a  Partition  that  is  accessible  by  the  HQ  Phones  
(e.g.  “PSTN_PT”).    
 

 
 
Next,  we  must  assign  a  “Gateway/Route  List”  from  the  dropdown  box  on  the  Route  Pattern.  This  will,  
of  course,  be  the  Route  List  that  was  recently  created  specifically  to  meet  the  task  requirements  (e.g.  
“SB_SIP_ICT-­‐R1_MGCP_RL”).  
 

 
 
Take  note  that  no  digit  manipulation  needs  to  occur  in  the  Route  Pattern.  Since  we  have  two  options  
for  how  the  call  should  be  routed,  it  makes  sense  that  the  manipulation  should  be  performed  in  the  
Route  List.  Before  we  explore  that  option,  click  the  Save  button  so  you  don’t  lose  your  work!  
 
With  the  Route  Pattern  saved,  click  the  “Edit”  link  next  to  the  “Gateway/Route  List”  option  on  the  
Route  Pattern.  From  here,  we  can  select  a  Route  Group  on  which  to  perform  digit  manipulation  from  
the  “Route  List  Details”  section.    
 

 
 
   

295 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  on  the  first  option  in  the  Route  List  (e.g.  “SB_SIP_ICT_RG”)  to  edit  the  settings.  On  the  “Route  List  
Detail  Configuration”  page,  we  can  perform  digit  manipulation  for  all  calls  going  over  the  SIP  ICT.  In  this  
case,  as  shown  below,  nothing  has  been  done  to  modify  the  dialed  string.  This  is  because  we  are  going  
to  rely  on  the  SB  cluster  to  properly  manipulate  the  digits  as  the  call  is  routed  out  the  SB  PSTN.  
 

 
 
Click  the  back  button  to  go  back  to  the  “Route  List  Configuration”  page.  Click  on  the  “R1_MGCP_RG”  
Route  Group  this  time  under  the  “Route  List  Details”  section.  Here,  we  must  manipulate  the  digits  so  
the  call  can  be  routed  successfully  out  the  R1  gateway.  Think  back  to  the  routing  requirements  in  the  
previous  lab  and  apply  the  correct  manipulations  here.  Below  is  the  Digit  Manipulation  table  for  long  
distance  numbers  when  dialed  from  the  HQ  CUCM  cluster.  
 
Digit  Manipulation  Table  
Route  Pattern   91[2-­‐9]XX[2-­‐9]XXXXXX  
ANI  Digits  Required   10  
DNIS  Digits  Required   10  
Calling  Party  Number  Type   National  
Called  Party  Number  Type   National  
Special  Requirements   N/A  
 
   

296 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Based  on  the  table,  set  the  “Route  List  Detail  Configuration”  parameters  accordingly.  
 

 
 
Now  in  the  case  where  the  primary  option  is  not  available,  calls  can  be  routed  successfully  out  the  R1  
MGCP  gateway  based  on  the  manipulations  that  are  configured  in  the  Route  List.  
 
Next,  we  must  configure  the  SB  CUCM  cluster  to  route  the  inbound  call  to  the  PSTN  gateway.  Since  the  
call  will  be  traversing  the  SIP  trunk,  we  must  ensure  that  we  have  the  proper  access  to  the  PSTN  
pattern  designated  to  route  the  call  (based  on  the  SIP  Trunk  CSS).  First,  however,  we  should  configure  a  
new  Route  Pattern  and  Partition  specifically  for  this  purpose  on  the  SB  CUCM  cluster  so  as  to  not  
override  settings  in  the  current  dial  plan.    
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  the  Add  New  button.  Enter  a  Partition  
to  be  assigned  to  the  new  Route  Pattern  (e.g.  “HQ_TEHO_PT”).  
 

 
 
Next,  we  must  create  a  CSS  to  be  assigned  to  the  SIP  ICT  to  support  inbound  calls  to  cluster  DNs  as  well  
as  the  TEHO  Route  Pattern.  Navigate  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  
click  the  Add  New  button.  Enter  a  descriptive  name  for  the  CSS  (e.g.  “HQ_TEHO_CSS”)  and  add  the  
“HQ_TEHO_PT”  in  addition  to  the  “INTERNAL_PT”  as  shown  below.  
 

 
 

297 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Once  the  CSS  has  been  created,  it  should  be  assigned  to  the  SIP  ICT  as  the  Inbound  CSS.  Navigate  to  
Device  !  Trunk  and  click  on  the  “HQ_SIP_ICT_TRUNK”  link.  Under  the  “Inbound  Calls”  section,  assign  
the  newly  created  “HQ_TEHO_CSS”  as  the  “Calling  Search  Space”.  
 

 
 
Click  the  Save  and  Reset  buttons  when  complete.  
 
Next,  create  the  TEHO  Route  Pattern  on  the  SB  CUCM  cluster  that  will  be  accessed  by  the  HQ  phones.  
Remember  that  the  digit  manipulation  must  follow  the  conventions  outlined  for  local  calls  in  the  
previous  lab.  See  the  below  table  for  the  requirements.  
 
Digit  Manipulation  Table  
Route  Pattern   9[2-­‐9]XXXXXX  
ANI  Digits  Required   7  
DNIS  Digits  Required   7  
Calling  Party  Number  Type   Subscriber  
Called  Party  Number  Type   Subscriber  
Special  Requirements   N/A  
 
Create  the  Route  Pattern  by  navigating  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  clicking  the  
Add  New  button.  Enter  the  pattern  that  will  be  received  from  the  HQ  cluster  as  “91312.[2-­‐9]XXXXXX”  
and  place  it  in  the  “HQ_TEHO_PT”  Partition  that  was  just  created.    
 

 
 
Next,  select  the  “Gateway/Route  List”  as  the  “R2_SIP_RL”  so  calls  can  be  routed  using  the  R2  gateway.  
 

 
 
Next,  we  can  perform  some  digit  manipulation  on  the  Route  Pattern  in  this  case.  Normally,  since  this  is  
a  SIP  gateway,  we  would  perform  all  formatting  on  the  gateway.  However,  in  this  case,  we  must  format  
the  number  to  match  the  “local”  dial-peer  that  has  already  been  created  on  R2.  We  can  

298 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

accomplish  this  by  setting  the  “Discard  Digits”  parameter  to  “PreDot”  and  setting  the  “Prefix  Digits  
(Outgoing  Calls)”  parameter  to  “9”.  
 

 
 
On  R2,  let’s  have  a  look  at  the  dial-peer  to  ensure  that  it  matches  what  is  being  sent  from  CUCM.    
 
R2  
R2#sh run | sec dial-peer voice 7

dial-peer voice 7 pots


translation-profile outgoing TRANSLATE-LOCAL-OUTBOUND
destination-pattern 9[2-9]......$
port 0/0/0:23
 
This  pattern  will  indeed  match  the  dial-peer.  Make  a  test  call  now  from  an  HQ  phone  to  the  SB  
PSTN  number  by  dialing  “913127764016”  and  view  the  output  using  the  debug isdn q931  
command  on  R2.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 23 07:17:38.920: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0 0x0, Calling num
1001
Oct 23 07:17:38.924: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x008F callID = 0x8010 switch =
primary-ni interface = User
Oct 23 07:17:38.924: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x008F
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x0081, '1001'
Plan:Unknown, Type:Unknown
Called Party Number i = 0xC1, '7764016'
Plan:ISDN, Type:Subscriber(local)
Oct 23 07:17:38.964: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x808F
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 23 07:17:39.084: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808F
Oct 23 07:17:43.944: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x008F
Cause i = 0x8090 - Normal call clearing
Oct 23 07:17:43.956: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x808F
Oct 23 07:17:43.956: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x008F
 

299 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

From  the  above  debug  output,  we  can  see  that  the  “Calling  Party  Number”  is  actually  being  sent  as  a  4-­‐
digit  number.  We  should  change  the  format  to  a  10-­‐digit  number  and  use  the  ISDN/National  plan  and  
type,  based  on  the  requirements  of  the  question.  We  can  accomplish  this  pretty  easily  by  simply  
adding  a  new  rule  to  the  existing  voice translation-rule  that  modifies  the  calling  number  for  
local  calls.  Based  on  the  configuration,  of  the  profile,  we  can  see  that  this  is  voice translation-
rule 3.  
 
R2  
R2#sh run | sec voice translation-profile TRANSLATE-LOCAL
voice translation-profile TRANSLATE-LOCAL-OUTBOUND
translate calling 3
translate called 4

R2#sh run | sec voice translation-rule 3


voice translation-rule 3
rule 1 /^\(2...$\)/ /333\1/ type any subscriber plan any isdn

R2(config)#voice translation-rule 3
R2(cfg-translation-rule)#rule 2 /^\(1...$\)/ /408222\1/ type any national plan any isdn
 
Run  the  debug isdn q931  command  on  R2  again  and  observe  the  output.  
 
R2  
Oct 23 07:28:33.476: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num
4082221001
Oct 23 07:28:33.476: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0091 callID = 0x8012 switch =
primary-ni interface = User
Oct 23 07:28:33.476: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0091
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusiv
R2#e, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x2181, '4082221001'
Plan:ISDN, Type:National
Called Party Number i = 0xC1, '7764016'
Plan:ISDN, Type:Subscriber(local)
Oct 23 07:28:33.512: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8091
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 23 07:28:33.628: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8091
R2#
Oct 23 07:28:43.560: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8091
Oct 23 07:28:43.560: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0091

This  time,  we  can  see  that  the  call  is  sent  out  in  10-­‐digit  format  for  the  calling  number.    
 
As  a  final  step,  we  should  shut  down  the  “local”  dial-peer  on  the  R2  gateway  in  order  to  force  the  
call  to  fail  over  to  the  second  Route  List  option  of  the  R1  MGCP  gateway.  
 
R2  
R2(config)#dial-peer voice 7
R2(config-dial-peer)#shutdown
 

300 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  make  the  test  call  again  while  running  the  debug isdn q931  command  on  the  R1  gateway  to  
capture  the  output.  
 
R1  
Oct 23 07:51:31.255: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000E
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x2181, '4082221001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '3127764016'
Plan:ISDN, Type:National
Oct 23 07:51:31.291: ISDN Se0/0/0:23 Q931: RX <-
R1# CALL_PROC pd = 8 callref = 0x800E
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 23 07:51:31.411: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800E
R1#
Oct 23 07:51:40.823: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x800E
Oct 23 07:51:40.855: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x000E
R1#
Oct 23 07:53:33.182: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x000E
Cause i = 0x8090 - Normal call clearing
Oct 23 07:53:33.190: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x800E
Oct 23 07:53:33.214: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x000E

Remember  to  issue  the  no shutdown  command  under  the  “local”  dial-peer  on  the  R2  gateway  
to  ensure  that  it  can  still  route  calls  as  normal.  
 
R2  
R2(config)#dial-peer voice 7
R2(config-dial-peer)#no shutdown
 
   

301 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 17.2 When  a  phone  on  the  SB  cluster  dials  a  number  in  the  408  area  code  (local  to  HQ)  
ensure  that  the  call  is  routed  out  of  the  HQ  gateway  as  a  local  call.  Send  a  10-­‐digit  
ANI  along  with  a  calling  party  number  type  of  national.  The  call  should  fall  back  to  
use  the  local  gateway  if  the  HQ  gateway  is  unavailable.    
 
This  task  is  asking  us  to  configure  a  Tail  End  Hop  Off  (TEHO)  scenario  in  which  SB  phones  utilize  the  
gateway  resources  on  the  HQ  CUCM  cluster  to  make  calls  without  incurring  long  distance  charges  from  
the  PSTN  provider.  In  addition,  we  are  tasked  with  providing  a  backup  routing  option  if  the  call  should  
fail  to  successfully  traverse  the  HQ  gateway  resource  (R1  MGCP  GW).    
 
The  first  step  in  this  configuration  is  to  choose  a  trunk  that  will  be  used  to  route  the  call  from  the  SB  to  
HQ  CUCM  cluster.  Since  they  were  configured  previously,  we  have  the  option  to  use  either  the  SIP  or  
H.323  ICT.  In  this  case,  the  SIP  ICT  was  chosen  to  route  the  TEHO  calls.    
 
Next,  we  must  create  a  Route  List  to  contain  both  routing  options.  Navigate  to  Call  Routing  !  
Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Use  a  descriptive  name  to  label  the  Route  List  
(e.g.  “HQ_SIP_ICT-­‐R2_SIP_RL”).  Based  on  the  name,  we  know  that  the  SIP  ICT  to  HQ  is  the  first  routing  
option  with  the  R2  SIP  gateway  at  SB  acting  as  the  backup.  Click  the  Save  button  to  go  to  the  “Route  
List  Configuration”  page.  
 

 
 
Add  the  “HQ_SIP_ICT_RG”  and  “R2_SIP_RG”  to  the  Route  List  (in  that  order)  by  clicking  the  Add  Route  
Group  button.  Click  the  Save  button  when  complete.  
 

 
 
   

302 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  Route  List  has  been  created,  we  must  create  a  Route  Pattern  for  calls  to  the  “408”  area  
code.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  Enter  
the  “Route  Pattern”  as  “91408[2-­‐9]XXXXXX”  and  assign  a  Partition  that  is  accessible  by  the  SB  Phones  
(e.g.  “PSTN_PT”).    
 

 
 
Next,  we  must  assign  a  “Gateway/Route  List”  from  the  dropdown  box  on  the  Route  Pattern.  This  will,  
of  course,  be  the  Route  List  that  was  recently  created  specifically  to  meet  the  task  requirements  (e.g.  
“HQ_SIP_ICT-­‐R2_SIP_RL”).  
 

 
 
Take  note  that  no  digit  manipulation  needs  to  occur  in  the  Route  Pattern  at  this  point.  However,  we  
should  modify  the  Route  List  option  for  the  SIP  ICT  destination.  This  is  because  we  need  to  set  the  
number  of  digits  displayed  in  the  ANI  to  “10”.  This  cannot  be  done  successfully  after  the  call  has  
already  been  passed  to  the  HQ  CUCM  cluster.  Therefore,  we  must  make  the  change  here.  In  order  to  
make  the  necessary  modification,  click  the  “Edit”  link  next  to  the  “Gateway/Route  List”  parameter  in  
the  Route  Pattern.  On  the  “Route  List  Configuration”  page,  click  the  “HQ_SIP_ICT_RG”  under  the  
“Route  List  Details”  heading.  
 

 
 
Set  the  “Use  Calling  Party's  External  Phone  Number  Mask”  dropdown  box  to  “On”  and  set  the  “Calling  
Party  Transform  Mask”  to  a  value  of  “XXXXXXXXXX”  in  order  to  use  the  rightmost  10  digits  from  the  
string.  
 

 
 
   

303 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  configure  the  HQ  CUCM  cluster  to  route  the  inbound  call  from  SB  to  the  PSTN  gateway.  
Since  the  call  will  be  traversing  the  SIP  trunk,  we  must  ensure  that  we  have  the  proper  access  to  the  
PSTN  pattern  designated  to  route  the  call  (based  on  the  SIP  Trunk  CSS).  First,  however,  we  should  
configure  a  new  Route  Pattern  and  Partition  specifically  for  this  purpose  on  the  HQ  CUCM  cluster  so  as  
to  not  override  settings  in  the  current  dial  plan.    
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  the  Add  New  button.  Enter  a  Partition  
to  be  assigned  to  the  new  Route  Pattern  (e.g.  “SB_TEHO_PT”).  
 

 
 
Next,  we  must  create  a  CSS  to  be  assigned  to  the  SIP  ICT  to  support  inbound  calls  to  cluster  DNs  as  well  
as  the  TEHO  Route  Pattern.  Navigate  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  
click  the  Add  New  button.  Enter  a  descriptive  name  for  the  CSS  (e.g.  “SB_TEHO_CSS”)  and  add  the  
“SB_TEHO_PT”  in  addition  to  the  “INTERNAL_PT”  as  shown  below.  
 

 
 
Once  the  CSS  has  been  created,  it  should  be  assigned  to  the  SIP  ICT  as  the  inbound  CSS.  Navigate  to  
Device  !  Trunk  and  click  on  the  “SB_SIP_ICT_TRUNK”  link.  Under  the  “Inbound  Calls”  section,  assign  
the  newly  created  “SB_TEHO_CSS”  as  the  “Calling  Search  Space”.  
 

 
 
Click  the  Save  and  Reset  buttons  when  complete.  
 
   

304 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  create  the  TEHO  Route  Pattern  on  the  HQ  CUCM  cluster  that  will  be  accessed  by  the  SB  phones.  
Remember  that  the  digit  manipulation  must  follow  the  conventions  outlined  for  local  calls  in  the  
previous  lab.  See  the  below  table  for  the  requirements.  
 
Digit  Manipulation  Table  
Route  Pattern   9[2-­‐9]XXXXXX  
ANI  Digits  Required   7  
DNIS  Digits  Required   7  
Calling  Party  Number  Type   Subscriber  
Called  Party  Number  Type   Subscriber  
Special  Requirements   N/A  
 
Create  the  Route  Pattern  by  navigating  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  clicking  the  
Add  New  button.  Enter  the  pattern  that  will  be  received  from  the  SB  cluster  as  “91408.[2-­‐9]XXXXXX”  
and  place  it  in  the  “SB_TEHO_PT”  Partition  that  was  just  created.    
 

 
 
Next,  select  the  “Gateway/Route  List”  as  the  “R1_MGCP_RL”  so  calls  can  be  routed  using  the  R1  MGCP  
gateway.  
 

 
 
Next,  we  should  perform  some  digit  manipulation  on  the  Route  Pattern  in  this  case.  Under  the  “Calling  
Party  Transformations”  section,  we  should  set  the  “Calling  Party  Number  Type/Plan”  to  meet  the  
requirements  of  the  question  (e.g.  “National/ISDN”).  Remember,  the  number  was  previously  
manipulated  to  use  a  10-­‐digit  ANI  before  it  was  sent  over  the  SIP  ICT  by  the  SB  CUCM  cluster.  
 

 
 

305 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “Called  Party  Transformations”  section,  set  the  “Discard  Digits”  parameter  to  “PreDot”  
and  the  “Called  Party  Number  Type/Plan”  to  “Subscriber/ISDN”.  
 

 
 
Now,  we  can  make  a  test  call  from  an  SB  phone  to  the  HQ  PSTN  number  by  dialing  “914086131218”.  
Examine  the  output  on  the  R1  MGCP  gateway  using  the  debug isdn q931  command.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 23 08:46:06.151: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000F


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Calling Party Number i = 0x21A3, '3123332001'
Plan:ISDN, Type:National
Called Party Number i = 0xC1, '6131218'
Plan:ISDN, Type:Subscriber(local)
Oct 23 08:46:06.191: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 cal
R1#lref = 0x800F
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 23 08:46:06.303: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800F
R1#
Oct 23 08:46:16.663: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x000F
Cause i = 0x8090 - Normal call clearing
Oct 23 08:46:16.675: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x800F
Oct 23 08:46:16.707: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x000F

Next,  we  must  fail  the  R1  MGCP  gateway  so  we  can  ensure  that  the  call  is  still  routed  successfully  out  
the  R2  SIP  gateway.  The  easiest  way  to  accomplish  this  is  to  issue  the  no mgcp  command  on  the  R1  
gateway.  This  will  prevent  the  call  from  being  sent  from  the  HQ  CUCM  cluster  to  R1.    
 
R1  
R1(config)#no mgcp
 
   

306 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  enter  the  debug isdn q931  command  on  R2  and  observe  the  output.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 23 08:49:46.253: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num
3123332001
Oct 23 08:49:46.253: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0092 callID = 0x8013 switch =
primary-ni interface = User
Oct 23 08:49:46.253: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0092
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusiv
R2#e, Channel 3
Display i = 'SB Phone 1'
Calling Party Number i = 0x2181, '3123332001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '4086131218'
Plan:ISDN, Type:National
Oct 23 08:49:46.293: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8092
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 23 08:49:46.453: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8092
R2#
Oct 23 08:49:55.141: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8092
Oct 23 08:49:55.141: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0092

Based  on  the  above,  the  call  has  been  routed  successfully  to  the  backup  Route  List  destination.  Make  
sure  to  re-­‐enable  MGCP  on  the  R1  gateway.  
 
R1  
R1(config)#mgcp
 
   

307 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 17.3 When  phones  on  either  the  HQ  or  SB  cluster  dial  international  numbers  using  
country  code  49,  the  Germany  country  code  (local  to  SC),  ensure  that  the  call  is  
routed  out  of  the  SC  gateway.  Calls  should  be  routed  using  SIP  through  the  CUBE  on  
R1  to  accomplish  this.  Send  +E.164  ANI  with  a  calling  party  number  type  of  
international.  Fall  back  to  the  local  gateway  if  the  call  is  unsuccessful.  
 
This  task  requires  that  TEHO  calls  for  SC  PSTN  destinations  on  the  R3  gateway  be  configured  for  both  
the  HQ  and  SB  CUCM  clusters.  The  calls  must  successfully  route  through  the  CUBE  on  R1  before  
reaching  the  PSTN  on  R3.    
 
In  order  to  complete  the  requirement,  we  will  need  to  create  a  Route  List  with  two  options  on  both  
clusters.  The  first  option  will  be  the  “CUBE_SIP_RG”  on  both  the  HQ  and  SB  CUCM  clusters.  The  second  
option  will  be  the  Route  Group  corresponding  to  the  local  gateway  at  HQ  and  SB,  “R1_MGCP_RG”  and  
“R2_SIP_RG”,  respectively.  
 
On  the  HQ  CUCM  cluster,  we  must  create  a  Route  List  to  contain  both  routing  options.  Navigate  to  Call  
Routing  !  Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Use  a  descriptive  name  to  label  
the  Route  List  (e.g.  “CUBE_SIP-­‐R1_MGCP_RL”).  Based  on  the  name,  we  know  that  the  CUBE  SIP  trunk  is  
the  first  routing  option  with  the  R1  MGCP  gateway  at  HQ  acting  as  the  backup.  Click  the  Save  button  to  
go  to  the  “Route  List  Configuration”  page.  
 

 
 
In  the  “Route  List  Configuration”  page,  add  the  “CUBE_SIP_RG”  and  the  “R1_MGCP_RG”  Route  Groups  
by  clicking  the  Add  Route  Group  button.  
 

 
 
Click  the  Save  button  when  complete.  
 
   

308 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  Route  List  has  been  created,  we  must  create  a  Route  Pattern  for  calls  to  the  “49”  country  
code.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  Enter  
the  “Route  Pattern”  as  “9011.49!”  and  assign  a  Partition  that  is  accessible  by  the  HQ  Phones  (e.g.  
“PSTN_PT”).    
 

 
 
Next,  we  must  assign  a  “Gateway/Route  List”  from  the  dropdown  box  on  the  Route  Pattern.  This  will,  
of  course,  be  the  Route  List  that  was  recently  created  specifically  to  meet  the  task  requirements  (e.g.  
“CUBE_SIP-­‐R1_MGCP_RL”).  
 

 
 
Take  note  that  no  digit  manipulation  needs  to  occur  in  the  Route  Pattern.  Since  we  have  two  options  
for  call  routing,  it  makes  sense  that  the  manipulation  should  be  performed  in  the  Route  List.  Before  we  
explore  that  option,  click  the  Save  button  so  you  don’t  lose  your  work!  
 
With  the  Route  Pattern  saved,  click  the  “Edit”  link  next  to  the  “Gateway/Route  List”  option  on  the  
Route  Pattern.  From  here,  we  can  select  a  Route  Group  on  which  to  perform  digit  manipulation  from  
the  “Route  List  Details”  section.  
 

 
 
Click  on  the  first  option  in  the  Route  List  (e.g.  “CUBE_SIP_RG”)  to  edit  the  settings.  On  the  “Route  List  
Detail  Configuration”  page,  we  can  perform  digit  manipulation  for  all  calls  going  over  the  CUBE  SIP  
trunk.  In  this  case,  as  shown  below,  we  have  modified  the  4-­‐digit  extension  to  instead  use  the  +E.164  
number  for  the  ANI.  No  manipulations  need  to  be  performed  here  for  the  ISDN  Plan/Type  settings.    
 

 
 

309 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “Called  Party  Transformations”  settings,  we  can  modify  the  number  to  send  the  E.164  
number  in  the  dialed  string.  Of  course,  this  setting  is  completely  optional,  since  digit  manipulation  can  
be  done  anywhere  and  in  any  way  necessary  to  route  the  call.  For  the  “Discard  Digits”  parameter,  we  
should  select  the  “NANP:PreDot  Trailing-­‐#”  option  in  this  case.  This  will  ensure  that  if  the  “#”  character  
is  entered  to  avoid  waiting  for  the  timeout  of  the  T.302  timer,  it  is  stripped  before  sending  to  the  
gateway/trunk.  This  is  not  necessary  for  the  above  pattern  of  “9011.49!”,  but  will  be  needed  for  the  
“9011.49!#”  pattern.  Once  again,  no  manipulations  are  required  for  the  ISDN  Plan/Type  settings.  
 

 
 
Click  the  back  button  to  go  back  to  the  “Route  List  Configuration”  page.  Click  on  the  “R1_MGCP_RG”  
Route  Group  this  time  under  the  “Route  List  Details”  section.  Here,  we  must  manipulate  the  digits  so  
the  call  can  be  routed  successfully  out  the  R1  gateway.  Think  back  to  the  routing  requirements  in  the  
previous  lab  and  apply  the  correct  manipulations  here.  Below  is  the  Digit  Manipulation  table  for  
international  numbers  when  dialed  from  the  HQ  CUCM  cluster.  
 
Digit  Manipulation  Table  
Route  Pattern   9011!  
ANI  Digits  Required   +E.164    
DNIS  Digits  Required   All  digits,  no  “011”  prefix  
Calling  Party  Number  Type   International  
Called  Party  Number  Type   International  
Special  Requirements   N/A  
 
Based  on  the  table  set  the  “Route  List  Detail  Configuration”  parameters  accordingly.  
 

 
 

310 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  in  the  case  where  the  primary  option  is  not  available,  calls  can  be  routed  successfully  out  the  R1  
MGCP  gateway  based  on  the  manipulations  that  are  configured  in  the  Route  List.  
 
Next,  we  must  configure  the  CUBE  to  accept  the  SIP  call  and  route  it  to  the  R3  gateway.  To  accomplish  
this,  we  must  create  a  new  dial-peer  that  matches  the  E.164  number  being  sent.  This  dial-peer  
will  serve  both  inbound  and  outbound  purposes  for  the  CUBE.  
 
R1  
R1(config)#dial-peer voice 49 voip
R1(config-dial-peer)#destination-pattern 49T
R1(config-dial-peer)#session protocol sipv2
R1(config-dial-peer)#session target ipv4:10.10.31.1
R1(config-dial-peer)#incoming called-number 49T
R1(config-dial-peer)#no vad
 
Once  the  dial-peer  is  created  on  R1,  we  should  also  create  a  dial-peer  on  R3  to  support  these  
calls  as  well.  We  will  need  a  VoIP  dial-peer  to  accept  the  inbound  call  and  a  POTS  dial-peer  to  
route  the  call  to  the  PSTN.  We  will  also  need  a  voice translation-rule/profile  to  format  
the  call  properly  as  it  is  forwarded  to  the  PSTN.  
 
R3  
R3(config)#voice translation-rule 2
R3(cfg-translation-rule)#rule 1 /^\+1.*/ /\0/ type any international plan any isdn

R3(cfg-translation-rule)#voice translation-rule 3
R3(cfg-translation-rule)#rule 1 /^49\(30.*\)/ /\1/ type any national plan any isdn

R3(config)#voice translation-profile TRANSLATE-TEHO-OUTBOUND


R3(cfg-translation-profile)#translate calling 2
R3(cfg-translation-profile)#translate called 3

R3(config)#dial-peer voice 2 voip


R3(config-dial-peer)#incoming called-number .
R3(config-dial-peer)#voice-class codec 1
R3(config-dial-peer)#no vad

R3(config-dial-peer)#dial-peer voice 49 pots


R3(config-dial-peer)#translation-profile outgoing TRANSLATE-TEHO-OUTBOUND
R3(config-dial-peer)#destination-pattern 49T
R3(config-dial-peer)#port 0/0/0:15
R3(config-dial-peer)#forward-digits all
 
In  the  above,  the  ISDN  Plan/Type  is  being  applied  to  the  ANI,  the  “49”  is  being  dropped  from  the  DNIS,  
and  the  “National/ISDN”  Plan  and  Type  are  being  applied  to  the  DNIS.  The  inbound  call  is  accepted  at  
dial-peer voice 2 voip  and  sent  to  the  PSTN  via  dial-peer voice 49 pots.  
 
   

311 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  order  to  test  the  configuration,  make  a  test  call  from  an  HQ  phone  to  the  SC  PSTN  number  
(“901149307128788”)  and  observe  the  output  on  the  R3  gateway  while  running  the  debug isdn
q931  command.  If  the  call  fails,  you  may  need  to  troubleshoot  using  the  debug ccsip messages  
command  on  the  CUBE  (R1)  and  R3.  
 
R3  
R3#debug isdn q931
debug isdn q931 is ON.

Oct 24 03:19:42.057: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x1 0x1, Calling num
+14082221001
Oct 24 03:19:42.057: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x0081 callID = 0x8002 switch =
primary-net5 interface = User
Oct 24 03:19:42.057: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0081
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exc
R3#lusive, Channel 3
Calling Party Number i = 0x1181, '+14082221001'
Plan:ISDN, Type:International
Called Party Number i = 0xA1, '307128788'
Plan:ISDN, Type:National
Oct 24 03:19:42.097: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8081
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 24 03:19:42.221: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8081
R3#
Oct 24 03:19:48.381: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x8081
Oct 24 03:19:48.385: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0081

Don’t  forget  to  test  the  failover  functionality  to  R1!  Once  again,  this  can  be  accomplished  by  shutting  
down  dial-peer voice 49 pots  on  R3.  Run  the  debug isdn q931  command  on  the  R1  
gateway  to  ensure  the  call  is  routed  properly.  
 
R3  
R3(config)#dial-peer voice 49 pots
R3(config-dial-peer)#shutdown

R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 24 05:13:26.560: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0002


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x1181, '+14082221001'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '49307128788'
Plan:ISDN, Type:International
Oct 24 05:13:26.596: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8002
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 24 05:13:26.728: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8002
Oct 24 05:13:30.260: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8002

312 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Oct 24 05:13:30.264: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0002

Make  sure  to  re-­‐enable  dial-peer voice 49 pots  on  R3  by  issuing  the  no shutdown  
command.    
 
R3  
R3(config)#dial-peer voice 49 pots
R3(config-dial-peer)#shutdown
 
Now  that  TEHO  has  been  configured  on  the  HQ  CUCM  cluster  for  the  SC  PSTN,  we  must  configure  the  
SB  CUCM  cluster  to  route  calls  to  the  German  PSTN  using  TEHO  through  R3.    
 
On  the  SB  CUCM  cluster,  we  must  create  a  Route  List  to  contain  both  routing  options.  Navigate  to  Call  
Routing  !  Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Use  a  descriptive  name  to  label  
the  Route  List  (e.g.  “CUBE_SIP-­‐R2_SIP_RL”).  Based  on  the  name,  we  know  that  the  CUBE  SIP  trunk  is  
the  first  routing  option  with  the  R2  SIP  gateway  at  SB  acting  as  the  backup.  Click  the  Save  button  to  go  
to  the  “Route  List  Configuration”  page.  
 

 
 
In  the  “Route  List  Configuration”  page,  add  the  “CUBE_SIP_RG”  and  the  “R2_SIP_RG”  Route  Groups  by  
clicking  the  Add  Route  Group  button.  
 

 
 
Click  the  Save  button  when  complete.  
 
   

313 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  Route  List  has  been  created,  we  must  create  a  Route  Pattern  for  calls  to  the  “49”  country  
code.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  Enter  
the  “Route  Pattern”  as  “9011.49!”  and  assign  a  Partition  that  is  accessible  by  the  SB  Phones  (e.g.  
“PSTN_PT”).    
 

 
 
Next,  we  must  assign  a  “Gateway/Route  List”  from  the  dropdown  box  on  the  Route  Pattern.  This  will,  
of  course,  be  the  Route  List  that  was  recently  created  specifically  to  meet  the  task  requirements  (e.g.  
“CUBE_SIP-­‐R2_SIP_RL”).  
 

 
 
Take  note  that  no  digit  manipulation  needs  to  occur  in  the  Route  Pattern.  Since  we  have  two  options  
for  call  routing,  it  makes  sense  that  the  manipulation  should  be  performed  in  the  Route  List.  Before  we  
explore  that  option,  click  the  Save  button  so  you  don’t  lose  your  work!  
 
With  the  Route  Pattern  saved,  click  the  “Edit”  link  next  to  the  “Gateway/Route  List”  option  on  the  
Route  Pattern.  From  here,  we  can  select  a  Route  Group  on  which  to  perform  digit  manipulation  from  
the  “Route  List  Details”  section.    
 

 
 
Click  on  the  first  option  in  the  Route  List  (e.g.  “CUBE_SIP_RG”)  to  edit  the  settings.  On  the  “Route  List  
Detail  Configuration”  page,  we  can  perform  digit  manipulation  for  all  calls  going  over  the  CUBE  SIP  
trunk.  In  this  case,  as  shown  below,  we  have  modified  the  4-­‐digit  extension  to  instead  use  the  +E.164  
number  for  the  ANI.  No  manipulations  need  to  be  performed  here  for  the  ISDN  Plan/Type  settings.    
 

 
 
Next,  under  the  “Called  Party  Transformations”  settings,  we  can  modify  the  number  to  send  the  E.164  
number  in  the  dialed  string.  Of  course,  this  setting  is  completely  optional,  since  digit  manipulation  can  

314 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

be  done  anywhere  and  in  any  way  necessary  to  route  the  call.  For  the  “Discard  Digits”  parameter,  we  
should  select  the  “NANP:PreDot  Trailing-­‐#”  option  in  this  case.  This  will  ensure  that  if  the  “#”  character  
is  entered  to  avoid  waiting  for  the  timeout  of  the  T.302  timer,  it  is  stripped  before  sending  to  the  
gateway/trunk.  This  is  not  necessary  for  the  above  pattern  of  “9011.49!”,  but  will  be  needed  for  the  
“9011.49!#”  pattern.  Once  again,  no  manipulations  are  required  for  the  ISDN  Plan/Type  settings.  
 

 
 
Click  the  back  button  to  go  back  to  the  “Route  List  Configuration”  page.  Click  on  the  “R2_SIP_RG”  
Route  Group  this  time  under  the  “Route  List  Details”  section.  Here,  we  must  manipulate  the  digits  so  
the  call  can  be  routed  successfully  out  the  R2  gateway.  Think  back  to  the  routing  requirements  in  the  
previous  lab  and  apply  the  correct  manipulations  here.  Below  is  the  Digit  Manipulation  table  for  
international  numbers  when  dialed  from  the  SB  CUCM  cluster.  
 
Digit  Manipulation  Table  
Route  Pattern   9011!  
ANI  Digits  Required   +E.164    
DNIS  Digits  Required   All  digits,  no  “011”  prefix  
Calling  Party  Number  Type   International  
Called  Party  Number  Type   International  
Special  Requirements   N/A  
 
   

315 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  set  the  “Route  List  Detail  Configuration”  parameters  accordingly.  Remember,  this  section  
provides  formatting  that  will  allow  the  dialed  digits  to  match  the  “International”  dial-peer  on  R2.    
 

 
 
Now  in  the  case  where  the  primary  option  is  not  available,  calls  can  be  routed  successfully  out  the  R2  
SIP  gateway  based  on  the  manipulations  that  are  configured  in  the  Route  List.  Since  the  CUBE  was  
configured  in  the  previous  section,  all  that  we  need  to  do  here  is  make  a  test  call.  
 
In  order  to  test  the  configuration,  make  a  test  call  from  an  SB  phone  to  the  SC  PSTN  number  
(“901149307128788”)  and  observe  the  output  on  the  R3  gateway  while  running  the  debug isdn
q931  command.  If  the  call  fails,  you  may  need  to  troubleshoot  using  the  debug ccsip messages  
command  on  the  CUBE  (R1)  and  R2.  
 
R3  
R3#debug isdn q931
debug isdn q931 is ON.

Oct 24 03:44:01.171: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x1 0x1, Calling num
+13123332001
Oct 24 03:44:01.171: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x0082 callID = 0x8003 switch =
primary-net5 interface = User
Oct 24 03:44:01.175: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0082
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Calling Party Number i = 0x1181, '+13123332001'
Plan:ISDN, Type:International
Called Party Number i = 0xA1, '307128788'
Plan:ISDN, Type:National
Oct 24 03:44:01.211: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8082
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 24 03:44:01.335: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8082
Oct 24 03:44:06.779: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x8082
Oct 24 03:44:06.779: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0082

316 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Once  again,  we  must  test  the  failover  functionality  to  R2!  Shut  down  dial-peer voice 49 pots  
on  R3  and  run  the  debug isdn q931  command  on  the  R2  gateway  to  ensure  the  call  is  routed  
properly.  
 
R3  
R3(config)#dial-peer voice 49 pots
R3(config-dial-peer)#shutdown

R2  
R2#debug isdn q931
debug isdn q931 is ON.

Oct 24 05:23:34.782: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0 0x0, Calling num
+13123332001
Oct 24 05:23:34.786: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0093 callID = 0x8014 switch =
primary-ni interface = User
Oct 24 05:23:34.786: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0093
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclus
R2#ive, Channel 3
Display i = 'SB Phone 1'
Calling Party Number i = 0x0081, '+13123332001'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x91, '49307128788'
Plan:ISDN, Type:International
Oct 24 05:23:34.822: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8093
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 24 05:23:35.630: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8093
R2#
Oct 24 05:23:44.906: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8093
Oct 24 05:23:44.910: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0093

Make  sure  to  re-­‐enable  dial-peer voice 49 pots  on  R3  by  issuing  the  no shutdown  
command.  
 
R3  
R3(config)#dial-peer voice 49 pots
R3(config-dial-peer)#shutdown

317 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 18: Digit Manipulations and Presentations


Task 18.1 Using  the  route  pattern  that  was  configured  in  Task  16.7,  ensure  that  all  digit  
manipulation  is  done  at  the  route  pattern  level.  This  configuration  applies  to  the  HQ  
site  only.  
 
The  task  outlined  in  16.7  refers  to  supporting  7-­‐digit  local  dialing  for  both  the  HQ  and  SB  CUCM  
clusters.  In  this  task,  we’ve  been  asked  to  ensure  that  the  digit  manipulation  occurs  in  the  Route  
Pattern  only.  This  means  that  we  must  not  use  a  Route  List  or  a  Calling/Called  Party  Transformation  
Pattern  to  format  the  number.  Take  a  look  at  the  Digit  Manipulation  Table  below  to  understand  how  
the  number  should  be  formatted.  Remember,  this  task  is  only  supposed  to  be  configured  for  the  HQ  
CUCM  cluster!  
 
Digit  Manipulation  Table  
Route  Pattern   9[2-­‐9]XXXXXX  
ANI  Digits  Required   7  
DNIS  Digits  Required   7  
Calling  Party  Number  Type   Subscriber  
Called  Party  Number  Type   Subscriber  
Special  Requirements   N/A  
 
In  this  case,  the  digit  manipulation  was  already  performed  at  the  Route  Pattern  level  for  this  task  (per  
the  Lab  16  Detailed  Solution  Guide).  However,  let’s  analyze  how  it  was  done.  On  the  HQ  CUCM  cluster,  
navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Find  button.  Click  on  the  “9.[2-­‐
9]XXXXXX”  pattern  in  the  “PSTN_PT”  Partition.  Under  the  “Calling  Party  Transformations”  section,  the  
parameters  were  set  for  the  ANI.    
 
To  meet  the  requirement  of  sending  a  7-­‐digit  number,  the  combination  of  the  “Use  Calling  Party's  
External  Phone  Number  Mask”  and  “Calling  Party  Transform  Mask”  parameters  were  used.  This  uses  
only  the  rightmost  7  digits  from  the  Calling  Party  Number  in  this  case,  which  meets  the  requirement.  
Next,  the  “Calling  Party  Number  Type”  was  set  to  “Subscriber”  (meaning  a  local  number)  and  the  
“Calling  Party  Numbering  Plan”  was  set  to  “ISDN”  (indicating  a  network  outside  of  CUCM).  These  
settings  were  also  required  by  the  question.  
 

 
 

318 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “Called  Party  Transformations”  section,  the  DNIS  was  manipulated.  In  the  “Discard  
Digits”  dropdown  box,  the  “PreDot”  option  was  selected.  This  means  that  everything  to  the  left  of  the  
“dot”  character  in  the  Route  Pattern  was  discarded.  Since  the  pattern  in  this  case  is  “9.[2-­‐9]XXXXXX”,  
this  means  that  the  “9”  was  dropped  from  the  dialed  string.  Next,  the  “Called  Party  Number  Type”  and  
“Called  Party  Numbering  Plan”  were  set  to  “Subscriber”  and  “ISDN”,  respectively.  This  meets  the  
requirements  of  the  question  and  formats  the  DNIS  appropriately.  
 

 
 
At  this  point,  all  digit  manipulation  has  been  configured  for  7-­‐digit  local  calls  at  HQ.  Make  a  test  call  
from  an  HQ  phone  to  the  local  HQ  PSTN  (96131218)  in  order  to  confirm  the  configuration.  Enter  the  
debug isdn q931  command  on  the  R1  MGCP  gateway.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 24 08:27:48.125: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0004


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x4181, '2221002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '6131218'
Plan:ISDN, Type:Subscriber(local)
Oct 24 08:27:48.165: ISDN Se0/0/0:23
R1# Q931: RX <- CALL_PROC pd = 8 callref = 0x8004
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 24 08:27:48.281: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8004
 
   

319 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 18.2 Using  the  route  pattern  that  was  configured  in  Task  16.8,  ensure  that  all  digit  
manipulation  is  done  at  the  route  list  level.  You  may  create  a  new  route  list  if  so  
desired.  This  configuration  applies  to  the  HQ  site  only.  Use  the  number  810-­‐332-­‐
1444  to  test  this  (it  will  ring  line  6  on  the  PSTN  phone).  
 
The  task  outlined  in  16.8  refers  to  supporting  11-­‐digit  long  distance  dialing  for  both  the  HQ  and  SB  
CUCM  clusters.  In  this  task,  we’ve  been  asked  to  ensure  that  the  digit  manipulation  occurs  in  the  Route  
List  only.  This  means  that  we  must  not  use  a  Route  Pattern  or  a  Calling/Called  Party  Transformation  
Pattern  to  format  the  number.  Take  a  look  at  the  Digit  Manipulation  Table  below  to  understand  how  
the  number  should  be  formatted.  Remember,  this  task  is  only  supposed  to  be  configured  for  the  HQ  
CUCM  cluster!  
 
Digit  Manipulation  Table  
Route  Pattern   91[2-­‐9]XX[2-­‐9]XXXXXX  
ANI  Digits  Required   10  
DNIS  Digits  Required   10  
Calling  Party  Number  Type   National  
Called  Party  Number  Type   National  
Special  Requirements   N/A  
 
In  this  case,  the  digit  manipulation  was  already  performed  at  the  Route  Pattern  level  for  this  task  (per  
the  Lab  16  Detailed  Solution  Guide).  This  means  that  we’ll  need  to  disable  all  of  the  digit  manipulation  
on  the  Route  Pattern  and  move  it  over  to  the  Route  List.  First,  let’s  do  as  the  task  suggests  and  create  a  
new  Route  List  to  perform  the  number  formatting.    
 
Navigate  to  Call  Routing  !  Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Enter  a  descriptive  
name  for  the  Route  List  (e.g.  “HQ_LD_DM_RL”)  and  select  the  desired  CUCM  group.    
 

 
 
   

320 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Save  button  when  complete.  Next,  on  the  “Route  List  Configuration”  page,  click  the  Add  
Route  Group  button  and  select  the  “R1_MGCP_RG”  that  was  previously  created.  Click  the  Save  button  
when  complete.  
 

 
 
Next,  click  the  “R1_MGCP_RG”  link  on  the  “Route  List  Configuration  Page”  under  the  “Route  List  
Details”  heading.    
 

 
 
Here,  in  the  “Route  List  Detail  Configuration”  page,  we  can  configure  the  proper  digit  manipulation  for  
the  pattern  in  question.  In  this  case,  we  must  send  a  10-­‐digit  number  for  the  ANI  as  well  as  the  correct  
plan  and  type  information  (ISDN,  Subscriber).  This  is  done,  just  as  it  was  with  a  Route  Pattern,  under  
the  “Calling  Party  Transformations”  section.  The  only  real  difference  here  is  the  way  that  the  page  
looks.  For  example,  the  “Use  Calling  Party's  External  Phone  Number  Mask”  is  configured  using  a  
dropdown  box  instead  of  a  checkbox.  The  “On”  value  in  the  dropdown  box  should  be  selected  here  in  
this  case.  Next,  the  “Calling  Party  Transform  Mask”  should  be  set  to  a  value  of  “XXXXXXXXXX”  so  only  
the  rightmost  10  digits  are  used  for  the  ANI.  Next,  make  sure  to  select  the  “National”  option  for  the  
“Calling  Party  Number  Type”  parameter  and  the  “ISDN”  option  for  the  “Calling  Party  Numbering  Plan”  
parameter.    
 

 
 
Next,  we  should  set  the  parameters  under  the  “Called  Party  Transformations”  heading.  On  the  “Discard  
Digits”  dropdown  box,  you  may  notice  that  all  options  are  prefixed  with  “NANP”.  This  acronym  stands  
for  the  North  American  Numbering  Plan,  which  is  installed  on  the  cluster  by  default.  There  is  no  need  

321 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

to  worry  about  this—it  is  doing  the  same  exact  thing  that  the  Route  Pattern  is  doing.  In  this  case,  we  
can  select  the  “NANP:PreDot”  option  for  the  “Discard  Digits”  parameter  to  strip  everything  to  the  left  
of  the  “dot”,  just  as  before.  Next,  we  should  set  the  “Called  Party  Number  Type”  and  “Called  Party  
Numbering  Plan”  to  “National”  and  “ISDN”,  as  required  by  the  task.  
 

 
 
Next,  we  must  modify  the  existing  “long  distance”  Route  Pattern  by  navigating  to  Call  Routing  !  
Route/Hunt  !  Route  Pattern  and  clicking  the  Find  button.  Click  on  the  “91.[2-­‐9]XX[2-­‐9]XXXXXX”  
pattern  in  the  “PSTN_PT”  Partition.  Select  the  new  “Gateway/Route  List”  that  was  just  created  (e.g.  
“HQ_LD_DM_RL”)  and  ensure  that  all  digit  manipulation  that  was  previously  configured  in  the  Route  
Pattern  has  been  removed.  
 

 
 
Click  the  Save  button  when  complete.  
 
   

322 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

At  this  point,  all  digit  manipulation  has  been  configured  for  11-­‐digit  long  distance  calls  at  HQ.  Make  a  
test  call  from  an  HQ  phone  to  a  long  distance  number  specified  in  the  question  (918103321444)  in  
order  to  confirm  the  configuration.  Enter  the  debug isdn q931  command  on  the  R1  MGCP  
gateway.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 24 10:01:47.449: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0005


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x2181, '4082221002'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '8103321444'
Plan:ISDN, Type:National
Oct 24 10:01:47.489: ISDN Se0/0/0:23 Q931: RX <-
R1# CALL_PROC pd = 8 callref = 0x8005
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 24 10:01:47.677: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8005
 
   

323 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 18.3 Using  the  route  pattern  that  was  configured  in  Task  16.9,  ensure  that  all  digit  
manipulation  is  done  using  called  and  calling  party  transformations  at  the  gateway  
level.  This  configuration  applies  to  the  HQ  site  only.  
 
The  task  outlined  in  16.9  refers  to  supporting  international  dialing  for  both  the  HQ  and  SB  CUCM  
clusters.  In  this  task,  we’ve  been  asked  to  ensure  that  the  digit  manipulation  occurs  in  the  Calling  and  
Called  Party  Transformation  only.  This  means  that  we  must  not  use  a  Route  Pattern  or  a  Route  List  to  
format  the  number.  Take  a  look  at  the  Digit  Manipulation  Table  below  to  understand  how  the  number  
should  be  formatted.  Remember,  this  task  is  only  supposed  to  be  configured  for  the  HQ  CUCM  cluster!  
 
Digit  Manipulation  Table  
Route  Pattern   9011!  
ANI  Digits  Required   +E164    
DNIS  Digits  Required   All  digits,  no  “011”  prefix  
Calling  Party  Number  Type   International  
Called  Party  Number  Type   International  
Special  Requirements   N/A  
 
In  this  case,  the  digit  manipulation  was  already  performed  at  the  Route  Pattern  level  for  this  task  (per  
the  Lab  16  Detailed  Solution  Guide).  This  means  that  we’ll  need  to  disable  all  of  the  digit  manipulation  
on  the  Route  Pattern  and  move  it  over  to  a  Calling  and  Called  Party  Transformation.  First,  we  must  
configure  new  Partitions  and  Calling  Search  Spaces  that  will  be  assigned  to  the  transformations.  
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  the  Add  New  button.  Enter  two  
descriptive  Partition  names.  
 

 
 
Next,  add  CSSs  by  navigating  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  clicking  the  
Add  New  button.  Add  a  CSS  for  each  Partition  that  was  created  above  and  click  the  Save  button.  
 
• CALLED_TRANSFORM_CSS  
 

 
 
324 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

• CALLING_TRANSFORM_CSS  
 

 
 
Now  that  the  Partitions  and  CSSs  have  been  created,  we  can  add  Called  and  Calling  Party  
Transformation  Patterns  to  manipulate  the  digits  properly.  Navigate  to  Call  Routing  !  Transformation  
!  Transformation  Pattern  !  Called  Party  Transformation  Pattern  and  click  the  Add  New  button.    
 
For  the  “Pattern”  parameter,  add  a  value  that  matches  that  of  the  original  dialed  string.  Remember,  
this  value  is  unaffected  by  the  digit  manipulation  (if  any)  that  was  done  in  the  Route  Pattern  or  Route  
List.  Therefore,  since  it  matches  what  the  user  dialed,  we  should  enter  the  “9011.!”  pattern  here.  Make  
sure  to  use  the  “CALLED_TRANSFORM_PT”  option  for  the  Partition  assignment.  
 

 
 
Next,  under  the  “Called  Party  Transformations”  section,  set  the  digit  manipulation  options  as  required  
by  the  task.  Set  the  “PreDot”  value  for  the  “Discard  Digits”  parameter.  For  the  “Called  Party  Number  
Type”  and  “Called  Party  Numbering  Plan”  select  the  “International”  and  “ISDN”  options.  
 

 
 
Click  the  Save  button  when  complete.  
 
   

325 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Call  Routing  !  Transformation  !  Transformation  Pattern  !  Calling  Party  
Transformation  Pattern  and  click  the  Add  New  button.  Using  the  same  logic  as  the  “Called  Party  
Transformation  Pattern”,  we  must  use  the  original  calling  number  as  it  entered  the  Route  Pattern.  That  
means  we  must  match  the  4-­‐digit  extension  of  the  phone  (e.g.  “1XXX”)  rather  than  a  +E.164  number.  
Make  sure  to  select  the  “CALLING_TRANSFORM_PT”  for  the  Partition.  
 

 
 
Next,  under  the  “Calling  Party  Transformations”  section,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  box  to  ensure  that  the  call  is  sent  with  +E.164  ANI.  Also,  set  the  “Calling  Party  Number  
Type”  and  “Calling  Party  Numbering  Plan”  as  “International”  and  “ISDN”  to  meet  the  requirements  of  
the  question.  
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  we  must  assign  the  Calling/Called  Party  Transformations  to  the  R1  gateway.  Navigate  to  Device  
!  Gateway  and  click  on  the  “R1.ipexpert.com”  MGCP  gateway.  Click  on  the  T1  PRI  0/0/0  port  to  enter  
the  “Gateway  Configuration”  page.  Scroll  down  to  the  “Call  Routing  Information  -­‐  Outbound  Calls”  
section  and  set  the  proper  CSS  for  the  “Called/Calling  Party  Transformation  CSS”  parameters.  Ensure  
that  the  options  for  “Use  Device  Pool  Called/Calling  Party  Transformation  CSS”  are  unchecked.  
 

 
 
At  this  point,  both  the  Calling  and  Called  Party  Transformation  Patterns  are  active  on  the  R1  MGCP  
gateway.  Let’s  make  some  test  calls  to  verify  the  behavior.  

326 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  R1  gateway,  enter  the  debug isdn q931  command  and  examine  the  output  when  HQ  
phones  call  an  international  PSTN  number  (e.g.  “689220420”).  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 25 00:10:44.482: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0009


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x1181, '+14082221002'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '689220420'
Plan:ISDN, Type:International
Oct 25 00:10:44.518: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8009
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 00:10:44.638: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8009

At  this  point,  the  digit  manipulation  appears  to  be  successful.  In  the  next  task,  we’ll  find  that  there  are  
a  few  caveats  with  Called  and  Calling  Party  Transformations  of  which  we  will  need  to  be  fully  aware.  
 
   

327 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 18.4 Ensure  that  both  Task  18.1  and  Task  18.2  still  work  correctly  using  the  digit  
manipulation  method  of  your  choice.  This  configuration  applies  to  the  HQ  site  only.  
 
Task  18.1  dictated  that  we  utilize  the  Route  Pattern  for  all  digit  manipulation  when  calling  local  
numbers.  Task  18.2  required  that  the  attached  Route  List  should  be  used  to  format  the  11-­‐digit  long  
distance  number.  Why  wouldn’t  they  still  work  correctly?  We  just  tediously  worked  through  all  of  the  
configurations!  
 
The  issue  is  that  the  Calling  Party  Transformation  Pattern  now  is  taking  precedence  over  any  and  all  
digit  manipulation  that  has  been  done  in  the  Route  Pattern/Route  List.  To  observe  the  problem,  run  
the  debug isdn q931  command  on  the  R1  router  and  examine  the  output  when  dialing  both  local  
and  long  distance  numbers.    
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 25 00:22:19.765: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000A


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x1181, '+14082221002'
Plan:ISDN, Type:International
Called Party Number i = 0xC1, '6131218'
Plan:ISDN, Type:Subscriber(local)
Oct 25 00:22:19.805: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x800A
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 00:22:19.929: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800A

Oct 25 00:25:22.924: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000B


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x1181, '+14082221002'
Plan:ISDN, Type:International
Called Party Number i = 0xA1, '8103321444'
Plan:ISDN, Type:National
Oct 25 00:25:22.964: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x800B
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 00:25:23.108: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800B

As  you  can  see  from  the  above  debug  output,  calls  to  both  the  local  and  long  distance  numbers  now  
have  the  ANI  displayed  in  +E.164  format  and  are  using  the  “ISDN/International”  plan  and  type.  Once  
again,  this  is  because  all  three  types  of  calls  are  presented  to  their  respective  Route  Patterns  using  the  
same  ANI  (1XXX).  

328 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  order  to  fix  this  issue,  we  must  figure  out  a  way  to  manipulate  the  digits  before  entering  the  “Route  
Pattern  Layer”.  If  we  can  make  this  change,  the  number  will  no  longer  be  presented  as  a  4-­‐digit  ANI  
when  it  enters  the  Route  Pattern,  and  therefore,  will  not  be  translated  by  the  Calling  Party  
Transformation  Pattern.  
 
One  way  that  we  can  accomplish  this  requirement  is  to  send  the  call  through  a  Translation  Pattern  
before  accessing  the  Route  Pattern.  The  Translation  Pattern  must  have  access  (through  a  CSS)  to  Route  
Patterns  that  forward  calls  to  the  PSTN.  Also,  to  ensure  that  users  are  not  able  to  dial  the  PSTN  Route  
Patterns  directly,  we  should  place  them  in  a  new  Partition,  not  directly  “dial-­‐able”  by  the  users.  Here  
are  a  couple  diagrams  of  the  call  flow  to  better  understand  what  I  mean.  
 
Current  Call  Flow  

Route  Pa€ern     R1  MGCP  Gateway    


User  Dials  
91.[2-­‐9]XX[2-­‐9]XXXXXX  in  PSTN_PT  is   routes  the  call  to  the  
918103321444   matched   PSTN  

 
 
Proposed  Call  Flow  
Transla•on  Pa€ern   Route  Pa€ern    
R1  MGCP  Gateway  
User  Dials     91[2-­‐9]XX[2-­‐9]XXXXXX  in   91.[2-­‐9]XX[2-­‐9]XXXXXX  in  
TRANSLATE_PT  is   TRANSLATED_PSTN_PT  is    routes  the  call  to  
918103321444   the  PSTN  
matched   matched  
 
 
In  the  “Proposed  Call  Flow”  above,  the  Translation  Pattern  will  contain  the  digit  manipulation  for  the  
ANI.  The  Route  Pattern/Route  List  can  still  hold  the  digit  manipulations  for  the  DNIS.  
 
Based  on  the  above,  let’s  create  the  required  Partition  and  Calling  Search  Space.  Navigate  to  Call  
Routing  !  Class  of  Control  !  Partition  and  click  the  Add  New  button.  Enter  a  Partition  name  that  will  
contain  the  PSTN  Route  Patterns  (not  “dial-­‐able”  by  the  user).    
 

 
 
   

329 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  click  the  Add  New  
button.  Typically,  I  will  try  and  use  the  name  that  was  used  in  the  Partition  to  avoid  confusion.  In  this  
case,  the  “TRANSLATED_PSTN_CSS”  name  was  chosen.  Select  the  Partition  that  was  just  created  and  
click  the  Save  button.  
 

 
 
Next,  navigate  to  Call  Routing  !  Translation  Pattern  and  add  the  Translation  Patterns  for  the  local  and  
long  distance  numbers.  Use  the  “9[2-­‐9]XXXXXX”  pattern  for  the  local  dialing  pattern  and  select  the  
“TRANSLATE_PT”  from  the  Partition  dropdown  box.    
 

 
 
Next,  ensure  that  the  “Calling  Search  Space”  created  above  (e.g.  “TRANSLATED_PSTN_CSS”)  is  assigned  
to  the  Translation  Pattern.  
 

 
 
Under  the  “Calling  Party  Transformations”  section,  ensure  that  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  checkbox  is  checked  and  the  “Calling  Party  Transform  Mask”  is  set  to  a  value  of  
“XXXXXXX”  to  use  only  the  rightmost  7  digits  for  the  ANI.  Also,  make  sure  that  the  “Subscriber”  and  
“ISDN”  values  are  set  for  the  “Calling  Party  Number  Type/Plan”  settings.  
 

 
 
Click  the  Save  button  when  complete.  

330 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Add  New  button  to  create  a  new  Translation  Pattern  for  the  “91[2-­‐9]XX[2-­‐9]XXXXXX”  long  
distance  pattern.  Make  sure  to  select  the  “TRANSLATE_PT”  from  the  Partition  dropdown  box.  
 

 
 
Next,  ensure  that  the  “Calling  Search  Space”  created  above  (e.g.  “TRANSLATED_PSTN_CSS”)  is  assigned  
to  the  Translation  Pattern.  
 

 
 
Under  the  “Calling  Party  Transformations”  section,  ensure  that  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  checkbox  is  checked  and  the  “Calling  Party  Transform  Mask”  is  set  to  a  value  of  
“XXXXXXXXXX”  to  use  only  the  rightmost  10  digits  for  the  ANI.  Also,  make  sure  that  the  “National”  and  
“ISDN”  values  are  set  for  the  “Calling  Party  Number  Type/Plan”  settings.  
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  we  must  not  forget  to  change  the  Partition  of  the  existing  Route  Patterns  to  the  newly  created  
“TRANSLATED_PSTN_PT”.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Find  
button.    
 

 
 
Click  on  both  the  local  and  long  distance  patterns  to  modify  the  Partition.  
 

 
Remember  to  click  the  Save  button  when  complete.    
331 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Now  that  the  configuration  is  complete,  let’s  run  another  debug isdn q931  on  the  R1  MGCP  
gateway  and  call  both  the  local  and  long  distance  numbers.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 25 01:39:52.777: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000E


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x4181, '2221002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '6131218'
Plan:ISDN, Type:Subscriber(local)
Oct 25 01:39:52.813: ISDN Se0/0/0:23
R1# Q931: RX <- CALL_PROC pd = 8 callref = 0x800E
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 01:39:52.933: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800E

Oct 25 01:38:59.186: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x000D


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x2181, '4082221002'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '8103321444'
Plan:ISDN, Type:National
Oct 25 01:38:59.222: ISDN Se0/0/0:23 Q931: RX <-
R1# CALL_PROC pd = 8 callref = 0x800D
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 01:38:59.338: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x800D

As  you  can  see,  call  presentations  for  both  types  of  calls  are  now  correct.  
 
   

332 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 18.5 All  tasks  from  Lab  16  must  still  work  correctly  and  meet  all  requirements.  Lab  17  
tasks  do  not  need  to  meet  all  Lab  18  requirements.  
 
This  task  has  required  that  all  patterns  mentioned  in  Lab  16  work  correctly  after  the  application  of  the  
Calling  Party  Transformation  Pattern  in  Task  18.3.  In  the  previous  task,  we  repaired  the  functionality  of  
both  the  local  and  long  distance  Route  Patterns  by  using  a  Translation  Pattern.  Now  in  this  task,  we  
must  perform  the  same  steps  for  the  “911”,  “9.911”,  and  “91.866XXXXXXX”  patterns.    
 
The  configuration  for  the  “911”  Translation  Pattern  is  below.  
 

 
 

 
 
   

333 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  configuration  for  the  “9911”  Translation  Pattern  is  below.  


 

 
 

 
 
The  configuration  for  the  “91866XXXXXXX”  Translation  Pattern  is  below.  
 

 
 

334 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  we  must  modify  the  Partition  on  the  Route  Patterns  for  the  above  call  types  to  use  the  
“TRANSLATED_PSTN_PT”.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Find  
button.  Click  on  the  patterns  in  question  and  modify  the  Partition.  
 

 
 
Finally,  test  each  call  and  run  the  debug isdn q931  command  on  the  R1  MGCP  gateway  to  capture  
the  output  for  calls  to  “911”,  “9911”,  and  “918662258064”.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.

Oct 25 02:20:36.371: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0016


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x4181, '4082221002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
Oct 25 02:20:36.411: ISDN Se0/0/0:23Q931: RX <- CALL_PROC pd = 8 callref = 0x8016
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 02:20:36.547: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8016

335 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Oct 25 02:20:52.171: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0017


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x4181, '4082221002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
Oct 25 02:20:52.207: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8017
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 02:20:52.327: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8017

Oct 25 02:21:05.859: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0018


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 2'
Calling Party Number i = 0x2181, '+14082221002'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '8662258064'
Plan:ISDN, Type:National
Oct 25 02:21:05.899: ISDN Se0/0/0:23 Q931: RX
R1#<- CALL_PROC pd = 8 callref = 0x8018
Channel ID i = 0xA98383
Exclusive, Channel 3
Oct 25 02:21:06.015: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8018

All  calls  are  now  configured  to  route  correctly,  based  on  the  task  requirements.  
 
   

336 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 18.6 Ensure  that  calls  between  phones  on  the  HQ  cluster  display  the  +E164  number  as  
the  calling  number.  
 
This  task  is  asking  us  to  make  sure  that  the  calling  number  displays  as  a  +E.164  number  when  calling  
between  other  HQ  phones.  In  CUCM  versions  prior  to  9.x,  this  task  required  modifying  the  dial  plan.  
We  would  have  to  send  the  call  through  a  Translation  Pattern  (similar  to  the  previous  task)  and  
manipulate  the  ANI  there,  before  forwarding  it  off  to  the  dialed  phone.  This  of  course,  requires  that  
the  phone  not  have  direct  access  to  the  Partition  assigned  to  other  phones  at  the  site.  This  can  be  
problematic  and  overly  complicated  for  administrators  to  achieve.    
 
In  CUCM  9.x,  in  the  “Phone  Configuration”  page,  a  new  feature  exists  in  order  to  change  the  way  in  
which  the  ANI  is  sent  from  the  phone.  This  is  controlled  with  a  Calling  Party  Transformation  
Partition/CSS/Pattern.  Therefore,  to  begin  the  configuration,  we  should  create  a  new  Partition  and  CSS  
for  this  purpose.  
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  the  Add  New  button.  Enter  a  
descriptive  name  for  the  Partition.  
 

 
 
Next,  add  a  CSS  by  navigating  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  clicking  
the  Add  New  button.  Add  a  corresponding  CSS  for  the  above  Partition  and  click  the  Save  button.  
 
• PHONE_CALLING_TRANSFORM_CSS  
 

 
 
Now  that  the  Partition  and  CSS  have  been  created,  we  can  add  the  Calling  Party  Transformation  
Pattern  to  manipulate  the  ANI  properly.  Navigate  to  Call  Routing  !  Transformation  !  Transformation  
Pattern  !  Calling  Party  Transformation  Pattern  and  click  the  Add  New  button.  Once  again,  we  must  
match  the  4-­‐digit  extension  of  the  phone  (e.g.  “1XXX”)  rather  than  a  +E.164  number.  Make  sure  to  
select  the  “PHONES_CALLING_TRANSFORM_PT”  for  the  Partition.  
 

337 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Next,  under  the  “Calling  Party  Transformations”  section,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  box  to  ensure  that  the  call  is  sent  with  +E.164  ANI.    
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  we  must  assign  the  above  CSS  to  the  “Calling  Party  Transformation  CSS”  parameter  on  each  HQ  
phone.  Navigate  to  Device  !  Phone  and  click  on  one  of  the  HQ  phones.  Under  the  “Number  
Presentation  Transformation”  section,  set  the  “Calling  Party  Transformation  CSS”  parameter  to  use  the  
“PHONE_CALLING_TRANSFORM_CSS”  that  was  just  created.  Remember  to  uncheck  the  “Use  Device  
Pool  Calling  Party  Transformation  CSS  (Caller  ID  For  Calls  From  This  Phone)”  checkbox.  
 

 
 
Test  the  calls  between  phones  (by  dialing  the  4-­‐digit  number).  Make  sure  that  the  displayed  ANI  is  in  
+E.164  format  as  shown  below.  
 

 
   

338 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 18.7 Ensure  that  calls  between  phones  on  the  SB  cluster  display  the  10-­‐digit  number  as  
the  calling  number.  
 
This  task  requires  that  we  duplicate  the  configuration  that  was  done  on  the  HQ  CUCM  cluster  to  the  SB  
CUCM  cluster.  
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  the  Add  New  button.  Enter  a  
descriptive  name  for  the  Partition.  
 

 
 
Next,  add  a  CSS  by  navigating  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  clicking  
the  Add  New  button.  Add  a  corresponding  CSS  for  the  above  Partition  and  click  the  Save  button.  
 
• PHONE_CALLING_TRANSFORM_CSS  
 

 
 
Now  that  the  Partition  and  CSS  has  been  created,  we  can  add  the  Calling  Party  Transformation  Pattern  
to  manipulate  the  ANI  properly.  Navigate  to  Call  Routing  !  Transformation  !  Transformation  Pattern  
!  Calling  Party  Transformation  Pattern  and  click  the  Add  New  button.  Once  again,  we  must  match  the  
4-­‐digit  extension  of  the  phone  (e.g.  “2XXX”)  rather  than  a  +E.164  number.  Make  sure  to  select  the  
“PHONES_CALLING_TRANSFORM_PT”  for  the  Partition.  
 

 
 
   

339 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “Calling  Party  Transformations”  section,  check  the  “Use  Calling  Party's  External  Phone  
Number  Mask”  box  to  ensure  that  the  call  is  sent  with  +E.164  ANI.    
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  we  must  assign  the  above  CSS  to  the  “Calling  Party  Transformation  CSS”  parameter  on  each  SB  
phone.  Navigate  to  Device  !  Phone  and  click  on  one  of  the  SB  phones.  Under  the  “Number  
Presentation  Transformation”  section,  set  the  “Calling  Party  Transformation  CSS”  parameter  to  use  the  
“PHONE_CALLING_TRANSFORM_CSS”  that  was  just  created.  Remember  to  uncheck  the  “Use  Device  
Pool  Calling  Party  Transformation  CSS  (Caller  ID  For  Calls  From  This  Phone)”  checkbox.  
 

 
 
Test  the  calls  between  phones  (by  dialing  the  4-­‐digit  number).  Make  sure  that  the  displayed  ANI  is  in  
+E.164  format  as  shown  below.  
 

340 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 19: Globalized and Localized Dialing


Task 19.1 On  HQ  and  SB,  ensure  that  the  ANI  for  all  calls,  regardless  of  type  (local,  national,  
international)  arrives  at  the  phone  screen  in  +E164  format.  
 
To  globalize  the  calling  party  number  for  calls  that  get  routed  to  multiple  geographical  locations,  Cisco  
Unified  Communications  Manager  allows  you  to  configure  prefixes  for  required  access  codes,  escape  
codes,  country  codes,  and  so  on,  based  on  the  calling  party  number  type  that  the  PSTN  provides.  The  
calling  party  number  type  that  the  PSTN  provides  determines  whether  the  incoming  call  arrives  from  
the  PSTN  as  a  national,  international,  subscriber,  or  unknown  call.  For  example,  if  the  call  comes  from  a  
caller  in  Hamburg  to  an  enterprise  gateway  in  Hamburg,  the  call  arrives  to  Cisco  Unified  
Communications  Manager  with  calling  party  number  69XXXXXXX  with  number  type  of  Subscriber.  
However,  if  the  call  comes  from  a  caller  in  Frankfurt  to  an  enterprise  gateway  in  Hamburg,  the  call  
arrives  to  Cisco  Unified  Communications  Manager  with  caller  party  number  69XXXXXXX  with  number  
type  of  National.  
 
Configuring  the  Calling  Party  Number  Type  setting  and  prefixes  in  Cisco  Unified  Communications  
Manager  Administration  allows  Cisco  Unified  Communications  Manager  to  reformat  the  calling  party  
number  from  the  PSTN-­‐localized  version  to  the  globally  dialable  version  by  prefixing  required  access  
codes,  international  access  codes,  and  so  on,  to  the  calling  party  number.  You  can  configure  the  Calling  
Party  Number  Type  setting  for  various  patterns,  for  example,  translation  patterns,  calling  party  
transformation  patterns,  and  route  patterns,  for  both  called  and  calling  parties  to  ensure  that  Cisco  
Unified  Communications  Manager  stamps  the  number  type  during  various  stages  of  incoming  and  
outgoing  calls.  After  Cisco  Unified  Communications  Manager  globalizes  the  calling  party  number,  the  
call  gets  routed  as  expected  to  its  destination.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF
0C471_00_cucm-­‐features-­‐services-­‐guide-­‐90/CUCM_BK_CEF0C471_00_cucm-­‐features-­‐and-­‐services-­‐
guide_chapter_01001.html]    
 
This  task  dictates  that  we  perform  the  process  of  “globalization”  to  the  ANI  as  it  is  routed  inbound  
from  the  PSTN.  Essentially,  this  means  that  we  are  modifying  the  format  of  the  number  to  use  a  
presentation  that  is  unique  on  a  global  scale.  For  example,  the  number  6131218  (HQ  PSTN  Phone)  is  
only  locally  significant,  since  only  the  local  PSTN  switch  at  HQ  has  the  ability  to  route  calls  dialed  with  7  
digits.  The  number  4086131218  is  nationally  significant  in  that  it  can  be  dialed  from  any  phone  within  
the  US.  Finally,  the  number  +14086131218  is  globally  significant  since  it  can  be  dialed  in  this  format  
from  anywhere  in  the  world.  When  the  calling  number  is  formatted  in  this  fashion,  it  makes  calls  easier  
to  route  and  modify  when  necessary.    
 
   

341 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  order  to  accomplish  this  task,  we  must  configure  the  gateway  in  CUCM  such  that  the  Calling  Party  
Number  Type  sent  by  the  PSTN  is  recognized  and  configured  accordingly.  Remember,  the  HQ  CUCM  
cluster  has  the  R1  MGCP  gateway  configured  to  accept  calls  from  the  PSTN  while  the  SB  CUCM  cluster  
uses  the  SIP  gateway  configured  on  R2.    
 
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Gateway  and  click  the  Find  button.  Click  on  the  
“R1.ipexpert.com”  MGCP  gateway  link,  then  click  on  the  T1  PRI  on  port  0/0/0.  Scroll  toward  the  
bottom  of  the  page  and  look  for  “Incoming  Calling  Party  Settings”.  Here,  we  will  make  the  
modifications  to  convert  the  number  to  +E.164  format.    
 

 
 
As  you  can  see  from  the  above  screenshot,  we  need  to  be  concerned  about  three  different  number  
types:  “National”,  “International”,  and  “Subscriber”.  Of  course,  the  “Unknown”  type  is  reserved  for  
situations  where  there  are  no  matches  to  the  previous  three.  To  determine  the  format  in  which  the  
ANI  is  being  sent  from  the  PSTN  for  each  number  type,  the  easiest  way  is  to  run  the  debug isdn
q931  command  on  the  gateway  and  view  the  output  while  making  test  calls.    
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.
 
Test call from the “Subscriber” HQ PSTN
...
Calling Party Number i = 0x4181, '6131218'
Plan:ISDN, Type:Subscriber(local)
...
 
Test call from the “National” SB PSTN
...
Calling Party Number i = 0x2181, '3127764016'
Plan:ISDN, Type:National
...

Test call from the “International” SC PSTN


...
Calling Party Number i = 0x1181, '49307128788'
Plan:ISDN, Type:International
...
 
Based  on  the  above  information,  we  now  know  that  numbers  with  the  “Subscriber”  type  arrive  at  the  
router  from  the  PSTN  in  7-­‐digit  format,  while  calls  with  the  “National”  and  “International”  number  
types  arrive  in  10-­‐digit  and  E.164  formats,  respectively.  In  order  to  convert  the  number  to  the  

342 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

“globalized”  +E.164  format,  we  must  now  prefix  the  necessary  digits  under  the  “Incoming  Calling  Party  
Settings”  section  in  the  gateway.  For  “Subscriber”  numbers,  we  should  prefix  “+1408”  to  the  
“6131218”  number  that  was  received  from  the  PSTN.  For  “National”  numbers,  we  should  prefix  “+1”  to  
the  “3127764016”  number  that  was  received  from  the  PSTN.  For  International  numbers,  simply  
prefixing  the  “+”  character  will  fulfill  the  requirement  since  the  number  is  already  in  E.164  format.  
Remember  to  click  the  Save  and  Reset  buttons  to  apply  the  new  configuration.  
 

 
   
All  calls  that  enter  the  HQ  CUCM  cluster  from  the  R1  MGCP  gateway  should  now  be  displayed  in  +E.164  
format.  Make  test  calls  to  ensure  that  this  is  the  case.  
 

 
 
On  the  SB  CUCM  cluster,  we’ll  be  doing  the  same  thing,  except  this  time  we’ll  be  configuring  the  
settings  within  the  IOS  gateway  rather  than  the  CUCM  configuration,  since  a  peer-­‐to-­‐peer  protocol  
(SIP)  is  being  used  to  connect  to  R2.  Remember,  it  is  much  better  to  configure  the  IOS  gateway  if  the  
opportunity  is  there,  since  it  will  function  properly  in  all  scenarios  (including  SRST).    
 
Once  again,  in  order  to  determine  the  correct  manipulations  to  apply  to  the  numbers  as  they  are  
routed  in  from  the  PSTN,  use  the  debug isdn q931  command  on  the  R2  gateway.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

343 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Test  call  from  the  “Subscriber”  SB  PSTN  


...
Calling Party Number i = 0x4181, '7764016'
Plan:ISDN, Type:Subscriber(local)
...
 
Test  call  from  the  “National”  HQ  PSTN  
Calling Party Number i = 0x2181, '4086131218'
Plan:ISDN, Type:National
...

Test  call  from  the  “International”  SC  PSTN  


...
Calling Party Number i = 0x1181, '49307128788'
Plan:ISDN, Type:International
...
 
Using  the  above  information,  we  can  then  apply  the  proper  settings  to  the  gateway.  We  must  first  
configure  a  voice translation-rule  that  matches  each  of  the  Numbering  Types  and  prefixes  
the  proper  digits.  In  the  first  rule,  a  7-­‐digit  “Subscriber”  number  is  being  matched.  As  long  as  the  
incoming  call  matches  these  two  settings,  the  “+1312”  string  will  be  prefixed.  The  next  two  rules  are  
configured  to  prefix  “+1”  and  “+”  for  “National”  and  “International”  calls,  respectively.  Next,  the  
voice translation-profile  was  created  to  instruct  the  router  to  translate  the  calling  number  
according  to  voice translation-rule 100.  Finally,  the  voice translation-profile  
was  applied  to  the  inbound  POTS  dial-peer  on  the  R2  gateway.  
 
R2  
R2(config)#voice translation-rule 100
R2(cfg-translation-rule)#rule 1 /^[2-9]......$/ /+1312\0/ type subscriber subscriber plan isdn isdn
R2(cfg-translation-rule)#rule 2 /^[2-9]..[2-9]......$/ /+1\0/ type national national plan isdn isdn
R2(cfg-translation-rule)#rule 3 /.*/ /+\0/ type international international plan isdn isdn

R2(config)#voice translation-profile TRANSLATE-PSTN-INBOUND


R2(cfg-translation-profile)#translate calling 100

R2(config)#dial-peer voice 1 pots


R2(config-dial-peer)#translation-profile incoming TRANSLATE-PSTN-INBOUND
 
   

344 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

At  this  point,  each  type  of  number  has  been  “globalized”  to  +E.164  format.  Place  test  calls  and  ensure  
that  this  is  reflected  on  the  phone.  
 

 
 
   

345 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 19.2 On  HQ  and  SB,  ensure  that  calls  from  local  numbers  are  presented  using  a  7-­‐digit  
ANI.  
 
Now  that  the  number  has  been  “globalized”,  we  must  “localize”  the  display  for  the  users  at  HQ  and  SB.  
Localization  is  simply  displaying  the  number  in  a  location-­‐specific  format  so  end  users  are  more  
comfortable  with  what  is  being  displayed.  For  example,  at  HQ,  users  might  expect  to  see  the  HQ  PSTN  
number  in  a  7-­‐digit  format  (“6131218”)  while  users  at  SB  would  like  to  see  the  same  number  in  10-­‐digit  
format  (“4086131218”)  instead.  For  this  particular  task,  the  display  will  be  “localized”  to  display  calls  
from  local  numbers  in  7-­‐digit  format.  
 
This  task  should  be  completed  using  a  Calling  Party  Transformation  Pattern.  With  that  in  mind,  we  
must  create  the  proper  Partitions  and  CSSs  to  accommodate  the  requirements  before  configuring  the  
pattern.    
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  the  Add  New  button.  Enter  a  
descriptive  Partition  name.  
 

 
 
Next,  add  the  CSS  by  navigating  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  clicking  
the  Add  New  button.  Add  a  CSS  for  the  Partition  that  was  created  above  and  click  the  Save  button.  
 
• LOCALIZE_CALLING_TRANSFORM_CSS  
 

 
 
Now  that  the  Partitions  and  CSSs  have  been  created,  we  can  add  a  Calling  Party  Transformation  
Pattern  to  manipulate  the  digits  properly  for  local  calls.  Navigate  to  Call  Routing  !  Transformation  !  
Transformation  Pattern  !  Calling  Party  Transformation  Pattern  and  click  the  Add  New  button.    
 
   

346 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

For  the  “Pattern”  field,  add  the  +E.164  number  that  should  be  matched  for  the  local  numbers  that  
need  to  be  manipulated.  In  this  case,  since  we  need  to  match  the  “+”  character  in  the  string,  we  must  
escape  the  “special  meaning”  or  regular-­‐expression  properties  of  it  by  prefixing  the  “\”  character.  
Whenever  the  “\”  character  is  used  before  a  special  character  in  a  regular  expression,  it  means  that  the  
following  character  will  be  matched  “as  is”  instead  of  using  it  as  part  of  the  search  string.  In  this  
example,  the  “Pattern”  that  should  be  entered  is  “\+1408.[2-­‐9]XXXXXX”,  which  matches  any  number  in  
the  “408”  area  code  that  starts  with  the  “+”  character.  Ensure  that  the  
“LOCALIZE_CALLING_TRANSFORM  _PT”  is  selected  for  the  Partition  as  well.  
 

 
 
Next,  under  the  “Calling  Party  Transformations”  section,  ensure  that  the  “Discard  Digits”  parameter  
has  the  “PreDot”  option  selected  in  order  to  drop  the  “+1408”  from  the  beginning  of  the  string.  This,  of  
course,  will  result  in  a  7-­‐digit  number  after  the  Calling  Party  Transformation  Pattern  is  applied.  
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  we  must  apply  this  Calling  Party  Transformation  Pattern  to  the  HQ  phones  by  way  of  the  CSS  that  
was  previously  created.  We  have  the  ability  to  configure  this  within  the  Device  Pool  or  within  the  
configuration  of  the  phone.  In  this  case,  let’s  assign  it  directly  to  the  device  by  navigating  to  Device  !  
Phone  and  clicking  the  Device  Name  of  one  of  the  phones.  Scroll  to  the  “Number  Presentation  
Transformation”  section  and  locate  the  “Calling  Party  Transformation  CSS”  parameter  under  the  
“Remote  Number”  section.  Select  the  CSS  as  “LOCALIZE_CALLING_TRANSFORM_CSS”  and  make  sure  to  
uncheck  the  “Use  Device  Pool  Calling  Party  Transformation  CSS  (Device  Mobility  Related  Information)”  
checkbox.  
 

 
 
Remember  to  click  the  Save  and  Reset  buttons  to  apply  the  configuration.    
   

347 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Follow  the  above  steps  for  the  other  HQ  phone  as  well.  Test  the  configuration  by  dialing  one  of  the  HQ  
phones  from  the  HQ  PSTN  number  and  observing  the  phone  display.  
 

 
 
Next,  configure  the  SB  CUCM  cluster  in  the  same  fashion  in  order  to  display  local  calls  using  a  7-­‐digit  
number  on  the  phone  display  of  SB  users.  It  is  a  good  idea  to  use  the  same  Partition  and  Calling  Search  
Space  names  here  to  keep  things  consistent.  The  only  thing  that  should  be  different  is  the  pattern  that  
is  used,  since  the  area  code  will  be  different  than  the  HQ  CUCM  cluster  (e.g.  “\+1312.[2-­‐9]XXXXXX”).    
 

 
 
   

348 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  Calling  Party  Transformation  CSS  should  be  applied  to  the  SB  phones  in  the  same  way  that  it  was  
on  the  HQ  CUCM  cluster.  Of  course,  we  should  test  the  configuration  to  ensure  that  everything  is  
working  correctly!  
 

 
 
   

349 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 19.3 On  HQ  and  SB,  ensure  that  calls  from  national  numbers  are  presented  using  a  10-­‐
digit  ANI.  
 
In  much  the  same  way  that  was  done  in  the  previous  task,  we  must  configure  the  proper  formatting  of  
“National”  numbers  as  well.  We  are  still  going  to  use  a  Calling  Party  Transformation  Pattern  along  with  
a  Partition  and  CSS  to  manipulate  the  digits.  Fortunately,  both  the  PT  and  CSS  were  already  created  in  
the  previous  task,  so  there  is  no  need  to  recreate  them.  Also,  the  CSS  was  already  assigned  to  the  
phones  in  question,  so  the  only  thing  left  is  to  create  the  pattern  that  needs  to  be  manipulated.  
 
Once  again,  navigate  to  Call  Routing  !  Transformation  !  Transformation  Pattern  !  Calling  Party  
Transformation  Pattern  and  click  the  Add  New  button.    
 
For  the  “Pattern”,  add  the  +E.164  number  that  should  be  matched  for  inbound  national  numbers  that  
should  be  manipulated.  Enter  the  “Pattern”  as  “\+1.[2-­‐9]XX[2-­‐9]XXXXXX”,  which  matches  any  number  
in  the  “+1”  country  code  (“National”  from  the  US  perspective).  Ensure  that  the  
“LOCALIZE_CALLING_TRANSFORM  _PT”  is  selected  for  the  Partition  as  well.  
 

 
 
Next,  under  the  “Calling  Party  Transformations”  section,  ensure  that  the  “Discard  Digits”  parameter  
has  the  “PreDot”  option  selected  in  order  to  drop  the  “+1”  from  the  beginning  of  the  string.  This,  of  
course,  will  result  in  a  10-­‐digit  number  after  the  Calling  Party  Transformation  Pattern  is  applied.  
 

 
 
Click  the  Save  button  when  complete.    
 
   

350 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  make  test  calls  from  “National”  PSTN  numbers  on  both  the  HQ  and  SB  CUCM  clusters  and  
observe  the  phone  display  to  confirm  the  configuration.  
 

 
 

 
 
   

351 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 19.4 On  HQ  and  SB,  ensure  that  calls  from  international  numbers  are  presented  using  the  
full  E164  number  without  the  leading  +.  
 
In  this  task,  we  have  been  asked  to  format  “International”  numbers  as  well.  We  are  still  going  to  use  a  
Calling  Party  Transformation  Pattern  along  with  a  Partition  and  CSS  to  manipulate  the  digits.  
Fortunately,  both  the  PT  and  CSS  were  already  created  in  the  previous  task,  so  there  is  no  need  to  
recreate  them.  Also,  the  CSS  was  already  assigned  to  the  phones  in  question,  so  the  only  thing  left  is  to  
create  the  pattern  that  needs  to  be  manipulated.  
 
Once  again,  navigate  to  Call  Routing  !  Transformation  !  Transformation  Pattern  !  Calling  Party  
Transformation  Pattern  and  click  the  Add  New  button.    
 
For  the  “Pattern”,  add  the  +E.164  number  that  should  be  matched  for  inbound  international  numbers  
that  should  be  manipulated.  Enter  the  “Pattern”  as  “\+.!”,  which  matches  any  number  in  any  country  
code.  Ensure  that  the  “LOCALIZE_CALLING_TRANSFORM  _PT”  is  selected  for  the  Partition  as  well.  
 

 
 
Next,  under  the  “Calling  Party  Transformations”  section,  ensure  that  the  “Discard  Digits”  parameter  
has  the  “PreDot”  option  selected  in  order  to  drop  the  “+”  from  the  beginning  of  the  string.  This,  of  
course,  will  result  in  an  E.164  number  after  the  Calling  Party  Transformation  Pattern  is  applied.  
 

 
 
Click  the  Save  button  when  complete.    
 
   

352 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  make  test  calls  from  “International”  PSTN  numbers  on  both  the  HQ  and  SB  CUCM  clusters  and  
observe  the  phone  display  to  confirm  the  configuration.  
 

 
 

 
 
   

353 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 19.5 Configure  the  HQ  and  SB  clusters  to  support  plus  dialing  from  the  call  lists,  since  all  
missed,  placed,  and  received  call  entries  are  listed  in  +E164  format.  Do  not  create  
any  additional  route  patterns  to  accomplish  this.  
 
One  thing  that  you  may  have  noticed  while  configuring  and  testing  the  above  manipulations  is  the  fact  
that  the  call  history  (missed/placed/received  calls)  still  displays  the  number  in  +E.164  format.  This  
means  that  the  Calling  Party  Transformations  that  were  applied  affect  the  phone  display  during  the  
“Ring  In”  state  only.  Since  the  entries  use  the  +E.164  format,  we  can  use  this  to  our  advantage  by  
creating  patterns  within  the  CUCM  system  that  are  able  to  route  the  number  when  dialed  in  this  
fashion.  The  task  explicitly  states  that  a  Route  Pattern  may  not  be  used  in  this  case,  so  a  Translation  
Pattern  must  be  used  instead.    
 
Although  not  a  requirement  of  the  question,  it  is  a  pretty  good  idea  to  create  a  separate  Partition  and  
Calling  Search  Space  specifically  for  the  purpose  of  controlling  access  to  the  “plus  dial”  patterns  and  
routing  calls  from  the  configured  Translation  Pattern.  
 
On  the  HQ  CUCM  cluster,  navigate  to  Call  Routing  !  Class  of  Control  !  Partition  and  click  the  Add  
New  button.  Enter  a  descriptive  Partition  name  (e.g.  “PLUS_DIAL_PT”).  
 

 
 
Next,  add  the  CSS  for  the  Translation  Pattern  by  navigating  to  Call  Routing  !  Class  of  Control  !  Calling  
Search  Space  and  clicking  the  Add  New  button.  Enter  a  descriptive  name  for  the  CSS  (e.g.  “PSTN_CSS”)  
and  make  sure  to  add  the  Partitions  that  provide  access  to  the  PSTN.  In  this  case,  we  added  both  the  
“PSTN_PT”  and  “TRANSLATE_PT”  Partitions  in  order  to  provide  access  to  all  PSTN  Route/Translation  
Patterns  in  the  system.  Click  the  Save  button  when  complete.  
 
• PSTN_CSS  
 

 
 
   

354 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  create  the  Translation  Patterns  to  accommodate  local,  long  distance,  and  international  
dialing.  Navigate  to  Call  Routing  !  Translation  Pattern  to  add  the  Translation  Patterns.  For  the  
“Pattern”  enter  the  “\+1408.[2-­‐9]XXXXXX”  pattern  for  the  local  dialing  pattern  and  select  the  
“PLUS_DIAL_PT”  option  from  the  Partition  dropdown  box.    
 

 
 
Next,  ensure  that  the  “Calling  Search  Space”  created  above  (e.g.  “PSTN_CSS”)  is  assigned  to  the  
Translation  Pattern.  
 

 
 
Under  the  “Called  Party  Transformations”  section,  ensure  that  the  “Discard  Digits”  dropdown  box  has  
the  “PreDot”  option  selected,  in  order  to  strip  the  “+1408”  from  the  dialed  string.  Next,  we  must  also  
prefix  a  “9”  so  when  forwarded,  it  matches  either  the  Route  Pattern  or  Translation  Pattern  configured  
to  route  the  call  out  the  PSTN  gateway.  
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  make  sure  to  add  the  Translation  Patterns  for  both  long  distance  and  international  dialing  using  
the  steps  from  above.  
 

 
 

355 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 

 
 

 
 
With  the  HQ  CUCM  cluster  configuration  complete,  make  test  calls  to  ensure  that  the  HQ  phones  can  
make  calls  by  highlighting  the  missed/placed/received  call  and  pressing  the  “Dial”  softkey.    
 
Next,  ensure  that  the  same  configuration  is  applied  to  the  SB  CUCM  cluster  so  SB  phones  are  able  to  
make  calls  using  “+”  as  the  leading  character.  Of  course,  the  Partition  and  Calling  Search  Space  should  
be  configured  as  the  first  step  in  this  case  as  well.  When  that  is  complete,  add  the  Translation  Patterns  
as  shown  below.  
 

356 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 

 
 

 
 

 
 

 
 

357 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  SB  CUCM  cluster  configuration  complete,  make  test  calls  to  ensure  that  the  SB  phones  can  
make  calls  by  highlighting  the  missed/placed/received  call  and  pressing  the  “Dial”  softkey.    

358 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 20: CUCM Hunting and Queuing


Task 20.1 Configure  the  number  1030  (Sales)  on  the  HQ  cluster  to  receive  calls  and  forward  to  
the  appropriate  party  in  “Top  Down”  fashion.  All  available  HQ  phones  should  be  in  
the  configuration.    
 
The  “hunting”  structure  within  CUCM  is  very  similar  to  the  “routing”  structure.  As  you  now  know,  
routing  calls  in  CUCM  requires  a  Route  Group,  Route  List,  and  Route  Pattern.  In  a  similar  fashion,  
CUCM  hunting  requires  a  Line  Group,  Hunt  List,  and  Hunt  Pilot.  The  Line  Group  contains  a  list  of  
Directory  Numbers  that  should  be  involved  in  the  configuration.  The  Line  Group  is  then  assigned  to  a  
Hunt  List,  which  contains  an  ordered  list  of  Line  Groups.  Finally,  the  Hunt  Pilot  assigns  a  Hunt  List,  so  
the  proper  call  coverage  can  be  attained.    
 
Based  on  the  above  information,  the  first  thing  that  we  must  do  is  to  configure  a  Line  Group  that  
contains  all  available  HQ  phones  (HQ  Phone  1  and  2).  Navigate  to  Call  Routing  !  Route/Hunt  !  Line  
Group  and  click  the  Add  New  button.  For  the  “Line  Group  Name”  field,  add  a  descriptive  name  that  
describes  its  contents  (e.g.  “Sales_LG”).    
 

 
 
Next,  choose  a  “Distribution  Algorithm”  from  the  dropdown  box.  To  meet  the  requirements  of  the  
question,  “Top  Down”  was  used.  
 

 
 
Obviously,  other  options  exist  for  the  “Distribution  Algorithm”.  See  the  below  list  for  the  explanation  
contained  within  the  CUCM  Help  Pages.  
 
• Top  Down—If  you  choose  this  distribution  algorithm,  Cisco  Unified  CM  distributes  a  call  to  idle  
or  available  members  starting  from  the  first  idle  or  available  member  of  a  line  group  to  the  last  
idle  or  available  member.  
• Circular—If  you  choose  this  distribution  algorithm,  Cisco  Unified  CM  distributes  a  call  to  idle  or  
available  members  starting  from  the  (n+1)th  member  of  a  route  group,  where  the  nth  member  
is  the  next  sequential  member  in  the  list  who  is  either  idle  or  busy  but  not  "down."  If  the  nth  
member  is  the  last  member  of  a  route  group,  Cisco  Unified  CM  distributes  a  call  starting  from  
the  top  of  the  route  group.  

359 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

• Longest  Idle  Time—If  you  choose  this  distribution  algorithm,  Cisco  Unified  CM  only  distributes  
a  call  to  idle  members,  starting  from  the  longest  idle  member  to  the  least  idle  member  of  a  line  
group.  
• Broadcast—If  you  choose  this  distribution  algorithm,  Cisco  Unified  CM  distributes  a  call  to  all  
idle  or  available  members  of  a  line  group  simultaneously.  See  the  Note  in  the  description  of  the  
Selected  DN/Route  Partition  field  for  additional  limitations  in  using  the  Broadcast  distribution  
algorithm.  
[Source:    CUCM  9.x  Help  !  This  Page]  
 
Next,  select  the  DNs  that  should  be  part  of  the  Line  Group  from  the  “Available  DN/Route  Partition”  list  
in  the  “Line  Group  Member  Information”  section.  Click  the  Add  to  Line  Group  button  to  make  the  DNs  
a  part  of  the  list.  
 

 
 
The  “Current  Line  Group  Members”  section  will  now  display  the  added  DNs.  
 

 
 
When  completed,  click  the  Save  button.  
 
   

360 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  to  add  a  Hunt  List,  navigate  to  Call  Routing  !  Route/Hunt  !  Hunt  List  and  click  the  Add  New  
button.  Enter  a  descriptive  name  for  the  Hunt  List  (e.g.  “Sales_HL”),  select  a  CUCM  Group,  and  enable  
the  checkbox  for  the  “Enable  this  Hunt  List  (change  effective  on  Save;  no  reset  required)”  setting.  Click  
the  Save  button  when  complete.  
 

 
 
Next,  click  the  Add  Line  Group  button  to  associate  the  previously  configured  Line  Group  with  the  Hunt  
List.  Select  the  “Sales_LG”  and  click  the  Save  button.  
 

 
 
Click  the  Save  button  to  save  the  Hunt  List  configuration.  
 
Next,  to  add  a  Hunt  Pilot,  navigate  to  Call  Routing  !  Route/Hunt  !  Hunt  Pilot  and  click  the  Add  New  
button.  Enter  the  directory  number  to  be  used  as  the  Hunt  Pilot.  In  this  case,  “1030”  was  used  based  
on  the  task  requirements.  Select  a  Partition  to  assign  to  the  Hunt  Pilot  that  is  accessible  by  phones  and  
external  systems.    
 

 
 
Next,  assign  the  “Hunt  List”  configured  in  the  previous  task  to  the  Hunt  Pilot  by  selecting  it  from  the  
dropdown  list  and  click  the  Save  button  to  complete  the  configuration.  
 

 
 
With  the  configuration  complete,  make  a  few  test  calls  to  the  Hunt  Pilot  number.  Keep  in  mind  that  
this  number  should  be  accessible  from  the  PSTN,  so  it  can  be  tested  from  there  as  well,  if  desired.    
 
361 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Below  is  the  display  of  an  HQ  phone  that  is  a  member  of  the  “Sales_LG”  Line  Group  upon  receiving  a  
call  from  the  HQ  PSTN  phone  destined  toward  the  Hunt  Pilot  number.  
 

 
 
   

362 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.2 Ensure  that  the  maximum  amount  of  time  available  to  answer  the  call  is  30  seconds.  
 
The  maximum  amount  of  time  available  to  answer  a  call  refers  to  a  setting  called  the  “Maximum  Hunt  
Timer”  within  the  configuration  of  the  Hunt  Pilot.  See  below  for  the  explanation  from  the  CUCM  Help  
pages.  
 
This  timer  cancels  if  either  a  hunt  member  answers  the  call  or  if  the  hunt  list  gets  exhausted  before  the  
timer  expires.  If  you  do  not  specify  a  value  for  this  timer,  hunting  continues  until  a  hunt  member  
answers  or  hunting  exhausts.  If  neither  event  takes  place,  hunting  continues  for  30  minutes,  after  
which  the  call  gets  taken  for  final  treatment.  
 
In  addition,  Cisco  Unified  CM  only  uses  the  configuration  for  the  Maximum  Hunt  Timer  setting  if  you  
configure  the  Hunt  Forward  settings  in  the  Hunt  Pilot  Configuration  window.  
[Source:    CUCM  9.x  Help  !  This  Page]    
 
To  configure  the  setting,  navigate  to  Call  Routing  !  Route/Hunt  !  Hunt  Pilot  and  click  on  the  “1030”  
Hunt  Pilot.  Scroll  down  to  the  “Hunt  Call  Treatment  Settings”  section  and  find  the  setting  labeled  
“Maximum  Hunt  Timer”  under  the  parameters  for  “Forward  Hunt  No  Answer”.  In  this  field,  enter  a  
value  of  “30”  to  meet  the  task  requirements.  In  addition,  make  sure  that  an  option  is  selected  for  the  
forwarding  of  the  call  (e.g.  “Use  Forward  Settings  of  Line  Group  Member”).  If  this  is  not  configured,  the  
“Maximum  Hunt  Timer”  setting  does  not  take  effect,  as  mentioned  above.  
 

 
 
When  testing  the  configuration,  you  might  find  that  the  call  disconnects  after  20  seconds.  This  is  
because  the  “RNA  Reversion  Timeout”  parameter  in  the  configured  Line  Group  defaults  to  10  seconds  
and  there  are  only  two  lines.  Obviously,  when  more  lines  are  added  to  the  system,  the  “Maximum  
Hunt  Timer”  will  “kick  in”  and  use  the  limit  of  30  seconds.  
 
   

363 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.3 If  any  IP  Phone  decides  to  forward  their  own  normal  DN  to  this  Hunt  Group,  and  for  
some  reason  the  call  is  not  answered  in  a  timely  fashion  by  this  Hunt  Group,  the  
“Forward  No  Coverage”  settings  should  be  honored  for  the  party  who  forwarded  the  
call,  instead  of  being  honored  for  the  Hunt  Group  itself.  
 
This  task  has  actually  been  completed  (albeit  unknowingly)  in  the  previous  question.  The  setting  “Use  
Forward  Settings  of  Line  Group  Member”  within  the  “Forward  Hunt  No  Answer”  settings  of  the  Hunt  
Pilot  must  be  selected  to  meet  this  requirement.  This  allows  the  “Forward  No  Coverage  
Internal/External”  setting  configured  within  the  “Directory  Number  Configuration”  page  to  be  used  
instead  of  those  settings  configured  on  the  Hunt  Pilot.  These  settings  will  take  effect  only  when  a  
phone  has  forwarded  a  call  to  the  Hunt  Pilot  in  some  fashion  (CFA/CFB/CFNA/CFUR/etc.).    
 
To  fulfill  this  requirement,  navigate  to  Call  Routing  !  Route/Hunt  !  Hunt  Pilot  and  click  on  the  “1030”  
Hunt  Pilot  that  was  previously  configured.  Ensure  that  the  “Use  Forward  Settings  of  Line  Group  
Member”  radio  button  is  selected  under  the  “Forward  Hunt  No  Answer”  section.  
 

 
 
To  test  this  setting,  navigate  Device  !  Phone  and  click  on  any  HQ  phone  (e.g.  HQ  Phone  1).  Next,  click  
on  the  primary  DN  of  the  phone  and  scroll  down  to  the  “Call  Forward  and  Call  Pickup  Settings”  section.  
For  the  “Forward  All”  setting,  configure  the  Hunt  Pilot  (“1030”)  as  the  “Destination”  and  select  a  Calling  
Search  Space  that  allows  access.    
 

 
 
For  the  “Forward  No  Coverage  Internal/External”  settings,  enter  a  dialable  test  number,  such  as  
“2002”.  Also,  set  the  Calling  Search  Space  to  ensure  that  access  to  the  number  is  available.  
 

 
 
Remember  to  click  the  Save  and  Apply  Config  buttons  to  save  the  configuration.    
 
Now  make  a  test  call  from  the  HQ  PSTN  phone  to  HQ  Phone  1.  It  should  immediately  forward  to  the  
Hunt  Pilot  and  begin  ringing  the  Line  Group  members.  After  the  “Maximum  Hunt  Timer”  is  met,  the  call  
should  forward  to  SB  Phone  2  at  number  2002.  Experiment  with  the  settings  and  perform  some  more  
tests  to  get  the  hang  of  it!  
 
   

364 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.4 Ensure  that  calls  that  are  designated  as  busy  get  forwarded  to  extension  1002.  
 
Calls  that  are  deemed  “busy”  can  be  configured  to  forward  to  DN  “1002”  within  the  configuration  of  
the  Hunt  Pilot.  Just  as  we  discovered  in  the  previous  task,  the  “Call  Forward  No  Coverage”  settings  can  
also  be  used  for  calls  that  were  forwarded  to  the  Hunt  Pilot  if  so  desired.  In  this  case,  let’s  configure  
the  setting  on  the  Hunt  Pilot.    
 
To  fulfill  this  requirement,  navigate  to  Call  Routing  !  Route/Hunt  !  Hunt  Pilot  and  click  on  the  “1030”  
Hunt  Pilot  that  was  previously  configured.  Under  the  “Forward  Hunt  No  Answer”  section,  ensure  that  
the  “Forward  Busy  Calls  to”  radio  button  is  selected  and  the  number  “1002”  is  entered  in  the  
“Destination”  field.  Lastly,  ensure  that  a  Calling  Search  Space  is  selected  that  provides  access  to  the  
configured  number  (e.g.  “INTERNAL_CSS”).  
 

 
 
To  test  the  configuration,  simply  “busy  out”  the  two  phones  at  HQ  by  making  a  call  from  one  phone  to  
the  other.  Now  that  the  phones  are  busy,  make  a  call  from  the  PSTN  and  ensure  that  it  forwards  to  HQ  
Phone  2  (“1002”).  
 

 
 
   

365 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.5 Configure  the  number  2040  (Support)  on  the  SB  cluster  to  queue  calls  and  forward  
to  line  group  members  (all  SB  phones)  in  “Broadcast”  fashion.    
 
Unified  CM  provides  call  queuing  natively  to  users  so  that  callers  can  be  held  in  a  queue  until  hunt  
members  are  available  to  answer  them.  Callers  in  a  queue  receive  an  initial  greeting  announcement  
followed  by  music  on  hold  or  tone  on  hold.  If  the  caller  remains  in  queue  for  a  period  of  time,  a  
secondary  announcement  is  played  at  a  configured  interval  until  the  call  can  be  answered—or  until  the  
maximum  wait  timer  expires.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF
0C471_00_cucm-­‐features-­‐services-­‐guide-­‐90/CUCM_BK_CEF0C471_00_cucm-­‐features-­‐and-­‐services-­‐
guide_chapter_0111.html]    
 
This  task  requires  that  we  configure  Native  Call  Queuing  (NCQ)  on  the  SB  CUCM  cluster.  NCQ  is  a  new  
feature  in  CUCM  9.x  that  isn’t  exactly  feature-­‐rich  at  this  point.  However,  we  must  know  how  to  
configure  it  for  the  CCIE  Collaboration  lab!  The  major  “breakthrough”  here  is  that  CUCM  can  now  
provide  queuing  functions  without  having  to  use  a  “Contact  Center”  type  of  application.  Before  you  run  
off  and  throw  away  your  UCCX  server,  understand  that  this  feature  has  one  massive  limitation—it  will  
only  queue  calls  when  agents  are  considered  “busy”.  This  means  that  you  will  not  call  into  an  NCQ-­‐
enabled  Hunt  Pilot  and  immediately  be  greeted  by  a  queue  announcement.  You  will  instead  be  treated  
just  as  a  caller  would  be  in  a  “normal”  CUCM  hunting  scenario.  CUCM  will  attempt  to  ring  the  Line  
Group  members  according  to  the  configured  Distribution  Algorithm  and  when  the  “Maximum  Hunt  
Timer”  is  reached,  the  call  will  either  be  dropped  or  forwarded  to  another  destination.  Wouldn’t  it  be  
nice  if  they  just  placed  the  call  in  queue  at  that  point?  But  they  don’t—so  I’ll  have  to  get  over  it.  
 
To  configure  NCQ,  we  start  by  configuring  a  Line  Group,  Hunt  List,  and  Hunt  Pilot,  just  as  it  was  done  in  
the  first  task  on  the  HQ  CUCM  cluster.  That  configuration  is  shown  below.  
 

 
 

 
   

366 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 

 
 
At  this  point,  we  are  at  the  same  configuration  level  that  we  were  with  the  Hunt  Pilot  configured  on  
the  HQ  CUCM  cluster.  Next,  to  configure  the  NCQ  feature,  navigate  to  Call  Routing  !  Route/Hunt  !  
Hunt  Pilot  and  click  on  the  “2040”  Hunt  Pilot  that  was  just  configured.  Scroll  down  to  the  section  
labeled  “Queuing”.  Check  the  box  next  to  “Queue  Calls”  in  order  to  enable  the  feature.  
 

 
 
   

367 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  select  an  option  for  the  “Network  Hold  MOH  Source  &  Announcements”  parameter  from  the  
dropdown  box.  By  default  the  only  one  available  is  the  “SampleAudioSource”,  which  is  the  weird,  
spacy,  techno  song  that  Cisco  chose  for  its  default  hold  music.  I’ve  heard  it  so  many  times  at  this  point  
that  I’ve  started  to  like  it—maybe  I’ll  write  lyrics!  We  can  then  click  the  Save  button  to  write  the  
configuration  to  memory.  
 

 
 
Next,  we  must  also  configure  the  “Music  on  Hold  Audio  Source”  to  play  the  Initial  Announcement  upon  
entering  the  queue  and  the  Periodic  Announcement  after  waiting  30  seconds  (by  default)  in  the  queue.  
Navigate  to  Media  Resources  !  Music  on  Hold  Audio  Source  and  click  the  Find  button.  Click  on  the  
SampleAudioSource  file  and  locate  the  “Initial  Announcement”  and  “Periodic  Announcement”  
parameters  under  the  “Announcement  Settings”  section  and  set  a  suitable  value  for  each.  
 

 
 
Click  the  Save  button  when  complete.  
 
Test  the  configuration  by  calling  the  Hunt  Pilot  while  both  users  at  SB  are  in  the  busy  state.  In  this  case,  
the  easiest  way  is  to  have  SB  Phone  1  call  SB  Phone  2.  Remember,  only  in  this  state  will  the  NCQ  
announcements  be  played!    
 
   

368 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.6 Ensure  that  the  longest  a  caller  will  wait  in  the  queue  is  2  minutes,  before  being  
transferred  to  extension  2001.  
 
We  have  the  ability  to  “fine-­‐tune”  some  of  the  queuing  parameters  within  the  Hunt  Pilot  configuration.  
One  of  these  parameters  is  the  amount  of  time  callers  have  to  wait  in  the  queue.  This  can  be  
configured  by  navigating  to  Call  Routing  !  Route/Hunt  !  Hunt  Pilot  and  clicking  on  the  “2040”  Hunt  
Pilot.  On  the  “Hunt  Pilot  Configuration”  page,  set  the  “Maximum  Wait  Time  in  Queue”  to  a  value  of  
“120”,  which  is  the  value  of  2  minutes  in  seconds.  
 

 
 
Click  the  Save  button  to  apply  the  configuration.  Test  the  configuration  by  calling  the  Hunt  Pilot  and  
letting  the  timer  expire  once  in  the  queue.    
 
   

369 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.7 If  there  are  no  hunt  members  available,  forward  the  call  to  extension  2002.  
 
Once  again,  we  can  set  these  queuing  parameters  within  the  Hunt  Pilot  configuration.  Navigate  to  Call  
Routing  !  Route/Hunt  !  Hunt  Pilot  and  click  on  the  “2040”  Hunt  Pilot.  On  the  “Hunt  Pilot  
Configuration”  page,  under  the  “Queuing”  section,  set  the  “Route  the  call  to  this  destination”  
parameter  to  a  value  of  “2002”  for  both  the  “When  maximum  wait  time  is  met”  and  “When  no  hunt  
members  answer,  are  logged  in,  or  registered”  parameters.  Next,  set  a  CSS  that  has  access  to  the  
Partition  assigned  to  the  number  above  (e.g.  “INTERNAL_CSS”).  This  ensures  that  whenever  a  Line  
Group  member  is  unavailable  for  any  reason,  the  call  will  be  forwarded  to  extension  2002  on  the  SB  
CUCM  cluster.  
 

 
 
Click  the  Save  button  to  apply  the  configuration.  Test  the  configuration  by  calling  the  Hunt  Pilot  and  
letting  the  timer  expire  once  in  the  queue.    
 
   

370 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.8 Only  6  callers  are  allowed  in  the  queue  at  one  time.  
 
Once  again,  we  must  set  a  parameter  within  the  Hunt  Pilot  configuration  to  complete  this  task.  
Navigate  to  Call  Routing  !  Route/Hunt  !  Hunt  Pilot  and  click  on  the  “2040”  Hunt  Pilot.  On  the  “Hunt  
Pilot  Configuration”  page,  under  the  “Queuing”  section,  set  the  “Maximum  Number  of  Callers  Allowed  
in  Queue”  parameter  to  a  value  of  “6”  and  click  the  Save  button.    
 

 
 
This  one  is  a  little  bit  harder  to  test  (at  the  configured  value).  A  great  way  to  test  the  functionality  is  
just  to  set  the  value  to  “1”  and  observe  the  behavior  when  a  second  call  is  queued.  In  this  case,  the  
default  setting  is  to  “Disconnect  the  call”.    
   

371 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 20.9 Ensure  both  phone  types  (SCCP  and  SIP)  have  the  ability  to  log  in  and  out  of  the  hunt  
group  at  both  HQ  and  SB.  
 
In  order  to  give  the  phones  the  ability  to  log  in  and  out  of  the  hunt  group,  we  must  configure  the  
assigned  “Softkey  Template”  for  SCCP  phones  and  the  “Phone  Button  Template”  for  SIP  phones.  This  
means  that  a  softkey  (HLog)  will  be  used  to  log  in  and  out  of  the  configured  hunt  group  for  SCCP  
phones.  As  mentioned  in  previous  labs,  9971  phones  do  not  have  the  ability  to  control  softkeys  
through  a  “Softkey  Template”.  They  must  use  a  “Feature  Control  Policy”  instead.  However,  in  this  case,  
there  is  no  available  “Feature  Control  Policy”  that  adds  the  “HLog”  softkey.  This  means  that  we  must  
use  a  “Phone  Button  Template”  to  add  the  Hunt  Group  Login/Logout  Feature.  
 
On  the  HQ  CUCM  cluster,  configure  the  “Phone  Button  Template”  for  the  9971  by  navigating  to  Device  
!  Device  Settings  !  Phone  Button  Template  and  click  the  Find  button.  Look  for  the  template  that  is  
currently  assigned  to  the  9971  (“Standard  9971  SIP  -­‐  3L-­‐1SB-­‐1P-­‐1S”).  This  was  created  in  an  earlier  lab  
to  support  three  lines,  one  BLF  speed  dial,  one  Call  Park  BLF,  and  one  “normal”  speed  dial.  In  this  case,  
the  location  of  the  button  is  not  specified  in  the  question,  so  it  should  go  in  any  available  space.  Let’s  
remove  one  of  the  “Line”  slots  and  replace  it  with  the  “Hunt  Group  Logout”  button.  Remember  to  
name  the  “Phone  Button  Template”  appropriately  for  the  new  functionality.  
 

 
 
   

372 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Save  and  Apply  Config  buttons  to  save  the  changes  to  the  phone.  After  the  modification,  the  
phone  display  should  appear  as  shown  below.  
 

 
 
Test  the  functionality  by  logging  in  and  out  of  the  Hunt  Group  and  making  test  calls.  
 
Next,  modify  the  existing  “Softkey  Template”  that  is  associated  with  HQ  Phone  2  (SCCP)  to  include  the  
“HLog”  key.  Navigate  to  Device  !  Device  Settings  !  Softkey  Template  and  click  the  “Standard  User  –  
Pickup”  template  that  was  configured  in  a  previous  lab.  Click  the  “Configure  Softkey  Layout”  link  in  the  
top  right-­‐hand  corner  and  add  the  “HLog”  key  to  the  “On  Hook”  state.    
 

 
 
This  will  allow  the  SCCP  phones  that  use  this  softkey  template  (HQ  Phone  2)  to  log  in  and  out  of  the  
Hunt  Group.  Make  sure  to  click  the  Save  and  Apply  Config  buttons  to  save  the  configuration  to  the  
phone.    
 
   

373 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  phone  should  display  the  softkey  as  shown  below.  


 

 
 
Ensure  that  the  proper  Softkey  Templates  are  modified  to  include  the  “HLog”  key  within  the  
“Connected”  state  for  the  phones  on  the  SB  CUCM  cluster  as  well.  

374 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 21: Time of Day Routing Configuration


Task 21.1 Configure  the  HQ  CUCM  cluster  such  that  calls  to  HQ  Phone  1  will  only  ring  during  
the  hours  of  12pm  and  3pm  PST  (UTC  -­‐8)  from  Monday  through  Friday.  Obviously  
these  times  can  change  if  necessary  for  testing  purposes.  All  calls  outside  of  those  
hours  will  forward  to  SB  Phone  1.  
 
Time-­‐of-­‐Day  routing  comprises  individual  time  periods  that  the  administrator  defines  and  groups  into  
time  schedules.  The  administrator  associates  time  schedules  with  a  partition.  In  the  Partition  
Configuration  window,  the  administrator  chooses  either  the  time  zone  of  the  originating  device  or  any  
specific  time  zone  for  a  time  schedule.  The  system  checks  the  chosen  time  zone  against  the  time  
schedule  when  the  call  gets  placed  to  directory  numbers  in  this  partition.  The  Time  Period  and  Time  
Schedule  menu  items  exist  in  the  Call  Routing  menu  under  the  Class  of  Control  submenu.  The  Partition  
and  Calling  Search  Space  menu  items  also  have  moved  to  the  Class  of  Control  submenu.  
 
A  time  period  comprises  a  start  time  and  end  time.  The  available  start  times  and  end  times  comprise  
15-­‐minute  intervals  on  a  24-­‐hour  clock  from  00:00  to  24:00.  Additionally,  a  time  period  requires  
definition  of  a  repetition  interval.  Repetition  intervals  comprise  the  days  of  the  week  (for  example,  
Monday  through  Friday)  or  a  day  of  the  calendar  year  (for  example,  June  9).  
 
A  time  schedule  comprises  a  group  of  defined  time  periods  that  the  administrator  associates.  After  the  
administrator  has  configured  a  time  period,  the  time  period  displays  in  the  Available  Time  Periods  list  
box  in  the  Time  Schedule  Configuration  window.  The  administrator  can  select  a  time  period  and  add  it  
to  the  Selected  Time  Periods  list  box.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmsys/CUCM_BK_CD2F
83FA_00_cucm-­‐system-­‐guide-­‐90/CUCM_BK_CD2F83FA_00_system-­‐guide_chapter_01111.html]    
 
In  this  task,  we  have  specific  requirements  that  are  outlined  for  us  to  achieve  a  working  “Time  of  Day  
Routing”  configuration.  In  this  case,  to  meet  the  requirements  with  as  minimal  impact  to  the  existing  
CUCM  dial  plan  as  possible,  we  should  define  Time  Periods  that  are  the  opposite  of  those  mentioned  
above.  Then  we  can  assign  a  Partition  that  is  active  only  outside  of  the  time  periods  defined  in  the  task.  
If  we  decided  to  configure  the  opposite,  and  define  the  time  periods  as  stated  in  the  question,  we  
would  then  have  to  create  a  specific  Partition  for  the  DN  and  modify  the  “normal”  CUCM  dial  plan  that  
was  created  throughout  the  previous  labs.  
 
With  that  said,  our  first  step  is  to  create  two  time  periods  by  navigating  to  Call  Routing  !  Class  of  
Control  !  Time  Period  and  clicking  the  Add  New  button.  Enter  a  descriptive  name  for  the  Time  Period  
(e.g.  “00-­‐12_M-­‐F_TP”).  
 

 
 
Next,  select  the  “Time  of  Day  Start”  and  “Time  of  Day  End”  from  the  dropdown  box.  

375 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  select  the  “Repeat”  parameters  that  should  take  place  for  the  time  period.  In  this  case,  “Week  
from  Mon  through  Fri”  was  selected.  
 

 
 
The  above  configuration  defines  only  one  half  of  the  time  period  that  is  necessary  in  our  configuration  
(00:00  to  12:00).  Remember,  the  question  is  asking  for  HQ  Phone  1  to  be  active  between  the  hours  of  
12pm  and  3pm  PST,  so  we  must  also  define  the  period  of  15:00  to  24:00.  
 

 
 
With  the  Time  Periods  configured  successfully,  we  must  now  create  a  Time  Schedule  by  navigating  to  
Call  Routing  !  Class  of  Control  !  Time  Schedule  and  clicking  the  Add  New  button.  Enter  a  descriptive  
name  for  the  Time  Schedule  (e.g.  “00-­‐12_15-­‐24_TS”)  and  click  the  Save  button  to  continue.  
 

 
 
   

376 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  select  the  previously  created  Time  Periods  and  move  them  to  the  “Selected  Time  Periods”  list  
box.  
 

 
 
Next,  we  must  create  a  Partition  that  has  the  newly  created  Time  Schedule  assigned.  This  will  allow  the  
Partition  to  be  active  only  during  the  configured  Time  Periods.  Navigate  to  Call  Routing  !  Class  of  
Control  !  Partition  and  click  the  Add  New  button.  Enter  a  descriptive  name  for  the  Partition  and  click  
the  Save  button.  
 

 
 
Next,  we  must  edit  the  newly  created  Partition  to  include  the  correct  Time  Schedule.  Click  on  the  
“HQP1_TOD_PT”  from  the  Partition  list  to  bring  up  the  “Partition  Configuration”  window.  Make  sure  to  
select  the  correct  Time  Schedule  (e.g.  “00-­‐12_15-­‐24_TS”)  and  Time  Zone  (PST)  per  the  task  
requirements.  
 

 
 
Next,  we  must  assign  the  Partition  to  Calling  Search  Spaces  that  have  the  requirement  to  reach  HQ  
Phone  1.  In  other  words,  any  CSS  that  has  the  “INTERNAL_PT”  should  be  modified  to  include  the  
“HQP1_TOD_PT”  as  well.  Keep  in  mind  that  the  “HQP1_TOD_PT”  should  be  positioned  above  the  
“INTERNAL_PT”  so  when  it  is  active,  calls  are  routed  to  the  number  assigned  to  the  “HQP1_TOD_PT”  
Partition.  This  includes  the  below  list  of  CSSs.  
 
• GW_TRUNK_CSS  
• INTERNAL_CSS  
• PHONE_CSS  
• SB_TEHO_CSS  

377 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Navigate  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  click  the  Find  button.  Click  on  
the  above  CSSs  and  modify  them  as  described  above.  
 

 
 
Next,  we’ll  need  to  create  a  CSS  for  the  Translation  Pattern  that  satisfies  the  routing  requirement.  
Since  we  will  need  to  forward  the  call  to  SB  Phone  1,  we’ll  need  to  create  a  CSS  that  has  access  to  the  
“SB_SIP_ICT_PT”  Partition.  Give  it  a  name  that  is  easily  recognizable  (e.g.  “SB_SIP_ICT_CSS”)  and  add  
the  Partition  to  the  list.    
 

 
 
Finally,  we  must  create  a  Translation  Pattern  to  accommodate  the  routing  requirements  when  the  
“HQP1_TOD_PT”  Partition  is  active.  Remember,  the  requirements  of  the  question  stated  that  we  must  
forward  the  call  to  SB  Phone  1  (2001).  Navigate  to  Call  Routing  !  Translation  Pattern.  Enter  the  
pattern  as  “1001”  to  match  the  DN  of  HQ  Phone  1  and  select  the  “HQP1_TOD_PT”  Partition  from  the  
dropdown  box.  
 

 
 
   

378 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  be  sure  to  select  the  previously  created  CSS  (e.g.  “SB_SIP_ICT_CSS”)  that  has  the  ability  to  access  
DN  “2001”  in  the  “SB_SIP_ICT_PT”  Partition.    
 

 
 
Next,  under  the  “Called  Party  Transformations”  section,  use  the  “Called  Party  Transform  Mask”  to  
overwrite  the  original  called  number  with  “2001”.    
 

 
 
Click  the  Save  button  when  completed.  
 
Now  we  can  test  the  configuration  by  placing  a  test  call  from  anywhere  that  has  access  to  HQ  Phone  1.  
If  calling  outside  the  hours  of  12pm  –  3pm  PST,  the  call  should  ring  SB  Phone  1.  During  those  hours,  HQ  
Phone  1  should  ring  as  normal.  As  the  task  states,  you  may  change  the  Time  Period  as  necessary  to  test  
the  configuration.  
 
   

379 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 21.2 Configure  the  SB  CUCM  cluster  such  that  calls  to  SB  Phone  2  will  only  ring  during  the  
hours  of  8am  and  10am,  12pm  and  3pm,  and  7pm  and  9pm  CST  (UTC  -­‐6),  Monday  
through  Friday.  All  calls  outside  of  those  hours  will  ring  SB  Phone  1.    
 
The  task  requirements  here  are  very  similar  to  the  previous  question.  In  this  case,  we  must  configure  
four  different  Time  Periods  and  assign  them  to  a  Time  Schedule.  From  there,  we  must  create  a  
Partition  that  uses  the  created  Time  Schedule.  The  CSSs  that  have  access  to  SB  Phone  2  should  once  
again  be  modified  to  include  the  created  “TOD”  Partition  as  the  preferred  option  in  the  Partition  list.  
Finally  a  Translation  Pattern  should  be  created  for  DN  “2002”  that  translates  to  “2001”  outside  of  the  
defined  hours  in  the  question.  See  the  below  screenshots  for  the  configuration.  
 
Create  the  Time  Periods  
 

 
 

 
 

 
 

380 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Create  the  Time  Schedule  
 

 
 
Create  the  Partition  
 

 
 
   

381 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Modify  the  CSSs  


• GW_TRUNK_CSS  
• HQ_TEHO_CSS  
• INTERNAL_CSS  
• PHONE_CSS  
 

 
 
Create  the  Translation  Pattern  
 

 
 

 
 
Now  we  can  test  the  configuration  by  placing  a  test  call  from  anywhere  that  has  access  to  SB  Phone  2.  
As  the  task  states,  you  may  change  the  Time  Period  as  necessary  to  test  the  configuration.  
 

382 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 22: Device Mobility


Task 22.1 A  little  subnetting  knowledge  never  hurt  anybody  right?  In  order  to  properly  test  this  
feature,  we  need  to  “trick”  CUCM  into  thinking  that  there  are  two  different  voice  
subnets  even  though  there  is  only  one  in  reality.  With  that  said,  the  two  subnets  
used  for  this  section  will  be  “host  addresses”;  in  other  words  a  subnet  mask  of  
255.255.255.255  (/32).  Configure  a  new  Device  Pool  named  DM_DP  on  the  HQ  
CUCM  to  represent  the  roaming  site.  The  new  “site”  is  in  the  Eastern  Time  Zone  
(UTC  -­‐5).  
 
Before  configuring  Device  Mobility,  let’s  perform  a  little  “set  up”.  We’ll  need  to  create  both  a  
Date/Time  Group  and  Device  Pool  to  accommodate  the  requirements.  
 
Navigate  to  System  !  Date/Time  Group  and  click  the  Find  button.  Click  on  the  existing  “PST_DTG”  and  
click  the  Copy  button.  Next,  change  the  name  to  “EST_DTG”,  select  a  “GMT  -­‐5”  time  zone  (e.g.  
America/New  York)  from  the  dropdown  box,  and  click  the  Save  button.  
 

 
 
Next,  navigate  to  System  !  Device  Pool  and  click  the  Find  button.  Select  the  “HQ_PHONE_DP”  and  
click  the  Copy  button  to  create  a  new  Device  Pool  based  on  the  existing  Device  Pool.  Rename  it  to  
“DM_DP”  as  dictated  by  the  task  and  select  the  Date/Time  Group  that  was  previously  configured  (e.g.  
“EST_DTG”).  
 

 
 
   

383 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 22.2 Configure  CUCM  such  that  HQ  Phone  2  is  able  to  “roam”  to  another  site  on  the  HQ  
cluster,  represented  by  a  newly  configured  Device  Pool,  DM_DP.    
 
With  Cisco  Unified  Communications  Manager,  a  site  or  a  physical  location  gets  identified  by  using  
various  settings,  such  as  locations,  regions,  calling  search  spaces,  and  media  resources.  Cisco  Unified  IP  
Phones  that  reside  at  a  particular  site  get  statically  configured  with  these  settings  and  Cisco  Unified  
Communications  Manager  uses  these  settings  for  proper  call  establishment,  call  routing,  media  
resource  selection,  and  so  forth.  However,  when  phones  get  moved  from  the  home  location  to  a  
remote  location,  these  phones  retain  the  home  settings  that  are  statically  configured  on  the  phones.  
Cisco  Unified  Communications  Manager  uses  these  home  settings  for  the  phones  that  are  located  at  
the  remote  site,  which  may  cause  problems  with  call  routing,  codec  selection,  media  resource  
selection,  and  other  call  processing  functions.  
 
You  can  configure  device  mobility,  which  allows  Cisco  Unified  Communications  Manager  to  determine  
whether  the  phone  is  at  its  home  location  or  at  a  roaming  location.  Cisco  Unified  Communications  
Manager  uses  the  device  IP  subnets  to  determine  the  exact  location  of  the  phone.  By  enabling  device  
mobility,  mobile  users  can  roam  from  one  site  to  another  and  acquire  the  site-­‐specific  settings.  Cisco  
Unified  Communications  Manager  then  uses  these  dynamically  allocated  settings  for  call  routing,  codec  
section,  media  resource  selection,  and  so  forth.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF
0C471_00_cucm-­‐features-­‐services-­‐guide-­‐90/CUCM_BK_CEF0C471_00_cucm-­‐features-­‐and-­‐services-­‐
guide_chapter_010110.html]    
 
The  following  image  is  an  overview  of  the  configuration  elements  for  Device  Mobility.  
 

 
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/9x/uc9x/mobilapp.html#wp12398
11]    

384 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Based  on  the  above  information,  we  can  use  Device  Mobility  to  apply  settings  to  a  device  based  on  the  
location.  Specifically,  we  can  use  an  IP  address  to  determine  the  location  of  the  device.  With  that  in  
mind,  we  must  create  a  “Device  Mobility  Info”  object  and  add  subnet  information  for  the  location  of  
the  phones.    
 
Navigate  to  System  !  Device  Mobility  !  Device  Mobility  Info  and  click  the  Add  New  button.  Enter  a  
descriptive  name  (e.g.  “HQP2_DMI”)  as  well  as  the  “Subnet”  and  “Subnet  Mask”  information.  
Remember,  a  host  address  is  going  to  be  used  in  this  case  due  to  the  fact  that  we  have  limited  phones  
with  which  to  test.  Therefore,  the  IP  address  of  HQ  Phone  2  should  be  entered  for  the  “Subnet”  and  a  
value  of  “32”  should  be  set  for  the  “Subnet  Mask”.  
 

 
 
Next,  we  must  assign  the  IP  addressing  information  to  the  correct  Device  Pool  by  highlighting  the  
desired  option  within  the  list  and  clicking  the  arrow  to  add  it  to  the  “Selected  Device  Pools”  list.  
 

 
 
Next,  we  must  configure  a  Physical  Location  to  be  associated  with  the  Device  Pool.  This  will  help  to  
determine  whether  or  not  a  device  is  in  the  “roaming”  state.  If  the  Physical  Location  is  different  from  
what  is  configured  in  the  phone’s  normally  configured  Device  Pool,  the  phone  is  considered  to  be  
“roaming”  and  will  use  the  Device  Pool  that  has  the  Physical  Location  assigned.  Navigate  to  System  !  
Physical  Location  and  click  the  Add  New  button.  Assign  a  descriptive  name  (e.g.  “HQP2_PHY”)  and  click  
the  Save  button.  
 

 
 
Next,  we  must  create  a  Device  Mobility  Group  in  order  to  determine  whether  or  not  the  “Device  
Mobility  Related  Information”  settings  within  the  Device  Pool  should  be  applied.  Remember,  these  

385 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

settings  will  only  be  applied  if  the  configured  Device  Mobility  Groups  match  across  Device  Pools.  
Navigate  to  System  !  Device  Mobility  !  Device  Mobility  Group.  Add  a  descriptive  name  and  click  the  
Save  button  when  complete.  
 

 
 
Next,  we  must  assign  the  Physical  Location  and  Device  Mobility  Group  to  a  Device  Pool  by  navigating  to  
System  !  Device  Pool  and  clicking  the  Find  button.  Click  the  “DM_DP”  that  was  created  earlier  in  the  
lab.  Under  the  “Roaming  Sensitive  Settings”  section,  select  the  “Physical  Location”  as  “HQP2_PHY”  and  
the  “Device  Mobility  Group”  as  “HQP2_DMG”.  
 

 
 
Click  the  Save  button  when  complete.  
 
As  a  final  step,  we  must  enable  Device  Mobility  on  the  phone  by  navigating  to  Device  !  Phone  and  
clicking  the  Find  button.  Locate  HQ  Phone  2  and  click  it  to  edit  the  settings.  Under  the  “Device  
Information”  section,  set  the  “Device  Mobility  Mode”  dropdown  box  to  “On”  and  click  the  Save  and  
Reset  buttons  to  apply  the  configuration.  
 

 
 
   

386 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

At  this  point,  the  phone  should  reboot  and  display  a  message  stating  “Device  in  Roaming  Location”.  
 

 
 
Examine  the  below  flow  chart  (taken  from  the  SRND)  to  get  a  better  feel  for  the  way  in  which  Device  
Mobility  applies  different  Device  Pool  settings.  
 

 
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/9x/uc9x/mobilapp.html#wp12398
11]      

387 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 22.3 Ensure  that  HQ  Phone  2  can  make  a  successful  call  to  HQ  Phone  1.  Ensure  that  this  
call  uses  the  iLBC  codec.    
 
In  order  to  assure  that  the  iLBC  codec  is  used  between  HQ  Phone  1  and  HQ  Phone  2  (while  roaming),  
we  must  create  a  new  Region  and  assign  it  to  the  Device  Pool  in  which  the  user  is  roaming.  In  this  case,  
the  “DM_DP”  was  used  for  roaming  purposes,  so  it  should  be  modified  to  include  a  new  Region  with  
the  appropriate  codec.  
 
Navigate  to  System  !  Region  Information  !  Region  and  click  the  Add  New  button.  Enter  a  descriptive  
name  (e.g.  “DM_REG”)  and  click  the  Save  button.  
 

 
 
Next,  select  the  “HQ_REG”  name  in  the  “Regions”  list  box  and  select  the  “Maximum  Audio  Bit  Rate”  to  
be  “16  kbps  (iLBC,  G.728)”.  
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  assign  the  newly  created  Region  to  the  “DM_DP”  Device  Pool  by  navigating  to  System  !  Device  
Pool  and  selecting  the  “DM_DP”  from  the  list.  Under  the  “Roaming  Sensitive  Settings”  area,  select  the  
“DM_REG”  for  the  “Region”  parameter.    
 

 
 
Click  the  Save  and  Reset  buttons  to  apply  the  configuration.  
 
   

388 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Make  a  test  call  and  verify  the  codec  being  used  between  the  two  devices.  
 
HQ  Phone  1  (9971)  
Settings  !  Administrator  Settings  !  Status  !  Call  Statistics  
 

 
 
HQ  Phone  2  (7965)  
Double-­‐Click  the  “?”  Key  
 

 
 
   

389 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 22.4 Ensure  that  HQ  Phone  2  returns  to  normal  configuration  after  verifying  the  above  
tasks.  
 
To  return  HQ  Phone  2  to  the  “normal”  configuration,  simply  change  the  “Subnet”  parameter  in  the  
Device  Mobility  Info  section  by  navigating  to  System  !  Device  Mobility  !  Device  Mobility  Info  and  
clicking  the  “HQP2_DMI”  link.  Change  the  “Subnet”  field  to  an  address  that  is  not  currently  being  used  
on  any  phone  (e.g.  “10.10.11.254”).  
 

 
 
Click  the  Save  button  when  complete.  
 

390 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 23: Unified Mobility


Task 23.1 Create  users  for  the  HQ  and  SB  clusters  and  associate  with  the  corresponding  
devices/lines.  Username/Password/PIN/Last  Name/First  Name:  
hqp1/cisco/12345/Simpson/Homer;  hqp2/cisco/12345/Simpson/Marge;  
sbp1/cisco/12345/Griffin/Peter;  sbp2/cisco/12345/Griffin/Lois.  
 
Cisco  Unified  Mobility  extends  the  rich  call  control  capabilities  of  Cisco  Unified  Communications  
Manager  from  the  primary  workplace  desk  phone  of  a  mobile  worker  to  any  location  or  device  of  their  
choosing.  
 
For  example,  Cisco  Unified  Mobility  associates  a  user  mobile  phone  number  with  the  user  business  IP  
phone  number.  Cisco  Unified  Mobility  then  directs  incoming  calls  to  ring  on  a  user  mobile  phone  as  
well  as  the  business  phone,  thus  providing  a  single  number  for  callers  to  reach  the  user.  Calls  that  go  
unanswered  on  all  the  designated  devices  get  redirected  to  the  enterprise  voice  mailbox  of  the  user  
(not  to  the  mobile  voice  mailbox).  
 
Administrators  can  configure  Cisco  Unified  Mobility,  formerly  known  as  Cisco  Unified  Mobility  
Manager,  by  using  the  Cisco  Unified  Communications  Manager  Administration  windows  to  configure  
the  setup  for  end  users.  End  users  can  use  Cisco  Unified  CM  User  Options  windows  to  configure  their  
own  personal  settings.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF
0C471_00_cucm-­‐features-­‐services-­‐guide-­‐90/CUCM_BK_CEF0C471_00_cucm-­‐features-­‐services-­‐guide-­‐
90_chapter_0101001.html]    
 
As  a  first  step  in  configuring  Unified  Mobility  in  CUCM,  we  must  configure  user  accounts  within  the  
CUCM  system.  This  task  requires  that  we  configure  End  Users  on  both  the  HQ  and  SB  CUCM  clusters.    
 
On  the  HQ  CUCM  cluster,  navigate  to  User  Management  !  End  User  and  click  the  Add  New  button.  
For  the  first  user,  enter  the  “User  ID”  as  “hqp1”  and  the  “Password”  as  “cisco”.  The  “PIN”  should  be  
entered  as  “12345”  and  the  “Last  Name”  and  “First  Name”  should  be  entered  as  “Simpson”  and  
“Homer”,  respectively.  
 

 
 
Since  the  task  dictates  that  we  must  associate  the  End  User  with  the  corresponding  phone  and  line,  we  
now  must  locate  the  “Device  Information”  section  and  click  the  Device  Association  button  to  begin  the  
process  of  associating  a  phone.  
391 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Upon  clicking  the  Device  Association  button,  find  the  device  to  control  on  the  “User  Device  
Association”  page.  Select  the  proper  device  and  click  the  “Save  Selected/Changes”  button.  Select  the  
“Back  to  User”  option  for  the  “Related  Links”  menu  and  click  the  Go  button  to  return  to  the  End  User  
Configuration.  
 

 
 
Next,  under  the  “Device  Information”  section,  click  the  Line  Appearance  Association  for  Presence  
button  to  launch  a  new  window  allowing  the  selection  of  a  line.  Find  the  proper  line,  click  the  
“Associate”  checkbox,  and  click  the  Save  button.  
 

 
 
At  this  point,  the  proper  device  and  line  (not  displayed  below)  has  been  associated  to  the  End  User  
account.  
 

 
 
The  last  step  is  to  select  the  “Primary  Extension”  for  the  user  under  the  “Directory  Number  
Associations”  section.    
 

392 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Once  all  of  the  above  steps  have  been  performed,  click  the  Save  button  to  complete  the  configuration.  
 
Remember  to  create  the  other  user  on  the  HQ  CUCM  cluster  (hqp2)  and  the  two  other  users  on  the  SB  
CUCM  cluster  (sbp1  and  sbp2)  by  following  the  above  steps.  
 
   

393 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 23.2 When  any  phone  dials  HQ  Phone  2  on  extension  1002,  the  call  should  be  presented  
at  both  HQ  Phone  2  as  well  as  HQ  Phone  2’s  mobile  number  (PSTN  Line  2).  Turn  off  
auto  answer  on  this  line.  
 
The  feature  that  is  being  described  in  this  task  is  called  Single  Number  Reach  (SNR)  or  Mobile  Connect.  
It  works  by  generating  a  call  to  the  configured  Remote  Destination  (mobile  number)  when  a  call  is  
received  at  the  desk  phone  of  the  user.  In  this  case,  we  are  specifically  going  to  configure  this  task  for  
the  HQ  Phone  2  user.  
 
The  first  step  is  to  create  a  Remote  Destination  Profile  (RDP)  for  the  user  by  navigating  to  Device  !  
Device  Settings  !  Remote  Destination  Profile  and  clicking  the  Add  New  button.  Add  a  descriptive  
name  in  the  “Name”  field  of  the  profile  (e.g.  “HQP2_RDP”).  
 

 
 
Next,  select  a  “User  ID”  from  the  dropdown  box.  Since  this  profile  is  specifically  being  created  for  the  
HQ  Phone  2  user,  select  the  “hqp2”  user.    
 

 
 
Next,  select  the  desired  “Device  Pool”  and  from  the  dropdown  box.  Generally,  this  should  be  the  same  
Device  Pool  that  is  configured  for  the  phone  (e.g.  “HQ_PHONE_DP”).    
 

 
 
Next,  the  “Calling  Search  Space”  is  a  parameter  that  would  typically  be  configured  here.  In  this  specific  
situation,  however,  it  is  not  necessary.  The  purpose  of  the  CSS  is  to  provide  access  for  Mobile  Voice  
Access  (MVA)  users,  which  will  be  configured  later  in  this  lab.  It  is  OK  to  set  a  value  here,  but  just  
realize  that  it  will  not  be  utilized  for  the  SNR  feature.  
 

 
 
   

394 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  another  CSS  option  can  be  configured  within  the  RDP  called  the  “Rerouting  Calling  Search  Space”.  
This  CSS  is  important  to  configure  here,  because  it  deals  directly  with  SNR  calls.  This  CSS  controls  
access  to  whatever  the  Remote  Destination  Number  happens  to  be.  A  specific  CSS  can  be  created,  if  
desired,  but  for  now,  the  “PHONE_CSS”  will  work  just  fine.  
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  under  the  “Association  Information”  section,  click  the  link  labeled  “Line  [1]  -­‐  Add  a  new  DN”  to  
add  a  new  DN  to  the  RDP.  In  this  case,  we  are  basically  creating  a  shared  line  between  the  RDP  and  the  
Phone.    
 

 
 
For  the  “Directory  Number”  and  “Route  Partition”  fields,  make  sure  to  enter  the  same  DN  that  is  
configured  for  HQ  Phone  2  (1002)  and  select  the  same  Partition  as  well  (e.g.  “INTERNAL_PT”).  
 

 
 
After  configuring  the  above  settings,  the  rest  of  the  fields  in  the  “Directory  Number  Configuration”  
page  should  auto-­‐populate,  since  the  DN  is  already  configured  in  the  system.  Click  the  Save  button  to  
save  the  configuration.    
 
Next,  on  the  “Remote  Destination  Profile  Configuration”  page,  click  the  link  to  “Add  a  New  Remote  
Destination”  to  add  a  PSTN  destination  to  the  configured  profile.    
 

 
 
Keep  in  mind  that  we  can  also  navigate  to  Device  !  Remote  Destination  and  click  the  Add  New  button  
to  get  to  the  same  configuration  window.    
 
   

395 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

For  the  “Name”  field,  add  a  descriptive  name  such  as  “HQP2_RDI”  to  describe  the  new  remote  
destination  number.    
 

 
 
Next,  for  the  “Destination  Number”  field,  we  should  enter  the  dialable  string  of  the  desired  PSTN  
number.  The  task  dictates  that  we  use  the  HQ  PSTN  (408-­‐613-­‐1218)  as  the  Remote  Destination  
number,  so  we  should  enter  the  number  as  if  the  user  were  dialing  it  directly.  In  this  case,  we  have  
patterns  in  the  system  that  accommodate  a  prefix  of  “9”  as  the  first  digit  as  well  as  +E.164,  or  “plus  
dial”.  With  this  in  mind,  the  number  should  be  in  one  of  those  two  formats.  I  will  typically  use  a  +E.164  
number  for  all  remote  destinations,  so  that  is  what  has  been  configured  here.    
 

 
 
The  pattern  that  this  will  eventually  match  is  the  “\+1408.[2-­‐9]XXXXXX”  Translation  Pattern  in  the  
“PLUS_DIAL_PT”  that  was  configured  in  a  previous  lab.  
 
Next,  if  not  already  chosen,  select  the  “HQP2_RDP”  for  the  “Remote  Destination  Profile”  and  ensure  
that  the  “Mobile  Phone”  and  “Enable  Mobile  Connect”  checkboxes  are  selected.    
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  ensure  that  the  “Line  Association”  checkbox  is  selected  for  line  “1002”.  This  will  ensure  that  the  
Remote  Destination  number  is  analogous  to  “1002”  as  far  as  CUCM  is  concerned.    
 

 
 
Click  the  Save  button  when  complete.  
 
   

396 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lastly,  make  sure  that  the  End  User  (hqp2)  has  the  Mobility  feature  enabled  and  that  the  Remote  
Destination  Profile  is  displayed  within  the  “End  User  Configuration”  page.  Navigate  to  User  
Management  !  End  User  and  click  on  the  “hqp2”  user.  Locate  the  “Mobility  Information”  section  and  
configure  the  settings  as  shown  below.  
 

 
 
To  verify  the  configuration,  make  a  test  call  from  HQ  Phone  1  to  DN  1002.  The  phone  should  ring  both  
the  desk  phone  and  the  “mobile  phone”  (HQ  PSTN).  You  can  utilize  the  debug isdn q931  
command  on  the  R1  gateway  to  examine  both  the  inbound  and  outbound  calls.  
 
R1  
R1#debug isdn q931
...
Nov 1 01:55:16.354: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x00DF
...
Display i = 'SB PSTN Phone'
Calling Party Number i = 0x2181, '3127764016'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '4082221002'
Plan:ISDN, Type:National
...
Nov 1 01:57:20.813: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x001F
...
Display i = 'HQ Phone 1'
Calling Party Number i = 0x4181, '2221001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '6131218'
Plan:ISDN, Type:Subscriber(local)
Redirecting Number i = 0x00008F, '+14082221002'
Plan:Unknown, Type:Unknown
...
 
   

397 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  PSTN  phone  display  should  appear  as  shown  below.  


 

 
 
   

398 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 23.3 The  call  should  ring  both  phones  simultaneously.    
 
You  may  have  noticed  in  the  last  task  that  there  was  a  small  delay  in  ringing  the  mobile  number  for  the  
“hqp2”  user  (HQ  PSTN).  This  is  because  the  default  timer  settings  within  the  “Remote  Destination  
Configuration”  page  were  not  optimized  to  generate  the  SNR  call  immediately.  Navigate  to  Device  !  
Remote  Destination  and  click  on  the  “HQP2_RDI”  link.  Notice  the  timer  settings  that  are  currently  
configured.    
 

 
 
Below  are  the  definitions  for  each  timer  according  to  the  CUCM  Help  Pages.  
 
• Answer  Too  Soon  Timer  –  Enter  the  minimum  time  in  milliseconds  that  Cisco  Unified  
Communications  Manager  requires  the  mobile  phone  to  ring  before  answering  the  call.  This  
setting  accounts  for  situations  where  the  mobile  phone  is  switched  off  or  is  not  reachable;  in  
which  case  the  network  may  immediately  divert  the  call  to  the  mobile  phone  voice  mail.  If  the  
mobile  phone  is  answered  before  this  timer  expires,  Cisco  Unified  Communications  Manager  
pulls  the  call  back  to  the  enterprise.  
• Answer  Too  Late  Timer  –  Enter  the  maximum  time  in  milliseconds  that  Cisco  Unified  
Communications  Manager  allows  for  the  mobile  phone  to  answer.  If  this  value  is  reached,  Cisco  
Unified  Communications  Manager  stops  ringing  the  mobile  phone  and  pulls  the  call  back  to  the  
enterprise.  
• Delay  Before  Ringing  Timer  –  Enter  the  time  that  elapses  before  the  mobile  phone  rings  when  
a  call  is  extended  to  the  remote  destination.  
[Source:    CUCM  !  Help  !  This  Page]  
 
Based  on  the  above  information,  we  can  determine  that  the  “Delay  Before  Ringing  Timer”  must  be  
modified  to  accommodate  the  requirements  in  the  task.  In  this  case,  we  should  set  the  timer  to  a  value  
of  “0”  in  order  to  ensure  that  there  is  no  delay  in  ringing  the  Remote  Destination.  
 

 
 
Click  the  Save  button  when  complete.    
 
Test  the  configuration  to  ensure  that  the  mobile  phone  for  the  “hqp2”  user  rings  immediately  after  the  
DN  1002  is  dialed  from  another  phone  in  the  enterprise.      

399 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 23.4 The  call  should  ring  the  mobile  number  for  at  least  3  rings,  but  not  long  enough  to  
forward  to  the  voicemail  of  the  mobile  phone  (4  rings).  The  call  should  use  the  
CallForward  NoAnswer  configuration  at  the  line  level.  (PSTN  forwards  to  line  6  to  
simulate  voicemail).  
 
In  this  case,  the  task  is  asking  for  the  Remote  Destination  to  be  configured  such  that  the  mobile  phone  
rings  for  at  least  12  seconds  (3  rings),  but  not  long  enough  to  enter  the  voicemail  system  of  the  mobile  
phone  (16  seconds).  We  may  need  to  modify  the  “Answer  Too  Late  Timer”,  since  that  controls  how  
long  the  mobile  phone  has  to  answer  the  call.  By  default,  this  timer  is  set  to  a  value  of  19  seconds.    
 
In  addition  to  the  “Answer  Too  Late  Timer”,  the  “Call  Forward  No  Answer”  (CFNA)  settings  within  the  
“Directory  Number  Configuration”  page  can  also  play  a  huge  role  in  the  success  of  the  answering  the  
question.  By  default,  the  CFNA  Timer  is  set  to  12  seconds.  This  means  that  the  caller  has  12  seconds  to  
answer  the  call  before  the  CFNA  settings  are  enforced  and  the  call  is  routed  to  an  alternate  
destination.    
 
With  this  in  mind,  we  really  shouldn’t  have  a  problem  meeting  the  requirements  of  the  question  using  
the  default  values.  The  mobile  number  should  ring  at  least  3  times,  since  the  configured  value  of  19  
seconds  is  more  than  enough  time.  Also,  the  call  should  successfully  be  “pulled  back”  to  CUCM  after  
the  third  ring,  since  the  CFNA  timer  is  set  to  12  seconds.  
 
All  that  to  say—you  don’t  have  to  configure  anything  here!  Feel  free  to  play  around  with  the  timers,  
however,  in  order  to  gain  a  thorough  understanding  of  their  operation.    
 
   

400 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 23.5 The  mobile  phone  should  only  be  rung  on  Monday  –  Friday  between  the  hours  of  
8am  and  3pm.  
 
This  task  requires  that  we  place  restrictions  on  when  the  mobile  number  of  “hqp2”  can  be  dialed  using  
the  SNR  feature.  Only  between  the  hours  of  0800  and  1500  on  Monday  through  Friday  should  SNR  be  
invoked.  To  configure  this  feature,  navigate  to  Device  !  Remote  Destination  and  click  on  the  
“HQP2_RDI”  link  to  enter  the  configuration.  Locate  the  “Ring  Schedule”  section  and  modify  the  
schedule  to  match  the  requirements  of  the  question.  
 

 
 
When  complete,  click  the  Save  button.  
 
To  test  the  configuration,  make  sure  that  SNR  does  not  attempt  to  ring  the  mobile  number  for  “hqp2”  
outside  of  the  hours  specified  within  the  “Remote  Destination  Configuration”  page.    
 
   

401 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 23.6 On  the  HQ  cluster,  configure  Mobile  Voice  Access  to  trigger  an  IVR  when  the  number  
408-­‐222-­‐1899  is  dialed  from  the  PSTN.  
 
This  next  task  exits  the  realm  of  SNR  and  enters  the  world  of  two-­‐stage  dialing  using  Mobile  Voice  
Access  (MVA).  
 
Mobile  Voice  Access  extends  Mobile  Connect  capabilities  by  allowing  users  to  originate  a  call  from  a  
remote  destination  such  as  a  cellular  phone  as  if  dialing  from  the  desktop  phone.  A  remote  destination  
is  a  phone  that  is  designated  as  available  for  Mobile  Connect  responses  and  pickup.  The  user  dials  
Mobile  Voice  Access  from  the  remote  destination.  The  user  is  prompted  for  the  PIN  assigned  to  the  
user  in  Cisco  Unified  Communications  Manager.  Once  authenticated,  the  user  can  make  a  call  using  the  
same  Mobile  Connect  features  that  would  be  available  if  the  user  originated  the  call  from  the  
enterprise  desktop  phone.  
 
When  calling  Mobile  Voice  Access,  the  system  prompts  the  user  for  the  originating  phone  number  in  
addition  to  the  PIN  if  any  of  the  following  is  true:  
 
• The  number  the  user  is  calling  from  is  not  one  of  the  user's  remote  destinations.  
• The  number  is  blocked  by  the  user  or  the  user's  carrier  (shown  as  "Unknown  Number").  
• The  number  is  not  accurately  matched  in  the  Cisco  Unified  Communications  Manager  database;  
for  example,  if  the  number  is  510-­‐666-­‐9999,  but  it  is  listed  as  666-­‐9999  in  the  database,  or  the  
number  is  408-­‐999-­‐6666,  but  it  is  entered  as  1-­‐408-­‐999-­‐6666  in  the  database.  
 
If  the  user  incorrectly  enters  any  requested  information  (such  as  cellular  phone  number  or  PIN)  three  
times  in  a  row,  the  Mobile  Voice  Access  call  disconnects,  and  the  user  is  locked  out  for  a  period  of  time.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/6_0_1/ccmfeat/cmfsgd601/fsm
obmgr.html#wp1124994]    
 
Since  all  of  the  user  accounts  have  been  created  and  both  the  “Remote  Destination  Profile”  and  
“Remote  Destination”  have  been  configured,  the  first  thing  we  must  do  to  configure  MVA  is  to  enable  
it.  This  can  be  accomplished  by  navigating  to  System  !  Service  Parameters  !  10.10.13.11  !  Cisco  
CallManager  and  locating  the  “Clusterwide  Parameters  (System  -­‐  Mobility)”  sub-­‐section.  In  this  section,  
the  parameter  entitled  “Enable  Mobile  Voice  Access”  should  be  set  to  “True”  using  the  dropdown  box.  
 

 
 
   

402 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  define  the  number  to  be  used  for  MVA  (“Mobile  Voice  Access  Number”).  In  this  case,  
the  number  “1899”  in  the  408-­‐222-­‐1XXX  DID  range  should  be  used,  since  that  was  defined  in  the  task.  
Calls  arrive  at  the  HQ  CUCM  in  4-­‐digit  format,  so  we  must  enter  the  4-­‐digit  version  of  the  number  here.    
 

 
 
Next,  we  must  define  the  number  of  digits  that  should  be  matched  as  the  call  is  routed  inbound  from  
the  PSTN.  In  this  case,  this  is  referring  to  the  ANI  of  the  PSTN  caller.  By  default,  the  PSTN  ANI  must  
exactly  match  whatever  number  is  configured  in  the  “Remote  Destination  Configuration”  page  to  be  
considered  an  equivalent  number.  For  example,  if  a  call  is  routed  into  CUCM  with  the  ANI  of  
“4086131218”  and  the  Remote  Destination  Number  is  configured  as  “+14086131218”,  the  number  
does  not  match.  Fortunately,  there  are  two  Service  Parameters  available  to  overcome  this  limitation,  
called  “Matching  Caller  ID  with  Remote  Destination”  and  “Number  of  Digits  for  Caller  ID  Partial  Match”.  
Setting  the  former  to  “Partial  Match”  and  the  latter  to  a  value  of  “10”  solves  the  above  problem  
because  only  10  digits  must  match  in  both  strings.  Of  course,  the  benefit  here  is  that,  when  configured  
properly,  the  system  will  automatically  recognize  that  the  number  from  which  you  are  calling  is  a  
configured  Remote  Destination  and  thus,  will  not  ask  you  to  input  the  number  to  log  into  the  system.  
 

 
 
At  this  point,  we  can  click  the  Save  button  to  apply  the  settings  of  the  configured  Service  Parameters.    
 
Next  on  the  list  in  our  quest  to  configure  MVA  is  to  configure  the  MVA  number  within  the  system.  The  
Service  Parameter  configuration  listed  what  the  number  should  be,  but  we  must  also  configure  the  
number  within  the  Media  Resources  menu  as  well.  Navigate  to  Media  Resources  !  Mobile  Voice  
Access  and  enter  the  “Mobile  Voice  Access  Directory  Number”  as  “1899”.  Also,  select  a  Partition  that  is  
accessible  by  all  phones  (e.g.  “INTERNAL_PT”).  Finally,  select  a  “Locale”  for  the  MVA  DN  (e.g.  “English  
United  States”).  
 

 
 
Click  the  Save  button  when  complete.  

403 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  next  component  of  MVA  is  to  configure  the  gateway.  Believe  or  not,  this  requires  the  use  of  either  
a  SIP  or  H.323  gateway.  The  reason  is  because  we  need  to  invoke  a  VoiceXML  script  (triggered  by  a  
dial-peer)  from  the  gateway  and  this  cannot  be  done  with  MGCP.  Now  here’s  the  problem—PSTN  
calls  are  routed  into  the  HQ  CUCM  cluster  using  the  MGCP  gateway.  So  how  can  we  accomplish  this  
requirement  while  only  using  MGCP?  The  very  simple  answer  is—we  can’t!  What  we  will  need  to  do  is  
first  accept  the  call  from  the  PSTN  destined  toward  the  MVA  DN  of  1899  on  the  MGCP  gateway.  At  that  
point,  we  must  then  route  the  call  back  out  to  a  gateway  (SIP/H.323)  in  order  to  invoke  the  VoiceXML  
script.  This  process  is  sometimes  called  hairpinning.  
 
What  we  should  do  at  this  point  is  create  a  SIP  or  H.323  gateway  on  R1  to  be  used  for  the  VoiceXML  
invocation.  In  this  case,  we  can  use  an  H.323  gateway.  Navigate  to  Device  !  Gateway  and  click  the  
Add  New  button.  Select  the  “H.323  Gateway”  from  the  dropdown  box  and  click  the  Next  button  to  
continue.  
 

 
 
Next,  enter  the  IP  address  of  the  R1  gateway  that  should  be  used  for  H.323  communication.  In  this  
case,  Loopback  0  (10.10.1.1)  was  used.  Select  a  “Device  Pool”  for  the  gateway  as  well.  
 

 
 
Next,  make  sure  that  a  CSS  is  selected  for  the  gateway  under  the  “Call  Routing  Information  -­‐  Inbound  
Calls”  section.  This  controls  access  to  the  patterns  dialed  by  the  remote  user.  
 

 
 
Click  the  Save  button  when  complete.  Place  the  newly  created  H.323  gateway  in  a  Route  Group  (e.g.  
“MVA_RG”)  and  Route  List  (e.g.  “MVA_RL”)  using  the  techniques  demonstrated  in  previous  labs.    
 
   

404 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  create  a  Route  Pattern  for  the  MVA  number  at  “1899”  that  utilizes  a  Partition  accessible  by  the  
MGCP  gateway  (e.g.  “MVA_PT”)  and  a  Route  List  that  utilizes  the  newly  created  H.323  gateway.  
 

 
 
Make  sure  that  the  CSS  of  the  MGCP  gateway  has  access  to  the  “MVA_PT”,  so  calls  can  be  successfully  
hairpinned.  
 

 
 
Next,  we  must  configure  the  R1  gateway  to  communicate  with  the  HQ  CUCM  cluster  using  H.323.  Just  
as  is  done  with  all  H.323  gateways,  we  must  configure  the  IP  source  address.  This  was  defined  as  the  
Loopback  0  interface  within  the  CUCM  configuration,  so  the  h323-gateway voip bind
srcaddr <IP Address>  command  must  be  added  to  the  Loopback  0  on  the  router.  
 
R1  
R1(config)#interface Loopback0
R1(config-if)# h323-gateway voip bind srcaddr 10.10.1.1
 
   

405 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  configure  a  dial-peer  to  accept  the  hairpinned  call  as  it  is  routed  from  the  HQ  
CUCM.  Remember,  we  need  to  match  the  MVA  DN  at  “1899”  that  was  configured  in  the  system.  
 
R1  
R1(config)#dial-peer voice 1899 voip
R1(config-dial-peer)#destination-pattern 1899
R1(config-dial-peer)#session target ipv4:10.10.13.12
R1(config-dial-peer)#incoming called-number 1899
R1(config-dial-peer)#codec g711ulaw
R1(config-dial-peer)#no vad
 
Next,  we  must  add  the  VoiceXML  application.  This  is  actually  just  a  simple  URL  pointing  toward  the  HQ  
CUCM  Publisher  server.  It  can  be  obtained  by  searching  the  CUCM  help  files.  
 
R1  
R1(config)#application
R1(config-app)#service MVA http://10.10.13.11:8080/ccmivr/pages/IVRMainpage.vxml
 
Once  the  application  is  created,  we  must  add  it  to  the  previously  created  dial-peer  in  the  system.  
This  will  invoke  the  MVA  application.  
 
R1  
R1(config)#dial-peer voice 1899 voip
R1(config-dial-peer)#service mva
 
At  this  point,  we  are  ready  to  make  calls.  Use  the  HQ  PSTN  line  to  make  a  7-­‐digit  call  to  the  MVA  DN  
(“2221899”)  and  ensure  that  the  prompt  is  played.  We  will  take  a  deeper  dive  into  the  “testing”  phase  
in  the  next  few  tasks.  
 
   

406 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 23.7 The  IVR  should  prompt  for  the  Remote  Destination  and  then  a  PIN.    
 
If  you  experimented  with  the  configuration  after  testing  the  previous  task,  excellent  job!  Learning  the  
configuration  environment  is  an  excellent  way  to  learn  the  “ins  and  outs”.  The  reason  why  I  mentioned  
this  here  specifically  is  because  there  may  be  some  unexpected  behavior  occurring  with  the  MVA  DN.    
 
When  dialing  the  MVA  number,  the  system  immediately  asks  for  the  Remote  Destination  number  and  
PIN.  While  this  meets  the  requirement  of  the  current  task,  this  may  not  make  too  much  sense.  We  
went  through  all  the  trouble  of  configuring  the  “Partial  Match”  Service  Parameters  so  the  number  
would  match  the  Remote  Destination,  right?  We  did,  but  in  this  specific  case,  those  settings  do  not  
matter!  The  reason  is  because  by  the  time  the  call  arrives  at  the  CUCM  cluster,  it  has  already  been  
recognized  as  a  configured  Remote  Destination  and  has  thus,  changed  it  to  the  number  that  it  uses  for  
its  shared  line  appearance  (DN  1002).  This  means  that  by  the  time  it  accesses  the  H.323  gateway  
immediately  following  the  hairpin,  the  ANI  is  not  recognizable  for  comparison  against  the  configured  
Remote  Destination  (“1002”  vs.  “+14086131218”).  We  can  verify  this  by  running  a  debug voip
dialpeer  on  the  R1  gateway  to  observe  the  calling  number  (1002)  as  it  enters  the  gateway.  
 
R1  
R1#debug voip dialpeer
voip dialpeer default debugging is on

Nov 1 08:21:28.380: //-1/80F969120500/DPM/dpAssociateIncomingPeerCore:


Calling Number=1002, Called Number=1899, Voice-Interface=0x0,
 
Basically  what  we  need  to  understand  in  this  section  is  that  ANI  recognition  is  not  possible  when  the  
call  has  been  hairpinned  to  another  gateway.    
 
Aside  from  that,  trying  to  log  into  the  system  may  yield  some  puzzling  results.  The  Remote  Destination  
number  should  be  entered  in  E.164  format  (14086131218)  and  the  PIN  that  should  be  used  
corresponds  to  the  PIN  of  the  “hqp2”  End  User  (12345).  Upon  logging  in,  you  will  receive  a  message  
that  asks  if  you  would  like  to  turn  on  Cisco  Unified  Mobility.  If  option  2  is  selected  to  “turn  on”,  nothing  
happens  at  all  to  grant  access  to  dial  other  numbers  in  the  system.  This  is  because  we  must  enable  the  
“Mobile  Voice  Access”  feature  on  the  End  User  page  in  the  system  first.    
 
Navigate  to  User  Management  !  End  User  and  click  on  the  “hqp2”  user.  Under  the  “Mobility  
Information”  section,  check  the  “Enable  Mobile  Voice  Access”  checkbox  and  click  the  Save  button.  
 

 
 
Now  make  another  call  into  the  MVA  number.  You  should  be  able  to  successfully  log  in  at  this  point.  
 
   

407 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 23.8 Set  the  IVR  such  that  pressing  1  allows  the  user  to  dial  another  number,  pressing  2  
enables  Mobile  Connect,  and  pressing  3  disables  Mobile  Connect.  
 
I  have  to  admit,  this  question  is  a  “freebie”.  Everything  described  in  this  task  happens  by  default  with  
the  MVA  application.  In  fact,  there  is  no  way  to  modify  to  IVR  options  at  all  with  MVA.  Test  all  the  
available  options  to  familiarize  yourself  with  the  configuration.  
 
   

408 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 23.9 When  calling  from  the  mobile  phone  to  HQ  Phone  1,  it  should  appear  as  if  the  call  is  
coming  directly  from  HQ  Phone  2  (Calling  Name  and  Number).  
 
Once  again,  this  is  a  feature  that  happens  by  default  once  logged  in.  This  feature  is  at  the  heart  of  the  
application  in  that  the  whole  point  is  to  be  able  to  make  calls  that  appear  to  be  originating  from  the  
desk  phone  at  the  Enterprise.  Test  the  configuration  to  ensure  that  everything  is  working  as  expected.  
Below  is  an  example  call  being  made  from  the  PSTN  phone  (after  logging  into  MVA)  to  HQ  Phone  1.  
 

 
 

409 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 24: Extension Mobility and Extension Mobility Cross Cluster


Task 24.1 Configure  extension  mobility  on  both  the  HQ  and  SB  clusters  such  that  HQ  users  can  
log  in  to  any  HQ  phone  and  SB  users  can  log  in  to  any  SB  phone.  
 
Cisco  Extension  Mobility  allows  users  to  temporarily  access  their  Cisco  Unified  IP  Phone  configuration  
such  as  line  appearances,  services,  and  speed  dials  from  other  Cisco  Unified  IP  Phones.  
 
Extension  mobility  functionality  extends  to  most  Cisco  Unified  IP  Phones.  You  can  configure  each  Cisco  
Unified  IP  Phone  to  support  Cisco  Extension  Mobility  by  using  the  Default  Device  Profile  window  in  
Cisco  Unified  Communications  Manager  Administration.  This  allows  users  who  do  not  have  a  user  
device  profile  for  a  particular  Cisco  Unified  IP  Phone  to  use  Cisco  Extension  Mobility  with  that  phone.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmfeat/CUCM_BK_C3E
0EFA0_00_cucm-­‐features-­‐services-­‐guide-­‐91/CUCM_BK_C3E0EFA0_00_cucm-­‐features-­‐services-­‐guide-­‐
91_chapter_0110111.html]    
 
As  the  name  implies,  Extension  Mobility  (EM)  is  used  to  allow  the  user  to  move  his/her  associated  
extension  to  another  phone  after  properly  authenticating.  All  dialing  behavior  will  be  retained  at  that  
point  and  the  user  can  make  calls  just  as  would  normally  be  done  at  the  “home”  location  of  that  user.  
Keep  in  mind  that  EM  is  a  service  that  only  has  the  ability  to  allow  “log  in”  functionality  on  a  single  
cluster.  
 
On  both  the  HQ  and  SB  CUCM  clusters,  the  first  step  to  enable  EM  is  to  activate  the  service  within  the  
Cisco  Unified  Serviceability  web  page  by  navigating  to  Tools  !  Service  Activation  !  Select  Server  and  
checking  the  “Cisco  Extension  Mobility”  service  checkbox.  
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  an  instance  of  the  EM  Phone  Service  must  be  created  on  each  CUCM  cluster  in  order  for  phones  
to  have  access  to  log  in.  Ensure  that  the  Cisco  Unified  CM  Administration  webpage  is  used  to  navigate  
to  Device  !  Device  Settings  !  Phone  Services.  Click  the  Add  New  button  to  configure  the  EM  service.    
 
   

410 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Enter  the  Service  Name  (e.g.  “EM”)  to  be  displayed  on  the  phone  screen  when  the  user  attempts  to  log  
in.  Next,  enter  the  EM  URL  to  access  the  service  through  the  CUCM  publisher  server  (e.g.  
http://10.10.13.11:8080/emapp/EMAppServlet?device=#DEVICENAME#  for  the  HQ  CUCM  cluster).  
This  URL  can  be  obtained  from  the  CUCM  Features  and  Services  Guide  (linked  above).    
 

 
 
Next,  make  sure  to  check  the  “Enable”  checkbox.  The  “Enterprise  Subscription”  checkbox  can  also  be  
selected  to  subscribe  every  device  to  the  service.  This  box  can  safely  be  checked  here,  but  if  the  
intention  is  to  only  activate  the  service  on  a  handful  of  devices  in  the  cluster,  it  is  best  to  leave  this  
setting  unchecked.  
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  we  must  create  the  Device  Profile  to  be  utilized  by  the  end  user  when  logging  into  the  EM  
service.  The  HQ  CUCM  cluster  will  be  used  in  this  example,  but  ensure  that  Device  Profiles  are  created  
on  both  CUCM  clusters  to  support  users  in  each  location.  Navigate  to  Device  !  Device  Settings  !  
Device  Profile  and  click  the  Add  New  button.  Select  the  “Device  Profile  Type”  from  the  dropdown  
menu  to  select  the  model  of  the  phone  with  which  the  Device  Profile  should  be  associated.  In  this  case,  
the  “Cisco  9971”  was  selected.  Click  the  Next  button  when  complete.  
 

 
 
   

411 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  enter  a  value  for  the  “Device  Profile  Name”  textbox.  A  typical  naming  convention  here  includes  
the  username  and  the  phone  type  in  some  fashion  (e.g.  “HQP1_9971_DP”)  so  that  the  intention  for  
user  assignment  is  understood  simply  by  looking  at  the  name.  As  you  can  see,  the  user  in  this  case  is  
“HQP1”  and  the  phone  type  is  “9971”.    
 

 
 
Next,  select  the  “Phone  Button  Template”  from  the  dropdown  box.  Select  the  option  that  is  currently  
associated  with  the  9971  phone  on  the  cluster  (e.g.  “Standard  9971  SIP  –  2L-­‐1HG-­‐1SB-­‐1P-­‐1S”).    
 

 
 
Click  the  Save  button  when  complete.    
 
You  may  have  noticed  that  nowhere  in  the  “Device  Profile  Configuration”  page  is  a  “Device  CSS”  
available  as  a  configuration  option.  This  is  because  the  Device  CSS  associated  with  the  phone  used  for  
log  in  will  be  used  instead.  In  fact,  it  will  be  concatenated  with  any  “Line  CSS”  that  is  configured  on  the  
Device  Profile  (with  the  “Line  CSS”  taking  precedence).    
 
With  that  said,  the  next  item  that  must  be  configured  is  the  line  to  be  associated  with  the  newly  
created  Device  Profile.  Click  the  “Line  [1]  -­‐  Add  a  new  DN”  link  under  the  “Association  Info”  section.  
 

 
 
Add  a  “Directory  Number”  to  be  associated  with  the  Device  Profile.  This  should  be  the  same  DN  that  is  
assigned  to  the  desk  phone  of  the  user  at  this  point.  Essentially,  this  means  that  we  are  creating  a  
shared  line  between  the  desk  phone  and  the  Device  Profile.  In  this  example,  DN  1001  was  used  since  
this  is  the  DN  currently  assigned  to  the  “HQP1”  user  by  way  of  the  9971  phone  at  HQ  (HQ  Phone  1).  
The  “INTERNAL_PT”  was  selected  here  as  well.  
 

 
 

412 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

After  selecting  the  “Directory  Number”  and  “Route  Partition”,  all  of  the  relevant  information  for  the  
line  should  appear,  since  the  line  is  already  created  in  the  database  and  assigned  to  a  phone.  Click  the  
Save  button  the  complete  the  configuration.  
 
Now  that  the  Device  Profile  has  been  configured,  it  can  be  assigned  to  a  user.  In  this  case,  we  don’t  
have  to  create  a  user  since  one  has  already  been  created  in  a  previous  lab.  Navigate  to  User  
Management  !  End  User  and  click  on  the  “hqp1”  user.  Under  the  “Device  Information”  section,  from  
the  “Available  Profiles”  list  box,  select  the  Device  Profile  that  was  created  (e.g.  “HQP1_9971_DP”)  and  
click  the  arrows  to  move  it  into  the  “CTI  Controlled  Device  Profiles”  list  box.  
 

 
 
Next,  under  the  “Extension  Mobility”  section,  select  the  “HQP1_9971_DP”  Device  Profile  again  and  
click  the  arrows  to  move  it  into  the  “Controlled  Profiles”  list  box.  
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  we  must  enable  EM  on  each  phone  configured  in  the  system  by  navigating  to  Device  !  Phone  
and  clicking  on  the  phone  in  question.  Under  the  “Extension  Information”  section  on  the  “Phone  
Configuration”  page,  check  the  “Enable  Extension  Mobility”  box  to  enable  EM  on  the  phone.    
 

 
 
Click  the  Save  button  when  complete.  Ensure  that  these  steps  are  followed  for  all  phones  on  both  the  
HQ  and  SB  CUCM  clusters.    

413 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  test  the  configuration,  press  the  Settings  (9971)/Services  (7965)  button  on  the  phone.  On  the  9971  
phone,  the  EM  service  must  be  selected  from  the  list.  On  the  7965  phone,  since  there  are  no  other  
services  installed,  the  EM  service  will  automatically  be  selected.    
 

 
 

 
 
   

414 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Log  in  to  the  phone  using  the  User  ID  and  PIN  configured  within  the  End  User  configuration  page.  
 

 
 
After  successfully  logging  in,  the  following  message  appears.  
 

 
 
Remember,  you  should  be  able  to  successfully  log  in  to  each  phone  with  any  user  on  each  cluster.  You  
will  not  be  able  to  log  in  with  an  HQ  user  on  the  SB  CUCM  cluster  and  vice  versa  at  this  point.  
 
   

415 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 24.2 Do  not  use  an  enterprise  wide  subscription  model.  


 
Well  this  task  throws  a  wrench  in  the  mix  doesn’t  it?  We’ve  already  created  the  EM  service  and  used  
an  enterprise  wide  subscription  model.  There  is  actually  no  way  to  change  the  type  of  subscription  
model  after  the  service  is  created  either.  This  means  that  we  must  delete  the  service  and  recreate  it  
without  the  enterprise  subscription  designation.    
 
Navigate  to  Device  !  Device  Settings  !  Phone  Services  and  click  on  the  “EM”  service.  Click  the  
“Delete”  button  to  remove  the  service  and  click  the  “OK”  button  
 

 
 
Next,  recreate  the  service  with  the  parameters  described  in  the  previous  task  and  click  the  Save  
button.  
 

 
 
Since  we  don’t  have  the  “luxury”  of  using  the  “Enterprise  Subscription”,  we  must  now  subscribe  the  
phone  to  the  newly  created  EM  service.  Navigate  to  Device  !  Phone  and  click  on  any  phone.  Under  
the  “Related  Links”  section,  select  the  “Subscribe/Unsubscribe  Services”  option  from  the  list  and  click  
the  Go  button.  
 

 
 

416 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  new  window,  select  the  Service  to  be  subscribed  (e.g.  “EM”)  and  click  the  Next  button  
 

 
 
Click  the  Subscribe  button  to  subscribe  the  service.  This  will  allow  the  user  to  login  to  the  phone  to  use  
the  EM  service.  Remember,  we  must  also  subscribe  the  EM  service  to  the  Device  Profile  as  well.  If  the  
Device  Profile  is  not  subscribed,  the  user  will  not  be  able  to  log  out  of  the  profile  when  necessary!  
 
   

417 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 24.3 Usernames  should  be  hqp1,  hqp2,  sbp1,  and  sbp2.  
 
If  the  usernames  that  you  created  for  EM  are  different,  please  modify  the  usernames  as  described  in  
the  task.  Navigate  to  User  Management  !  End  User  and  click  on  each  user  to  make  the  necessary  
changes.  
 
   

418 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 24.4 Enable  Extension  Mobility  Cross  Cluster  such  that  any  HQ  user  can  log  in  to  any  SB  
phone  and  vice  versa.  You  may  use  the  SFTP  server  on  the  HQ  Test  PC.  
 
The  previous  tasks  have  focused  on  enabling  the  EM  service  on  a  single  cluster.  This  task  is  now  asking  
for  us  to  enable  the  Extension  Mobility  Cross  Cluster  (EMCC)  service  on  both  clusters  in  order  to  allow  
users  from  each  cluster  to  log  in  at  either  location.  
 
Cisco  Extension  Mobility  Cross  Cluster  allows  an  enterprise  user  of  one  Cisco  Unified  Communications  
Manager  cluster  (the  home  cluster)  to  log  in  to  a  Cisco  Unified  IP  Phone  of  another  Cisco  Unified  
Communications  Manager  cluster  (the  visiting  cluster)  during  travel  as  if  the  user  is  using  the  IP  phone  
at  the  home  office.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmfeat/CUCM_BK_C3E
0EFA0_00_cucm-­‐features-­‐services-­‐guide-­‐91/CUCM_BK_C3E0EFA0_00_cucm-­‐features-­‐services-­‐guide-­‐
91_chapter_0110001.html]    
 
The  first  step  in  configuring  EMCC  is  to  enable  the  necessary  services  within  the  Cisco  Unified  
Serviceability  web  page  on  both  the  HQ  and  SB  CUCM  clusters  by  navigating  to  Tools  !  Service  
Activation  !  Select  Server.  Under  the  “CM  Services”  section,  ensure  that  the  “Cisco  CallManager”,  
“Cisco  TFTP”,  “Cisco  Extension  Mobility”,  and  “Cisco  Bulk  Provisioning”  services  are  activated.    
 

 
 

 
 
   

419 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  create  the  Phone  Service  for  EMCC  just  as  we  did  for  EM.  Navigate  to  Device  !  Device  
Settings  !  Phone  Services  and  click  on  the  Add  New  button.  Enter  the  “Service  Name”  and  “Service  
URL”  parameters.  The  URL  will  be  different  in  this  case,  since  we  are  invoking  the  EMCC  service  rather  
than  the  EM  service  (e.g.  http://10.10.13.11:8080/emapp/EMAppServlet?device=#DEVICENAME#&  
EMCC=#EMCC#  for  the  HQ  CUCM  cluster).  Take  note  however,  that  although  the  URL  is  different,  we  
can  actually  use  the  EMCC  URL  for  both  EM  and  EMCC.  Therefore,  when  configuring  the  service  in  the  
future,  always  configure  the  Phone  Service  using  the  EMCC  URL.  That  way,  you’ll  never  have  to  revisit  
and  make  a  modification,  forcing  you  to  lose  precious  time.  Just  as  before,  the  URL  can  be  found  in  the  
CUCM  Features  and  services  guide  (linked  above).  Remember  to  “Enable”  the  service  and  check  the  
“Enterprise  Subscription”  box,  since  it  is  not  specifically  disallowed  in  this  case.  Also,  remember  to  
create  the  Phone  Service  on  both  CUCM  clusters.  
 

 
 
The  next  step  would  normally  be  to  create  the  Device  Profile  to  associate  with  the  user.  In  this  case,  
they  were  created  in  a  previous  task  within  this  lab.  However,  there  is  a  setting  of  which  we  should  all  
be  aware,  called  the  Extension  Mobility  Cross  Cluster  CSS,  which  should  be  set  within  the  Device  Profile  
before  moving  on.  This  CSS  is  going  to  allow  the  visiting  phone  to  assign  this  CSS  at  the  device  level,  
meaning  that  it  essentially  acts  just  a  Device  CSS  would.  In  non-­‐EMCC  Extension  Mobility,  the  Device  
CSS  would  be  derived  from  the  phone  that  is  being  used  to  process  the  login.  However,  in  this  case,  the  
phone  that  is  processing  the  login  is  registered  to  another  cluster  and  does  not  have  a  CSS  configured  
that  would  be  recognized  by  the  home  cluster.  The  EMCC  CSS  acts  in  its  place  and  allows  the  visiting  
phone  to  use  it  as  the  Device  CSS.  Navigate  to  Device  !  Device  Settings  !  Device  Profile  and  click  on  
each  of  the  created  profiles  in  both  clusters.  Select  a  CSS  for  the  “Extension  Mobility  Cross  Cluster  CSS”  
parameter  (e.g.  “PHONE_CSS”)  and  click  the  Save  button.    
 

420 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Once  again,  the  next  step  in  the  configuration  (creating  End  Users)  has  been  “mostly”  completed  in  the  
previous  lab  tasks.  There  is  another  setting  that  we  must  enable  within  the  “End  User  Configuration”  
page,  however.  Navigate  to  User  Management  !  End  User  and  click  on  each  of  the  users  within  both  
CUCM  clusters.  Scroll  down  to  the  “Extension  Mobility”  section  and  check  the  box  next  to  the  “Enable  
Extension  Mobility  Cross  Cluster”  setting.  
 

 
 
Click  the  Save  button  when  finished.  Complete  these  steps  this  for  each  user  on  the  cluster.  
 
Next,  in  order  to  support  the  “Security  by  Default”  feature  and  ensure  that  phones  registered  to  the  
visiting  cluster  will  be  able  to  cross-­‐register  with  the  home  cluster,  we  must  export  the  certificates  for  
all  clusters  to  a  single  SFTP  server,  consolidate  them  into  a  single  file,  and  then  import  the  consolidated  
certificate  into  each  CUCM  cluster.  This  process  takes  place  within  the  Cisco  Unified  OS  Administration  
web  page  under  the  Security  !  Bulk  Certificate  Management  menu.  Here,  we  must  specify  an  SFTP  
server  on  which  to  place  the  files.  As  suggested  in  the  task,  we  can  use  the  Test  PC  at  HQ  (10.10.13.17)  
to  complete  the  task.  Before  we  configure  the  SFTP  connection  on  both  CUCM  servers,  let’s  ensure  
that  the  SFTP  server  is  up  and  running.    
 
Open  a  Remote  Desktop  session  to  10.10.13.17  (HQ  Test  PC  1)  and  double-­‐click  the  “Mini-­‐SFTP-­‐
Server.exe”  file  on  the  Desktop.  By  default,  the  credentials  and  path  will  be  set  to  some  pre-­‐configured  
values;  “cisco/cisco”  and  “C:\TFTP-­‐Root”,  respectively.  You  may  modify  these  values  if  so  desired  
before  clicking  the  Start  button  to  run  the  service.  
 

 
 
   

421 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  SFTP  server  is  running,  configure  the  values  accordingly  within  each  CUCM  cluster.  Enter  
the  “IP  Address”  of  “10.10.13.17”,  the  “User  ID”  and  “Password”  of  “cisco”  and  “cisco”,  and  the  
“Directory”  of  “/”  and  click  the  Save  button.  
 

 
 
Next,  click  the  Export  button  at  the  top  of  the  page  to  export  the  proper  certificates  to  the  SFTP  server.    
 

 
 
In  the  new  popup  window,  select  the  “Certificate  Type”  as  “All”  and  click  the  Export  button.  
 

 
 
Next,  log  into  the  SB  CUCM  cluster  and  perform  the  same  steps  to  export  All  Certificates  to  the  SFTP  
server  on  HQ  Test  PC  1.  Once  exported,  all  certificates  should  be  displayed  in  the  SFTP  Root  directory.  
 

 
 

422 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  click  the  Consolidate  button  on  the  top  of  the  screen  to  create  a  single  PCKS12  file  from  the  
existing  certificates  on  the  SFTP  server.  
 

 
 
In  the  popup  window,  select  the  “Certificate  Type”  as  “All”  and  click  the  Consolidate  button.  
 

 
 
When  complete,  the  SFTP  directory  should  be  displayed  as  follows.  
 

 
 
Finally,  click  the  Import  button  on  each  CUCM  cluster  to  import  the  newly  consolidated  certificate  into  
the  system.  
 

 
 
In  the  popup  window,  select  “All”  as  the  “Certificate  Type”  and  click  the  Import  button.  
 

 
 
   

423 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  certificate  management  portion  of  the  configuration  has  been  completed,  the  next  step  
is  to  add  “placeholders”  for  the  future  EMCC  devices  that  will  be  registered  to  each  CUCM  cluster.  For  
these  “placeholders”,  templates  must  be  created  in  order  to  apply  configuration  settings  to  those  
devices.  Navigate  to  Bulk  Administration  !  EMCC  !  EMCC  Template  and  click  the  Add  New  button.  
Enter  a  descriptive  “Template  Name”  and  select  a  “Device  Pool”  to  which  EMCC  phones  should  register  
(e.g.  “HQ_PHONES_DP”).    
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  navigate  to  Bulk  Administration  !  EMCC  !  Insert/Update  EMCC.  Although  it  may  seem  a  little  
backwards,  we  must  update  the  EMCC  devices  first  in  order  to  set  the  Default  EMCC  Template,  which  
was  created  in  the  previous  step.  Once  the  update  is  complete,  devices  can  then  be  inserted  into  the  
database.  Select  the  “Update  EMCC  Devices”  radio  button  and  select  the  “HQ_EMCC”  template  that  
was  created  in  the  previous  step  from  the  dropdown  box.  Click  the  “Reset”  radio  button  as  well.  
 

 
 
Next,  select  the  “Run  Immediately”  radio  button  and  click  the  Submit  button  to  complete  the  
configuration.  
 

 
 
Check  the  status  of  the  job  by  navigating  to  Bulk  Administration  !  Job  Scheduler  and  clicking  on  the  
“Update  EMCC  Devices”  job.  Ensure  that  the  result  of  the  job  is  labeled  as  “Success”.    
 

 
 

424 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  once  again  to  Bulk  Administration  !  EMCC  !  Insert/Update  EMCC.  This  time,  select  
the  “Insert  EMCC  Devices”  radio  button  and  enter  the  “Number  of  EMCC  Devices  to  be  added”  in  the  
corresponding  textbox.  This  will  create  the  “placeholders”  for  the  EMCC  devices  in  the  database.    
 

 
 
Select  the  “Run  Immediately”  radio  button  and  click  the  Submit  button  to  complete  the  configuration.  
 
Check  the  status  of  the  job  by  navigating  to  Bulk  Administration  !  Job  Scheduler  and  clicking  on  the  
“Insert  EMCC  Devices”  job.  Ensure  that  the  result  of  the  job  is  labeled  as  “Success”.    
 

 
 
Ensure  that  the  above  steps  are  performed  on  both  the  HQ  and  SB  CUCM  clusters.  
 
Now  that  the  device  “placeholders”  have  been  added,  the  next  step  is  to  set  the  Cluster  ID  in  order  to  
properly  identify  each  CUCM  cluster.  Navigate  to  System  !  Enterprise  Parameters  and  locate  the  
“Cluster  ID”  parameter.  The  default  value  of  “StandAloneCluster”  should  be  modified  to  something  
that  describes  the  cluster,  like  “HQ”  (HQ  CUCM)  or  “SB”  (SB  CUCM).    
 

 
 
Remember  to  click  the  Save  button  when  finished.    
 
Next,  a  Geolocation  Filter  must  be  defined  in  order  to  assist  in  determining  the  Device  Pool  in  which  
the  visiting  phone  should  be  placed.  By  default,  the  Device  Pool  will  be  determined  by  the  EMCC  
Template,  configured  earlier.  If  the  visiting  cluster  defines  Geolocation  parameters,  the  Geolocation  
Filter  will  determine  the  “important”  parameters  and  make  a  decision  on  which  Device  Pool  to  place  
the  visiting  phone  on  the  home  cluster.  
 

425 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Navigate  to  System  !  Geolocation  Filter  and  click  the  Add  New  button.  Enter  a  descriptive  “Name”  for  
the  Geolocation  Filter  (e.g.  “HQ_GEO”)  and  select  the  “important”  criteria  from  the  list  below  in  order  
to  successfully  determine  the  location.  In  this  case,  the  “Country”,  “State”  and  “City”  were  selected  as  
criteria    
 

 
 
Click  the  Save  button  when  complete.  Remember  to  complete  this  step  on  the  SB  CUCM  cluster  as  
well.  
 
Next,  we  must  set  the  system-­‐level  parameters  for  EMCC  under  the  Advanced  Features  !  EMCC  !  
EMCC  Feature  Configuration.  For  the  “TFTP  Server”  parameters,  select  the  TFTP  servers  on  the  HQ  
CUCM  cluster  that  will  provide  configuration  files  to  visiting  phones.  In  this  case,  “10.10.13.12”  and  
“10.10.13.11”  were  selected.  Next,  the  configured  “EMCC  Geolocation  Filter”  should  be  selected  (e.g.  
“HQ_GEO”).  Last,  configure  the  “Default/Backup  Server  for  Remote  Cluster  Update”  in  order  for  
remote  clusters  to  access  information  about  the  local  cluster.  
 

 
 
Next,  the  EMCC  SIP  trunk  must  be  created  on  each  CUCM  cluster.  This  trunk  will  only  be  used  for  PSTN  
access  as  calls  flow  across  the  trunk  from  the  home  cluster  of  the  EMCC  device.  For  example,  if  a  user  
from  a  remote  cluster  logs  into  a  phone  on  the  HQ  CUCM  cluster  (now  termed  the  “visiting  cluster”),  
calls  placed  through  the  SB  CUCM  cluster  (now  termed  the  “home  cluster”)  with  the  Standard  Local  

426 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Route  Group  assigned  will  traverse  the  EMCC  SIP  trunk  to  provide  local  PSTN  access  for  the  call  
through  the  visiting  cluster.  The  SIP  trunk  will  not  have  a  configured  destination  IP  address;  the  remote  
cluster  to  which  it  dynamically  connects  will  determine  that.  Navigate  to  Device  !  Trunk  and  click  the  
Add  New  button.  Select  the  “Trunk  Type”  as  “SIP  Trunk”  and  select  the  “Trunk  Service  Type”  as  
“Extension  Mobility  Cross  Cluster”  and  click  the  Next  button.  
 

 
 
Enter  a  “Device  Name”  for  the  SIP  trunk  (e.g.  “HQ_EMCC_SIP_TRUNK”)  and  select  a  “Device  Pool”  for  
the  trunk  (e.g.  “HQ_PHONE_DP”).    
 

 
 
Next,  select  the  default  “SIP  Trunk  Security  Profile”  and  “SIP  Profile”  from  the  dropdown  box.    
 

 
 
Click  the  Save  button  when  complete.  Remember  to  create  a  SIP  trunk  for  EMCC  on  the  SB  CUCM  
cluster  as  well.  
 
   

427 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Advanced  Features  !  EMCC  !  EMCC  Intercluster  Service  Profile  to  activate  the  
services  on  the  local  cluster.  Click  the  checkbox  for  “EMCC”,  “PSTN  Access”,  and  select  the  newly  
created  SIP  trunk  for  EMCC  (e.g.  “HQ_EMCC_SIP_TRUNK”).  
 

 
 
Click  the  Save  button  when  the  configuration  is  complete.  Complete  the  configuration  on  the  SB  CUCM  
cluster  as  well.  
 
Next,  configure  the  connection  to  the  remote  cluster  by  navigating  to  Advanced  Features  !  Cluster  
View  and  clicking  the  Add  New  button.  Enter  the  “Cluster  ID”  of  the  remote  cluster  (e.g.  “SB”)  and  the  
IP  Address  of  the  Publisher  server  for  the  “Fully  Qualified  Name”  (e.g.  “10.10.23.11”).  Click  the  Save  
button  when  complete.  
 

 
 
Next,  click  the  Enable  All  Services  button  to  select  all  available  services  and  click  the  Save  button.  
 

 
 

428 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Update  EMCC  Remote  Cluster  Now  button  to  get  the  current  information  from  the  remote  
cluster.  
 

 
 
Ensure  that  the  above  steps  are  performed  on  the  SB  CUCM  cluster  as  well.    
 
After  the  marathon-­‐style  configuration,  we  are  finally  ready  to  test  it  out!  On  SB  Phone  1,  press  the  
Services  button  on  the  phone,  select  the  EMCC  service,  and  log  in  using  the  credentials  of  one  of  the  
HQ  users.  Ensure  that  this  works  on  HQ  phones  for  SB  users  as  well.  
 
   

429 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 24.5 When  HQ  users  log  in  to  SB  phones,  assure  that  7-­‐digit  local  calls  continue  to  use  the  
R1  gateway.  You  may  modify  the  current  routing  design  to  accomplish  this.  
 
Now  that  EMCC  has  been  configured,  call  routing  for  the  EMCC  devices  should  be  configured  to  
support  the  above  task  requirements.  When  HQ  users  are  logged  into  SB  phones,  the  R1  gateway  
should  still  be  used  to  route  local  calls.    
 
As  you  know,  the  Home  cluster  (HQ  in  this  case)  will  always  be  the  first  system  to  analyze  the  digits.  
With  this  in  mind,  we  must  configure  the  HQ  CUCM  dial  plan  to  ensure  that  all  7-­‐digit  local  calls  
traverse  the  R1  gateway.  This  can  be  accomplished  by  configuring  a  Route  List  that  specifically  points  
toward  the  gateway.  The  Standard  Local  Route  Group  option  cannot  be  used  in  this  case,  since  that  
would  indicate  (to  EMCC)  that  the  call  should  be  routed  over  the  EMCC  SIP  trunk  toward  the  Visiting  
cluster.  With  that  in  mind,  we  must  set  the  9.[2-­‐9]XXXXXX  Route  Pattern  to  use  the  R1  gateway  
specifically  (no  SLRG).  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  “9.[2-­‐
9]XXXXXX”  pattern.  For  the  “Gateway/Route  List”  parameter,  select  the  “R1_MGCP_RL”  from  the  
dropdown  list  and  click  the  Save  button.  
 

 
 
To  verify  that  calls  are  indeed  traversing  the  R1  gateway,  run  the  debug isdn q931  command  on  
R1  and  make  a  call  from  a  SB  phone  while  logged  in  as  an  HQ  user.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.
 
Nov 11 07:38:01.725: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x002E
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'HQ Phone 1'
Calling Party Number i = 0x4181, '2221001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '6131218'
Plan:ISDN, Type:Subscriber(local)
Nov 11 07:38:01.765: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x802E
Channel ID i = 0xA98383
Exclusive, Channel 3
Nov 11 07:38:02.029: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x802E
Nov 11 07:38:05.537: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x002E
Cause i = 0x8090 - Normal call clearing
Nov 11 07:38:05.549: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x802E
Nov 11 07:38:05.573: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x002E
 
   

430 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 24.6 When  SB  users  log  in  to  HQ  phones,  assure  that  7-­‐digit  local  calls  traverse  the  R1  
gateway.  Calling  number  does  not  need  to  be  modified.  
 
In  this  case,  we  must  use  the  Standard  Local  Route  Group  on  the  SB  CUCM  cluster  to  forward  the  call  
over  the  EMCC  SIP  trunk.  Check  the  current  Route  Pattern  configuration  by  navigating  to  Call  Routing  
!  Route/Hunt  !  Route  Pattern  and  clicking  on  the  “9[2-­‐9]XXXXXX”  pattern.  Currently,  the  pattern  is  
set  to  use  the  R2  SIP  Gateway  to  route  local  calls.  In  this  case,  we  must  select  the  “LOCAL_RL”  in  order  
to  route  calls  back  to  the  visiting  cluster  over  the  EMCC  SIP  trunk.  
 

 
 
Next,  we  must  configure  the  Calling  Search  Space  on  the  HQ  EMCC  SIP  trunk  in  order  to  route  the  call  
to  the  correct  Route  pattern  on  the  HQ  CUCM  cluster.  Navigate  to  Device  !  Trunk  and  click  on  the  
“HQ_EMCC_SIP_TRUNK”.  Under  the  “Inbound  Calls”  section  select  a  Calling  Search  space  that  has  
access  to  the  local  pattern.  In  this  case,  “EMCC_CSS”  was  selected  (contains  “EMCC_PSTN_PT”).  
 

 
 
Next,  we  must  create  a  Route  Pattern  on  the  HQ  cluster  to  accommodate  the  inbound  pattern  and  
route  the  call  successfully  to  the  PSTN.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  
click  the  Add  New  button.  Create  the  “9.[2-­‐9]XXXXXX”  pattern,  assign  the  “EMCC_PSTN_PT”  Partition,  
and  select  the  “R1_MGCP_RL”.    
 

 
 
   

431 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “Outbound  Calls”  section,  select  the  “PreDot”  option  for  “Discard  Digits”  and  enter  
“312”  for  the  “Prefix”.  Also,  select  the  “Called  Party  Number  Type/Plan”  as  “National/ISDN”  to  meet  
the  call  routing  requirements  of  the  PSTN.  
 

 
 
To  verify  that  calls  are  indeed  traversing  the  R1  gateway,  run  the  debug isdn q931  command  on  
R1  after  logging  into  an  HQ  phone  with  a  SB  user  and  placing  a  local  call.  
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.
Nov 11 07:57:16.202: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x002F
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'SB Phone 2'
Calling Party Number i = 0x2183, '2002'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '3127764016'
Plan:ISDN, Type:National
Nov 11 07:57:16.242: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x802F
Channel ID i = 0xA98383
Exclusive, Channel 3
Nov 11 07:57:16.490: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x802F

432 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 25: URI Dialing


Task 25.1 Configure  a  Directory  URI  for  all  phones  on  both  the  HQ  and  SB  clusters  and  
associate  it  with  the  primary  line  of  each  phone.  The  format  of  the  URI  at  HQ  should  
be  <username>@ipexpert.com;  the  SB  format  should  be  <username>@cucm.com  
(e.g.  sbp2@cucm.com).  
 
Cisco  Unified  Communications  Manager  supports  dialing  using  directory  URIs  for  call  addressing.  
Directory  URIs  look  like  email  addresses  and  follow  the  username@host  format  where  the  host  portion  
is  an  IPv4  address  or  a  fully  qualified  domain  name.  A  directory  URI  is  a  uniform  resource  identifier,  a  
string  of  characters  that  can  be  used  to  identify  a  directory  number.  If  that  directory  number  is  
assigned  to  a  phone,  Cisco  Unified  Communications  Manager  can  route  calls  to  that  phone  using  the  
directory  URI.  URI  dialing  is  available  for  SIP  and  SCCP  endpoints  that  support  directory  URIs.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmsys/CUCM_BK_CD2F
83FA_00_cucm-­‐system-­‐guide-­‐90/CUCM_BK_CD2F83FA_00_system-­‐guide_chapter_0101111.html]    
 
Directory  URIs  functions  as  aliases  to  Directory  Numbers  in  the  system.  When  created,  Directory  URIs  
must  be  associated  with  a  DN  in  some  fashion  because  of  this  fact.  When  a  user  dials  a  Directory  URI,  it  
serves  to  route  the  call  to  the  DN  in  question  “through”  the  configured  Directory  URI  for  that  user.  
Accessibility  is  configured  just  as  would  be  done  normally,  through  Partitions  and  CSSs.  Directory  URIs  
can  be  assigned  to  any  Partition  in  the  system  as  long  as  it  is  configured  on  the  “Directory  Number  
Configuration”  page.  Directory  URIs  can  also  be  created  on  the  End  User  configuration  page.  Once  
assigned,  the  selected  “Primary  Line”  of  the  End  User  is  used  to  determine  the  DN  where  the  Directory  
URI  should  be  aliased.  The  difference  here  is  that  End  User  generated  Directory  URIs  is  always  placed  
within  the  default  “Directory  URI”  Partition.    
 
With  that  said,  the  first  step  is  to  create  the  Directory  URIs  within  both  the  HQ  and  SB  CUCM  clusters.  
In  our  example,  let’s  use  the  “End  User”  method  of  assignment  by  navigating  to  User  Management  !  
End  User  and  clicking  on  the  “hqp1”  user.  Under  the  “User  Information”  section,  enter  the  “Directory  
URI”  as  described  in  the  task  (e.g.  “hqp1@ipexpert.com”)  
 

 
 
Next,  ensure  that  a  “Primary  Extension”  is  selected  for  the  user  so  the  configured  Directory  URI  can  be  
assigned  appropriately.  
 

 
 
Click  the  Save  button  when  complete.  
 

433 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  verify  that  the  Directory  URI  was  assigned,  navigate  to  Device  !  Phone  and  click  on  “HQ  Phone  1”.  
Click  the  “Line  [1]  -­‐  1001  in  INTERNAL_PT”  link  and  locate  the  “Directory  URIs”  section.  The  newly  
created  “hqp1@ipexpert.com”  should  be  listed  in  the  “Directory  URI”  Partition.  
 

 
 
For  the  SB  CUCM  cluster,  although  the  Directory  URI  can  be  assigned  in  the  same  fashion,  let’s  assign  it  
using  the  alternative  method  of  configuring  the  DN  directly.  Navigate  to  Device  !  Phone  and  select  
“SB  Phone  1”.  Click  the  “Line  [1]  -­‐  2001  in  INTERNAL_PT”  link  and  locate  the  “Directory  URIs”  section.  
Enter  the  “Directory  URI”  as  “sbp1@cucm.com”  and  select  an  appropriate  Partition  (e.g.  
“INTERNAL_PT”).  
 

 
 
Remember  to  click  the  Save  button  when  complete.  
 
Configure  the  above  for  all  remaining  users  on  both  clusters  before  moving  on  to  the  next  task.  
 
   

434 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 25.2 Create  a  speed  dial  on  the  last  button  of  each  HQ  phone  that  corresponds  to  the  
configured  directory  URI  of  the  other  HQ  phone.  
 
In  order  to  test  the  Directory  URI  configuration,  we  must  add  a  speed  dial,  since  there  is  no  way  to  dial  
the  Directory  URI  from  the  phone.  Alternatively,  we  could  use  the  Jabber  client  to  make  the  call,  but  
that  has  not  been  configured  within  Volume  1  at  this  point!  The  task  is  asking  us  to  configure  the  speed  
dial  on  the  last  button  of  each  HQ  phone,  which  is  currently  occupied  by  the  “DCP  Retrieve”  button  to  
retrieve  Directed  Call  Park  calls.  Since  this  is  already  a  speed  dial,  there  is  no  problem  in  overwriting  
this  configuration  with  the  Directory  URI  from  this  task.    
 
Navigate  to  Device  !  Phone  and  click  on  “HQ  Phone  1”.  Under  the  “Association  Information”  section,  
click  on  the  “801099”  speed  dial  that  currently  exists.  Add  the  speed  dial  for  the  other  phone  at  HQ  
(e.g.  “hqp2@ipexpert.com”)  and  click  the  Save  button.  
 

 
 
Create  a  speed  dial  for  “hqp1@ipexpert.com”  for  “HQ  Phone  2”  as  well.  
 

 
 

 
 
When  testing  the  configuration,  you  may  have  noticed  that  that  call  did  not  complete  successfully.  
Remember,  the  Directory  URI  was  assigned  to  the  primary  line  of  each  phone  using  the  End  User  
configuration.  This  means  that  the  Directory  URIs  that  is  configured  on  the  HQ  CUCM  cluster  is  
contained  within  the  “Directory  URI”  default  Partition.  With  that  in  mind,  to  enable  the  routing  of  calls,  
we  must  either  add  the  “Directory  URI”  Partition  to  the  CSS  of  the  phones  (e.g.  “PHONE_CSS”)  or  set  
the  “Directory  URI  Alias  Partition”  parameter  by  navigating  to  System  !  Enterprise  Parameters  and  
locating  the  “End  User  Parameters”  section.  Set  the  “Directory  URI  Alias  Partition”  to  a  Partition  that  is  
accessible  by  the  other  phones  within  the  cluster  (e.g.  “INTERNAL_PT”).  Essentially,  this  means  that  we  
are  setting  the  default  “Directory  URI”  Partition  equal  to  the  “INTERNAL_PT”  Partition.  
 

 
   

435 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 25.3 Create  a  speed  dial  on  the  last  button  of  each  SB  phone  that  corresponds  to  the  
configured  directory  URI  of  the  other  SB  phone.  
 
Each  SB  phone  should  be  configured  with  a  speed  dial  to  the  Directory  URI  of  the  other  cluster  phone  
on  the  last  button.  Currently,  neither  slot  is  occupied,  so  the  speed  dial  can  be  added  without  any  need  
for  reconfiguration.    
 
Navigate  to  Device  !  Phone  and  click  on  one  of  the  SB  phones.  Under  the  “Association  Information”  
section,  click  the  “Add  a  new  SD”  link  on  button  6.  Add  the  “sbpX@cucm.com”  speed  dial  and  click  the  
Save  button.  
 

 
 
Perform  this  step  for  all  phones  on  the  SB  CUCM  cluster  and  ensure  that  dial  access  is  provided  by  way  
of  the  Device  CSS  or  the  “Directory  URI  Alias  Partition”  Enterprise  Parameter.  
 
   

436 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 25.4 Create  an  ILS  network  between  the  HQ  and  SB  clusters  to  share  directory  URI  
information.  
 
Now  that  the  Directory  URIs  have  been  created  and  tested  on  both  CUCM  clusters,  the  Intercluster  
Lookup  Service  (ILS)  can  be  initiated  on  each  cluster  to  share  the  Directory  URI  information.  Once  the  
information  is  shared,  it  can  be  used  to  route  calls  to  phones  on  the  remote  cluster.  
 
The  first  step  is  to  configure  the  CUCM  cluster  to  share  the  Directory  URI  information  from  each  
cluster.  Navigate  to  Call  Routing  !  Intercluster  Directory  URI  !  Intercluster  Directory  URI  
Configuration  and  click  the  “Exchange  Directory  URI  Catalogs  with  Remote  Clusters”  checkbox.  Next,  
specify  a  “Route  String”  that  is  used  to  identify  the  Directory  URIs  for  the  cluster.  Typically,  this  can  be  
populated  with  geographical  information  to  identify  the  location  of  the  cluster,  but  any  descriptive  
term  can  be  used  as  long  as  the  purpose  is  easily  identifiable.  In  terms  of  formatting,  Route  Strings  can  
be  up  to  250  alphanumeric  characters  and  can  include  dots  and  dashes.  The  documentation  states  that  
Route  Strings  must  have  at  least  one  dot,  but  this  does  not  appear  to  be  enforced  within  CUCM.  In  this  
example,  the  Route  String  of  “HQ.NA.US.CA.SanJose”  was  entered  to  share  the  Directory  URIs  from  the  
HQ  CUCM  cluster.  
 

 
 
Click  the  Save  button  when  complete.  The  configuration  on  the  SB  CUCM  cluster  is  as  shown  in  the  
following  screenshot.  
 

 
 
After  configuring  each  CUCM  cluster  to  share  the  Directory  URIs,  we  must  configure  ILS  to  run  on  both  
clusters  to  exchange  the  information.  On  the  HQ  CUCM  cluster,  navigate  to  Advanced  Features  !  ILS  
Configuration  to  begin  the  configuration.  Modify  the  “Role”  of  the  cluster  from  the  default  value  of  
“StandAloneCluster”  to  either  “Hub  Cluster”  or  “Spoke  Cluster”.  With  ILS,  we  have  the  option  of  
creating  two  “Hub  Clusters”  or  a  “Hub  Cluster”  and  “Spoke  Cluster”,  but  not  two  “Spoke  Clusters”.  A  
“Hub  Cluster”  must  be  involved  in  some  fashion.  In  this  case,  let’s  create  a  “Hub  Cluster”  at  HQ.  
 

 
 

437 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  it  is  recommended  to  modify  the  “Synchronization  Clusters  Every”  parameter  from  the  default  
value  of  “10”.  It  is  best  to  change  this  to  the  lowest  value  possible  (“1”)  in  order  to  receive  quick  
updates.  
 

 
 
Next,  instead  of  using  the  default  method  of  authentication,  TLS  Certificates,  it  is  actually  much  quicker  
(albeit  less  secure)  to  use  a  shared  password  between  all  clusters  participating  in  ILS.  In  this  case,  the  
password  of  “cciecollab”  was  entered.  
 

 
 
Click  the  Save  button  to  complete  the  configuration.  A  new  window  will  appear  and  will  prompt  for  
registration  to  another  ILS  server.  Since  this  is  the  first  hub  in  the  network,  the  field  can  be  left  blank.  
Click  the  OK  button  to  continue.  
 

 
 
Next,  on  the  SB  CUCM  cluster,  perform  the  steps  detailed  above  to  configure  the  cluster  as  a  “Spoke  
Cluster”.  
 

 
 

438 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

After  clicking  the  Save  button,  configure  the  IP  Address  of  the  Hub  Cluster  (HQ  CUCM  Publisher)  on  the  
SB  CUCM  cluster  and  click  the  OK  button.    
 

 
 
At  this  point,  the  status  of  the  ILS  Configuration  is  displayed  at  the  bottom  of  the  screen,  showing  that  
synchronization  between  CUCM  clusters  has  been  achieved.  
 

 
 
In  the  next  task,  call  routing  using  the  newly  synchronized  ILS  information  will  be  configured.  
 
   

439 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 25.5 Enable  ILS  routing  between  the  clusters  supporting  URI  dialing.  Only  use  one  route  
pattern,  but  do  not  use  wildcards  to  accomplish  this.    
 
Routing  calls  for  situations  in  which  Directory  URIs  are  dialed  can  be  achieved  by  creating  a  SIP  Route  
Pattern.  A  SIP  Route  Pattern  can  be  configured  on  the  CUCM  cluster  and  can  operate  independently  of  
any  ILS  configuration  that  may  exist.  It  is  possible  to  route  a  Directory  URI  call  to  another  cluster  by  
simply  configuring  a  SIP  Route  Pattern  using  the  domain  name  (e.g.  “cucm.com”).  In  order  to  use  ILS,  
we  can  create  a  SIP  Route  Pattern  to  the  configured  Route  String  of  the  remote  CUCM  cluster.  Before  
that  can  be  configured,  however,  we  must  configure  a  SIP  trunk  to  support  URI  dialing  between  
clusters.  
 
In  this  case,  a  SIP  trunk  has  already  been  configured  between  clusters;  “SB_SIP_ICT_TRUNK”  for  the  HQ  
CUCM  cluster  and  “HQ_SIP_ICT_TRUNK”  for  the  SB  CUCM  cluster.  Before  modifying  any  settings  on  the  
existing  trunks,  we  must  create  a  SIP  Profile  that  allows  the  passing  of  the  Fully  Qualified  Domain  Name  
(FQDN)  in  the  dialed  string.  Navigate  to  Device  !  Device  Settings  !  SIP  Profile  and  click  the  Find  
button.  Select  the  “Standard  SIP  Profile”  and  click  the  Copy  button  to  create  a  new  profile  based  on  the  
standard  profile.  Create  a  descriptive  “Name”  for  the  profile  (e.g.  “Standard  SIP  Profile  –  FQDN”)  and  
check  the  box  for  the  “Use  Fully  Qualified  Domain  Name  in  SIP  Requests”  parameter.    
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  navigate  to  Device  !  Trunk  and  click  on  the  “SB_SIP_ICT_TRUNK”.  Under  the  “Outbound  Calls”  
section,  for  the  “Calling  and  Connected  Party  Info  Format”,  set  the  dropdown  box  to  use  the  “Deliver  
URI  and  DN  in  connected  party,  if  available”  setting.  
 

 
 

440 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  select  the  “SIP  Profile”  that  was  previously  created  (e.g.  “Standard  SIP  Profile  –  FQDN”)  from  the  
dropdown  box.  
 

 
 
Click  the  Save  button  when  complete.  Make  sure  to  perform  the  above  steps  on  the  SB  CUCM  cluster  
as  well.  
 
Next,  create  the  SIP  Route  Pattern  by  navigating  to  Call  Routing  !  SIP  Route  Pattern  and  clicking  the  
Add  New  button.  For  the  “IPv4  Pattern”  parameter,  enter  the  Route  String  of  the  remote  cluster.  For  
the  HQ  CUCM  cluster,  the  “SB.NA.US.IL.Chicago”  Route  String  was  used.  Next,  assign  an  appropriate  
Partition  (e.g.  “SB_PT”)  and  select  the  Route  List  that  contains  the  Intercluster  SIP  trunk  (e.g.  
“SB_SIP_ICT_RL”).    
 

 
 
The  SIP  Route  Pattern  on  the  SB  CUCM  cluster  should  be  configured  as  shown  below.  
 

 
 
Testing  of  the  ILS  Routing  configuration  will  be  performed  in  the  upcoming  tasks.  
 
   

441 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 25.6 Ensure  that  the  codec  is  G.729  when  the  call  is  active.  
 
Since  the  G.729  codec  should  be  used  when  Directory  URI  calls  are  placed  between  clusters,  we  must  
configure  separate  Regions  and  Device  Pools  for  the  SIP  trunks  being  used  to  route  the  call  between  
clusters.  In  our  case,  those  configurations  have  already  been  completed.  All  that  remains  is  to  navigate  
to  System  !  Region  Information  !  Region  and  configure  the  Region  relationship  between  HQ  Phones  
(HQ_REG)  and  the  Intercluster  SIP  Trunk  (SB_SIP_ICT_REG).  Click  on  the  “SB_SIP_ICT_REG”  and  
observe  the  configuration.  As  shown  below,  a  previous  lab  had  configured  the  iLBC  codec  between  
Regions.    
 

 
 
In  this  case,  it  is  OK  to  overwrite  this  setting,  since  all  lab  requirements  are  not  cumulative  in  the  
Volume  1  workbook.  However,  if  this  was  the  “real”  CCIE  Collaboration  lab  or  a  mock  lab,  all  
requirements,  regardless  of  when  they  were  presented  in  the  lab,  must  be  taken  into  consideration.  
This  would  mean  that  a  separate  SIP  trunk,  Device  Pool,  and  Region  would  need  to  be  created  to  
accommodate  Directory  URI  dialing  between  clusters.  As  this  is  not  the  case  here,  we  must  simply  
select  the  “SB_SIP_ICT_REG”  and  change  the  “Maximum  Audio  Bit  Rate”  to  the  “8  kbps  (G.729)”  
setting.  
 

 
 
Click  the  Save  button  when  complete.  Remember  to  perform  the  same  steps  for  the  SB  CUCM  cluster.  
 
   

442 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 25.7 Create  a  speed  dial  on  the  4th  and  5th  button  of  each  HQ  phone  that  corresponds  to  
the  configured  directory  URI  of  both  SB  phones.  Remove  any  existing  configuration  
that  may  exist  on  those  buttons.  
 
On  each  HQ  Phone,  we  must  create  a  speed  dial  for  “sbp1@cucm.com”  and  “sbp2@cucm.com”  on  
buttons  4  and  5,  respectively.  As  the  task  suggests,  we  must  remove  existing  configuration  and  modify  
the  Phone  Button  Templates  to  use  three  speed  dials  for  the  last  three  buttons.  The  Phone  Button  
Templates  for  the  7965  and  9971  phones  should  be  configured  as  shown  below.  
 

 
 

 
 
Next  configure  the  speed  dials  on  each  phone  by  navigating  to  Device  !  Phone  and  clicking  on  each  
phone.  Under  the  “Association  Information”  section,  click  on  an  available  Speed  Dial  slot  and  add  each  
Directory  URI  to  the  configuration.  
 

 
 
   

443 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Configure  the  other  HQ  phone  in  the  same  fashion.  Both  phones  should  appear  as  shown  below  after  
the  configuration  is  complete.  
 

 
 

 
 
Test  calls  between  clusters  to  ensure  proper  functionality.  
 
   

444 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 25.8 Create  a  speed  dial  on  the  4th  and  5th  button  of  each  SB  phone  that  corresponds  to  
the  configured  directory  URI  of  both  HQ  phones.  Remove  any  existing  configuration  
that  may  exist  on  those  buttons.  
 
On  each  SB  Phone,  we  must  create  a  speed  dial  for  “hqp1@ipexpert.com”  and  “hqp2@ipexpert.com”  
on  buttons  4  and  5,  respectively.  As  the  task  suggests,  we  must  remove  existing  configuration  and  
modify  the  Phone  Button  Templates  to  use  three  speed  dials  for  the  last  three  buttons.  The  Phone  
Button  Template  should  be  configured  as  shown  below.  
 

 
 
Next  configure  the  speed  dials  on  each  phone  by  navigating  to  Device  !  Phone  and  clicking  on  each  
phone.  Under  the  “Association  Information”  section,  click  on  an  available  Speed  Dial  slot  and  add  each  
Directory  URI  to  the  configuration.  
 

 
 
Once  configured  on  both  SB  phones,  test  Directory  URI  calls  between  CUCM  clusters.  
 

445 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 26: Service Advertisement Framework and Call Control Discovery


Task 26.1 Configure  a  SAF  forwarder  on  R1.  Use  the  “Loopback  0”  interface  on  R1  to  handle  all  
incoming  connections.    
 
Service  Advertisement  Framework  (SAF)  is  a  network-­‐based,  scalable,  bandwidth-­‐efficient  approach  to  
service  advertisement  and  discovery.  Unlike  traditional  service  discovery  mechanisms,  Cisco  SAF  
provides  a  dynamic,  network-­‐integrated,  real-­‐time  messaging  mechanism  that  allows  host  applications  
the  ability  to  discover  the  existence,  location,  and  configuration  of  networked  resources  through  a  
local  area  network  (LAN)  or  across  a  wide  area  network  (WAN)  based  on  industry-­‐proven  Cisco  IP  
routing  technology.  
 
SAF  Forwarders  run  on  Cisco  IOS  routers  and  switches  and  are  responsible  for  receiving  services  
published  by  SAF  Clients,  distributing  the  services  reliably  throughout  the  SAF  network,  and  making  the  
services  available  for  other  interested  SAF  Clients  to  use.  
 
The  SAF  Forwarder  Protocol  (SAF-­‐FP)  is  used  between  SAF  Forwarders  and  is  responsible  for  
advertising  information  about  services  over  IP  networks.  SAF-­‐FP  is  a  "service"  advertisement  protocol,  
not  an  IP  routing  protocol.  It  is  completely  separate  and  distinct  from  the  underlying  IP  routing  
protocol.    
 
SAF  Forwarder  Protocol  Characteristics:  
• Uses  the  EIGRP  transport  layer  for  service  advertisement  (does  not  require  or  rely  on  EIGRP  for  
IP  routing).  
• Uses  split-­‐horizon  and  the  Diffusing  Update  Algorithm  (DUAL)  to  prevent  service  advertisement  
loops.  
• Uses  link  local  multicast  on  LAN  and  Layer  2  segments  for  neighbor  discovery  (IPv4:  224.0.0.10;  
IPv6:  FF02::a).  
• Uses  IP  protocol  88.  
• Utilizes  incremental  updates  when  advertisement  changes  occur.  Does  not  periodically  
broadcast/flood  service  advertisements.  
[Source:    
 http://www.cisco.com/c/en/us/products/collateral/ios-­‐nx-­‐os-­‐software/service-­‐advertisement-­‐
framework-­‐saf/whitepaper_c11-­‐622512.html]    
 
To  configure  a  SAF  Forwarder  on  R1,  we  must  configure  a  “named”  EIGRP  process  (e.g.  “SAF”)  to  run  
on  a  defined  autonomous-system  (e.g.  “8”)  within  a  service-family  on  the  router.    
 
R1  
R1(config)#router eigrp SAF
R1(config-router)#service-family ipv4 autonomous-system 8

   

446 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  since  the  “Loopback  0”  interface  was  defined  in  the  task  as  the  specific  interface  that  should  
handle  incoming  connections,  we  must  define  it  in  the  configuration  and  disable  a  feature  called  split-­‐
horizon.  Split-­‐horizon  is  a  feature  that  prevents  a  route  (or  service  in  our  case)  from  being  advertised  
out  the  same  interface  on  which  it  was  learned.  Therefore,  if  all  services  are  learned  using  the  
“Loopback  0”  interface,  we  must  disable  split-­‐horizon  so  those  services  can  be  re-­‐advertised  out  the  
same  interface  to  other  systems.  The  EIGRP  configuration  is  continued  below.  
 
R1  
R1(config-router-sf)#sf-interface Loopback0
R1(config-router-sf-interface)#no split-horizon
   
Next,  we  must  add  a  “base”  topology  in  which  to  place  the  interface  on  the  router.  In  previous  versions  
of  SAF,  external-clients  could  be  specifically  defined  within  the  topology base  
configuration  heading.  However,  those  commands  are  now  deprecated  and  only  the  topology
base  command  is  required.  
 
R1  
R1(config-router-sf)#topology base
 
In  addition  to  the  EIGRP  configuration  on  R1,  we  must  also  configure  XMCP  (Extensible  Messaging  
Client  Protocol)  to  handle  client  connections.  It  was  not  previously  necessary  to  configure  XMCP  since  
the  external-client  command  was  used  to  connect  clients  using  SAF.  Technically,  SAF  is  no  
longer  used  to  connect  CUCM  clients—XMCP  is  used  instead.  To  configure  XMCP,  we  must  use  the  
service-routing xmcp listen  command  within  the  global  configuration  of  R1.  Optionally,  we  
can  specify  a  port  on  which  XMCP  should  listen;  the  default  port  is  4788.  
 
R1  
R1(config)#service-routing xmcp listen
 
After  entering  this  command,  we  must  specify  a  client  username  with  which  to  connect  to  the  XMCP  
service  on  the  router.  Since  we  will  eventually  be  connecting  to  the  HQ  and  SB  CUCM  clusters,  we  
should  create  separate  client  usernames  and  passwords  for  each.  We  must  also  specify  the  SAF  
domain  (AS)  in  which  the  clients  exist,  so  the  proper  advertisements  can  be  shared  by  all  connected  
systems.  Since  the  AS  was  specified  as  “8”  in  the  EIGRP  process  configured  above,  the  default  domain  
should  be  specified  as  “8”  as  well.  
 
R1  
R1(config-xmcp)#client username hqcucm password 0 ipexpertsaf
R1(config-xmcp-client)#domain 8 default
R1(config-xmcp-client)#client username sbcucm password 0 ipexpertsaf
R1(config-xmcp-client)#domain 8 default
   

447 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

As  a  last  step  to  the  XMCP  configuration,  we  should  also  specify  a  domain  for  clients  that  do  not  
authenticate  to  the  system,  in  the  case  where  authentication  is  not  possible.    
 
R1  
R1(config-xmcp-client)#client unauthenticated
R1(config-xmcp-client)#domain 8 default

To  verify  the  XMCP  configuration,  enter  the  command  show service-routing xmcp server  
from  enable  mode  on  R1.  
 
R1  
R1#show service-routing xmcp server
XMCP Server listening on port 4788
Socket descriptors: 0 (TCP/IPv4)
Connected clients: 0 unauthenticated, 0 total
Maximum clients: unlimited
Allow-lists: <none>
Clients configured:
Unauthenticated, 0 client(s) connected
Username "hqcucm", 0 client(s) connected
Username "sbcucm", 0 client(s) connected
 
   

448 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 26.2 Configure  the  HQ  CUCM,  SB  CUCM,  and  R3  CUCME  as  SAF  clients.  
 
Now  that  the  SAF  forwarder  has  been  configured  on  R1,  we  must  configure  each  client  connection  in  
order  to  share  dial  plan  information  using  the  Call  Control  Discovery  (CCD)  service.  Each  CUCM  cluster  
be  configured  to  authenticate  using  XMCP  and  the  R3  CUCME  client  must  connect  using  EIGRP  (SAF).    
 
On  the  HQ  CUCM  cluster,  navigate  to  Advanced  Features  !  SAF  !  SAF  Security  Profile  and  click  the  
Add  New  button.  Assign  a  descriptive  “Name”  for  the  profile  (e.g.  “HQ_SPI”)  and  enter  the  “User  
Name”  (e.g.  “hqcucm”)  and  “User  Password”  (e.g.  “ipexpertsaf”)  that  was  configured  within  XMCP  on  
R1  to  set  the  authentication  credentials.  Click  the  Save  button  when  complete.  
 

 
 
Next,  navigate  to  Advanced  Features  !  SAF  !  SAF  Forwarder  to  configure  the  connection  to  R1.  Click  
the  Add  New  button  and  enter  a  descriptive  “Name”  for  the  SAF  Forwarder  (e.g.  “R1_SAF”).    
 

 
 
Next,  enter  a  “Client  Label”  for  the  SAF  Forwarder  in  the  configuration.  This  is  actually  referring  to  the  
“User  Name”  that  was  entered  for  the  SAF  Security  Profile  and  XMCP  configuration.  You  might  be  
asking  yourself  at  this  point,  why  do  I  have  to  enter  this  information  again?  The  reason  that  this  
information  is  redundant  is  because  CUCM  was  originally  designed  to  connect  using  the  SAF  protocol,  
and  a  “Client  Label”  was  required  to  match  the  external-client  configuration  within  EIGRP.  We  
are  now  connecting  using  XMCP  instead,  but  still  must  add  the  “Client  Label”  to  the  configuration  since  
CUCM  has  not  been  updated  to  remove  the  parameter.  In  this  case,  the  “hqcucm”  value  was  used.  
 

 
 
Next,  we  must  select  the  “SAF  Security  Profile”  that  was  previously  configured  (e.g.  “HQ_SPI”)  and  set  
the  IP  address  to  which  the  CUCM  should  connect.  We  should  use  the  IP  address  that  corresponds  to  
the  “Loopback  0”  interface  on  R1  (10.10.1.1),  since  this  was  required  by  the  task.  
 

 
 

449 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  should  set  the  “SAF  Forwarder  Port”  for  the  connection.  By  default,  CUCM  is  set  to  use  
“5050”,  since  that  is  the  port  on  which  SAF  communicates.  However,  since  we  are  now  connecting  
using  XMCP,  we  must  change  the  port  to  4788  in  the  configuration.  Alternatively,  we  could  have  
configured  XMCP  to  use  port  5050  using  the  service-routing xmcp listen port 5050  
configuration  command  on  R1.  
 

 
 
Next,  we  should  expand  the  “Show  Advanced”  link  to  reveal  more  configuration  options.  Within  this  
page,  we  must  select  the  CUCM  servers  that  will  be  anchoring  the  communication  between  CUCM  and  
R1.  In  this  case,  both  available  servers  were  selected.  
 

 
 
Click  the  Save  button  when  completed.  Remember  to  perform  the  same  steps  on  the  SB  CUCM  cluster  
in  order  to  connect  to  the  R1  SAF  forwarder.  
 
Now  that  the  CUCM  servers  are  configured  to  connect  to  the  R1  SAF  forwarder,  we  must  also  connect  
the  R3  CUCME  as  a  client  of  the  R1  SAF  forwarder.  The  trick  that  I  like  to  use  here  is  to  simply  copy  and  
paste  the  exact  EIGRP  configuration  from  R1  to  R3.  This  is  because  we  must  match  the  service-
family type as well as the autonomous-system  configured  in  R1  anyway!    
 
R3  
R3(config)#router eigrp SAF
R3(config-router)#service-family ipv4 autonomous-system 8
R3(config-router-sf)#sf-interface Loopback0
R3(config-router-sf-interface)#no split-horizon
R3(config-router-sf-interface)#exit-sf-interface
R3(config-router-sf)#topology base
R3(config-router-sf-topology)#exit-sf-topology
R3(config-router-sf)# exit-service-family

Once  the  configuration  is  added,  you  should  be  able  to  issue  the  command  show eigrp service-
family ipv4 8 neighbors  to  view  the  neighbor  relationship  between  R3  and  R1.  

R3  
R3#show eigrp service-family ipv4 8 neighbors
EIGRP-SFv4 VR(SAF) Service-Family Neighbors for AS(8)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
10.10.131.1 Se0/1/0.301 14 4w1d 5 1020 0 24

450 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 26.3 Ensure  that  R1  is  configured  to  assist  in  providing  the  CCD  service  to  the  SAF  
network.  
 
Up  to  this  point,  we  have  configured  a  SAF  forwarder  on  R1  and  SAF  clients  on  the  HQ  CUCM,  SB  
CUCM,  and  R3  CUCME  systems.  We  can  now  begin  to  configure  the  Call  Control  Discovery  (CCD)  
service  in  the  network  as  well.  This  task  specifically  focuses  on  the  CCD  configuration  for  R1.  Keep  in  
mind  that  CCD  configuration  on  a  SAF  forwarder  is  largely  unnecessary  since  it  does  nothing  with  the  
information.  It  simply  passes  it  along  to  the  other  SAF  clients  in  the  network  for  interpretation.  
However,  we  can  still  configure  R1  to  subscribe  to  the  CCD  advertisements  being  sent  in  order  to  view  
the  patterns  that  are  being  shared  between  systems.  
 
In  order  to  enable  CCD  on  an  IOS  router,  we  must  enter  the  voice service saf  command.  This  
seems  counterintuitive,  since  we  are  configuring  CCD—not  SAF.  Next,  we  must  specify  a  SAF  channel  to  
be  used  by  the  virtual  router  in  the  configuration  as  well  as  the  EIGRP  instance  and  AS  to  which  the  
channel  should  be  subscribed.  Within  the  channel,  both  the  publish  (share  CCD  information)  and  
subscribe (receive  CCD  information)  options  exist.  In  this  example,  the  subscribe  option  will  be  
used  to  view  the  patterns  that  are  being  received  by  the  SAF  forwarder.  
 
R1  
R1(config)#voice service saf
R1(conf-voi-serv-saf)#channel 1 vrouter SAF asystem 8
R1(conf-voi-serv-saf-chan)#subscribe callcontrol wildcarded
 
At  this  point,  we  can  enter  the  show voice saf dnDb all  command  to  display  all  patterns  that  
have  currently  been  learned  within  the  network.  In  this  case,  no  patterns  have  been  shared  yet,  so  
none  will  be  displayed.  
 
R1  
R1#show voice saf dnDb all
Total no. of patterns in db/max allowed : 0/6000
Patterns classified under dialplans (private/global) : 0/0
Informational/Error stats -
Patterns w/ invalid expr detected while add : 0
Patterns duplicated under the same instance : 0
Patterns rejected overall due to max capacity : 0
Attempts to delete a pattern which is invalid : 0

Last successful DB update @ 2014:11:12 16:57:39:005

******** Private Dialplan Partition ********

- none -

******** Global (E164) Dialplan Partition ********

- none –

The  next  task  will  configure  the  CCD  service  to  share  patterns  between  the  CUCM  and  CUCME  systems.  
 
   

451 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 26.4 Ensure  that  the  HQ  CUCM,  SB  CUCM,  and  R3  CUCME  can  forward  dial  plan  
information  using  CCD  to  each  other.  Share  the  1XXX  pattern  for  HQ,  the  2XXX  
pattern  for  SB,  and  the  3XXX  pattern  for  R3.  
 
The  first  step  towards  sharing  dial  plan  information  with  the  SAF  forwarder  in  CUCM  is  to  create  a  
trunk.  It  is  possible  to  use  a  SIP  trunk  or  an  H.323  trunk  (or  both)  to  route  calls  for  CCD.  In  this  case,  a  
SIP  trunk  was  used.    
 
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  
Type”  as  “SIP  Trunk”  and  the  “Trunk  Service  Type”  as  “Call  Control  Discovery”.  
 

 
 
Click  the  Next  button  to  configure  the  trunk.  As  always,  enter  a  descriptive  “Device  Name”  for  the  SIP  
trunk  (e.g.  “SAF_SIP_TRUNK”)  and  assign  an  appropriate  “Device  Pool”  (e.g.  “SAF_SIP_DP”).  As  stated  
in  previous  labs,  it  is  always  a  good  idea  to  create  a  separate  Device  Pool  for  each  trunk  or  gateway  in  
the  system  in  order  to  provide  the  greatest  flexibility  in  configuration.    
 

 
 
Next,  make  sure  that  a  “Calling  Search  Space”  is  assigned  under  the  “Inbound  Calls”  section  in  order  to  
provide  the  ability  to  route  inbound  calls  to  DNs  or  patterns  in  the  CUCM  system  (e.g.  
“GW_TRUNK_CSS”).  
 

 
 
   

452 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

We  must  also  set  the  “SIP  Trunk  Security  Profile”  as  “Non  Secure  SIP  Trunk  Profile”  and  the  “SIP  
Profile”  as  “Standard  SIP  Profile”  for  the  SIP  trunk.    
 

 
 
You  may  have  noticed  that  no  destination  IP  address  exists  on  the  SIP  trunk  configuration  page.  This  is  
because  the  destination  will  be  dynamically  determined  by  the  CCD  advertisement  that  is  received  by  
the  CUCM  cluster.  Click  the  Save  and  Reset  buttons  on  the  trunk  when  the  configuration  is  complete.    
 
Next,  to  configure  the  CCD  service,  navigate  to  Call  Routing  !  Call  Control  Discovery  !  Hosted  DN  
Group  and  click  the  Add  New  button.  Configure  a  descriptive  “Name”  for  the  group  (e.g.  “HQ_HDG”).  
 

 
 
All  other  fields  are  optional  here,  since  we  are  not  required  to  configure  PSTN  failover  with  SAF.  Click  
the  Save  button  when  complete.  
 
Next,  navigate  to  Call  Routing  !  Call  Control  Discovery  !  Hosted  Pattern  and  click  the  Add  New  
button.  Configure  the  “Hosted  Pattern”  in  the  textbox  as  “1XXX”  and  select  the  previously  configured  
“Hosted  DN  Group”  from  the  dropdown  box  (e.g.  “HQ_HDG”).  Once  again,  PSTN  failover  configuration  
is  not  required  here,  so  those  fields  may  be  left  blank.  Click  the  Save  button  when  complete.  
 

 
 
Next,  navigate  to  Call  Routing  !  Call  Control  Discovery  !  Advertising  Service  and  click  the  Add  New  
button.  Enter  a  descriptive  “Name”  in  the  textbox  for  the  service  (e.g.  “HQ_ASI”).  Next,  select  a  trunk  

453 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

that  should  be  used  in  the  advertisements.  In  this  case,  the  previously  configured  “SAF_SIP_TRUNK”  
was  selected  from  the  dropdown  box.  Next,  the  “Hosted  DN  Group”  should  be  selected  from  the  
dropdown  box  (e.g.  “HQ_HDG”).  Once  again,  PSTN  failover  configuration  is  not  required  here,  so  those  
fields  may  be  left  blank.  Click  the  Save  button  when  complete.  
 

 
 
Next,  navigate  to  Call  Routing  !  Call  Control  Discovery  !  Partition  and  enter  a  name  for  the  Partition  
where  “learned”  CCD  patterns  will  be  assigned  (e.g.  “SAF_CCD_PT”).  Click  the  Save  button  when  
complete.  
 

 
 
Next,  navigate  to  Call  Routing  !  Call  Control  Discovery  !  Requesting  Service  and  click  the  Add  New  
button.  Enter  a  descriptive  “Name”  in  the  textbox  for  the  service  (e.g.  “HQ_RSI”).  Next,  select  the  
Partition  in  which  the  “learned”  patterns  should  be  placed  (e.g.  “SAF_CCD_PT”).  Next,  select  the  
previously  created  SAF  SIP  Trunk  as  the  trunk  in  which  advertisements  should  be  received  (e.g.  
“SAF_SIP_TRUNK”).  Click  the  Save  button  when  complete.  
 

 
 
This  completes  the  CCD  configuration  for  the  HQ  CUCM  cluster.  Make  sure  to  perform  the  same  steps  
on  the  SB  CUCM  cluster  as  well.  
 

454 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  configure  the  R3  CUCME  system  to  share  patterns  with  the  SAF  forwarder  on  R1  using  
CCD.  Just  as  was  stated  earlier  in  this  lab,  configuring  CCD  is  done  within  IOS  by  using  the  voice
service saf command.  The  first  step  is  to  configure  the  protocol  by  which  other  clusters  will  
connect  to  R3.  This  can  be  done  with  the  profile trunk-route  command.  Within  the  subset  of  
this  command,  either  the  H.323  or  SIP  protocol  can  be  selected  by  using  the  session protocol  
command.  The  interface  and  transport  mechanism  can  then  be  defined  as  well.  
 
R3  
R3(config)#voice service saf
R3(conf-voi-serv-saf)#profile trunk-route 1
R3(conf-voi-serv-saf-tr)#session protocol sip interface Vlan31 transport tcp port 5060
 
Next,  the  pattern  that  should  be  advertised  can  be  defined  using  the  profile dn-block  
command.    
 
R3  
R3(conf-voi-serv-saf)#profile dn-block 1
R3(conf-voi-serv-saf-dnblk)#pattern 1 type extension 3XXX
 
Next,  a  Call  Control  Profile  must  be  created  to  combine  both  the  trunk and dn-block  profiles  in  
order  to  provide  a  proper  CCD  advertisement.  
 
R3  
R3(conf-voi-serv-saf)#profile callcontrol 1
R3(conf-voi-serv-saf-cc)#dn-service
R3(conf-voi-serv-saf-cc-dn)#trunk-route 1
R3(conf-voi-serv-saf-cc-dn)#dn-block 1

Finally,  we  should  configure  the  SAF  channel  to  subscribe  to  all  advertisements  (as  was  done  on  R1)  
and  publish  the  configured  Call  Control  Profile  to  the  SAF  forwarder.  
 
R3  
R3(conf-voi-serv-saf)#channel 1 vrouter CCIESAF asystem 8
R3(conf-voi-serv-saf-chan)#subscribe callcontrol wildcarded
R3(conf-voi-serv-saf-chan)#publish callcontrol 1

   

455 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  both  CUCM  clusters  and  R3  CUCME  have  been  configured  to  advertise  their  respective  DN  
blocks  to  the  SAF  network,  we  can  perform  some  verification  to  ensure  that  the  patterns  are  being  
received  properly.  On  both  R1  and  R3,  we  can  issue  the  show voice saf dnDb all  command  to  
view  the  received  patterns.  
 
R1  (SAF  Forwarder)  
R1#show voice saf dnDb all
Total no. of patterns in db/max allowed : 3/6000
Patterns classified under dialplans (private/global) : 3/0
Informational/Error stats -
Patterns w/ invalid expr detected while add : 0
Patterns duplicated under the same instance : 0
Patterns rejected overall due to max capacity : 0
Attempts to delete a pattern which is invalid : 0

Last successful DB update @ 2014:11:13 00:14:15:113

******** Private Dialplan Partition ********

Pattern - 1XXX
Primary Trunk-Route(s) ID : 8 9
Alias-Route(s) Prefix/Strip-Len : - Not Available -

Pattern - 2XXX
Primary Trunk-Route(s) ID : 10
Alias-Route(s) Prefix/Strip-Len : - Not Available -

Pattern - 3XXX
Primary Trunk-Route(s) ID : 4
Alias-Route(s) Prefix/Strip-Len : - Not Available -

******** Global (E164) Dialplan Partition ********

- none -

R3  (CUCME)  
R3#show voice saf dnDb all
Total no. of patterns in db/max allowed : 2/6000
Patterns classified under dialplans (private/global) : 2/0
Informational/Error stats -
Patterns w/ invalid expr detected while add : 0
Patterns duplicated under the same instance : 0
Patterns rejected overall due to max capacity : 0
Attempts to delete a pattern which is invalid : 0

Last successful DB update @ 2014:11:13 09:14:15:308

******** Private Dialplan Partition ********

Pattern - 1XXX
Primary Trunk-Route(s) ID : 7 8
Alias-Route(s) Prefix/Strip-Len : - Not Available -

Pattern - 2XXX
Primary Trunk-Route(s) ID : 9
Alias-Route(s) Prefix/Strip-Len : - Not Available -

******** Global (E164) Dialplan Partition ********

- none –

To  verify  that  the  patterns  are  being  properly  received  on  both  the  HQ  and  SB  CUCM  clusters,  we  can  
access  RTMT  (from  HQ  Test  PC  1)  and  view  the  SAF  Learned  Patterns  in  the  system.  First,  log  into  RTMT  
456 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

for  both  clusters.  Once  logged  in,  navigate  to  CallManager  !  CallManager  Summary  and  click  on  the  
“Learned  Pattern”  link  under  the  “Report”  sub-­‐section.  Next,  select  a  node  (e.g.  “HQPUB”)  at  the  top  of  
the  screen  and  examine  the  patterns.  
 
HQ  CUCM  Cluster  

 
 
SB  CUCM  Cluster  
 

 
 
Now  that  the  patterns  have  been  successfully  advertised  and  received  using  CCD,  test  calls  can  be  
made  between  CUCM  clusters  and  CUCME  using  SAF.  This  will  be  covered  in  the  next  task.  
 
   

457 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 26.5 Calls  using  SAF  should  use  the  G.729  codec.  
 
To  ensure  that  a  call  uses  a  specific  type  of  codec,  the  answer  is  always  to  configure  the  Region  settings  
to  accommodate  the  task  requirements.  In  this  case,  it  means  that  the  Region  corresponding  to  phones  
on  each  cluster  should  be  set  to  communicate  using  the  G.729  codec  with  the  SAF  SIP  Trunk  Region.  On  
the  HQ  CUCM  cluster,  navigate  to  System  !  Region  Information  !  Region  and  click  on  the  “HQ_REG”.  
Since  the  G.729  codec  is  required,  it  is  optional  to  configure  the  relationship  with  the  “SAF_SIP_REG”.  
As  long  as  the  “Default  Interregion  Max  Audio  Bit  Rate”  Service  Parameter  is  set  to  use  G.729,  nothing  
is  required  here.    
 

 
 
Configure  the  SB  CUCM  cluster  in  the  same  fashion.  
 
Before  making  test  calls  between  the  clusters,  don’t  forget  to  add  the  “SAF_CCD_PT”  to  the  CSS  of  the  
phone  on  each  cluster  so  calls  are  possible.  Also,  make  sure  that  the  CSS  of  each  SAF  SIP  trunk  is  
configured  to  allow  access  to  the  DNs  in  the  system.    
 
Lastly,  you  may  have  noticed  that  calls  are  not  possible  when  originating  from  SC  phones  on  the  R3  
CUCME.  This  is  because  we  have  not  configured  any  corresponding  dial-peers  to  accommodate  
the  dial  plan.  Unfortunately,  although  we  are  dynamically  learning  patterns,  we  still  must  configure  
static  dial-peers  with  destination-patterns  for  the  CCD  patterns.  The  only  difference  in  
the  configuration  is  the  session target  command.  Instead  of  using  an  IPv4  address,  we  must  use  
the  target  of  saf.  This  forces  the  dial-peer  to  query  the  CCD  database  to  route  the  call  to  the  
proper  destination.    
 
R3  
R3(config)#dial-peer voice 111 voip
R3(config-dial-peer)#destination-pattern 1...$
R3(config-dial-peer)#session target saf

R3(config-dial-peer)#dial-peer voice 222 voip


R3(config-dial-peer)#destination-pattern 2...$
R3(config-dial-peer)#session target saf
 
Alternatively,  we  can  configuration  a dial-peer  with  the  destination-pattern  of  .T,  so  any  
number  will  match.  However,  at  that  point,  there  will  be  an  interdigit  timeout  associated  with  each  
call.  
 
At  this  point,  all  calls  should  be  routed  by  the  SAF-­‐learned  patterns  while  using  the  G.729  codec.  
 

458 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 27: CUCME Call Routing


Task 27.1 Configure  R3  to  support  emergency  dialing  using  the  “999”  pattern.  Send  a  9-­‐digit  
ANI  and  Calling  Name,  using  a  calling  and  called  party  type  of  “Subscriber”.  As  soon  
as  the  pattern  is  matched,  the  call  should  be  routed  immediately.  
 
This  lab  will  focus  on  PSTN  call  routing  for  the  R3  CUCME  system  at  the  SC  site.  Earlier  in  this  section,  
when  configuring  each  CUCM  cluster  to  support  the  routing  of  calls  to  the  PSTN,  the  first  step  was  to  
create  a  Digit  Manipulation  Table.  With  CUCME,  it  should  be  no  different,  since  we  must  understand  
the  format  in  which  the  PSTN  accepts  inbound  calls.  In  this  case,  let’s  create  the  table  for  the  
Emergency  Services  pattern.  
 
Digit  Manipulation  Table  
Route  Pattern   999  
ANI  Digits  Required   9  
DNIS  Digits  Required   3  (999)  
Calling  Party  Number  Type   Subscriber  
Called  Party  Number  Type   Subscriber  
Special  Requirements   N/A  
 
The  first  step  in  this  case  is  to  create  the  voice translation-rules and voice
translation-profile  to  properly  manipulate  the  digits  for  this  type  of  call.  For  the  ANI,  create  a  
voice translation-rule  that  formats  the  number  to  use  9-­‐digits  as  well  as  the  Type  and  Plan  
of  “Subscriber”  and  “ISDN”.  
 
R3  
R3(config)#voice translation-rule 4
R3(cfg-translation-rule)#rule 1 /^3...$/ /89444\0/ type any subscriber plan any isdn

Next, create the translation for the DNIS by adding the Type and Plan of “Subscriber” and “ISDN”.

R3
R3(config)#voice translation-rule 5
R3(cfg-translation-rule)#rule 1 /^999/ /\0/ type any subscriber plan any isdn

Now that translations have been created for both the ANI and DNIS, a voice translation-profile must
be created to tie the rules together.

R3
R3(config)#voice translation-profile TRANSLATE-EMER-OUTBOUND
R3(cfg-translation-profile)#translate calling 4
R3(cfg-translation-profile)#translate called 5
   

459 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  translations  created,  we  can  now  create  a  dial-peer  for  the  Emergency  Services  
destination  and  assign  the  above  voice translation-profile.  Since  the  user  will  be  dialing  
“999”  in  this  case,  a  destination-pattern  must  be  created  to  match.  Next,  the  E1  ISDN  port  
must  be  added  in  order  to  set  the  physical  destination  for  the  call.  Lastly,  we  must  add  the
forward-digits all command    to  compensate  for  the  “automatic  digit  strip”  function  of  the  
POTS  dial-peer to  allow  all  dialed  digits  to  be  forwarded.  
 
R3  
R3(config)#dial-peer voice 999 pots
R3(config-dial-peer)#translation-profile outgoing TRANSLATE-EMER-OUTBOUND
R3(config-dial-peer)#destination-pattern 999
R3(config-dial-peer)#port 0/0/0:15
R3(config-dial-peer)#forward-digits all
 
To  test  that  the  call  is  sent  to  the  PSTN  in  the  proper  format,  use  the  debug isdn q931  command  
on  the  R3  gateway  and  observe  the  output.  
 
R3  
R3#debug isdn q931
debug isdn q931 is ON.

Nov 13 22:06:06.646: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x1, Calling num
894443002
Nov 13 22:06:06.646: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x0088 callID = 0x8009 switch =
primary-net5 interface = User
Nov 13 22:06:06.646: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0088
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Calling Party Number i = 0x4181, '894443002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '999'
Plan:ISDN, Type:Subscriber(local)
Nov 13 22:06:06.686: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8088
Channel ID i = 0xA98383
Exclusive, Channel 3
Nov 13 22:06:07.082: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8088
 
   

460 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 27.2 Configure  R3  to  support  national  calls.  The  user  should  dial  a  9  first,  followed  by  any  
digit  2  through  9,  followed  by  any  8  digits.  Send  a  9-­‐digit  ANI  and  Calling  Name  using  
the  calling  party  type  of  “National”.  Send  a  9-­‐digit  DNIS  and  use  the  called  party  type  
of  “National”.    
 
This  task  will  focus  on  routing  Germany  National  calls  out  the  E1  ISDN  PSTN  on  the  R3  CUCME  system  
at  the  SC  site.  As  always,  create  a  table  to  describe  the  necessary  formatting  for  the  pattern.  
 
Digit  Manipulation  Table  
Route  Pattern   9[2-­‐9]........  
ANI  Digits  Required   9  
DNIS  Digits  Required   9  
Calling  Party  Number  Type   National  
Called  Party  Number  Type   National  
Special  Requirements   N/A  
 
Once  again,  the  first  step  here  is  to  create  the  voice translation-rules  and  voice
translation-profile to  properly  manipulate  the  digits  for  this  type  of  call.  For  the  ANI,  create  
a  voice translation-rule  that  formats  the  number  to  use  9-­‐digits  as  well  as  the  Type  and  Plan  
of  “National”  and  “ISDN”.  
 
R3  
R3(config)#voice translation-rule 6
R3(cfg-translation-rule)#rule 1 /^3...$/ /89444\0/ type any national plan any isdn

Next,  create  the  translation  for  the  DNIS  by  adding  the  Type  and  Plan  of  “National”  and  “ISDN”.  

R3  
R3(config)#voice translation-rule 7
R3(cfg-translation-rule)#rule 1 /^9\([2-9]........$\)/ /\1/ type any national plan any isdn
 
Now  that  translations  have  been  created  for  both  the  ANI  and  DNIS,  a  voice translation-
profile  must  be  created  to  tie  the  rules  together.  
 
R3  
R3(config)#voice translation-profile TRANSLATE-NATL-OUTBOUND
R3(cfg-translation-profile)#translate calling 6
R3(cfg-translation-profile)#translate called 7
 
   

461 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  translations  created,  we  can  now  create  a  dial-peer  and  assign  the  above  voice
translation-profile.  First,  a  destination-pattern  must  be  created  to  match  the  dialed  
string.  Next,  the  E1  ISDN  port  must  be  added  in  order  to  set  the  physical  destination  for  the  call.  
Lastly,  we  must  add  the  forward-digits all  command  to  compensate  for  the  “automatic  digit  
strip”  function  of  the  POTS  dial-peer  and  allow  all  dialed  digits  to  be  forwarded.    
 
R3  
R3(config)#dial-peer voice 9 pots
R3(config-dial-peer)#translation-profile outgoing TRANSLATE-NATL-OUTBOUND
R3(config-dial-peer)#destination-pattern 9[2-9]........$
R3(config-dial-peer)#port 0/0/0:15
R3(config-dial-peer)#forward-digits all
 
To  test  that  the  call  is  sent  to  the  PSTN  in  the  proper  format,  use  the  debug isdn q931  command  
on  the  R3  gateway  and  observe  the  output.  
 
R3  
R3#debug isdn q931
debug isdn q931 is ON.

Nov 13 22:37:50.014: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x2 0x1, Calling num
894443002
Nov 13 22:37:50.014: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x0089 callID = 0x800A switch =
primary-net5 interface = User
Nov 13 22:37:50.014: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0089
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Calling Party Number i = 0x2181, '894443002'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '307128788'
Plan:ISDN, Type:National
Nov 13 22:37:50.054: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8089
Channel ID i = 0xA98383
Exclusive, Channel 3
Nov 13 22:37:50.310: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8089
 

462 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 27.3 Configure  R3  to  support  international  calls.  The  user  should  dial  a  9  first,  followed  by  
00,  followed  by  any  number  of  digits.  Send  +E164  ANI  and  Calling  Name  using  the  
calling  party  type  of  “International”.  Send  the  full  international  number  (without  00  
prefix)  as  DNIS  and  use  the  called  party  type  of  “International”.    
 
This  task  will  focus  on  routing  International  calls  out  the  E1  ISDN  PSTN  on  the  R3  CUCME  system  at  the  
SC  site.  Create  a  table  to  describe  the  necessary  formatting  for  the  pattern.  
 
Digit  Manipulation  Table  
Route  Pattern   900T  
ANI  Digits  Required   +E.164    
DNIS  Digits  Required   All  digits,  no  “00”  prefix  
Calling  Party  Number  Type   International  
Called  Party  Number  Type   International  
Special  Requirements   N/A  
 
Just  as  before,  the  first  step  is  to  create  the  voice translation-rules  and  voice
translation-profile to  properly  manipulate  the  digits  for  this  type  of  call.  For  the  ANI,  create  
a  voice translation-rule  that  formats  the  number  to  use  the  +E.164  format  as  well  as  the  
Type  and  Plan  of  “International”  and  “ISDN”.  
 
R3  
R3(config)#voice translation-rule 8
R3(cfg-translation-rule)#rule 1 /^3...$/ /+4989444\0/ type any international plan any isdn

Next,  create  the  translation  for  the  DNIS  by  adding  the  Type  and  Plan  of  “International”  and  “ISDN”.  

R3  
R3(config)#voice translation-rule 9
R3(cfg-translation-rule)#rule 1 /^900\(.*\)/ /\1/ type any international plan any isdn
 
Now  that  translations  have  been  created  for  both  the  ANI  and  DNIS,  a  voice translation-
profile must  be  created  to  tie  the  rules  together.  
 
R3  
R3(config)#voice translation-profile TRANSLATE-INTL-OUTBOUND
R3(cfg-translation-profile)#translate calling 8
R3(cfg-translation-profile)#translate called 9
 
   

463 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  translations  created,  we  can  now  create  a  dial-peer  and  assign  the  above  voice
translation-profile.  First,  a destination-pattern  must  be  created  to  match  the  
dialed  string.  Remember,  since  the  task  requires  “any  number  of  digits”  following  the  dialed  string  of  
“900”,  a  “T”  should  be  used  to  indicate  that  the  router  should  wait  for  the  interdigit  timer  to  expire  
before  routing  the  call.  Next,  the  E1  ISDN  port  must  be  added  in  order  to  set  the  physical  destination  
for  the  call.  Lastly,  the  forward-digits all  command  must  be  configured  to  compensate  for  the  
“automatic  digit  strip”  function  of  the  POTS  dial-peer,  which  allows  all  dialed  digits  to  be  
forwarded.  In  this  case,  the  DNIS  is  manipulated  further  within  the  voice translation-rule.    
 
R3  
R3(config)#dial-peer voice 900 pots
R3(config-dial-peer)#translation-profile outgoing TRANSLATE-INTL-OUTBOUND
R3(config-dial-peer)#destination-pattern 900T
R3(config-dial-peer)#port 0/0/0:15
R3(config-dial-peer)#forward-digits all
 
To  test  that  the  call  is  sent  to  the  PSTN  in  the  proper  format,  use  the  debug isdn q931  command  
on  the  R3  gateway  and  observe  the  output.  
 
R3  
R3#debug isdn q931
debug isdn q931 is ON.

Nov 13 22:51:01.167: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x1 0x1, Calling num
+49894443002
Nov 13 22:51:01.167: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x008A callID = 0x800B switch =
primary-net5 interface = User
Nov 13 22:51:01.167: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x008A
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Calling Party Number i = 0x1181, '+49894443002'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '14086131218'
Plan:ISDN, Type:International
Nov 13 22:51:01.207: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x808A
Channel ID i = 0xA98383
Exclusive, Channel 3
Nov 13 22:51:01.451: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x808A
 
   

464 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 27.4 Ensure  that  the  interdigit  timeout  value  is  set  to  half  the  default  value  to  support  
quicker  international  dialing.  
 
To  ensure  that  international  calls  are  routed  more  quickly,  we  can  set  the  interdigit  (T.302)  timer  
within  IOS.  First,  we  must  determine  the  default  value  so  it  can  be  set  to  meet  the  requirements  of  the  
question.  Logically  speaking,  since  the  dialing  behavior  is  controlled  by  the  phone  system,  we  must  
examine  both  the  SCCP  and  SIP  CUCME  systems  by  running  both  the  show telephony-service  
and  show voice register global  commands.  
 
R3  
R3#show telephony-service
CONFIG (Version=9.1)
=====================
Version 9.1
...
timeout interdigit 10
...

R3#show voice register global


CONFIG [Version=9.1]
========================
Version 9.1
...
timeout interdigit 10
...
 
From  the  above  output,  we  can  conclude  that  the  interdigit  timeout  value  should  be  set  to  a  value  of  
“5”,  since  that  is  half  of  the  configured  default  value  of  “10”.  Remember  to  rebuild  the  configuration  
and  reset  the  phones  when  complete.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#timeouts interdigit 5
R3(config-telephony)#create cnf-files
R3(config-telephony)#ephone 1
R3(config-ephone)#reset

R3(config)#voice register global


R3(config-register-global)#timeouts interdigit 5
R3(config-register-global)#create profile
R3(config-register-global)#voice register pool 1
R3(config-register-pool)#reset
 
To  test  the  configuration,  go  “off  hook”  and  dial  a  number  that  utilizes  the  international  pattern.  
Ensure  that  the  interdigit  timeout  is  now  5  seconds.  
 
   

465 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 27.5 Ensure  that  the  user  can  force  the  interdigit  timeout  period  to  end  by  pressing  the  #  
key  after  dialing  the  proper  amount  of  digits.  
 
The  user  must  be  able  to  end  the  interdigit  timeout  period  by  pressing  the  #  key.  In  CUCM,  we  actually  
had  to  add  the  #  character  to  the  Route  Pattern  in  order  to  support  this  behavior.  However,  in  this  
case,  nothing  is  required  since  the  #  key  is  the  default  interdigit  timeout  termination  character  in  IOS.  
We  do  have  the  ability  to  change  this  using  the  dial-peer terminator  command,  if  so  desired.  
 
R3  
R3(config)#dial-peer terminator ?
WORD Terminator character: '0'-'9', 'A'-'F', '*', or '#'

466 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 28: CUCME Call Hunting Configuration


Task 28.1 On  R3,  create  another  extension  (3021)  for  Phone  1  on  button  3.  Configure  the  
number  3030  to  hunt  to  both  extensions  3001  and  3021  using  the  circular  scheme.  
 
This  task  is  asking  us  to  configure  a  hunt  group  for  extensions  3001  and  3021  within  the  CUCME  
system.  Of  course,  since  Phone  1  at  SC  is  a  SCCP  phone,  it  is  configured  to  register  with  the  
telephony-service  process  on  the  router.  This  means  that  the  new  extension  should  be  
configured  as  an  ephone-dn  and  associated  with  the  previously  configured  ephone  corresponding  
to  SC  Phone  1.  When  complete,  we  should  configure  an ephone-hunt  group  to  accomplish  the  
hunting  requirements.  
 
First,  create  a  new  ephone-dn  and  assign  it  to  the  third  button  of  ephone 1  on  the  R3  router.  
 
R3  
R3(config)#ephone-dn 9
R3(config-ephone-dn)#number 3021

R3(config-ephone-dn)#ephone 1
R3(config-ephone)#button 3:9
R3(config-ephone)#restart
 
Next,  create  an  ephone-hunt  group  to  route  calls  to  each  of  the  lines  in  a  circular  fashion.  The  
options  that  exist  for  ephone-hunt  groups  are  as  follows.  
 
• Longest-­‐Idle  –  When  the  hunt  group  is  invoked,  the  member  that  has  been  idle  the  longest  
receives  the  first  call.  
• Peer  –  When  the  hunt  group  is  invoked,  the  next  member  (N+1)  in  the  list  receives  the  call,  
basically  starting  the  hunting  where  it  last  stopped  for  the  previous  call.  
• Sequential  –  When  the  hunt  group  is  invoked,  the  first  configured  member  in  the  list  receives  
the  call,  followed  by  the  second,  and  so  on.  
 
In  this  case,  to  meet  the  task  requirements,  we  must  use  the  “Peer”  method  of  hunting—another  term  
for  “Circular”.  Use  the  ephone-hunt  command  to  begin  the  configuration.  First,  we  must  define  the  
pilot  number  to  be  used.  In  this  case,  the  task  dictates  that  we  must  use  the  number  “3030”.  Next,  we  
must  configure  the  lines  “3001”  and  “3021”  in  the  hunt  configuration.    
 
R3  
R3(config)#ephone-hunt 1 peer
R3(config-ephone-hunt)#pilot 3030
R3(config-ephone-hunt)#list 3001,3021
 
   

467 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  test  the  configuration,  call  the  pilot  number  from  another  phone  in  the  system  and  let  it  ring.  Notice  
that  the  call  never  jumps  to  the  other  line  (3021)  on  the  phone.  This  is  because  there  are  currently  no  
timeout  values  configured  within  the  ephone-hunt  group.  These  values  determine  how  long  the  
line  will  ring  before  declaring  a  “No  Answer”  situation  and  moving  onto  the  next  available  member.    
 
R3  
R3(config)#ephone-hunt 1
R3(config-ephone-hunt)#timeout 60,60
 
Now  place  another  test  call  to  the  “3030”  pilot  number  and  observe  the  behavior.  One  of  the  lines  will  
ring  for  60  seconds  and  will  then  move  to  the  next  member  of  the  hunt  group.    
 
   

468 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 28.2 Configure  the  system  so  that  if  no  one  answers,  calls  are  forwarded  to  3002.  
 
In  order  to  ensure  that  calls  will  forward  to  extension  3002  (SC  Phone  2)  if  there  is  no  answer,  we  must  
configure  the  ephone-hunt  group  with  the  final  command.    
 
R3  
R3(config)#ephone-hunt 1
R3(config-ephone-hunt)#final 3002
 
Call  the  pilot  number  of  “3030”  to  test  the  configuration.  When  neither  line  answers  the  call,  SC  Phone  
2  will  ring.  
 
   

469 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 28.3 Ensure  that  callers  will  only  hear  ringing  for  a  maximum  of  1  minute.  
 
In  this  task,  we  are  capping  the  maximum  hunting  time  at  1  minute.  To  accomplish  this,  we  must  set  
the  max-timeout  parameter  to  60  seconds  under  the  ephone-hunt  group  configuration.  
 
R3  
R3(config)#ephone-hunt 1
R3(config-ephone-hunt)#max-timeout 60
 
When  testing,  the  call  will  now  be  forwarded  to  SC  Phone  2  after  60  seconds.  Notice  that  the  timeout  
values  that  are  currently  set  for  each  line  (60  seconds  each)  prevent  the  other  line  from  being  reached  
through  the  hunt  group.  We  must  configure  these  values  to  a  lower  value  if  we  are  tasked  with  
reaching  both  lines.  
 
   

470 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 28.4 On  R3,  configure  the  number  3040  to  ring  all  CME  phones  (SIP  and  SCCP)  
simultaneously.    
 
The  next  task  is  asking  us  to  create  a  voice hunt-group,  the  SIP-­‐based  counterpart  of  the  
ephone-hunt  group.  In  this  case,  we  know  that  the  task  is  asking  us  to  configure  a  voice hunt-
group because  it  is  specifically  asking  for  the  “simultaneous  ring”  feature,  which  does  not  exist  
within  ephone-hunt  groups.  
 
The  options  that  exist  for voice hunt-groups  are  as  follows.  
 
• Longest-­‐Idle  –  When  the  hunt  group  is  invoked,  the  member  that  has  been  idle  the  longest  
receives  the  first  call.  
• Peer  –  When  the  hunt  group  is  invoked,  the  next  member  (N+1)  in  the  list  receives  the  call,  
basically  starting  the  hunting  where  it  last  stopped  for  the  previous  call.  
• Sequential  –  When  the  hunt  group  is  invoked,  the  first  configured  member  in  the  list  receives  
the  call,  followed  by  the  second,  and  so  on.  
• Parallel  –  Rings  all  configure  members  simultaneously  when  the  hunt  group  is  invoked.  
 
To  configure,  enter  the  voice hunt-group  command  and  specify  the  parallel  option.  This  will  
allow  the  hunting  to  take  place  in  a  “broadcast”  fashion.  Next,  define  the  pilot  number  as  “3040”  and  
configure  the  DNs  for  SC  Phone  1  (3001)  and  SC  Phone  2  (3002)  in  the  member  list.    
 
R3  
R3(config)#voice hunt-group 1 parallel
R3(config-voice-hunt-group)#pilot 3040
R3(config-voice-hunt-group)#list 3001,3002

Test  the  configuration  by  placing  a  call  to  the  pilot  number  of  “3040”.  Make  sure  that  both  phones  ring  
simultaneously.  
 
   

471 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 28.5 Ensure  that  after  20  seconds,  unanswered  calls  go  to  extension  3002.  
 
In  a  similar  fashion  to  what  was  configured  on  the  ephone-hunt  group,  set  the  timeout  value  to  
20  seconds  and  ensure  that  the  final  command  specifies  number  “3002”.  
 
R3  
R3(config)#voice hunt-group 1 parallel
R3(config-voice-hunt-group)#timeout 20
R3(config-voice-hunt-group)#final 3002
 
Test  the  configuration  to  ensure  that  the  call  is  routed  to  extension  “3002”  after  20  seconds.  
 

472 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 29: Basic Automatic Call Distribution (B-ACD)


Task 29.1 Create  an  Auto-­‐Attendant  application  on  the  R3  router  using  the  B-­‐ACD  TCL  script.  
PSTN  callers  will  be  able  to  reach  the  Auto-­‐Attendant  by  dialing  the  full  E164  number  
of  49-­‐89-­‐444-­‐3500.  Callers  from  SC  can  reach  the  Auto-­‐Attendant  by  dialing  3500.    
 
Cisco  Unified  CME  Basic  Automatic  Call  Distribution  (B-­‐ACD)  provides  automatic  answering  and  call  
distribution  for  calls  through  the  use  of  interactive  menus  and  local  hunt  groups.  Each  Cisco  Unified  
CME  B-­‐ACD  application  consists  of  one  or  more  auto-­‐attendant  (AA)  services  and  one  call-­‐queue  
service.  The  call  flow  is  such  that  an  incoming  call  dials  the  B-­‐ACD  AA  pilot  number  and  hears  a  prompt  
that  provides  a  greeting  and  instructions  to  help  the  caller  automatically  route  the  call.  
 
For  example,  callers  to  a  newspaper  might  hear:  "Thank  you  for  calling  the  Times.  To  place  an  
advertisement  or  to  subscribe  to  the  Times,  press  1;  for  the  editorial  department,  press  2;  for  the  
operator,  press  0;  if  you  know  your  party's  extension,  press  4."  Callers  who  do  not  select  an  option  will  
hear  the  greeting  and  menu  options  repeated.  
 
After  a  caller  presses  a  digit  to  be  connected  to  a  particular  department  or  service,  the  call  is  routed  to  
a  call  queue  for  an  ephone  hunt  group  that  has  been  set  up  to  answer  calls  for  that  department  or  
service.  If  a  phone  is  available  in  the  hunt  group,  the  call  is  connected.  If  no  phone  is  available  in  the  
hunt  group,  the  call  remains  in  the  call  queue.  While  the  call  is  in  the  queue,  the  caller  hears  music  on  
hold  (MOH).  At  intervals,  the  caller  hears  a  second  greeting  audio  prompt.  From  the  queue,  the  call  
periodically  reattempts  to  connect  to  a  phone  in  the  hunt  group.  If  no  phone  becomes  available  within  
a  specified  period,  the  call  is  routed  to  an  alternate,  configurable  destination.  
 
The  Cisco  Unified  CME  B-­‐ACD  application  is  specified  by  two  Tool  Command  Language  (TCL)  scripts:  an  
AA  script  that  handles  the  welcome  prompt  and  menu  choices,  and  a  call-­‐queue  script  that  manages  
call  routing  and  queuing  behavior.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/bacd/configuration/guide/cme40tcl/4
0bacd.html]    
 
B-­‐ACD  can  be  a  little  bit  tricky  to  configure—mostly  because  within  the  application  configuration  
subsection,  we  don’t  have  access  to  the  “?”  feature  of  IOS  to  help  us  figure  out  most  of  the  parameters  
(param)  in  the  system  “on  the  fly”.  Therefore,  the  easiest  way  to  configure  B-­‐ACD  is  to  know  how  to  
navigate  the  Cisco  documentation.  Since  it  is  available  to  you  in  the  lab,  why  not  use  it,  right?  The  basic  
premise  is  to  find  a  configuration  example  and  modify  it  in  such  a  way  as  to  make  it  useful  for  us  in  our  
configuration.  Obviously,  this  means  that  we  must  first  find  an  example  configuration.    
 
From  the  Cisco  documentation  page  (http://www.cisco.com/cisco/web/psa/default.html?mode=prod),  
navigate  to  Unified  Communications  !  Call  Control  !  Mid-­‐Market  Call  Control  !  Unified  
Communications  Manager  Express  !  Unified  Communications  Manager  Express  !  Configuration  
Guides  !  Cisco  Unified  CME  B-­‐ACD  and  Tcl  Call-­‐Handling  Applications  !  Cisco  Unified  CME  Basic  
Automatic  Call  Distribution  and  Auto-­‐Attendant  Service  (B-­‐ACD).  This  document  is  an  excellent  
reference  guide  and  contains  an  outstanding  configuration  example;  select  the  “One  AA”  option.  

473 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
From  there,  the  entire  configuration  is  displayed,  along  with  notes  detailing  the  purpose  of  each  
command.  First,  let’s  analyze  the  application section  of  the  configuration.    
 
Excerpt  from  Cisco  Unified  CME  B-­‐ACD  and  Tcl  Call-­‐Handling  Applications  Guide  
application
service queue flash:app_b_acd_x.x.x.x.tcl ;Defines the service-name of the
;the call-queue script as "queue."

param queue-len 10 ;Declares the queue length per ephone


;hunt group.

param aa-hunt3 1111 ;Declares menu option 3 and associates


;it with the ephone hunt group pilot
;number 1111.

param aa-hunt4 2222


param number-of-hunt-grps 2 ;Number of hunt-group menu options.

param queue-manager-debugs 1 ;Enables collection of call statistics


;for debugging.

service aa flash:app_b_acd_aa_x.x.x.x.tcl ;Defines the service name of


;the AA script as "aa."

paramspace english location flash: ;Declares use of English package


;and location of audio files.

paramspace english index 1 ;Defines category 1 for English.

paramspace english language en ;Specifies language code to be en.

param aa-pilot 8005550100 ;Access number to Cisco Unified CME


;B-ACD.

param call-retry-timer 15 ;Time interval in which call in queue


;can attempt to access available
;ephone-dns and voice mail.

param second-greeting-time 60 ;Delay before second greeting is played.

param max-time-call-retry 600 ;Maximum time calls can wait in queue.

param max-time-vm-retry 2 ;Maximum time calls can attempt to be


;transferred to voice mail.

param service-name queue ;Associates AA script with queue script.

param dial-by-extension-option 5 ;Declares menu option number for


;extension dial.

param voice-mail 5000 ;Declares B-ACD alternate destination.

param number-of-hunt-grps 2 ;Declares the number of ephone hunt


;group menu options.

param handoff-string aa ;Passes AA name to queue script.


 
The  first  service  that  is  created  under  the  application  menu  is  called  “queue”  according  to  the  
configuration  within  the  document.  Obviously,  we  can  change  the  name  to  whatever  we  would  like,  

474 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

but  it’s  easy  enough  to  simply  leave  it  the  same.  The  TCL  script  that  is  being  called  by  the  “queue”  
service  has  conspicuously  omitted  the  version  number.  This  is  because  we  must  enter  the  proper  
version  (and  file  location)  for  the  TCL  script  that  resides  within  the  router.  We  should  check  the  flash  
directory  for  this  information.  
 
R3  
R3#sh flash | i .tcl
367 30421 Jul 1 2014 16:11:54 +01:00 cme/app-b-acd-3.0.0.2.tcl
368 55599 Jul 1 2014 16:11:56 +01:00 cme/app-b-acd-aa-3.0.0.2.tcl
 
Based  on  the  above  information,  the  file  location  would  be  listed  as  service queue
flash:cme/app-b-acd-3.0.0.2.tcl.  Within  the  service  “queue”,  all  of  the  parameters  
would  then  be  defined  with  the  param  commands  listed  above.    
 
The  next  service  defined  under  the  application  section  is  entitled  “aa”  and  utilizes  the  
“app_b_acd_aa_x.x.x.x.tcl“  TCL  script.  Once  again,  this  would  be  replaced  with  the  exact  version  and  
location  of  the  script  found  in  the  flash  directory  on  the  router.  All  parameters  would  then  be  defined  
as  shown  within  the  script  above,  according  to  the  task  requirements.  
 
Next,  the  ephone-hunt  groups  that  are  defined  within  the  configuration  (“1111”  and  “2222”)  are  
created.  
 
Excerpt  from  Cisco  Unified  CME  B-­‐ACD  and  Tcl  Call-­‐Handling  Applications  Guide  
ephone-hunt 1 longest-idle
pilot 1111
list 1001,1002,1003,1004
timeout 10

ephone-hunt 2 longest-idle
pilot 2222
list 2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
timeout 10
 
Next,  we  need  to  have  the  ability  to  invoke  the  services  defined  within  the  application  section  of  
the  configuration.  In  the  document,  this  was  accomplished  by  using  a  POTS  dial-peer.  
 
Excerpt  from  Cisco  Unified  CME  B-­‐ACD  and  Tcl  Call-­‐Handling  Applications  Guide  
dial-peer voice 1000 pots
service aa
incoming called-number 8005550100
port 1/0:23

As  you  can  see,  this  guide  contains  a  great  configuration  example  for  enabling  B-­‐ACD  on  a  router.  The  
only  thing  that  is  missing  is  a  “music  on  hold”  (MoH)  configuration.  Believe  or  not,  MoH  is  required  to  
enable  B-­‐ACD  services  on  a  router.  If  no  MoH  is  configured,  the  script  will  not  work  and  the  call  will  
drop.  
 
   

475 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  easiest  way  to  configure  MoH  is  to  enable  it  within  telephony-service  on  the  router.  Of  
course,  we  need  an  accessible  MoH  file  (found  in  the  flash  directory)  to  be  able  to  stream  it  to  
connected  callers.    
 
R3  
R3#sh flash | i music-
396 496521 Jul 1 2014 16:12:12 +01:00 cme/music-on-hold.au
 
As  you  can  see  from  the  above,  the  file  is  located  in  the  “cme”  directory  on  this  particular  router.  
Therefore,  we  must  configure  the  MoH  command  within  telephony-service  using  this  exact  file  
location.  
 
R3  
R3(config)#telephony-service
R3(config-telephony)#moh cme/music-on-hold.au
 
Now  that  we  understand  the  logic  of  the  configuration,  let’s  build  the  actual  configuration  for  R3  that  
was  described  in  the  task.  The  task  dictates  that  we  must  create  the  B-­‐ACD  “auto  attendant”  
application  on  R3  using  extension  “3500”  so  PSTN  callers  and  “local”  callers  can  reach  the  script.  In  this  
case,  no  parameters  are  specified  at  all.  We  simply  must  create  the  service  as  well  as  dial-peers  
to  invoke  it.    
 
Like  I  mentioned  above,  B-­‐ACD  can  be  a  tricky  animal,  so  what  we  should  do  here  is  to  simply  queue  
the  configuration  in  a  notepad  document  without  applying  it  to  the  router  at  this  point.  The  reason  for  
this  is  because  parameters  within  the  script  sometimes  fail  to  work  correctly  when  added  to  the  
configuration  in  a  “one  by  one”  fashion.  In  other  words,  incrementally  building  a  B-­‐ACD  script  within  
IOS  is  not  such  a  great  idea.  It  is  best  to  stage  it  within  notepad  (copied  from  the  example  
configuration),  and  then  paste  it  in  the  configuration  all  at  once.  With  that  said,  we  can  still  create  the  
necessary  dial-peers  to  accommodate  the  invocation  of  the  script  without  issue.    
 
Staged  Configuration  in  Notepad  (Changes  in  Bold)  
application
service queue flash:cme/app-b-acd-3.0.0.2.tcl
param queue-len 10
param aa-hunt3 1111
param aa-hunt4 2222
param number-of-hunt-grps 2
param queue-manager-debugs 1

service aa flash:cme/app-b-acd-aa-3.0.0.2.tcl
paramspace english location flash:
paramspace english index 1
paramspace english language en
param aa-pilot 3500
param call-retry-timer 15
param second-greeting-time 60
param max-time-call-retry 600
param max-time-vm-retry 2
param service-name queue
param dial-by-extension-option 5
param voice-mail 5000
param number-of-hunt-grps 2
param handoff-string aa
 
R3  

476 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3(config)#dial-peer voice 893500 pots


R3(config-dial-peer)#service aa
R3(config-dial-peer)#incoming called-number 894443500

R3(config)#dial-peer voice 3500 voip


R3(config-dial-peer)#service aa
R3(config-dial-peer)#destination-pattern 3500
R3(config-dial-peer)#session target ipv4:10.10.3.3
R3(config-dial-peer)#incoming called-number 3500
R3(config-dial-peer)#dtmf-relay h245-alphanumeric
R3(config-dial-peer)#codec g711ulaw
R3(config-dial-peer)#no vad
 
As  you  can  see  from  the  above,  the  VoIP  dial-peer  has  some  pretty  specific  settings.  Of  course,  we  
must  call  the  service aa  (Auto  Attendant),  which  is  not  yet  created  within  in  IOS.  We  also  need  a  
destination-pattern  and  incoming called-number  that  matches  the  dialed  digits  of  the  
user.  Without  this,  the  service  will  not  be  invoked  successfully.  Next,  we’ll  need  the  session
target  command  to  forward  to  the  IP  address  of  the  “Loopback  0”  interface.  The  codec  should  also  
be  set  to  use  G.711  without  VAD.  Lastly,  the  DTMF  Relay  method  should  be  set  to  use  H.245  
Alphanumeric,  as  required  by  the  B-­‐ACD  script.  
 
Now  when  the  script  is  actually  created  within  IOS,  accessing  it  from  the  SC  PSTN  by  dialing  89-­‐444-­‐
3500  or  the  locally  attached  phones  by  dialing  3500  would  now  be  possible.  
 
   

477 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 29.2 Callers  dialing  into  the  Auto  Attendant  should  be  able  to  hear  the  welcome  prompt  
and  be  able  to  press  2  to  be  routed  to  the  hunt  group  configured  in  Task  28.1.    
 
Let’s  continue  building  the  script  within  this  task  by  applying  the  requirements  to  the  previously  staged  
configuration.  The  “Welcome  Prompt”  for  the  caller  is  the  first  requirement  of  the  task.  With  that,  we  
must  find  the  location  of  the  B-­‐ACD  prompts  in  the  flash  directory  and  tie  that  to  the  service  within  
the  application  section  of  the  configuration.    
 
R3  
R3#sh flash | i .au
...
370 75650 Jul 1 2014 16:11:56 +01:00 cme/bacd/en_bacd_allagentsbusy.au
371 83291 Jul 1 2014 16:11:56 +01:00 cme/bacd/en_bacd_disconnect.au
372 63055 Jul 1 2014 16:11:58 +01:00 cme/bacd/en_bacd_enter_dest.au
373 37952 Jul 1 2014 16:11:58 +01:00 cme/bacd/en_bacd_invalidoption.au
374 496521 Jul 1 2014 16:12:00 +01:00 cme/bacd/en_bacd_music_on_hold.au
375 123446 Jul 1 2014 16:12:00 +01:00 cme/bacd/en_bacd_options_menu.au
376 42978 Jul 1 2014 16:12:02 +01:00 cme/bacd/en_bacd_welcome.au
 
Based  on  the  above,  we  can  determine  that  the  prompts  are  located  in  the  “cme/bacd”  directory  
within  flash.  We  can  then  apply  that  configuration  to  the  new  service  configuration  in  notepad.  The  
task  also  dictates  that  we  use  the  hunt  group  configured  in  Task  28.1  when  the  caller  presses  option  2.  
In  this  case,  that  is  referring  to  the  previously  created  ephone-hunt 1 peer  hunt  group  at  
extension  “3030”.  We  can  now  modify  the  staged  configuration  with  the  newly  acquired  information.  
 
Staged  Configuration  in  Notepad  (Changes  in  Bold)  
application
service queue flash:cme/app-b-acd-3.0.0.2.tcl
param queue-len 10
param aa-hunt2 3030
param aa-hunt4 2222
param number-of-hunt-grps 2
param queue-manager-debugs 1

service aa flash:cme/app-b-acd-aa-3.0.0.2.tcl
paramspace english location flash:cme/bacd/
paramspace english index 1
paramspace english language en
param welcome-prompt _bacd_welcome.au
param aa-pilot 3500
param call-retry-timer 15
param second-greeting-time 60
param max-time-call-retry 600
param max-time-vm-retry 2
param service-name queue
param dial-by-extension-option 5
param voice-mail 5000
param number-of-hunt-grps 2
param handoff-string aa
 
   

478 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 29.3 Only  10  callers  should  be  allowed  in  the  queue.  
 
Let’s  continue  to  modify  the  staged  configuration  in  notepad  to  allow  a  maximum  of  10  callers  in  the  
queue.  In  this  case,  the  queue-len  parameter  has  already  been  set  to  a  value  of  “10”,  so  nothing  
needs  to  be  done  here!  
 
Staged  Configuration  in  Notepad  (Changes  in  Bold)  
application
service queue flash:cme/app-b-acd-3.0.0.2.tcl
param queue-len 10
param aa-hunt2 3030
param aa-hunt4 2222
param number-of-hunt-grps 2
param queue-manager-debugs 1

service aa flash:cme/app-b-acd-aa-3.0.0.2.tcl
paramspace english location flash:cme/bacd/
paramspace english index 1
paramspace english language en
param welcome-prompt _bacd_welcome.au
param aa-pilot 3500
param call-retry-timer 15
param second-greeting-time 60
param max-time-call-retry 600
param max-time-vm-retry 2
param service-name queue
param dial-by-extension-option 5
param voice-mail 5000
param number-of-hunt-grps 2
param handoff-string aa
 
   

479 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 29.4 If  after  30  seconds  of  being  queued  all  members  of  the  huntgroup  are  busy,  the  
caller  should  be  redirected  to  extension  3001.  
 
We  must  now  set  the  parameter  within  the  “Auto  Attendant”  service  to  forward  to  a  final  destination  
when  it  has  been  determined  that  all  members  of  the  queue  are  busy  and  cannot  handle  the  call.  In  
this  case,  the max-time-call-retry  parameter  should  be  set  to  a  value  of  “30”  seconds.  Also,  
the  voice-mail  parameter  should  be  set  to  use  extension  “3001”.  Although  it  is  called  voice-
mail,  it  really  refers  to  the  extension  that  should  be  contacted  as  a  last  resort.    
 
Staged  Configuration  in  Notepad  (Changes  in  Bold)  
application
service queue flash:cme/app-b-acd-3.0.0.2.tcl
param queue-len 10
param aa-hunt2 3030
param aa-hunt4 2222
param number-of-hunt-grps 2
param queue-manager-debugs 1

service aa flash:cme/app-b-acd-aa-3.0.0.2.tcl
paramspace english location flash:cme/bacd/
paramspace english index 1
paramspace english language en
param welcome-prompt _bacd_welcome.au
param aa-pilot 3500
param call-retry-timer 15
param second-greeting-time 60
param max-time-call-retry 30
param max-time-vm-retry 2
param service-name queue
param dial-by-extension-option 5
param voice-mail 3001
param number-of-hunt-grps 2
param handoff-string aa
 
 
   

480 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 29.5 When  “0”  has  been  pressed  the  call  should  be  redirected  to  extension  3001.  There  
should  not  be  any  valid  DTMF  options  other  than  2  and  0.  
 
We  must  now  set  the  parameter  within  the  “Auto  Attendant”  service  to  forward  to  extension  “3001”  
when  the  “0”  key  has  been  pressed.  To  represent  the  “0”  key,  we  must  use  the  aa-hunt10  
parameter.  We  must  also  remove  all  other  DTMF  options  in  the  script,  other  than  “2”  and  “0”.    
 
Staged  Configuration  in  Notepad  (Changes  in  Bold)  
application
service queue flash:cme/app-b-acd-3.0.0.2.tcl
param queue-len 10
param aa-hunt2 3030
param aa-hunt10 3001
param number-of-hunt-grps 2
param queue-manager-debugs 1

service aa flash:cme/app-b-acd-aa-3.0.0.2.tcl
paramspace english location flash:cme/bacd/
paramspace english index 1
paramspace english language en
param welcome-prompt _bacd_welcome.au
param aa-pilot 3500
param call-retry-timer 15
param second-greeting-time 60
param max-time-call-retry 30
param max-time-vm-retry 2
param service-name queue
param dial-by-extension-option 5
param voice-mail 3001
param number-of-hunt-grps 2
param handoff-string aa
 
Looking  ahead  to  task  29.6,  we  can  see  that  this  is  the  end  of  the  configuration  for  this  particular  Auto  
Attendant.  This  means  that  we  are  finally  ready  to  paste  these  services  into  the  R3  router.  It  will  
definitely  look  a  bit  messy  when  entering  the  configuration  since  none  of  the  parameters  will  have  
been  “registered”  under  each  respective  service  namespace.  
 
R3  
R3(config)#application
R3(config-app)#service queue flash:cme/app-b-acd-3.0.0.2.tcl
R3(config-app-param)#param queue-len 10
Warning: parameter queue-len has not been registered under queue namespace
R3(config-app-param)#param aa-hunt2 3030
Warning: parameter aa-hunt2 has not been registered under queue namespace
R3(config-app-param)#param aa-hunt10 3001
Warning: parameter aa-hunt10 has not been registered under queue namespace
R3(config-app-param)#param number-of-hunt-grps 2
Warning: parameter number-of-hunt-grps has not been registered under queue namespace
R3(config-app-param)#param queue-manager-debugs 1
Warning: parameter queue-manager-debugs has not been registered under queue namespace

R3(config-app-param)#service aa flash:cme/app-b-acd-aa-3.0.0.2.tcl
R3(config-app-param)#paramspace english location flash:cme/bacd/
R3(config-app-param)#paramspace english index 1
R3(config-app-param)#paramspace english language en
R3(config-app-param)#param welcome-prompt _bacd_welcome.au
Warning: parameter welcome-prompt has not been registered under aa namespace
R3(config-app-param)#param aa-pilot 3500
Warning: parameter aa-pilot has not been registered under aa namespace
R3(config-app-param)#param call-retry-timer 15
Warning: parameter call-retry-timer has not been registered under aa namespace
R3(config-app-param)#param second-greeting-time 60
Warning: parameter second-greeting-time has not been registered under aa namespace

481 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3(config-app-param)#param max-time-call-retry 30
Warning: parameter max-time-call-retry has not been registered under aa namespace
R3(config-app-param)#param max-time-vm-retry 2
Warning: parameter max-time-vm-retry has not been registered under aa namespace
R3(config-app-param)#param service-name queue
Warning: parameter service-name has not been registered under aa namespace
R3(config-app-param)#param dial-by-extension-option 5
Warning: parameter dial-by-extension-option has not been registered under aa namespace
R3(config-app-param)#param voice-mail 3001
Warning: p
Nov 17 20:22:12.595: //-1//HIFS:/hifs_ifs_cb: hifs ifs file read succeeded. size=30421,
url=flash:cme/app-b-acd-3.0.0.2.tcl
Nov 17 20:22:12.595: //-1//HIFS:/hifs_free_idata: hifs_free_idata: 0x2443ED88
Nov 17 20:22:12.595: //-1//HIFS:/hifs_hold_idata: hifs_hold_idata: 0x2443ED88
Nov 17 20:22:13.331: //-1//HIFS:/hifs_ifs_cb: hifs ifs file read succeeded. size=55599,
url=flash:cmarameter voice-mail has not been registered under aa namespace
R3(config-app-param)#param number-of-hunt-grps 2
Warning: parameter number-of-hunt-grps has not been registered under aa namespace
R3(config-app-param)#param handoff-string aa
Warning: parameter handoff-string has not been registered under aa namespace
R3(config-app-param)#e/app-b-acd-aa-3.0.0.2.tcl
Nov 17 20:22:13.331: //-1//HIFS:/hifs_free_idata: hifs_free_idata: 0x2443F884
Nov 17 20:22:13.331: //-1//HIFS:/hifs_hold_idata: hifs_hold_idata: 0x2443F884
 
Show  the  configuration  in  the  router  to  verify  that  everything  has  been  correctly  added.  
 
R3  
R3#sh run | sec appl
application
service aa flash:cme/app-b-acd-aa-3.0.0.2.tcl
param number-of-hunt-grps 2
paramspace english index 1
param handoff-string aa
param dial-by-extension-option 5
paramspace english language en
param max-time-vm-retry 2
param aa-pilot 3500
paramspace english location flash:cme/bacd/
param second-greeting-time 60
param welcome-prompt _bacd_welcome.au
param call-retry-timer 15
param max-time-call-retry 30
param voice-mail 3001
param service-name queue
!
service queue flash:cme/app-b-acd-3.0.0.2.tcl
param queue-len 10
param aa-hunt10 3001
param queue-manager-debugs 1
param number-of-hunt-grps 2
param aa-hunt2 3030
!
 
Next,  since  we’ve  already  created  the  dial-peers  in  one  of  the  previous  tasks,  we  can  try  dialing  
into  the  script.  From  the  PSTN  phone,  dial  89-­‐444-­‐3500  and  from  any  SC  phone,  dial  3500.  You  will  hear  
the  auto  attendant  prompt  and  should  be  able  to  select  from  the  available  options.  Obviously,  the  auto  
attendant  prompt  will  not  necessarily  match  the  actual  options  that  have  been  configured  based  on  
the  task  requirements.  If  your  script  does  not  work,  after  carefully  evaluating  the  configuration,  use  the  
debug voice application script  command  to  troubleshoot  the  problem.  
 
The  below  is  a  working  sample  call  from  SC  Phone  2  to  the  pilot  number  of  3500.  Option  2  is  selected.  
 
 

482 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3  
R3#debug voice application script
voip application script debugging is on

R3#
Nov 17 20:32:05.758: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> B-ACD Service Running <<<
Nov 17 20:32:07.542: //14515//TCL :/tcl_PutsObjCmd:
proc init_perCallvars
Nov 17 20:32:07.542:
Nov 17 20:32:07.542: //14515//TCL :/tcl_PutsObjCmd: preced info : 0:-1:0 ,index : 2 ,return value: 0
Nov 17 20:32:07.542:
Nov 17 20:32:07.542: //14515//TCL :/tcl_PutsObjCmd: is mlpp = 0

Nov 17 20:32:07.542:
Nov 17 20:32:07.542: //14515//TCL :/tcl_PutsObjCmd:
>>>>>>>>>legstate = lg_001<<<<<<<<<<<

Nov 17 20:32:07.542
R3#:
Nov 17 20:32:07.542: //14515//TCL :/tcl_PutsObjCmd: TCL AA: ++ Playing Welcome Prompt and options
menu ++
R3#
Nov 17 20:32:17.878: //14515//TCL :/tcl_PutsObjCmd: >>>>>>>>>>>>> return from infotag get
evt_dcdigits is : 2 <<<<<<<<<<<<<<<<<<<<<<<<<
Nov 17 20:32:17.878:
Nov 17 20:32:17.878: //14515//TCL :/tcl_PutsObjCmd: preced info : 0:-1:0 ,index : 2 ,return value: 0
Nov 17 20:32:17.878:
Nov 17 20:32:17.882: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: +++ New incoming call to queue 3030
+++
Nov 17 20:32:17.882: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> Queue index is 0 <<<
Nov 17 20:32:17.882: //13924//T
R3#CL :/tcl_PutsObjCmd: TCL B-ACD: >>> THE QUEUE NOW IS {TclModule_0x2330F344_0_2981556360 {CALL_NEW}
{1416256337} {0}} <<<
Nov 17 20:32:17.882: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: +++ 3030 Queue Length = 1 +++
Nov 17 20:32:17.886: //14515//TCL :/tcl_PutsObjCmd: preced info : 0:-1:0 ,index : 0 ,return value: 0
Nov 17 20:32:17.886:
Nov 17 20:32:17.886: //14515//TCL :/tcl_PutsObjCmd: preced info : 0:-1:0 ,index : 1 ,return value: -1
Nov 17 20:32:17.886:
Nov 17 20:32:17.886: //14515//TCL :/tcl_Put
R3#sObjCmd: TCL AA: >>> Destination Huntgroup = 3030 <<<
Nov 17 20:32:17.890: //14515//TCL :/tcl_PutsObjCmd: preced info : 0:-1:0 ,index : 2 ,return value: 0
Nov 17 20:32:17.890:
Nov 17 20:32:17.890: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> THE QUEUE IS
{TclModule_0x2330F344_0_2981556360 {CALL_PROGRESS} {1416256337} {0}} <<<
R3#
Nov 17 20:32:27.878: //14515//TCL :/tcl_PutsObjCmd: preced info : 0:-1:0 ,index : 2 ,return value: 0
Nov 17 20:32:27.878:
Nov 17 20:32:27.878: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> THE QUEUE IS
{TclModule_0x2330F344_0_2981556360 {CALL_PROGRESS} {1416256347} {0}} <<<
Nov 17 20:32:27.878: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> Received HELLO from
TclModule_0x2330F344_0_2981556360 <<<
R3#
Nov 17 20:32:30.458: //14515//TCL :/tcl_PutsObjCmd: preced info : 0:-1:0 ,index : 2 ,return value: 0
Nov 17 20:32:30.458:
Nov 17 20:32:30.458: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> Call Abandoned Time = 13
Seconds<<<
Nov 17 20:32:30.458: //13924//TCL :/tcl_PutsObjCmd: TCL B-ACD ++ Service Counter = 3 ++
Nov 17 20:32:30.458: //13924//TCL :/tcl_Put
 
   

483 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 29.6 Create  a  second  Auto-­‐Attendant  with  extension  3501.  This  should  send  the  caller  to  
the  aforementioned  huntgroup  without  the  caller  hearing  a  prompt.  The  caller  
should  not  be  required  to  enter  any  DTMF  to  be  routed  to  the  huntgroup.  
 
The  next  setting  that  is  being  required  here  is  called  the  “Drop-­‐Through”  option.  This  allows  inbound  
callers  to  hear  a  queue  announcement  and  get  immediately  forwarded  to  the  proper  hunt  group  
(3030).  As  the  task  states,  this  should  be  completed  with  a  second  auto  attendant  on  extension  3501.  
Once  again,  the  documentation  should  be  used  here  to  understand  the  commands  that  must  be  
executed.  This  time,  select  one  of  the  “Drop-­‐Through”  options.    
 

 
 
From  the  example,  the  only  commands  that  are  different  from  the  previously  configured  script  are  the  
following:  
• param drop-through-prompt _bacd_welcome.au
• param drop-through-option 2

The  welcome-prompt  has  been  replaced  with  the  drop-through-prompt  and  the  drop-
through-option  parameter  has  been  added.  This  will  select  the  DTMF  option  within  the  “queue”  
service  automatically.  In  this  case,  we  can  copy  the  existing  services and  dial-peers,  
modify  them  as  necessary,  and  stage  the  configuration  in  notepad  before  pasting  into  R3.    
 
Staged  Configuration  in  Notepad  (Changes  in  Bold)  
application
service aa-drop flash:cme/app-b-acd-aa-3.0.0.2.tcl
paramspace english location flash:cme/bacd/
paramspace english index 1
paramspace english language en
param drop-through-prompt _bacd_welcome.au
param drop-through-option 2
param aa-pilot 3501
param call-retry-timer 15
param second-greeting-time 60
param max-time-call-retry 30
param max-time-vm-retry 2
param service-name queue
param dial-by-extension-option 5
param voice-mail 3001
param number-of-hunt-grps 1
param handoff-string aa

dial-peer voice 893501 pots


service aa-drop
incoming called-number 894443501

dial-peer voice 3501 voip


service aa-drop
destination-pattern 3501
session target ipv4:10.10.3.3
incoming called-number 3501
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
R3  
R3(config)#appl

484 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3(config-app)#no service aa-drop


R3(config-app)#service aa-drop flash:cme/app-b-acd-aa-3.0.0.2.tcl
R3(config-app-param)# paramspace english location flash:cme/bacd/
R3(config-app-param)# paramspace english index 1
R3(config-app-param)# paramspace english language en
R3(config-app-param)# param drop-through-prompt _bacd_welcome.au
Warning: parameter drop-through-prompt has not been registered under aa-drop namespace
R3(config-app-param)# param drop-through-option 2
Warning: parameter drop-through-option has not been registered under aa-drop namespace
R3(config-app-param)# param aa-pilot 3501
Warning: parameter aa-pilot has not been registered under aa-drop namespace
R3(config-app-param)# param call-retry-timer 15
Warning: parameter call-retry-timer has not been registered under aa-drop namespace
R3(config-app-param)# param second-greeting-time 60
Warning: parameter second-greeting-time has not been registered under aa-drop namespace
R3(config-app-param)# param max-time-call-retry 30
Warning: parameter max-time-call-retry has not been registered under aa-drop namespace
R3(config-app-param)# param max-time-vm-retry 2
Warning: parameter max-time-vm-retry has not been registered under aa-drop namespace
R3(config-app-param)# param service-name queue
Warning: parameter service-name has not been registered under aa-drop namespace
R3(config-app-param)# param dial-by-extension-option 5
Warning: parameter dial-by-extension-option has not been registered under aa-drop namespace
R3(config-app-param)# param voice-mail 3001
Warning: parameter voice-mail has not been registered under aa-drop namespace
R3(config-app-param)# param number-of-hunt-grps 2
Warning: parameter number-of-hunt-grps has not been registered under aa-drop namespace
R3(config-app-par
am)# param handoff-string aa :/hifs_ifs_cb: hifs ifs file read succeeded. size=55599,
url=flash:cme/app-b-acd-aa-3.0.0.2.tcl
Warning: parameter handoff-string has not been registered under aa-drop namespace
R3(config-app-param)#
Nov 17 21:03:49.036: //-1//HIFS:/hifs_free_idata: hifs_free_idata: 0x2443C91C
Nov 17 21:03:49.036: //-1//HIFS:/hifs_hold_idata: hifs_hold_idata: 0x2443C91C

R3(config)#dial-peer voice 893501 pots


R3(config-dial-peer)# service aa-drop
R3(config-dial-peer)# incoming called-number 894443501

R3(config)#dial-peer voice 3501 voip


R3(config-dial-peer)# service aa-drop
R3(config-dial-peer)# destination-pattern 3501
R3(config-dial-peer)# session target ipv4:10.10.3.3
R3(config-dial-peer)# incoming called-number 3501
R3(config-dial-peer)# dtmf-relay h245-alphanumeric
R3(config-dial-peer)# codec g711ulaw
R3(config-dial-peer)# no vad

With  the  configuration  loaded  into  R3,  test  the  script  by  dialing  89-­‐444-­‐3501  from  the  PSTN  Phone  or  
3501  from  any  SC  phone.  You  will  hear  the  auto  attendant  prompt  and  will  then  be  forwarded  directly  
to  the  “3030”  hunt  group.  
 

485 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  5:  Labs  30-­‐32  
Version  1.0  

486 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 5: Configuring and Troubleshooting CUCM and CUCME Media


Resources
Lab 30: CUCM Conferencing Media Resources Configuration
Task 30.1 Create  a  conference  bridge  on  R2  to  support  audio  conferences  for  SB  users.  The  
loopback  interface  on  R2  should  be  used  for  this  communication.  Assure  that  users  
hear  a  specific  tone  when  others  join  and  leave  the  conference.    
 
Cisco  Unified  Communications  functionality  requires  the  use  of  media  resources.  Media  resources  
provide  services  such  as  annunciator,  transcoding,  conferencing,  music  on  hold,  and  media  
termination.  
 
The  media  resource  manager  enhances  Cisco  Unified  Communications  Manager  features  by  making  
Cisco  Unified  Communications  Manager  more  readily  able  to  deploy  annunciator,  media  termination  
point,  transcoding,  conferencing,  and  music  on  hold  services.  
 
Conference  Bridge  for  Cisco  Unified  Communications  Manager  designates  a  software  or  hardware  
application  that  is  designed  to  allow  both  ad  hoc  and  meet-­‐me  voice  conferencing.  Additional  
conference  bridge  types  support  other  types  of  conferences,  including  video  conferences.  Each  
conference  bridge  can  host  several  simultaneous,  multiparty  conferences.  
 
Conference  Bridge  includes  the  following  features:  
• Creating  a  conference  call.  
• Adding  new  participants  to  an  existing  conference  call.  
• Ending  a  conference  call.  
• Dropping  conference  participants.  
• Canceling  a  conference  call.  
• Parking  a  conference  call.  
• Transferring  a  conference  call.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmsys/CUCM_BK_CD2F
83FA_00_cucm-­‐system-­‐guide-­‐90/CUCM_BK_CD2F83FA_00_system-­‐guide_chapter_011000.html]    
 
Media  resources  in  CUCM  can  vary  based  on  the  method  in  which  they  are  created.  The  “Cisco  IP  Voice  
Media  Streaming  App”  (IPVMS)  service  controls  all  of  the  “software”  media  resources  that  reside  
within  CUCM  (Annunciator,  Conference  Bridge,  Media  Termination  Point,  and  Music  on  Hold).  All  of  
the  “hardware”  media  resources  are  created  within  IOS  devices  using  DSP  resources  and  are  then  
connected  to  CUCM  using  SCCP.  
 
In  this  case,  we  have  been  tasked  with  creating  a  conference  bridge  on  R2  using  DSP  resources  
available  in  the  router.  This  bridge  should  only  support  audio  participants,  should  use  the  “Loopback  0”  
address  as  the  source,  and  should  play  a  different  tone  when  users  join  and  leave  the  conference.  
 
The  first  step  here  is  to  configure  the  voice-card  on  R2  to  support  the  creation  of  DSP-­‐based  
resources  on  the  router.  The  voice-card  section  configures  the  router  PVDM  modules,  depending  
487 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

on  their  specific  location  in  the  router.  Within  this  section,  we  must  configure  the  dspfarm  and  dsp
services dspfarm  commands.  Without  the  dspfarm  command,  we  would  not  be  able  to  create  
any  profiles  in  the  router  for  conferencing,  transcoding,  media  termination,  etc.  Without  the  dsp
services dspfarm  command,  configuring  and  activating  those  profiles  is  not  possible.  Moral  of  
the  story,  both  commands  are  absolutely  necessary  for  the  success  of  the  configuration.  
 
R2  
R2(config)#voice-card 0
R2(config-voicecard)#dspfarm
R2(config-voicecard)#dsp services dspfarm
 
Next,  we  must  create  the  dspfarm profile  to  support  audio  conferencing.  Enter  the  command  
from  global  configuration  mode.  
 
R2  
R2(config)#dspfarm profile 1 conference
R2(config-dspfarm-profile)#
 
Next,  the  maximum  number  of  conference  bridges  that  can  be  initiated  should  be  set  using  the  
maximum sessions command.  Issuing  the  “?”  character  will  display  the  maximum  number  of  
sessions  that  can  be  supported  by  the  router.  The  task  did  not  define  how  many  sessions  should  be  
used,  so  a  value  of  “2”  was  chosen  in  this  case.  When  in  doubt,  try  and  keep  the  number  low  so  as  to  
not  exhaust  all  resources  in  the  router.  
 
R2  
R2(config)#dspfarm profile 1 conference
R2(config-dspfarm-profile)#maximum sessions 2
 
The  next  step  is  to  associate  the  profile  with  the  application  that  will  be  used  to  control  the  utilization  
of  the  conference  bridge.  In  this  case,  and  in  the  case  of  all  “hardware”  media  resources  being  
registered  to  CUCM,  SCCP  will  be  used  to  accomplish  this.    
 
R2  
R2(config)#dspfarm profile 1 conference
R2(config-dspfarm-profile)#associate application sccp  
 
Lastly,  don’t  forget  to  switch  the  profile  “on”  by  issuing  the  no  shutdown  command.  
 
R2  
R2(config)#dspfarm profile 1 conference
R2(config-dspfarm-profile)#no shutdown  
 
Now  that  the  dspfarm profile  is  complete,  we  must  configure  the  SCCP  application  in  order  for  
the  media  resources  to  be  controlled  by  CUCM.  We  should  start  by  identifying  the  source  interface  for  
the  communication.  Based  on  the  task  requirements,  we  should  use  the  “Loopback  0”  interface.  
 
R2  
R2(config)#sccp local Loopback0
 
Next,  we  must  define  the  CUCM  server  to  which  the  R2  router  will  connect  using  the  sccp ccm  
command.  Within  this  command,  we  must  provide  an  identifier, priority,  and  version  for  

488 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

the  CUCM  server.  The  version  should  be  specified  as  “7.0+”  to  describe  CUCM  versions  greater  than  
7.x.  
 
R2  
R2(config)# sccp ccm 10.10.23.11 identifier 1 priority 1 version 7
 
Next,  we  must  create  a  SCCP  CUCM  group  to  associate  a  specified  dspfarm profile  with  a  CUCM  
server.  We  can  also  provide  a  descriptive  name  that  can  be  used  to  register  with  CUCM.  
 
R2  
R2(config)#sccp ccm group 1
R2(config-sccp-ccm)#associate ccm 1 priority 1
R2(config-sccp-ccm)#associate profile 1 register R2-CONF  
 
The  last  step  is  to  enable  SCCP  to  run  on  the  R2  router  by  issuing  the  sccp command.  
 
R2  
R2(config)#sccp
 
Next,  we  must  configure  the  CUCM  server  at  SB  to  accept  the  connection  from  R2  and  register  the  
newly  created  conference  bridge.  Navigate  to  Media  Resources  !  Conference  Bridge  and  click  the  Add  
New  button.  On  the  “Conference  Bridge  Configuration”  page,  select  the  “Conference  Bridge  Type”  as  
“Cisco  IOS  Enhanced  Conference  Bridge”.  
 

 
 
For  the  “Conference  Bridge  Name”,  enter  the  name  that  was  configured  on  the  R2  router  within  the  
SCCP  CUCM  group  (e.g.  “R2-­‐CONF”).  Also,  specify  a  “Device  Pool”  in  which  the  conference  bridge  can  
reside  (e.g.  “SB_PHONE_DP”).  
 

 
 
Next,  select  the  “Device  Security  Mode”  as  “Non  Secure  Conference  Bridge”  and  click  the  Save  button  
to  complete  the  configuration.  
 

489 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

At  this  point,  the  conference  bridge  should  be  registered  to  the  CUCM  server.  View  the  “Conference  
Bridge  Configuration”  page  to  verify.  
 

 
 
To  check  the  conference  bridge  registration  status  on  R2,  we  can  use  the  show dspfarm profile
1 command,  where  “1”  is  the  profile  number  that  should  be  viewed.  
 
R2  
R2#show dspfarm profile 1
Dspfarm Profile Configuration
...
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP

The  last  step  now  is  to  create  the  different  tones  for  “joining”  and  “leaving”  the  audio  conference  
bridge.  This  can  be  accomplished  by  using  the  voice class custom-cptone  command.  We  
must  create  a  different  voice class  for  each  type  of  tone.  A  frequency  and  cadence  must  be  
defined  under  the  dualtone conference  heading  in  order  to  create  a  unique  tone  for  each  
event.  Two  frequencies  must  be  specified.  For  the  cadence  command,  the  first  number  specifies  the  
number  of  milliseconds  that  the  tone  is  played  and  the  second  number  specifies  the  number  of  
milliseconds  in  which  the  tone  is  not  played.  Each  subsequent  number  specified  uses  the  same  logic:  
on,  off,  on,  off,  etc.  The  below  command  specifies  that  the  tone  should  be  played  for  100  milliseconds,  
stop  for  100  milliseconds,  and  play  for  another  100  milliseconds.  This  means  that  two  beeps  will  be  
played.    
 
R2  
R2(config)#voice class custom-cptone JOIN
R2(cfg-cptone)#dualtone conference
R2(cfg-cp-dualtone)#frequency 1000 2000
R2(cfg-cp-dualtone)#cadence 100 100 100

R2(config)#voice class custom-cptone LEAVE


R2(cfg-cptone)#dualtone conference
R2(cfg-cp-dualtone)#frequency 600 800
R2(cfg-cp-dualtone)#cadence 100 100 100
 
Next,  each  voice class  must  be  assigned  to  the  dspfarm profile  that  was  created  to  support  
the  audio  conference  bridge.  Remember,  to  make  any  changes,  we  must  first  shutdown  the  profile.  
We  can  use  the  conference-join  and  conference-leave  commands  to  set  the  configuration  
within  the  dspfarm profile.  It  is  a  good  idea  to  pay  attention  to  the  warning  that  is  issued  by  IOS,  
although  it  is  a  grammatical  nightmare.  Create  tones  that  sounds  different,  or  else  you  won’t  be  able  to  
distinguish  between  the  events.    
 
R2  
R2(config-dspfarm-profile)#shutdown

490 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Disabling profile will disconnect active CONFERENCING calls,


do you want to continue ? [yes/no]yes

R2(config-dspfarm-profile)#conference-join custom-cptone JOIN


Please note that conference join tone should better be different from leave tone!

R2(config-dspfarm-profile)#conference-leave custom-cptone LEAVE


Please note that conference join tone should better be different from leave tone!

R2(config-dspfarm-profile)#no shutdown

The  conference  bridge  will  be  tested  in  the  next  task.  
 
   

491 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 30.2 Users  at  SB  should  be  able  to  invoke  the  conference  bridge  by  using  the  Join  softkey  
or  the  conference  softkey.    
 
Not  only  do  we  have  to  modify  the  Softkey  Templates  for  the  7965  phones  that  reside  at  SB,  but  we  
must  also  create  a  Media  Resource  Group  (MRG)  and  Media  Resource  Group  List  (MRGL)  to  house  the  
conference  bridge  and  provide  access  to  the  resource  for  the  “SB_PHONE_DP”  Device  Pool.  
 
Cisco  Unified  Communications  Manager  media  resource  groups  and  media  resource  group  lists  provide  
a  way  to  manage  resources.  Use  these  resources  for  conferencing,  transcoding,  media  termination,  
and  music  on  hold  (MOH).  
 
Media  resource  groups  define  logical  groupings  of  media  servers.  You  can  associate  a  media  resource  
group  with  a  geographical  location  or  a  site  as  desired.  You  can  also  form  media  resource  groups  to  
control  the  usage  of  servers  or  the  type  of  service  (unicast  or  multicast)  that  is  desired.  
 
Media  resource  group  lists  specify  a  list  of  prioritized  media  resource  groups.  An  application  can  select  
required  media  resources  from  among  the  available  resources  according  to  the  priority  order  that  is  
defined  in  the  media  resource  group  list.  Media  resource  group  lists,  which  are  associated  with  devices,  
provide  media  resource  group  redundancy.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmsys/CUCM_BK_CD2F
83FA_00_cucm-­‐system-­‐guide-­‐90/CUCM_BK_CD2F83FA_00_system-­‐guide_chapter_010110.html]    
 
The  first  thing  that  should  be  done  is  to  create  an  MRG  to  contain  the  conference  bridge  on  R2  that  is  
registered  to  the  SB  CUCM  cluster.  Navigate  to  Media  Resources  !  Media  Resource  Group  and  click  
the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  group  (e.g.  “R2-­‐CONF_MRG”)  and  select  the  
“R2-­‐CONF  (CFB)”  conference  bridge  that  was  added  in  the  previous  task.  
 

 
 
Click  the  Save  button  when  complete.  
 

492 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  an  MRGL  must  be  created  to  contain  the  newly  created  MRG.  Navigate  to  Media  Resources  !  
Media  Resource  Group  List  and  click  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  list  (e.g.  
“SB_MRGL”)  and  select  the  newly  created  MRG  (e.g.  “R2-­‐CONF_MRG”)  from  the  list.    
 

 
 
Click  the  Save  button  to  complete  the  configuration.  
 
Next,  we  must  assign  the  MRGL  to  the  Device  Pool  for  SB  Phones  (e.g.  “SB_PHONE_DP”)  so  users  at  SB  
can  invoke  the  conference  bridge  for  an  audio  call.  Navigate  to  System  !  Device  Pool  and  click  on  the  
“SB_PHONE_DP”  Device  Pool.  Locate  the  “Media  Resource  Group  List”  parameter  and  select  the  
“SB_MRGL”  option  from  the  dropdown  box.    
 

 
 
Click  the  Save  and  Reset  buttons  to  save  and  apply  the  configuration  to  the  phones.    
 
Next,  we  must  update  the  Softkey  Template  so  users  at  SB  can  access  the  proper  keys  to  create  a  
conference.  Navigate  to  Device  !  Device  Settings  !  Softkey  Template  and  click  the  Find  button.  Click  
on  one  of  the  previously  created  templates  (either  "Standard  User  -­‐  NoNewCall"  or  "Standard  User  -­‐  
QRT")  and  then  click  the  Go  button  to  “Configure  Softkey  Layout”  in  the  “Related  Links”  section.  
 

 
 
Add  the  “Conference  (Confrn)”,  “Select  (Select)”  and  “Join  (Join)”  softkeys  to  every  available  call  state.  
Remember,  the  select  key  is  necessary  to  select  the  parties  that  should  be  conferenced  when  using  the  
“Join”  functionality.  
 

493 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Remember  to  click  the  Save  button  when  complete.  Update  the  other  softkey  template  as  necessary  so  
both  phones  have  the  required  functionality.  
 
To  verify  the  configuration,  create  a  conference  using  a  phone  at  SB  as  the  initiator.  On  the  R2  router,  
where  the  conferencing  resources  reside,  issue  the  show sccp connections  command  to  view  
the  connections  being  made  to  the  conference  bridge.  
 
R2  
R2#show sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

16782222 16777457 conf sendrecv g711u 16620 18688 10.10.21.24


16782222 16777455 conf sendrecv g729 16618 17080 10.10.11.1
16782222 16777454 conf sendrecv g711u 16616 16612 10.10.2.2

Total number of active session(s) 1, and connection(s) 3


 
   

494 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 30.3 The  conference  bridge  should  be  able  to  support  users  at  HQ,  SC,  and  the  PSTN.  The  
SIP  ICT  configured  in  Task  14.1  should  be  used  for  calls  to  HQ,  the  SIP  trunk  to  CUBE  
(R1)  should  be  used  to  call  SC,  and  the  R2  gateway  should  be  used  to  access  the  
PSTN.    
 
Two  of  the  above  call  flows  have  been  previously  configured  in  the  Volume  1  labs,  so  we  only  have  to  
configure  call  routing  for  one  of  the  described  flows.  SB  users  should  already  be  able  to  dial  11XXX  to  
utilize  the  SIP  trunk  when  calling  HQ  users  and  any  PSTN  pattern  to  traverse  the  R2  PSTN  router.  
However,  support  for  calls  to  SC  users  through  CUBE  has  not  yet  been  configured.    
 
Since  a  SIP  trunk,  Route  Group,  and  Route  List  have  already  been  created  for  calls  to  CUBE  on  the  SB  
CUCM  cluster,  all  that  must  be  added  is  a  Route  Pattern  to  dial  SC  users.  Navigate  to  Call  Routing  !  
Route  Pattern  and  click  the  Add  New  button.  Although  not  specified,  it  is  easiest  to  use  4-­‐digit  dialing,  
so  a  “Route  Pattern”  of  “3XXX”  should  be  entered.  Also,  a  Partition  should  be  specified  to  provide  
access  to  the  pattern  for  SB  users  (e.g.  “SC_PT”).  Next,  specify  the  “CUBE_SIP_RL”  for  the  
“Gateway/Route  List”  parameter  and  click  the  Save  button.  
 

 
 
Next,  configure  the  CUBE  on  R1  to  route  the  call  to  R3  by  adding  a dial-peer.  The  
destination-pattern  should  be  added  for  the  dialed  number  of  3...,  the session
protocol should  set  as  SIPv2,  the  session target  should  be  set  to  10.10.31.1,  and  the  
incoming called-number  command  should  also  use  3...  to  support  inbound  calls  and  VAD  
should  be  disabled.  
R3  
R1(config)#dial-peer voice 3000 voip
R1(config-dial-peer)#destination-pattern 3...$
R1(config-dial-peer)#session protocol sipv2
R1(config-dial-peer)#session target ipv4:10.10.31.1
R1(config-dial-peer)#incoming called-number 3...$
R1(config-dial-peer)#no vad
 
The  change  that  must  be  made  to  the  conference  bridge  is  only  to  support  the  iLBC  codec  that  is  
negotiated  between  endpoints  for  calls  between  SB  and  HQ.  By  default,  the  conference  bridge  does  
not  support  this  codec,  so  it  must  be  added  so  the  conference  is  able  to  operate  successfully  for  this  

495 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

call  flow.  This  change  should  be  made  within  the  dspfarm profile  that  was  created  to  support  
the  audio  conference  bridge.  Remember,  we  need  to  first  shutdown  the  bridge  to  make  any  changes.  
Don’t  forget  to  issue  the  no shutdown  command  when  complete.  
 
R2  
R2(config)#dspfarm profile 1 conference
R2(config-dspfarm-profile)#shutdown

Disabling profile will disconnect active CONFERENCING calls,


do you want to continue ? [yes/no]yes

R2(config-dspfarm-profile)#codec ilbc
R2(config-dspfarm-profile)#no shutdown
 
Now  initiate  a  conference  from  the  SB  phone  that  includes  HQ,  SC,  and  PSTN  users.  Ensure  that  the  
conference  operates  successfully.  
 
R2  
R2#sh sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

16782222 16777459 conf sendrecv ilbc 16622 21576 10.10.11.12


16782222 16777457 conf sendrecv g711u 16620 18688 10.10.21.24
16782222 16777455 conf sendrecv g729 16618 17080 10.10.11.1
16782222 16777454 conf sendrecv g711u 16616 16612 10.10.2.2

Total number of active session(s) 1, and connection(s) 4


 
   

496 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 30.4 Use  a  media  termination  point  to  enable  the  H.323  ICT  between  HQ  and  SB  for  
FastStart.  HQ’s  MTP  should  be  configured  on  R1  and  SB’s  MTP  should  be  configured  
on  R2.    
 
H.323  FastStart  is  a  method  by  which  the  audio  codecs  can  be  negotiated  during  the  setup  of  a  call  
instead  of  at  the  end  of  the  setup.  H.323  is  made  up  of  two  different  protocols,  H.225  and  H.245.  H.225  
handles  the  signaling  and  call  setup  while  H.245  handles  the  media  negotiation  between  endpoints.  In  
“normal”  or  “slow  start”  mode,  H.323  uses  H.225  to  set  up  the  call  and  once  the  call  is  set  up,  H.245  to  
negotiate  the  media.  See  the  diagram  below  for  an  illustration  of  this  call  flow.  
 

 
 
With  FastStart,  the  H.245  messages  are  actually  “tunneled”  within  the  initial  H.225  setup  message.  This  
allows  the  media  negotiation  to  happen  immediately.  See  the  below  diagram  for  an  illustration  of  the  
call  flow.  
 

 
 

497 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  this  case,  Media  Termination  Points  (MTPs)  are  required  to  enable  FastStart  since  the  H.245  
message  needs  to  be  generated  by  the  H.323  ICT.  To  create  an  MTP,  the  process  is  not  all  that  different  
from  the  previous  task  in  which  a  conference  bridge  was  created.  However,  there  are  a  few  subtle  
differences  that  we  must  understand.    
 
Just  as  before,  we  must  configure  the  IOS  devices  (routers)  to  create  an  MTP  within  a  dspfarm
profile.  Then,  we  must  create  the  SCCP  configuration  to  register  the  media  resource  to  the  CUCM  
cluster.  Let’s  start  by  configuring  the  voice-card  and  dspfarm profile  on  R1.  The  voice-
card  will  use  the  same  configuration  that  was  entered  on  the  R2  router  when  creating  the  conference  
bridge,  so  nothing  will  be  different  here.  The  dspfarm profile  on  the  other  hand,  should  be  very  
different.  First,  we  should  tag  the  profile  with  the  mtp  keyword,  in  order  to  create  an  MTP  resource.  
Next,  we  must  define  the  codec  that  will  be  used  within  the  MTP.  Since  the  communication  between  
HQ  and  SB  phones  will  use  the  G.729  codec,  and  MTP  profiles  only  allow  the  use  of  one  codec,  we  must  
remove  the  default  G.711  codec  and  add  the  G.729  codec  to  the  profile  using  the  codec  command.  
Next,  the  command  codec pass-through  must  be  entered  in  order  to  support  multiple  codecs  
within  the  profile.  This  is  necessary  in  all  cases  for  MTP  usage.  The  next  command  usually  creates  a  bit  
of  confusion  with  students.  The  maximum sessions  command  will,  of  course,  define  the  maximum  
number  of  connections  that  can  be  made  to  the  profile.  However,  the  software keyword  instructs  
the  router  to  use  its  CPU  to  handle  the  connection.  This  means  that  a  hardware  DSP  resource  (PVDM  
Module)  is  not  being  used  on  the  router  for  the  profile.  CUCM  will  still  refer  to  this  resource  as  a  
“hardware”  resource,  even  though  it  is  really  configured  within  software  (CPU)  on  the  router.  This  
option  must  be  used  when  creating  an  MTP.  Finally,  we  must  associate  the  profile  with  the  SCCP  
application  and  switch  it  on.  
 
R1  
R1(config)#voice-card 0
R1(config-voicecard)#dspfarm
R1(config-voicecard)#dsp services dspfarm

R1(config)#dspfarm profile 1 mtp


R1(config-dspfarm-profile)#no codec g711ulaw
R1(config-dspfarm-profile)#codec g729r8
R1(config-dspfarm-profile)#codec pass-through
R1(config-dspfarm-profile)#maximum sessions software 10
R1(config-dspfarm-profile)#associate application SCCP
R1(config-dspfarm-profile)#no shutdown
 
Once  created,  we  must  configure  SCCP  on  R1  to  make  the  connection  with  the  HQ  CUCM.  Source  
traffic  from  the  “Loopback  0”  address  on  R1  and  add  the  HQ  CUCM  server  to  the  SCCP  configuration.  
Create  the  SCCP  CUCM  Group  to  register  the  MTP  using  a  descriptive  name  (e.g.  “R1-­‐MTP”).  
 
R1  
R1(config)#sccp local Loopback0
R1(config)#sccp ccm 10.10.13.12 identifier 1 priority 1 version 7.0
R1(config)#sccp ccm group 1
R1(config-sccp-ccm)#associate ccm 1 priority 1
R1(config-sccp-ccm)#associate profile 1 register R1-MTP
R1(config)#sccp

498 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  add  the  MTP  to  the  HQ  CUCM  cluster  by  navigating  to  Media  Resources  !  Media  
Termination  Point  and  clicking  the  Add  New  button.  Enter  the  “Media  Termination  Point  Name”  as  
“R1-­‐MTP”  and  select  a  “Device  Pool”  to  which  the  MTP  should  be  assigned  (e.g.  “HQ_PHONE_DP”).  
 

 
 
Click  the  Save  button  to  complete  the  configuration.  
 
Ensure  that  the  MTP  has  successfully  registered  with  the  CUCM  cluster  by  issuing  the  show dspfarm
profile 1  command  on  the  R1  router.  
 
R1  
R1#sh dspfarm profile 1
Dspfarm Profile Configuration
...
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : NONE Status : NONE
...
 
Next,  we  must  add  an  MRG  and  a  MRGL  so  the  H.323  ICT  can  utilize  the  MTP.  Navigate  to  Media  
Resources  !  Media  Resource  Group  and  click  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  
group  (e.g.  “R1-­‐MTP_MRG”)  and  select  “R1-­‐MTP”  that  was  previously  created.  Click  the  Save  button  
when  complete.  
 

 
 
Next,  navigate  to  Media  Resources  !  Media  Resource  Group  List  and  click  the  Add  New  button  to  
create  the  MRGL.  Remember,  this  MRGL  will  eventually  be  assigned  to  the  H.323  ICT,  so  it  should  be  
named  with  that  in  mind  (e.g.  “SB_H323_ICT_MRGL”).  Make  sure  to  add  the  previously  created  MRG  
as  well.  Click  the  Save  button  when  complete.  

499 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  we  must  assign  the  MRGL  to  the  H.323  ICT  and  configure  the  trunk  for  H.323  FastStart.  Navigate  
to  Device  !  Trunk  and  click  the  Find  button.  Click  on  the  “SB_H323_ICT_TRUNK”  link.  For  the  “Media  
Resource  Group  List”  parameter,  select  the  “SB_H323_ICT_MRGL”  option.  
 

 
 
Next,  check  the  “Media  Termination  Point  Required”  checkbox  to  ensure  that  an  MTP  is  used  when  
calls  traverse  the  ICT.  This  setting  is  required  to  enable  H.323  FastStart.    
 

 
 
Next,  under  the  “Inbound  Calls”  section,  check  the  box  to  “Enable  Inbound  FastStart”  in  order  to  
support  calls  that  originated  using  H.323  FastStart.  We  need  to  check  this  box  in  order  to  support  calls  
from  the  SB  CUCM  cluster.    
 

 
 
Last,  we  must  set  the  trunk  to  perform  FastStart  for  outbound  calls  by  checking  the  “Enable  Outbound  
FastStart”  checkbox  under  the  “Outbound  Calls”  section.  We  must  also  select  a  codec  option;  in  this  
case  it  should  be  “G729”.  
 

 
 

500 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Click  the  Save  and  Reset  buttons  to  save  and  apply  the  configuration  to  the  trunk.  
 
Make  sure  that  the  MTP  is  created  on  R2  for  the  SB  CUCM  cluster  as  well.  Also,  configure  the  H.323  ICT  
to  support  FastStart  and  create  the  requisite  MRG  and  MRGL  to  support  the  configuration.  
 
R2  
R2(config)#dspfarm profile 2 mtp
R2(config-dspfarm-profile)#no codec g711ulaw
R2(config-dspfarm-profile)#codec g729r8
R2(config-dspfarm-profile)#codec pass-through
R2(config-dspfarm-profile)#maximum sessions software 10
R2(config-dspfarm-profile)#associate application sccp
R2(config-dspfarm-profile)#no shutdown
 
SB  CUCM  MTP  Configuration  
 
 

 
 
 
SB  CUCM  MRG  Configuration  
 
 

 
 
 

501 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

SB  CUCM  MRGL  Configuration  


 

 
 
SB  CUCM  H.323  ICT  Configuration  
 

 
 

 
 

 
 

 
 
R2  MTP  Registration  Verification    
R2#sh dspfarm pro 2
Dspfarm Profile Configuration
...
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
...
 

502 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  verify  the  configuration,  make  a  test  call  between  an  HQ  and  SB  phone  over  the  H.323  ICT.  Issue  the  
show sccp connections  command  on  each  router  to  verify  the  connection  while  the  call  is  up.  
This  will  confirm  that  the  MTP  is  being  used  on  each  router.  
 
R1
R1#show sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

33559465 33554716 mtp sendrecv g729 17096 30388 10.10.11.12


33559465 33554715 mtp sendrecv g729 17094 16624 10.10.2.2

Total number of active session(s) 1, and connection(s) 2


 
R2  
R2#show sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

16782223 16777464 mtp sendrecv g729 16626 30824 10.10.21.25


16782223 16777463 mtp sendrecv g729 16624 17094 10.10.1.1

Total number of active session(s) 1, and connection(s) 2

   

503 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 30.5 Ensure  that  media  resources  configured  on  R1  utilize  SCCP  redundancy.  
 
You  may  have  noticed  in  the  previous  task  that  we  did  not  specify  a  redundant  option  for  SCCP  
connectivity  on  the  R1  router.  This  means  that  the  R1  router  can  only  make  a  connection  using  SCCP  
with  one  HQ  CUCM  server.  To  specify  an  additional  server,  we  must  use  the  sccp ccm  command  and  
enter  the  IP  address,  ID,  priority,  and  version.  We  must  also  add  that  server  to  the  existing  sccp ccm
group.  When  complete,  issue  a  no sccp  command  followed  by  a  sccp command  to  restart  SCCP  
on  the  router.  
 
R1  
R1(config)#sccp ccm 10.10.13.11 identifier 2 priority 2 version 7.0
R1(config)#sccp ccm group 1
R1(config-sccp-ccm)#associate ccm 2 priority 2

R1(config)#no sccp
R1(config)#sccp
 
   

504 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 30.6 Configure  a  transcoder  on  R1  to  register  with  the  HQ  CUCM  cluster.  Ensure  that  any  
phone  at  HQ  can  invoke  it.    
 
This  task  requires  that  we  configure  a  transcoder  on  the  R1  router.  In  this  case,  we  can  utilize  the  
existing  SCCP  configuration  on  R1,  but  we  must  create  a  new  dspfarm profile  and  register  it  to  
CUCM.  Also,  we  should  create  a  new  MRG/MRGL  and  assign  it  to  the  Device  Pool  of  the  HQ  phones.  
 
First,  let’s  create  the  dspfarm profile  for  the  transcoder  on  R1.  As  shown  below,  we  can  use  the  
transcode  tag  on  the  profile  to  identify  the  type.    We  also  have  the  option  of  adding  the  
universal  tag  in  addition  to  the  transcode  tag  in  order  to  transcode  between  two  non-­‐G.711  
codecs.  Next,  we  must  specify  the  G.729  codec  within  the  profile  because  only  G.729  Annex  A  and  AB  
are  included  by  default.  The  maximum sessions  command  allows  the  use  of  two  transcoding  
sessions  in  this  case.  Lastly,  the  SCCP  application  should  be  associated  and  the  profile  should  be  turned  
on.  
 
R1  
R1(config)#dspfarm profile 2 transcode
R1(config-dspfarm-profile)#codec g729r8
R1(config-dspfarm-profile)#maximum sessions 2
R1(config-dspfarm-profile)#associate application SCCP
R1(config-dspfarm-profile)#no shutdown
 
Next,  we  must  configure  the  SCCP  CUCM  group  to  add  the  newly  created  transcoder  to  the  list  of  
media  resources  handled  by  this  router.    
 
R1  
R1(config)#sccp ccm group 1
R1(config-sccp-ccm)#associate profile 2 register R1-XCODE
 
Next,  configure  the  transcode  to  register  with  the  HQ  CUCM  cluster  by  navigating  to  Media  Resources  
!  Transcoder  and  clicking  the  Add  New  button.  Select  the  “Cisco  IOS  Enhanced  Media  Termination  
Point”  from  the  “Transcoder  Type”  dropdown  list.  Next,  enter  the  “Device  Name”  as  the  same  name  
that  was  used  in  the  SCCP  configuration  on  R1  (e.g.  “R1-­‐XCODE”).  Select  a  suitable  “Device  Pool”  for  
the  transcoder  (e.g.  “HQ_PHONE_DP”)  and  click  the  Save  button  when  complete.  
 

 
 

505 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  transcoder  configured  in  CUCM,  issue  the  show dspfarm profile 2  command  on  R1  
to  view  the  registration  status  of  the  transcoder.  
 
R1  
R1#show dspfarm profile 2
Dspfarm Profile Configuration
...
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
...
 
Next,  we  must  add  an  MRG  and  a  MRGL  so  the  HQ  phones  can  utilize  the  transcoder.  Navigate  to  
Media  Resources  !  Media  Resource  Group  and  click  the  Add  New  button.  Enter  a  descriptive  “Name”  
for  the  group  (e.g.  “R1-­‐XCODE_MRG”)  and  select  “R1-­‐XCODE”  that  was  previously  created.  Click  the  
Save  button  when  complete.  
 

 
 
Next,  navigate  to  Media  Resources  !  Media  Resource  Group  List  and  click  the  Add  New  button  to  
create  the  MRGL.  Remember,  this  MRGL  will  eventually  be  assigned  to  the  HQ  phones,  so  it  should  be  
named  with  that  in  mind  (e.g.  “HQ_MRGL”).  Make  sure  to  add  the  previously  created  MRG  for  the  
transcoder  before  clicking  the  Save  button  to  complete  the  configuration.  
 

 
 
   

506 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  assign  the  MRGL  to  the  HQ  phones  by  way  of  the  Device  Pool.  Navigate  to  System  !  
Device  Pool  and  click  the  Find  button.  Click  on  the  “HQ_PHONE_DP”  and  set  the  “Media  Resource  
Group  List”  parameter  to  the  “HQ_MRGL”  option.  Click  the  Save  and  Reset  buttons  to  save  and  apply  
the  configuration.  
 

 
 
Whenever  a  transcoder  is  required  to  communicate  with  an  HQ  phone,  the  transcoder  configured  on  
R1  will  be  used.  Of  course,  the  show sccp connections  command  can  be  used  to  verify  the  
active  transcoding  session.  
 
   

507 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 30.7 Configure  all  devices  at  the  HQ  site  to  receive  Unicast  MOH  from  the  Publisher  MOH  
server  with  the  Subscriber  MOH  server  acting  as  a  backup  MOH  server  for  the  HQ  
devices.    
 
MoH  does  not  require  the  DSP  resources  available  in  an  IOS  router  to  operate.  In  this  case,  we  will  use  
the  built-­‐in  IPVMS  service  in  the  CUCM  cluster  to  handle  this  feature.  The  first  step  in  configuring  MoH  
is  to  activate  the  IPVMS  service  within  Unified  Serviceability.  Once  activated,  navigate  to  Media  
Resources  !  Music  On  Hold  Server  and  click  the  Find  button.  If  the  service  was  activated  on  both  the  
Publisher  and  Subscriber  servers,  then  two  servers  will  be  displayed  in  this  list,  which  is  the  case  here.  
Since  the  names  are  a  bit  cryptic,  you  can  verify  the  server  by  using  the  IP  address  field  on  the  far  right  
of  the  list.  
 

 
 
Since  the  question  states  that  we  must  configure  unicast  MoH  with  the  Publisher  acting  as  the  primary  
server  and  the  Subscriber  server  acting  as  backup,  we  must  configure  two  MRGs.  If  each  server  was  
configured  within  the  same  MRG,  the  connections  would  utilize  a  “round  robin”  selection  process  for  
the  two  devices  rather  than  utilizing  a  “primary/backup”  model  of  redundancy.    
 
Create  the  MRGs  by  navigating  to  Media  Resources  !  Media  Resource  Group  and  clicking  the  Add  
New  button.  Enter  a  descriptive  “Name”  for  the  group  (e.g.  “HQ_MOH_PUB_MRG”)  and  select  
“MOH_2  (MOH)”  that  was  found  in  the  list  above.  Click  the  Save  button  when  complete.  
 

 
 
   

508 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Do  the  same  for  the  Subscriber  server.  


 

 
 
Next,  navigate  to  Media  Resources  !  Media  Resource  Group  List  and  click  the  Find  button.  Click  on  
the  “HQ_MRGL”  that  was  created  and  assigned  to  HQ  phones  in  the  previous  task.  Add  both  newly  
created  MRGs  to  this  list.  Click  the  Save  button  when  complete.  
 

 
 
Test  the  configuration  by  calling  between  HQ  phones  and  placing  the  call  on  hold.  You  should  hear  the  
hold  music  that  is  configured  within  the  Media  Resources  !  Music  On  Hold  Audio  Source  
configuration.  
   

509 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  verify  the  streaming  is  happening  using  unicast,  SSH  into  the  Subscriber  server  on  the  HQ  CUCM  
cluster.  Issue  the  show perf query class “Cisco MOH Device”  command  to  view  the  
status.  
 
HQ  CUCM  Subscriber  
admin:show perf query class "Cisco MOH Device"
==>query class :

- Perf class (Cisco MOH Device) has instances and values:


MOH_2 -> MOHHighestActiveResources = 1
MOH_2 -> MOHMulticastResourceActive = 0
MOH_2 -> MOHMulticastResourceAvailable = 250000
MOH_2 -> MOHOutOfResources = 0
MOH_2 -> MOHTotalMulticastResources = 250000
MOH_2 -> MOHTotalUnicastResources = 250
MOH_2 -> MOHUnicastResourceActive = 1
MOH_2 -> MOHUnicastResourceAvailable = 249
MOH_3 -> MOHHighestActiveResources = 0
MOH_3 -> MOHMulticastResourceActive = 0
MOH_3 -> MOHMulticastResourceAvailable = 250000
MOH_3 -> MOHOutOfResources = 0
MOH_3 -> MOHTotalMulticastResources = 250000
MOH_3 -> MOHTotalUnicastResources = 250
MOH_3 -> MOHUnicastResourceActive = 0
MOH_3 -> MOHUnicastResourceAvailable = 250
 
As  you  can  see  from  the  above,  there  is  currently  one  unicast  resource  active  on  the  Publisher  server.  
 
   

510 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 30.8 Ensure  that  all  SB  devices  (including  PSTN  callers)  receive  multicast  music  on  hold.  
The  Multicast  IP  Address  used  should  be  239.1.1.254  on  port  16384.  The  SB  site  
must  be  receiving  hold  music  from  the  SB  router  flash  memory  (use  default  MoH  
file).  Test  this  task  by  placing  a  PSTN  caller  calling  through  the  SB  gateway  on  hold.    
 
This  task  is  asking  us  to  configure  multicast  MoH  on  the  SB  CUCM  cluster  and  stream  it  from  the  R2  
router’s  flash  directory.  The  first  step  to  completing  this  configuration  is  to  navigate  to  Media  
Resources  !  Music  On  Hold  Server  and  click  on  the  “MOH_2”  server  to  configure  MoH  on  the  
Publisher  server.  Within  the  “Music  On  Hold  (MOH)  Server  Configuration”  page  under  the  “Multi-­‐cast  
Audio  Source  Information”  section,  click  the  checkbox  for  the  “Enable  Multi-­‐cast  Audio  Sources  on  this  
MOH  Server”  setting.  Also,  enter  the  “Base  Multi-­‐cast  IP  Address”  as  “239.1.1.254”  and  the  “Base  
Multi-­‐cast  Port  Number”  as  “16384”.  It  is  important  to  set  the  “Increment  Multi-­‐cast  on”  radio  button  
to  “IP  Address”,  since  phones  can  sometimes  have  issues  with  receiving  the  stream  on  a  port  other  
than  16384.    
 

 
 
We  are  entering  a  “Base”  IP  address  and  port  number  because  this  information  is  subject  to  change  
based  on  the  codec  that  is  used  to  communicate  with  the  MoH  server.  For  G.711,  the  configured  
information  will  serve  as  the  connection  information  for  the  stream,  but  for  other  codecs,  a  different  IP  
address  would  be  used.  For  this  reason,  we  should  always  configure  the  Region  relationship  to  the  
MoH  server  using  the  G.711  codec.  The  best  way  to  do  this  is  create  a  separate  Device  Pool  (e.g.  
“MOH_DP”)  and  assign  a  specific  Region  (e.g.  “MOH_REG”).  Every  other  Region  in  the  system  should  
communicate  with  this  Region  using  G.711  as  shown  in  the  below  example.  
 

 
 
   

511 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  apply  the  correct  Region  setting,  don’t  forget  to  assign  the  “MOH_DP”  to  the  MOH  server  
configuration.  Click  the  Save  button  when  complete.  
 

 
 
Next,  we  must  configure  the  audio  source  for  multicast  by  navigating  to  Media  Resources  !  Music  On  
Hold  Audio  Source  and  clicking  on  the  “1”  link  corresponding  to  the  first  audio  source  in  the  system.  
 

 
 
Ensure  that  the  “Allow  Multicasting”  checkbox  is  selected  and  click  the  Save  button  to  complete  the  
configuration.  
 

 
 
Next,  go  back  to  the  MoH  Server  Configuration  page  by  navigating  to  Media  Resources  !  Music  On  
Hold  Server  and  clicking  on  the  “MOH_2”  server.  Scroll  down  to  the  “Selected  Multi-­‐cast  Audio  
Sources”  section  and  ensure  that  the  “Max  Hops”  parameter  is  set  to  the  lowest  value  possible  (1).  
Since  we  would  like  to  stream  the  multicast  MoH  from  the  router  flash,  we  don’t  want  the  server  MoH  
traffic  to  overlap.  
 

 
 
   

512 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  create  an  MRG/MRGL  to  contain  the  MoH  server  and  assign  it  to  the  phones  at  SB.  
Navigate  to  Media  Resources  !  Media  Resource  Group  and  click  the  Add  New  button.  Enter  a  
descriptive  “Name”  for  the  group  (e.g.  “SB_MOH_MRG”)  and  select  “MOH_2  (MOH)”  that  was  
configured  above.  Lastly,  click  the  “Use  Multi-­‐cast  for  MOH  Audio  (If  at  least  one  multi-­‐cast  MOH  
resource  is  available)”  checkbox  to  enable  the  MRG  for  multicast  MoH.  Click  the  Save  button  when  
complete.  
 

 
 
Next,  navigate  to  Media  Resources  !  Media  Resource  Group  List  and  click  the  Find  button.  Click  on  
the  “SB_MRGL”  that  was  created  and  assigned  to  SB  phones  in  one  of  the  previous  tasks.  Add  the  
newly  created  MRG  to  this  list.  Click  the  Save  button  when  complete.  
 

 
 
Next,  we  must  configure  the  R2  router  to  stream  the  multicast  MoH  from  the  router  flash.  This  task  can  
be  completed  using  either  telephony-service  or  call-manager-fallback.  Before  we  
begin,  however,  we  should  make  sure  that  a  MoH  file  exists  within  the  R2  flash  directory.  
 
R2  
R2#sh flash | i music-
327 496521 Jul 9 2014 12:46:30 -05:00 music-on-hold.au

   

513 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  this  case,  the  “music-­‐on-­‐hold.au”  file  exists  within  the  root  directory  of  flash  on  the  R2  router.  This  
means  that  it  can  now  be  utilized  in  the  MoH  configuration.  In  this  case,  let’s  use  the  call-
manager-fallback  option.  Use  the  moh  command  to  specify  the  name  of  the  file  and  the  
multicast moh  command  to  specify  the  multicast  IP  address  and  port  number  
(239.1.1.254/16384).  We  should  also  specify  the  IP  addresses  of  the  interfaces  on  which  the  multicast  
traffic  should  be  sent  after  the  route  keyword.  
 
R2  
R2(config)#call-manager-fallback
R2(config-cm-fallback)#moh music-on-hold.au
R2(config-cm-fallback)#multicast moh 239.1.1.254 port 16384 route 10.10.2.2 10.10.21.1
 
Next,  even  though  MGCP  is  not  in  use  on  the  router,  we  must  enter  the  ccm-manager music-on-
hold  command  on  R2.  This  will  ensure  that  multicast  MoH  is  supported  for  PSTN  calls.  
 
R2  
R2(config)#ccm-manager music-on-hold
 
Test  the  configuration  by  calling  between  SB  phones  and  placing  the  call  on  hold.  You  should  hear  the  
hold  music  that  is  configured  on  the  CUCM  system.  To  verify  the  streaming  is  happening  using  
multicast,  SSH  into  the  Publisher  server  on  the  SB  CUCM  cluster.  Issue  the  show perf query
class “Cisco MOH Device”  command  to  view  the  status.  
 
SB  CUCM  Publisher  
admin:show perf query class "Cisco MOH Device"
==>query class :

- Perf class (Cisco MOH Device) has instances and values:


MOH_2 -> MOHHighestActiveResources = 1
MOH_2 -> MOHMulticastResourceActive = 1
MOH_2 -> MOHMulticastResourceAvailable = 249999
MOH_2 -> MOHOutOfResources = 0
MOH_2 -> MOHTotalMulticastResources = 250000
MOH_2 -> MOHTotalUnicastResources = 250
MOH_2 -> MOHUnicastResourceActive = 0
MOH_2 -> MOHUnicastResourceAvailable = 250
 
As  you  can  see  from  the  above,  there  is  currently  one  multicast  resource  active  on  the  Publisher  server.  
 
When  placing  a  PSTN  caller  on  hold,  you  can  also  enter  the  show ccm-manager music-on-
hold command  to  verify  the  configuration.  
 
R2  
R2#sh ccm-manager music-on-hold
Current active multicast sessions : 1
Multicast RTP port Packets Call Codec Incoming
Address number in/out id Interface
===================================================================
239.1.1.254 16384 196/196 9355 g711ulaw Vl21
 

514 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 31: CUCM Video Conferencing


Task 31.1 Create  a  SIP  trunk  on  the  HQ  cluster  to  the  BB  CUCM  cluster  at  IP  address  
10.10.254.11.  
 
The  first  step  to  creating  a  videoconference  is  to  configure  the  point-­‐to-­‐point  communication  between  
endpoints  in  the  conference.  In  the  first  task,  we  must  configure  the  link  between  the  HQ  and  BB  
CUCM  clusters  in  order  to  support  video  calls  between  endpoints.  In  this  case,  the  BB  CUCM  cluster  is  
already  configured  to  accept  a  connection  from  a  SIP  trunk  on  HQ,  so  all  we  need  to  do  is  create  the  SIP  
trunk  on  the  HQ  CUCM  cluster.    
 
Navigate  to  Device  !  Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  Type”  as  “SIP  Trunk”,  
leave  the  “Trunk  Service  Type”  as  “None  (Default)”,  and  click  the  Next  button.  
 

 
 
Enter  a  “Device  Name”  for  the  SIP  trunk  (e.g.  “BB_SIP_TRUNK”)  and  select  an  appropriate  “Device  
Pool”  from  the  dropdown  list  (e.g.  “BB_SIP_DP”).  Once  again,  a  Device  Pool  specifically  created  for  this  
trunk  provides  the  maximum  flexibility.  
 

 
 
Next,  under  the  “Inbound  Calls”  section,  select  an  appropriate  “Calling  Search  Space”  (e.g.  
“GW_TRUNK_CSS”)  to  ensure  that  any  inbound  calls  for  this  SIP  trunk  are  routed  properly  to  the  
internal  DNs  in  the  system.  
 

 
 
   

515 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “SIP  Information”  section,  specify  the  IP  address  to  which  the  SIP  trunk  should  
connect.  This  was  specified  in  the  task  as  10.10.254.11.    
 

 
 
Next,  select  the  “Non  Secure  SIP  Trunk  Profile”  and  “Standard  SIP  Profile”  for  the  “SIP  Trunk  Security  
Profile”  and  “SIP  Profile”  parameters.  
 

 
 
Click  the  Save  and  Reset  buttons  when  complete.    
 
   

516 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 31.2 Ensure  that  users  at  HQ  can  dial  a  prefix  of  8,  followed  by  the  11-­‐digit  HQ  PSTN  
phone  number  (14086131218)  to  reach  the  video  capabilities  of  the  PSTN  phone.  
Ensure  that  the  BB  cluster  only  receives  an  11-­‐digit  DNIS.  
 
Now  that  the  SIP  trunk  is  created,  we  must  create  a  Route  Group,  a  Route  List,  and  a  Route  Pattern  to  
route  video  calls  across  the  SIP  trunk  when  HQ  users  dial  “814086131218”.    
 
Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Group  and  click  the  Add  New  button  to  create  a  new  
Route  Group.  Enter  a  descriptive  “Route  Group  Name”  (e.g.  “BB_SIP_RG”)  and  select  the  
“BB_SIP_TRUNK”  SIP  ICT  to  be  a  member  of  the  Route  Group.  
 

 
 
Next,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  List  and  click  the  Add  New  button  to  create  a  
new  Route  List.  Enter  a  descriptive  “Name”  for  the  Route  List  (e.g.  “BB_SIP_RL”)  and  select  the  “Cisco  
Unified  Communications  Manager  Group”  from  the  dropdown  box.  Click  the  Save  button  to  move  to  
the  next  configuration  page.  
 

 
 
   

517 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Add  the  “BB_SIP_RG”  to  the  Route  List  and  click  the  Save  button.  
 

 
 
Next,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  Enter  
the  “Route  Pattern”  as  “8.14086131218”  and  place  it  in  a  Partition  that  is  accessible  by  HQ  phones  (e.g.  
“BB_PT”).  
 

 
 
Next,  select  the  Route  List  that  was  previously  created  to  access  the  BB  SIP  ICT  (e.g.  “BB_SIP_RL”)  from  
the  “Gateway/Route  List”  dropdown  box.  
 

 
 
Finally,  under  the  “Called  Party  Transformations”  section,  make  sure  that  the  “PreDot”  option  is  
selected  for  the  “Discard  Digits”  field  so  the  leading  “8”  can  be  stripped  from  the  dialed  number.  
 

 
 
Click  the  Save  button  when  complete.    
 
To  test  the  configuration,  place  a  call  from  HQ  Phone  1  to  the  BB  PSTN  phone  by  dialing  
814086131218.  You  should  now  have  an  active  video  call  between  clusters.  If  the  call  did  not  work,  no  
video  is  being  displayed,  or  you  would  just  like  to  examine  the  call  flow  (highly  recommended),  open  
an  RTMT  session  and  check  it  out.    
 
Connect  to  HQ  Test  PC  1  with  Remote  Desktop  and  open  an  RTMT  session  to  10.10.13.11.  Click  the  
“CallManager  Summary”  tab  and  locate  the  “Real  Time  Data”  link  under  the  “Session  Trace  Log  View”  
section.  
 

 
 
518 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

From  there,  enter  the  “Start  Time”  that  the  log  collection  should  begin,  along  with  a  “Duration”  to  
provide  the  range.  Make  sure  to  set  the  “Time  Zone”  correctly  as  well.  Click  the  Run  button  when  
ready  to  perform  the  search.  
 

 
 
In  the  above  example,  we  have  a  result  for  calls  that  were  placed  during  the  specified  time  range.  
Double  click  it  to  view  a  diagram  of  the  call  flow.  
 

 
 
At  this  point,  you  can  click  on  any  one  of  the  messages  to  get  more  detail  about  that  message.  For  
example,  let’s  click  on  the  “[7]:  200  OK”  message  to  view  the  details.  

519 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
We  can  see  from  the  above  that  this  “200  OK”  message  contains  an  SDP  offering  the  use  of  G.729  as  
the  audio  codec  and  H.264  as  the  video  codec  (using  payload  type  97  or  126).  In  the  ACK  message  sent  
in  response  by  the  HQ  CUCM  cluster,  we  should  see  a  much  smaller  SDP,  with  the  codecs  actually  being  
used  in  the  session.  Based  on  the  below,  G.729/H.264  (payload  type  126)  was  used.  
 

 
 
   

520 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 31.3 Ensure  that  the  video  call  between  HQ  and  SC  (both  signaling  and  media)  flows  
through  the  CUBE  (R1).    
 
In  this  case,  we  are  tasked  with  configuring  call  routing  between  the  HQ  CUCM  cluster  and  the  SC  
CUCME.  We  must  use  the  CUBE  on  R1  to  accomplish  this.  The  question  states  that  the  signaling  and  
media  should  flow  through  the  CUBE.  In  this  case,  this  means  that  we  do  not  have  to  configure  
anything  in  addition  to  what  is  already  there,  since  “media  flow  through”  is  enabled  by  default  on  the  
CUBE.  To  configure  call  routing,  we  must  create  a  Route  Pattern  that  utilizes  the  existing  Route  
List/Route  Group/SIP  Trunk  that  was  created  to  CUBE  in  a  previous  lab.  Navigate  to  Call  Routing  !  
Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  Enter  the  “Route  Pattern”  as  “3XXX”  and  
select  a  Partition  that  is  accessible  by  HQ  phones  (e.g.  “SC_PT”).  Next,  select  the  “CUBE_SIP_RL”  from  
the  “Gateway/Route  List”  dropdown  box  and  click  the  Save  button  to  complete  the  configuration.  
 

 
 
Next,  we  must  configure  the  CUBE  on  R1  to  support  calls  to  SC.  In  the  previous  lab,  a  dial-peer  was  
created  on  CUBE  for  this  reason,  so  we  can  take  advantage  of  that  configuration  for  the  call  flow  
between  HQ  and  SC  as  well.  The  configuration  is  shown  below.  
 
R1  
R1#sh run | sec voice service
voice service voip
no ip address trusted authenticate
mode border-element
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
bind control source-interface GigabitEthernet0/0.11
bind media source-interface GigabitEthernet0/0.11
sip-profiles 2

R1#sh run | sec dial-peer voice 3000


dial-peer voice 3000 voip
destination-pattern 3...$
session protocol sipv2
session target ipv4:10.10.31.1
incoming called-number 3...$
no vad
 

521 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  make  a  test  call  between  HQ  Phone  1  and  SC  Phone  2.  The  phone  rings  and  the  call  is  routed  
successfully,  but  no  video  appears.  The  first  thing  we  should  do  is  answer  the  obvious  question:  Is  
video  enabled  on  each  phone?    
 
To  verify  within  the  HQ  CUCM  cluster,  navigate  to  Device  !  Phone  and  click  on  HQ  Phone  1.  Under  the  
“Product  Specific  Configuration  Layout”  section,  ensure  that  the  “Cisco  Camera”  and  “Video  
Capabilities”  parameters  are  set  to  “Enabled”.    
 

 
 
Next,  check  the  R3  router  for  any  video  configuration.  
 
R3  
R3#sh run | sec voice register
voice register global
mode cme
source-address 10.10.31.1 port 5060
timeouts interdigit 5
max-dn 10
max-pool 5
timezone 23
time-format 24
date-format D/M/Y
url authentication http://10.10.31.1/CCMCIP/authenticate.asp PVUSER ipexpert
tftp-path flash:
create profile sync 018903447582005A
network-locale DE
user-locale DE
ntp-server 10.10.1.1 mode directedbroadcast
voice register dn 1
number 3002
call-forward b2bua noan 3001 timeout 10
allow watch
name SC Phone 2
voice register template 1
softkeys hold Resume
voice register pool 1
busy-trigger-per-button 4
id mac 1C1D.86C5.8106
type 9971
number 1 dn 1
template 1
presence call-list
dtmf-relay rtp-nte
voice-class codec 1
username scp2 password cisco
description +49894443002
speed-dial 1 3001 label "SC Phone 1"
paging-dn 8
blf-speed-dial 1 3001 label "SC Phone 1 BLF"

In  this  case,  video  has  not  been  enabled  either  within  voice register global,  the  voice
register template,  or  the  voice register pool.  In  this  case,  let’s  configure  it  globally  for  
all  SIP  phones  on  CUCME.  Don’t  forget  to  issue  the  create profile  command  when  complete.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#video
R3(config-register-global)#camera
R3(config-register-global)#create profile
R3(config-register-global)#reset

522 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Once  the  phone  is  registered  again  at  SC,  make  another  test  call.  This  time,  video  works  between  HQ  
Phone  1  and  SC  Phone  2.    
 
Once  again,  let’s  analyze  the  debugs  to  understand  the  call  flow.  To  debug  the  call,  we  can  use  the  
“holy  grail”  of  all  debug  commands—debug ccsip messages.  Before  we  do  that,  however,  we  
must  first  make  sure  to  log  all  of  the  debug  output  to  the  buffer  instead  of  the  console.  This  is  because  
SIP  can  get  very  “chatty”  and  we  don’t  want  to  lose  access  to  our  console  for  an  extended  period.  
Make  sure  to  set  the  log  level  to  “debugging”  and  the  buffer  size  to  a  large  number.  This  should  be  
completed  on  both  R1  (CUBE)  and  R3  (CUCME).  
 
R1  
R1(config)#no logging console
R1(config)#logging buffered debugging
R1(config)#logging buffered 40000000
 
R3  
R3(config)#no logging console
R3(config)#logging buffered debugging
R3(config)#logging buffered 40000000
 
Next,  enter  the  debug ccsip messages  command  on  both  R1  and  R3  and  make  a  test  call.  Enter  
the  show logging  command  to  view  the  debug  output.  On  the  CUBE,  the  initial  INVITE  message  is  
sent  from  the  HQ  CUCM  cluster  and  then  forwarded  to  the  R3  router.  
 
R1  
Nov 21 02:48:24.153: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:3002@10.10.11.1:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.13.12:5060;branch=z9hG4bK864d49d2c9f4
From: "HQ Phone 1" <sip:+14082221001@10.10.13.12>;tag=96231~50386a8c-f53c-499c-b7b5-9b86cf06aed7-
33685016
To: <sip:3002@10.10.11.1>
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: db489180-46e1a7f8-77aa-c0d0a0a@10.10.13.12
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180

Allow-Events: presence, kpml


Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.10.13.12:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 3678966144-0000065536-0000000145-0202181130
Session-Expires: 1800
P-Asserted-Identity: "HQ Phone 1" <sip:+14082221001@10.10.13.12>
Remote-Party-ID: "HQ Phone 1" <sip:+14082221001@10.10.13.12>;party=calling;screen=yes;privacy=off
Contact: <sip:+14082221001@10.10.13.12:5060;transport=tcp>;video;audio
Max-Forwards: 69
Content-Length: 0

Nov 21 02:48:24.165: //662/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Sent:
INVITE sip:3002@10.10.31.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
Remote-Party-ID: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;party=calling;screen=yes;privacy=off
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1

523 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3678966144-0000065536-0000000145-0202181130
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE


Timestamp: 1416538104
Contact: <sip:+14082221001@10.10.11.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Length: 0
 
R3  receives  the  INVITE  message  from  CUBE  and  forwards  it  to  CUCME  SIP  Phone  (SC  Phone  2).  
 
R3  
Nov 21 02:48:24.169: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:3002@10.10.31.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
Remote-Party-ID: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;party=calling;screen=yes;privacy=off
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3678966144-0000065536-0000000145-0202181130
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1416538104
Contact: <sip:+14082221001@10.10.11.1:5060>
Expires: 180

Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Length: 0

Nov 21 02:48:24.181: //16546/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Sent:
INVITE sip:3002@10.10.31.36:51799 SIP/2.0
Via: SIP/2.0/TCP 10.10.31.1:5060;branch=z9hG4bK81F16A8
Remote-Party-ID: "HQ Phone 1" <sip:+14082221001@10.10.31.1>;party=calling;screen=yes;privacy=off
From: "HQ Phone 1" <sip:+14082221001@10.10.31.1>;tag=C2829208-ACC
To: <sip:3002@10.10.31.36>
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B231EC2D-705F11E4-83248F78-E38E18A3@10.10.31.1
Supported: timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 3678966144-0000065536-0000000145-0202181130
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1416538104
Contact: <sip:+14082221001@10.10.31.1:5060;transport=tcp>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 67
Session-Expires: 1800
Content-Length: 0
 

524 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

As  you  can  see,  this  call  is  being  set  up  using  “Delayed  Offer”  (DO)  and  not  “Early  Offer”  (EO)  since  
there  is  no  SDP  contained  within  the  initial  INVITE  message  (Content-Length: 0).  
 
Next,  a  100  TRYING  message  is  sent  from  R3  to  CUBE  and  received  at  SC  Phone  2  from  R3.  
 
R3  
Nov 21 02:48:24.181: //16545/DB4891800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Timestamp: 1416538104
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Content-Length: 0

Nov 21 02:48:24.277: //16546/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Received:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.10.31.1:5060;branch=z9hG4bK81F16A8
From: "HQ Phone 1" <sip:+14082221001@10.10.31.1>;tag=C2829208-ACC
To: <sip:3002@10.10.31.36>
Call-ID: B231EC2D-705F11E4-83248F78-E38E18A3@10.10.31.1
Date: Fri, 21 Nov 2014 02:48:23 GMT
CSeq: 101 INVITE
Server: Cisco-CP9971/9.4.1
Contact: <sip:8DAB8654-2359@10.10.31.36:51799;transport=tcp>;video
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-
cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-
cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.0.1
Allow-Events: kpml,dialog
Content-Length: 0
 
The  CUBE  (R1)  also  sends  a  100  TRYING  message  to  the  HQ  CUCM  cluster  and  receives  one  from  R3.  
 
R1  
Nov 21 02:48:24.161: //661/DB4891800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.10.13.12:5060;branch=z9hG4bK864d49d2c9f4
From: "HQ Phone 1" <sip:+14082221001@10.10.13.12>;tag=96231~50386a8c-f53c-499c-b7b5-9b86cf06aed7-
33685016
To: <sip:3002@10.10.11.1>
Date: Fri, 21 Nov 2014 02:48:24 GMT

Call-ID: db489180-46e1a7f8-77aa-c0d0a0a@10.10.13.12
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M3
Content-Length: 0

Nov 21 02:48:24.185: //662/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Timestamp: 1416538104

525 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

CSeq: 101 INVITE


Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M4

Content-Length: 0

Next,  R3  receives  a  180  RINGING  message  from  SC  Phone  2  and  forwards  it  along  to  CUBE.  
 
R3  
Nov 21 02:48:24.365: //16546/DB4891800000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.10.31.1:5060;branch=z9hG4bK81F16A8
From: "HQ Phone 1" <sip:+14082221001@10.10.31.1>;tag=C2829208-ACC
To: <sip:3002@10.10.31.36>;tag=1c1d86c53ebf0055572729f8-18a74c6b
Call-ID: B231EC2D-705F11E4-83248F78-E38E18A3@10.10.31.1
Date: Fri, 21 Nov 2014 02:48:23 GMT
CSeq: 101 INVITE
Server: Cisco-CP9971/9.4.1
Contact: <sip:8DAB8654-2359@10.10.31.36:51799;transport=tcp>;video
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.31.1>;party=called;id-
type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-
cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-
cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.0.1
Allow-Events: kpml,dialog
Content-Length: 0

Nov 21 02:48:24.365: //16545/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>;tag=C28292C4-5F
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Timestamp: 1416538104
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.31.1>;party=called;screen=yes;privacy=off
Contact: <sip:8DAB8654-2359@10.10.31.1:5060>
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Content-Length: 0
 
CUBE  then  receives  the  message  and  forwards  it  to  the  HQ  CUCM  cluster.  
 
R1  
Nov 21 02:48:24.373: //662/DB4891800000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>;tag=C28292C4-5F
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Timestamp: 1416538104
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.31.1>;party=called;screen=yes;privacy=off
Contact: <sip:8DAB8654-2359@10.10.31.1:5060>
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Content-Length: 0

Nov 21 02:48:24.377: //661/DB4891800000/SIP/Msg/ccsipDisplayMsg:

526 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.10.13.12:5060;branch=z9hG4bK864d49d2c9f4
From: "HQ Phone 1" <sip:+14082221001@10.10.13.12>;tag=96231~50386a8c-f53c-499c-b7b5-9b86cf06aed7-
33685016
To: <sip:3002@10.10.11.1>;tag=E7E58A28-1B74
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: db489180-46e1a7f8-77aa-c0d0a0a@10.10.13.12
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.11.1>;party=called;screen=yes;privacy=off
Contact: <sip:8DAB8654-2359@10.10.11.1:5060;transport=tcp>
Server: Cisco-SIPGateway/IOS-15.2.4.M3
Content-Length: 0

Next,  a  200  OK  message  is  received  from  SC  Phone  2  and  is  forwarded  on  to  R3.  Notice  that  this  
message  contains  an  SDP.  This,  of  course,  contains  information  on  the  codecs  that  should  be  used  for  
the  session.  Note  the  RTP  payload  difference  in  the  SDP  messages  on  R3  (bolded).  This  is  because  IOS  
uses  a  default  RTP  payload  type  of  “119”  for  the  H.264  codec,  while  9971  phones  use  “97”.
 
R3  
Nov 21 02:48:25.573: //16546/DB4891800000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.31.1:5060;branch=z9hG4bK81F16A8

From: "HQ Phone 1" <sip:+14082221001@10.10.31.1>;tag=C2829208-ACC


To: <sip:3002@10.10.31.36>;tag=1c1d86c53ebf0055572729f8-18a74c6b
Call-ID: B231EC2D-705F11E4-83248F78-E38E18A3@10.10.31.1
Date: Fri, 21 Nov 2014 02:48:24 GMT
CSeq: 101 INVITE
Server: Cisco-CP9971/9.4.1
Contact: <sip:8DAB8654-2359@10.10.31.36:51799;transport=tcp>;video
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.31.1>;party=called;id-
type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-
cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-
cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.0.1
Allow-Events: kpml,dialog
Content-Length: 626
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 17351 0 IN IP4 10.10.31.36
s=SIP Call

t=0 0
m=audio 17488 RTP/AVP 0 8 18 102 9 116 124 101
c=IN IP4 10.10.31.36
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:102 L16/16000
a=rtpmap:9 G722/8000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:124 ISAC/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 27908 RTP/AVP 97
c=IN IP4 10.10.31.36
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E;packetization-mode=0;level-asymmetry-allowed=1

527 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

a=imageattr:* recv [x=640,y=480,q=0.50]


a=sendrecv

Nov 21 02:48:25.581: //16545/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>;tag=C28292C4-5F
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Timestamp: 1416538104
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.31.1>;party=called;screen=yes;privacy=off
Contact: <sip:3002@10.10.31.1:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Supported: timer
Content-Type: application/sdp

Content-Disposition: session;handling=required
Content-Length: 414

v=0
o=CiscoSystemsSIP-GW-UserAgent 6343 2155 IN IP4 10.10.31.1
s=SIP Call
c=IN IP4 10.10.31.1
t=0 0
m=audio 16976 RTP/AVP 0 18 116
c=IN IP4 10.10.31.1
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
m=video 16982 RTP/AVP 119
c=IN IP4 10.10.31.1
b=TIAS:1000000
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=42801E;packetization-mode=0
 
The  CUBE  receives  the  200  OK  message  from  R3  at  this  point.  Notice  that  the  payload  types  are  both  
the  same  in  this  case  (119)  since  the  both  endpoints  (R3  and  R1)  are  IOS  devices.  
 
R1  
Nov 21 02:48:25.593: //662/DB4891800000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F0DC1
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>;tag=C28292C4-5F
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Timestamp: 1416538104
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.31.1>;party=called;screen=yes;privacy=off
Contact: <sip:3002@10.10.31.1:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M4
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 414

528 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

v=0
o=CiscoSystemsSIP-GW-UserAgent 6343 2155 IN IP4 10.10.31.1
s=SIP Call
c=IN IP4 10.10.31.1
t=0 0
m=audio 16976 RTP/AVP 0 18 116
c=IN IP4 10.10.31.1
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
m=video 16982 RTP/AVP 119
c=IN IP4 10.10.31.1
b=TIAS:1000000
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=42801E;packetization-mode=0

Nov 21 02:48:25.601: //661/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.13.12:5060;branch=z9hG4bK864d49d2c9f4

From: "HQ Phone 1" <sip:+14082221001@10.10.13.12>;tag=96231~50386a8c-f53c-499c-b7b5-9b86cf06aed7-


33685016
To: <sip:3002@10.10.11.1>;tag=E7E58A28-1B74
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: db489180-46e1a7f8-77aa-c0d0a0a@10.10.13.12
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "SC Phone 2" <sip:3002@10.10.11.1>;party=called;screen=yes;privacy=off
Contact: <sip:3002@10.10.11.1:5060;transport=tcp>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M3
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 342

v=0
o=CiscoSystemsSIP-GW-UserAgent 3016 9343 IN IP4 10.10.11.1

s=SIP Call
c=IN IP4 10.10.11.1
t=0 0
m=audio 17238 RTP/AVP 18
c=IN IP4 10.10.11.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
m=video 17244 RTP/AVP 119
c=IN IP4 10.10.11.1
b=TIAS:1000000
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=42801E;packetization-mode=0

 
Next,  an  ACK  (with  SDP)  message  is  received  from  the  HQ  CUCM  cluster  on  the  CUBE  to  complete  the  
media  negotiation.  Once  again,  notice  the  difference  in  RTP  payload  types  for  the  H.264  codec.  
 
R1  
Nov 21 02:48:25.613: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:3002@10.10.11.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.13.12:5060;branch=z9hG4bK864f1f57ac01

529 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

From: "HQ Phone 1" <sip:+14082221001@10.10.13.12>;tag=96231~50386a8c-f53c-499c-b7b5-9b86cf06aed7-


33685016
To: <sip:3002@10.10.11.1>;tag=E7E58A28-1B74
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: db489180-46e1a7f8-77aa-c0d0a0a@10.10.13.12

Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp
Content-Length: 369

v=0
o=CiscoSystemsCCM-SIP 96231 1 IN IP4 10.10.13.12
s=SIP Call
c=IN IP4 10.10.11.13
b=TIAS:1008000
b=AS:1008
t=0 0
m=audio 17726 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
m=video 20968 RTP/AVP 97
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E;packetization-mode=0;level-asymmetry-allowed=1
a=content:main

Nov 21 02:48:25.617: //662/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Sent:
ACK sip:3002@10.10.31.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F1B2F
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>;tag=C28292C4-5F
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 341

v=0
o=CiscoSystemsSIP-GW-UserAgent 716 5214 IN IP4 10.10.11.1
s=SIP Call
c=IN IP4 10.10.11.1
t=0 0
m=audio 17240 RTP/AVP 18
c=IN IP4 10.10.11.1

a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
m=video 17242 RTP/AVP 119
c=IN IP4 10.10.11.1
b=TIAS:1000000
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=42801E;packetization-mode=0

Finally,  the  ACK  message  is  received  on  R3  and  sent  to  SC  Phone  2  to  complete  the  call  setup.  
 
R3  
Nov 21 02:48:25.625: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:3002@10.10.31.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.11.1:5060;branch=z9hG4bK4F1B2F
From: "HQ Phone 1" <sip:+14082221001@10.10.11.1>;tag=E7E58954-154B
To: <sip:3002@10.10.31.1>;tag=C28292C4-5F
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B22F66B1-705F11E4-839CC04C-8C470642@10.10.11.1

530 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 341

v=0
o=CiscoSystemsSIP-GW-UserAgent 716 5214 IN IP4 10.10.11.1
s=SIP Call
c=IN IP4 10.10.11.1
t=0 0
m=audio 17240 RTP/AVP 18
c=IN IP4 10.10.11.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
m=video 17242 RTP/AVP 119

c=IN IP4 10.10.11.1


b=TIAS:1000000
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=42801E;packetization-mode=0

Nov 21 02:48:25.629: //16546/DB4891800000/SIP/Msg/ccsipDisplayMsg:


Sent:
ACK sip:8DAB8654-2359@10.10.31.36:51799;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.31.1:5060;branch=z9hG4bK820FF
From: "HQ Phone 1" <sip:+14082221001@10.10.31.1>;tag=C2829208-ACC
To: <sip:3002@10.10.31.36>;tag=1c1d86c53ebf0055572729f8-18a74c6b
Date: Fri, 21 Nov 2014 02:48:24 GMT
Call-ID: B231EC2D-705F11E4-83248F78-E38E18A3@10.10.31.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 406

v=0
o=CiscoSystemsSIP-GW-UserAgent 780 8080 IN IP4 10.10.31.1
s=SIP Call

c=IN IP4 10.10.31.1


t=0 0
m=audio 16978 RTP/AVP 18 101
c=IN IP4 10.10.31.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 16980 RTP/AVP 97
c=IN IP4 10.10.31.1
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E;packetization-mode=0
 
What  we  have  discovered  is  that  SC  Phone  2  is  sending  H.264  video  using  RTP  payload  type  97,  but  is  
receiving  it  using  RTP  payload  type  119.  HQ  Phone  1  is  doing  the  same.  This  has  the  potential  to  
introduce  issues  into  the  video  network,  so  make  sure  to  pay  attention  to  the  payload  types  that  are  
being  used,  especially  in  troubleshooting  one-­‐way  video  issues.  
 
   

531 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 31.4 Create  a  videoconference  bridge  on  R1  to  support  videoconferences  for  HQ,  SC,  and  
PSTN  users.    
 
Now  that  both  video  call  flows  are  configured  and  tested,  we  are  ready  to  create  the  videoconference  
bridge  on  R1.  First,  we  must  configure  the  voice-card  on  R1  to  support  video  traffic  by  entering  the  
voice-service dsp-reservation  command.  This  command  is  necessary  because  it  instructs  
the  router  to  reserve  a  percentage  of  its  hardware  resources  (PVDM  modules)  for  voice  traffic.  All  
remaining  traffic  will  be  allocated  to  video  services.  In  the  below  configuration,  90%  of  the  PVDM  
resources  on  the  router  have  been  allocated  to  support  video.  
 
R1  
R1(config)#voice-card 0
R1(config-voicecard)#voice-service dsp-reservation 10
 
Now  the  dspfarm profile  for  the  videoconference  can  be  created.  The  first  step  is  to  define  the  
type  of  videoconference  bridge  that  should  be  created—either  homogeneous  or  heterogeneous.  As  
shown  in  the  configuration  below,  homogeneous  conferences  only  support  one  video  codec,  whereas  
heterogeneous  conferences  support  multiple  codecs,  as  defined  in  the  dspfarm profile.  As  you  
might  imagine,  heterogeneous  conferences  use  a  large  amount  of  resources.  A  PVDM3-­‐256  module  is  
necessary  for  most  conferences  of  this  type,  although  a  PVDM3-­‐128  can  be  used  to  support  
conferences  with  participants  using  the  same  codec,  but  different  resolutions  (using  voice-
service dsp-reservation 0).  
 
R1  
R1(config)#dspfarm profile 3 conference video ?
guaranteed-audio Guaranteed-Audio Video Conference
heterogeneous Heterogeneous Video Conference
homogeneous Homogeneous Video Conference - only allows one video codec
 
In  this  case,  the  homogeneous  videoconference  type  should  be  used,  since  the  video  codecs  and  
resolutions  will  be  the  same.  Next,  the  video  codec  must  be  defined.  In  this  case,  H.264  CIF  (Common  
Intermediate  Format)  was  configured  using  the  codec h264 cif  command,  since  that  is  the  
resolution  supported  by  9971  phones.  Next,  just  as  with  audio  conferences,  the  maximum
sessions  command  should  be  used  to  define  the  number  of  videoconference  bridges  that  can  be  
invoked.  Finally,  we  must  associate  the  SCCP  application  to  the  dspfarm profile  and  enable  it  for  
use  with  the  no shutdown  command.  
 
R1  
R1(config)#dspfarm profile 3 conference video homogeneous
R1(config-dspfarm-profile)#codec h264 cif
R1(config-dspfarm-profile)#maximum sessions 1
R1(config-dspfarm-profile)#associate application SCCP
R1(config-dspfarm-profile)#no shutdown
 
   

532 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  add  the  videoconference  bridge  to  the  SCCP  configuration  on  R1  in  order  to  allow  it  to  
register  with  the  HQ  CUCM  cluster.  
 
R1  
R1(config-voicecard)#sccp ccm group 1
R1(config-sccp-ccm)#associate profile 3 register R1-VCONF
 
Next,  on  the  HQ  CUCM  cluster,  navigate  to  Media  Resources  !  Conference  Bridge  and  click  the  Add  
New  button.  In  the  “Conference  Bridge  Type”  dropdown  box,  select  the  “Cisco  IOS  Homogeneous  
Video  Conference  Bridge”  to  match  what  was  configured  in  the  dspfarm profile.  Next,  enter  the  
“Conference  Bridge  Name”  that  was  configured  on  R1  (e.g.  “R1-­‐VCONF”)  to  register  it  with  CUCM.  
Next,  select  a  “Device  Pool”  that  should  be  assigned  to  the  videoconference  bridge  (e.g.  
“HQ_PHONE_DP”).    
 

 
 
Click  the  Save  button  when  complete.  
 
Check  the  registration  status  of  the  videoconference  bridge  by  issuing  the  show dspfarm
profile 3  command  on  the  R1  router.    
 
R1  
R1#sh dspfarm profile 3
Dspfarm Profile Configuration

Profile ID = 3, Service = VIDEO CONFERENCING, Resource ID = 4


Video Conference Type : HOMOGENEOUS, Layout : disabled, osd : on
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
...
 
Next,  assign  the  videoconference  bridge  to  an  MRG  by  navigating  to  Media  Resources  !  Media  
Resource  Group  and  clicking  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  bridge  (e.g.  “R1-­‐
VCONF_MRG”)  and  select  the  “R1-­‐VCONF  (CFB)”  device  for  use  in  the  MRG.  

533 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Click  the  Save  button  when  complete.    
 
Next,  we  must  add  the  MRG  to  the  MRGL  that  is  associated  with  the  HQ  phones  (e.g.  “HQ_MRGL”).  
Since  this  was  added  in  a  previous  lab,  we  can  simply  modify  the  existing  configuration  by  navigating  to  
Media  Resources  !  Media  Resource  Group  List  and  clicking  on  the  “HQ_MRGL”  link.  Add  the  newly  
created  “R1-­‐VCONF_MRG”  to  the  list  and  click  the  Save  button  when  complete.  
 

 
 
   

534 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  initiate  the  videoconference  from  HQ  Phone  1  with  the  BB  PSTN  phone  and  SC  Phone  2.  All  video  
should  be  displayed  properly  on  each  phone.  Issue  the  show sccp connections  command  from  
R1  to  view  the  active  session.  
 
R1  
R1#show sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

33559467 33554740 vcf sendrecv h264 17236 21936 10.10.11.13 33554741


33559467 33554739 vcf sendrecv g711u 17234 17770 10.10.11.13
33559467 33554737 vcf sendrecv h264 17232 17224 10.10.11.1 33554738
33559467 33554736 vcf sendrecv g729 17230 17218 10.10.11.1
33559467 33554734 vcf sendrecv h264 17228 21664 10.10.253.26 33554735
33559467 33554733 vcf sendrecv g729 17226 22988 10.10.253.26

Total number of active session(s) 1, and connection(s) 6


 

535 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 32: CUCME Media Resources Configuration


Task 32.1 Create  a  conference  bridge  on  R3  to  support  conferences  on  both  SIP  and  SCCP  
phones.  
 
Creating  media  resources  on  CUCME  is  done  using  the  same  method  as  CUCM—create  the
dspfarm profile,  configure  the  SCCP  application,  and  register  it  to  the  call  agent.  Of  course,  
registering  the  resource  to  the  call  agent  (CUCME  in  this  case)  is  going  to  be  very  different  since  it  is  
done  through  the  CLI.  Media  resources  are  only  registered  within  telephony-service  in  CUCME,  
but  can  be  utilized  by  both  SCCP  and  SIP  phones.  
 
The  first  step  here  is  to  configure  the  voice-card  on  R3  to  support  the  creation  of  DSP-­‐based  
resources  on  the  router.  The voice-card  section  configures  the  router  PVDM  modules,  depending  
on  their  specific  location  in  the  router.  Within  this  section,  we  must  configure  the  dspfarm  and  dsp
services dspfarm  commands.  Without  the  dspfarm command  we  would  not  be  able  to  create  
any  profiles  in  the  router  for  conferencing,  transcoding,  media  termination,  etc.  Without  the  dsp
services dspfarm  command,  configuring  and  activating  those  profiles  is  not  possible.  Moral  of  
the  story,  both  commands  are  absolutely  necessary  for  the  success  of  the  configuration.  
 
R3  
R3(config)#voice-card 0
R3(config-voicecard)#dspfarm
R3(config-voicecard)#dsp services dspfarm
 
Next,  we  must  create  the  dspfarm profile  to  support  audio  conferencing.  Enter  the  command  
from  global  configuration  mode.  
 
R3  
R3(config)#dspfarm profile 1 conference
R3(config-dspfarm-profile)#
 
Next,  the  maximum  number  of  conference  bridges  that  can  be  initiated  should  be  set  using  the  
maximum sessions  command.  Issuing  the  “?”  character  will  display  the  maximum  number  of  
sessions  that  can  be  supported  by  the  router.  The  task  did  not  define  how  many  sessions  should  be  
used,  so  a  value  of  “2”  was  chosen  in  this  case.  When  in  doubt,  try  and  keep  the  number  low  so  as  to  
not  exhaust  all  resources  in  the  router.  
 
R3  
R3(config)#dspfarm profile 1 conference
R3(config-dspfarm-profile)#maximum sessions 2
 
   

536 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  next  step  is  to  associate  the  profile  with  the  application  that  will  be  used  to  control  the  utilization  
of  the  conference  bridge.  In  this  case,  and  in  the  case  of  all  “hardware”  media  resources  being  
registered  to  CUCME,  SCCP  will  be  used  to  accomplish  this.    
 
R3  
R3(config)#dspfarm profile 1 conference
R3(config-dspfarm-profile)#associate application sccp
 
Lastly,  don’t  forget  to  switch  the  profile  “on”  by  issuing  the  no  shutdown  command.  
 
R3  
R3(config)#dspfarm profile 1 conference
R3(config-dspfarm-profile)#no shutdown
 
Now  that  the  dspfarm profile  is  complete,  we  must  configure  the  SCCP  application  in  order  for  
the  media  resources  to  be  controlled  by  CUCME.  We  should  start  by  identifying  the  source  interface  for  
the  communication.  It  is  a  good  idea  to  use  the  “Loopback  0”  interface  here,  since  it  is  the  most  
reliable  interface  on  the  router.  
 
R3  
R3(config)#sccp local Loopback0
 
Next,  we  must  define  the  CUCME  server  to  which  the  R3  router  will  connect  using  the  sccp ccm  
command.  Within  this  command,  we  must  provide  an  identifier, priority,  and  version  for  
the  CUCME  server.  Even  though  we  are  using  CUCME  and  not  CUCM,  the  version  should  still  be  
specified  as  “7.0+”  to  describe  versions  greater  than  7.x.  
 
R3  
R3(config)# sccp ccm 10.10.31.1 identifier 1 priority 1 version 7
 
Next,  we  must  create  a  SCCP  CUCM  group  to  associate  the  newly  created  dspfarm profile  with  
the  CUCME  server.  We  can  also  provide  a  descriptive  name  that  can  be  used  to  register  with  CUCME.  
 
R2  
R3(config)#sccp ccm group 1
R3(config-sccp-ccm)#associate ccm 1 priority 1
R3(config-sccp-ccm)#associate profile 1 register R3-CONF
 
The  last  step  is  to  enable  SCCP  to  run  on  the  R3  router  by  issuing  the  sccp  command.  
 
R3  
R3(config)#sccp
 
Now  that  the  conference  bridge  is  created  and  the  SCCP  application  is  configured,  we  can  register  it  to  
the  CUCME  server  under  the  telephony-service  section  on  the  router.  First,  we  must  define  the  
number  of  media  resource  “units”  that  will  be  registered  to  the  router  with  the  sdspfarm units  
command.  As  a  general  rule,  I  like  to  define  the  highest  number  possible  here  so  I  don’t  have  to  come  
back  and  do  it  later  if  and  when  it  is  needed.  No  resources  are  actually  carved  out  by  using  this  

537 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

command,  so  it  is  safe  to  use  without  worry  of  resource  exhaustion.  Next,  define  the  resource  that  is  
being  added  by  using  the  sdspfarm tag  command.  This  will  allow  us  to  register  the  conference  
bridge  using  the  name  defined  in  the  SCCP  application  configuration  (e.g.  “R3-­‐CONF”).  Lastly,  we  must  
instruct  the  router  to  use  hardware  conferencing  instead  of  the  default  software  conferencing  by  
entering  the  conference hardware  command.    
 
R3  
R3(config)#telephony-service
R3(config-telephony)#sdspfarm units 10
R3(config-telephony)#sdspfarm tag 1 R3-CONF
R3(config-telephony)#conference hardware
 
Don’t  forget  to  add  the  conference hardware  command  to  voice register global  to  
support  hardware  conferencing  on  SIP  CUCME  phones  as  well.    
 
R3  
R3(config)#voice register global
R3(config-register-global)#conference hardware
R3(config-register-global)#create profile
R3(config-register-global)#reset
 
In  addition  to  the  telephony-service  configuration,  we  must  also  create  an  ephone-dn  
specifically  for  conferencing  purposes.  We  should  create  the  conference  DN  as  an  octo-line  so  it  
can  support  up  to  8  participants.  Next,  a  number  should  be  defined  so  it  can  be  used  by  the  router  to  
set  up  the  conference.  Oddly  enough,  the  number  command  supports  alpha  characters  as  well,  so  if  
users  are  not  able  to  dial  the  number,  it  is  best  to  use  an  “alpha-­‐only”  format.  Lastly,  we  must  add  the  
conference ad-hoc  command  to  specify  the  type  of  conference  that  is  supported  with  the  
configured  ephone-dn.  If  more  participants  than  8  per  conference  are  required,  we  can  create  
another  ephone-dn  using  the  same  number  to  support  the  requirement.  
 
R3  
R3(config)#ephone-dn 10 octo-line
R3(config-ephone-dn)#number AAAA
R3(config-ephone-dn)#conference ad-hoc
 
To  verify  the  status  of  the  conference,  we  can  use  the  show  dspfarm profile 1  and  show
dspfarm unit’s  commands.  
 
R3  
R3#sh dspfarm pro 1
Dspfarm Profile Configuration

Profile ID = 1, Service = CONFERENCING, Resource ID = 1


...
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
...
 

538 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3#sh sdspfarm units

conf-1 Device:R3-CONF TCP socket:[1] REGISTERED in SCCP ver 18/18


actual_stream:16 max_stream 16 IP:10.10.3.3 * 60593 Conference Dixieland keepalive 0
Supported codec:
G711Ulaw
G711Alaw
G729
G729a
G729b
G729ab

max-mtps:10, max-streams:0, alloc-streams:0, act-streams:0


 
   

539 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 32.2 Phones  at  SC  should  be  able  to  use  the  Join  or  Conference  softkeys  to  invoke  a  
conference.  
 
Invoking  a  conference  on  a  phone  registered  to  CUCME  is  no  different  than  if  it  were  registered  to  
CUCM.  The  user  must  still  be  able  to  use  the  soft  keys  in  some  fashion  to  create  a  conference.  In  SCCP  
CUCME,  this  is  controlled  with  an  ephone-template.  Several  labs  back,  ephone-template 1  
was  created  and  assigned  to  ephone 1  in  the  system,  corresponding  to  SC  Phone  1.  This  means  that  
we  can  simply  modify  this  existing  template  to  add  the  “Select”,  “Join”,  and  “Conference”  soft  keys  
where  applicable.  Make  sure  to  reset  ephone 1  when  complete.  
 
R3  
R3(config)#ephone-template 1
R3(config-ephone-template)#softkeys hold Resume Select Join
R3(config-ephone-template)#softkeys seized Redial Endcall Cfwdall Pickup Gpickup Meetme Callback
R3(config-ephone-template)#softkeys connected Hold Endcall Trnsfer Acct Flash Park Select Join
Confrn

R3(config)#ephone 1
R3(config-ephone)#reset
resetting 001E.BE92.3406
 
With  the  configuration  complete,  test  the  conference  by  calling  other  phones  in  the  network.  Issue  the  
show sccp connections  command  to  verify  that  the  R3  conference  bridge  is  being  used.  
 
R3  
R3#show sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

3221291009 65539 conf sendrecv g711u 17012 2000 10.10.31.1


3221291009 65538 conf sendrecv g711u 17010 2000 10.10.31.1
3221291009 65537 conf sendrecv g711u 17008 2000 10.10.31.1

Total number of active session(s) 1, and connection(s) 3


 
   

540 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 32.3 Configure  Meet-­‐Me  Conferencing  on  CUCME  such  that  users  can  dial  extension  3555  
and  be  connected  to  the  conference.  Ensure  that  any  SCCP  phone  can  initiate  the  
conference.    
 
In  Cisco  Unified  CME  4.1  and  later  versions,  Meet-­‐Me  conferences  consist  of  at  least  three  parties  
dialing  a  Meet-­‐Me  conference  number  predetermined  by  a  system  administrator.  For  example,  a  
conference  is  created  when  the  conference  creator  at  extension  1215  presses  the  MeetMe  soft  key  
and  hears  a  confirmation  tone,  then  dials  the  Meet-­‐Me  conference  number  1500.  Extension  1225  and  
extension  1235  join  the  Meet-­‐Me  conference  by  dialing  1500.  Extensions  1215,  1225,  and  1235  are  
now  parties  in  a  Meet-­‐Me  conference  on  extension  1500.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeadm/
cmeconf.html#pgfId-­‐1012774]    
 
The  first  thing  that  must  happen  to  create  a  Meet-­‐Me  conference  (since  the  dspfarm profile  is  
already  created)  is  to  create  an  ephone-dn  specifically  to  support  this  function.  The  ephone-dn  will  
be  very  similar  to  that  which  was  created  for  the  ad-­‐hoc  conference  in  a  previously  configured  task,  
except  that  the  MeetMe  keyword  will  be  used  instead  to  specify  the  conference  type.  Also,  depending  
on  how  your  telephony-service  configuration  is  set  up,  you  may  need  to  specify  a  larger  number  
for  the  max-dn  value  to  support  the  additional  ephone-dn.  
 
R3  
R3(config-ephone)#telephony-service
R3(config-telephony)#max-dn 15

R3(config)#ephone-dn 11 octo-line
R3(config-ephone-dn)#number 3555
R3(config-ephone-dn)#conference meetme

Next,  we  must  configure  the  proper  soft  keys  on  the  phones  to  support  the  Meet-­‐Me  function.  In  this  
case,  since  any  SCCP  phone  can  initiate  the  conference,  so  we  must  modify  the  ephone-template  
to  include  the  “Meetme”  soft  key  during  the  “Seized”  state.  Remember  to  reset  ephone 1  after  the  
soft  key  is  added.  
 
R3  
R3(config)#ephone-template 1
R3(config-ephone-template)#softkeys seized Redial Endcall Cfwdall Pickup Gpickup Meetme Callback

R3(config)#ephone 1
R3(config-ephone)#reset
resetting 001E.BE92.3406

   

541 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  test  the  configuration,  go  “off  hook”  on  SC  Phone  1  and  select  the  “Meetme”  soft  key.  Then  dial  the  
configured  Meet-­‐Me  number  of  3555  to  start  the  conference.  Join  the  conference  with  other  phones  
by  dialing  3555.  Verify  the  conference  is  active  on  R3  by  issuing  the  show sccp connections  
command.  
 
R3  
R3#show sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

3221356546 65543 conf sendrecv g711u 17034 2000 10.10.31.1


3221356546 65542 conf sendrecv g711u 17030 2000 10.10.31.1
3221356546 65541 conf sendrecv g711u 17024 2000 10.10.31.1
3221356546 65540 conf sendrecv g711u 17022 2000 10.10.31.1

Total number of active session(s) 1, and connection(s) 4


 
   

542 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 32.4 Ensure  that  callers  hear  distinct  “Join”  and  “Leave”  tones  when  parties  enter  or  exit  
the  conference.  
 
Next,  we  must  create  different  tones  for  “joining”  and  “leaving”  the  audio  conference  bridge.  This  
procedure  is  no  different  than  when  it  was  done  using  CUCM  as  the  call  agent.  We  can  accomplish  this  
task  by  using  the  voice class custom-cptone  command.  We  must  create  a  different  voice
class  for  each  type  of  tone.  A  frequency  and  cadence  must  be  defined  under  the  dualtone  
conference  heading  in  order  to  create  a  unique  tone  for  each  event.  Two  frequencies  must  be  
specified.  For  the  cadence  command,  the  first  number  specifies  the  number  of  milliseconds  that  the  
tone  is  played  and  the  second  number  specifies  the  number  of  milliseconds  in  which  the  tone  is  not  
played.  Each  subsequent  number  specified  uses  the  same  logic:  on,  off,  on,  off,  etc.  The  below  
command  specifies  that  the  tone  should  be  played  for  50  milliseconds  (ms),  stop  for  50  ms,  play  for  50  
ms,  stop  for  50  ms,  and  play  for  50  ms.  This  means  that  three  short  beeps  will  be  heard.    
 
R3  
R3(config)#voice class custom-cptone JOIN
R3(cfg-cptone)#dualtone conference
R3(cfg-cp-dualtone)#frequency 2500 3500
R3(cfg-cp-dualtone)#cadence 50 50 50 50 50

R3(config)#voice class custom-cptone LEAVE


R3(cfg-cptone)#dualtone conference
R3(cfg-cp-dualtone)#frequency 1500 2500
R3(cfg-cp-dualtone)#cadence 50 50 50 50 50

Next,  each  voice class  must  be  assigned  to  the  dspfarm profile  that  was  created  to  support  
the  audio  conference  bridge.  Remember,  to  make  any  changes,  we  must  first  shutdown  the  profile.  
We  can  use  the  conference-join  and  conference-leave  commands  to  set  the  configuration  
within  the  dspfarm profile.  It  is  a  good  idea  to  pay  attention  to  the  warning  that  is  issued  by  IOS,  
although  it  is  a  grammatical  nightmare.  Create  tones  that  sound  different,  or  else  you  won’t  be  able  to  
distinguish  between  the  events.    
 
R3  
R3(config-dspfarm-profile)#shutdown

Disabling profile will disconnect active CONFERENCING calls,


do you want to continue ? [yes/no]yes

R3(config-dspfarm-profile)#conference-join custom-cptone JOIN


Please note that conference join tone should better be different from leave tone!

R3(config-dspfarm-profile)#conference-leave custom-cptone LEAVE


Please note that conference join tone should better be different from leave tone!

R3(config-dspfarm-profile)#no shutdown

Test the configuration by starting another Meet-Me conference. Listen for the different “join” and
“leave” tones.
 
   

543 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 32.5 Ensure  that  SC  Phone  1  can  remove  users  from  the  Meet-­‐Me  conference  if  so  
desired.  
 
To  allow  SC  Phone  1  (SCCP)  to  remove  users  from  the  Meet-­‐Me  conference,  we  must  make  it  a  
conference  administrator  by  adding  the  conference admin  command  to  the  ephone 1  
configuration.  Also,  we  must  provide  access  to  the  conference  participant  list  by  adding  the  “ConfList”  
soft  key  in  the  “Connected”  state.  
 
R3  
R3(config)#ephone 1
R3(config-ephone)#conference admin

R3(config)#ephone-template 1
R3(config-ephone-template)#softkeys connected Hold Endcall Trnsfer Acct Flash Park Select Join Confrn
ConfList

R3(config)#ephone 1
R3(config-ephone)#reset
resetting 001E.BE92.3406

To  test,  create  a  Meet-­‐Me  conference  and  select  the  “ConfList”  soft  key  on  SC  Phone  1.  Highlight  an  
entry  and  use  the  “Remove”  soft  key  to  remove  the  participant.  
 

 
 

544 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Six  Labs  33  -­‐  34  
Version  1.0  

545 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 6: Configuring and Troubleshooting Call Admission Control


Lab 33: CUCM-Based CAC
Task 33.1 Temporarily  place  HQ  phone  2  in  a  separate  device  pool  and  ensure  that  it  has  a  
separate  location  created.  Ensure  that  a  maximum  of  1  call  is  allowed  between  HQ  
Phone  1  and  HQ  Phone  2.    
 
Locations,  which  are  available  in  Cisco  Unified  Communications  Manager,  provide  call  admission  
control  for  centralized  call-­‐processing  systems.  Call  admission  control  enables  you  to  control  the  audio  
quality  and  video  quality  of  calls  over  a  wide-­‐area  (IP  WAN)  link  by  limiting  the  number  of  calls  that  are  
allowed  on  that  link  at  the  same  time.  For  example,  you  can  use  call  admission  control  to  regulate  the  
voice  quality  on  a  56-­‐kb/s  frame  relay  line  that  connects  your  main  campus  and  a  remote  site.  
 
Audio  and  video  quality  can  begin  to  degrade  when  too  many  active  calls  exist  on  a  link  and  the  
amount  of  bandwidth  is  oversubscribed.  Call  admission  control  regulates  audio  and  video  quality  by  
limiting  the  number  of  calls  that  can  be  active  on  a  particular  link  at  the  same  time.  Call  admission  
control  does  not  guarantee  a  particular  level  of  audio  or  video  quality  on  the  link,  but  it  does  allow  you  
to  regulate  the  amount  of  bandwidth  that  active  calls  on  the  link  consume.  
 
Call  admission  control  operates  by  rejecting  a  call  for  bandwidth  and  policy  reasons.  When  a  call  gets  
rejected  due  to  call  admission  control,  the  phone  of  the  called  party  does  not  ring,  and  the  caller  
receives  a  busy  tone.  The  caller  also  receives  a  message  on  their  phone,  such  as  "Not  enough  
bandwidth."  
 
Without  call  admission  control,  you  may  perceive  that  IP  voice  is  low  in  quality  and  unreliable.  With  call  
admission  control,  you  may  experience  situations  similar  to  the  time-­‐division  multiplexing  (TDM)  
processing  and  realize  that  they  need  more  bandwidth  for  peak  hours.  If  your  system  does  not  contain  
IP  WAN  links  with  limited  available  bandwidth,  you  do  not  have  to  use  call  admission  control.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmsys/CUCM_BK_CD2F
83FA_00_cucm-­‐system-­‐guide-­‐90/CUCM_BK_CD2F83FA_00_system-­‐guide_chapter_01000.html]    
 
As  of  CUCM  9.x,  the  way  in  which  Locations  are  configured  has  changed.  We  now  have  the  ability  to  
create  “modeling”  locations  that  aren’t  actually  assigned  to  any  devices  in  the  system,  if  we  so  desire.  
We  can  also  share  Location  information  between  clusters  in  an  attempt  to  make  more  intelligent  CAC  
decisions  for  intercluster  calls.  That  new  method  will  be  covered  in  later  tasks  within  this  lab.  For  now,  
this  task  is  actually  attempting  to  utilize  a  “legacy”  approach  for  configuring  Locations.  Since  we  don’t  
have  any  other  sites  on  the  cluster,  the  task  is  asking  that  we  create  a  separate  Device  Pool  and  
Location  for  each  HQ  phone.  When  this  has  been  configured,  we  are  to  limit  the  number  of  calls  
between  phones  to  one.  
 
   

546 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

First,  let’s  configure  the  Locations  for  the  task  by  navigating  to  System  !  Location  Info  !  Location  and  
clicking  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  Location  to  be  assigned  to  HQ  Phone  
1,  such  as  “HQ_PHONE_LOC”.    
 

 
 
Next,  take  note  that  the  “Location”  list  box  under  the  “Links”  section  has  already  selected  the  
“Hub_None”  Location,  which  is  the  default  “hub”  Location  for  the  cluster.  It  is  probably  a  good  idea  to  
configure  this  relationship,  since  other  devices  that  do  not  have  a  Location  assigned  use  this  Location  
by  default.    
 

 
 
The  parameters  below  the  “Location”  list  box  specify  the  settings  that  relate  to  the  link  between  the  
“Hub_None”  Location  and  the  “HQ_PHONE_LOC”.  The  first  is  the  “Weight”  parameter.  This  setting  is  
available  to  help  determine  the  “Effective  Path”  in  the  system  when  there  is  more  than  one  way  to  get  
to  a  Location.  The  lower  the  “Weight”,  the  more  attractive  the  path  becomes.  This  setting  will  be  
discussed  further  in  later  tasks  within  this  lab.  Next,  we  have  the  “Audio”,  “Video”,  and  “Immersive  
Video”  bandwidth  settings.  These  settings  will  determine  how  many  calls  of  each  type  can  traverse  the  
Location.    
 

 
 
Of  course,  these  settings  work  in  combination  with  the  Region  settings  for  the  two  Locations.  The  
codec  that  is  configured  in  the  Region  will  determine  the  bandwidth  values  that  should  be  set  for  each  
Location.  The  per-­‐call  bandwidth  values  (available  in  the  CUCM  Help  Pages)  are  shown  below.  
 
• G.711  call  uses  80  kb/s.  
• G.722  call  uses  80  kb/s.  
• G.723  call  uses  24  kb/s.  
• G.728  call  uses  16  kb/s.  
• G.729  call  uses  24  kb/s.  
• GSM  call  uses  29  kb/s.  
• Wideband  call  uses  272  kb/s.  
 
Based  on  these  values,  to  allow  four  G.711  calls,  between  Locations,  the  value  must  be  set  to  320  kbps  
(4*80).    

547 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  click  the  “Show  Advanced”  link.  It  is  now  possible  to  define  bandwidth  values  for  calls  within  the  
same  location.    
 

 
 
This  is  not  a  required  setting  of  the  task,  but  can  be  a  useful  feature  to  know—especially  when  
studying  for  the  CCIE!  Finally,  we  can  click  the  Save  button  to  complete  the  configuration.    
 
Next,  click  the  Add  New  button  again  to  add  the  Location  for  the  other  HQ  phone.  Once  again,  provide  
a  descriptive  “Name”  for  the  Location  (e.g.  “HQ_PHONE_2_LOC”).  
 

 
 
This  time,  we  can  actually  create  a  Link  to  the  Location  that  was  previously  created  (e.g.  
“HQ_PHONE_LOC”).  For  now,  let’s  leave  all  the  settings  at  the  default  values  and  click  the  Save  button.  
 

 
 
   

548 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  let’s  assign  the  “HQ_PHONE_LOC”  Location  to  the  existing  “HQ_PHONE_DP”  Device  Pool  by  
navigating  to  System  !  Device  Pool  and  clicking  the  Find  button.  Modify  the  Location  setting  to  use  
the  “HQ_PHONE_LOC”  under  the  “Roaming  Sensitive  Settings”  section  of  the  “Device  Pool  
Configuration”  page  and  click  the  Save  button.  
 

 
 
Next,  click  the  Copy  button  to  copy  the  current  settings  to  a  new  Device  Pool  (to  be  assigned  to  HQ  
Phone  2).  Name  the  Device  Pool  appropriately  (e.g.  “HQ_PHONE_2_DP”)  and  modify  the  “Location”  
parameter  to  the  previously  created  Location  for  HQ  Phone  2  (e.g.  “HQ_PHONE_2_LOC”).    
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  assign  the  newly  created  Device  Pool  to  the  phone  by  navigating  to  Device  !  Phone  and  clicking  
on  HQ  Phone  2.  Select  the  “HQ_PHONE_2_LOC”  option  from  the  “Device  Pool”  dropdown  box.  
 

 
 
Click  the  Save  and  Reset  buttons  to  apply  the  configuration.  
 
Next,  navigate  to  System  !  Location  Info  !  Location  and  click  on  the  “HQ_PHONE_LOC”  Location.  
Take  note  of  the  Links  that  exist  between  Locations  at  this  point.  “HQ_PHONE_LOC”  is  linked  to  both  
the  “HQ_PHONE_2_LOC”  and  “Hub_None”  Locations.  
 

 
 

549 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  set  the  number  of  calls  that  are  allowed  to  traverse  the  path  between  HQ  Phone  1  and  2,  we  must  
modify  the  Link  to  “HQ_PHONE_2_LOC”  accordingly.  Remember,  the  codec  being  used  between  the  
Locations  is  determined  by  the  Region  setting,  which  is  set  to  use  G.711  since  the  phone  Device  Pools  
are  direct  copies  of  one  another  (except  the  Location  setting).  So  if  we  are  to  only  allow  one  call  
between  the  two,  we  must  set  the  “Audio  Bandwidth”  setting  to  80  kbps,  based  on  the  tracking  of  the  
per-­‐call  bandwidth  in  CUCM.    
 
Click  on  the  “HQ_PHONE_2_LOC”  link  to  launch  the  configuration  window  for  that  link.  Set  the  “Audio  
Bandwidth”  to  a  value  of  “80”  kbps  and  click  the  Save  button.  
 

 
 
With  the  link  configured,  we  can  now  make  a  test  call  between  the  two  HQ  phones.  This  will  be  
permitted  since  the  configured  Location  bandwidth  is  adequate  to  support  the  call  volume.  Now,  put  
the  call  on  hold  and  make  a  second  call  to  the  same  phone.  The  call  should  fail  due  to  the  configured  
Location  settings.  
 

 
 
   

550 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 33.2 Ensure  that  this  communication  occurs  by  way  of  the  Hub_None  location.  
 
In  the  previous  task,  we  created  a  Location  for  each  phone  at  the  HQ  site  as  well  as  a  link  that  allowed  
80  kbps  between  the  two  in  order  to  allow  one  call  across  the  network.  In  this  task,  our  goal  is  to  
accomplish  the  same  configuration  “through”  the  “Hub_None”  location.  This  means  that  we  cannot  
have  any  Links  configured  between  the  two  HQ  Locations.  Instead,  we  must  only  have  a  link  from  each  
Location  to  “Hub_None”.  We  must  also  still  allow  only  one  call.    
 
To  accomplish  this,  navigate  to  System  !  Location  Info  !  Location  and  click  on  the  “HQ_PHONE_LOC”  
Location.  As  shown  below,  two  links  exist,  one  to  “HQ_PHONE_2_LOC”  and  one  to  “Hub_None”.  
 

 
 
To  remove  the  link  to  “HQ_PHONE_2_LOC”,  check  the  box  and  click  the  Delete  Selected  button.  Now  
“HQ_PHONE_LOC”  only  has  a  link  to  “Hub_None”.  At  this  point,  we  should  go  back  to  the  list  of  
Locations  and  click  the  “HQ_PHONE_2_LOC”  link.  Since  we  only  added  the  link  to  the  
“HQ_PHONE_LOC”  Location,  there  should  not  be  any  links  configured.  Click  the  Add  button  to  create  a  
link  to  the  “Hub_None”  Location.  Set  the  “Audio  Bandwidth”  to  “80”  kbps  and  click  the  Save  button.  
 

 
 
At  this  point,  we  have  a  link  configured  from  “HQ_PHONE_LOC”  to  “Hub_None”  to  
“HQ_PHONE_2_LOC”  with  80  kbps  available  for  calls  between  the  last  two  Locations.  This  should  
successfully  limit  the  number  of  calls  between  the  HQ  phones  to  a  value  of  one.  Make  a  test  call  as  
described  above  and  observe  the  behavior.  It  should  act  exactly  as  it  did  in  the  previous  task.  
 

 
 
Please  take  note  that  this  configuration  will  not  allow  more  than  one  call  to  be  made  to  any  other  
“Hub_None”  device  in  the  system  as  well,  since  that  is  the  default  Location  assignment  throughout  the  
system.      

551 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 33.3 Return  the  configuration  to  its  previous  state  (Before  the  two  tasks  above).  Create  
separate  Location  Bandwidth  Manager  Groups  and  Hub  Groups  on  both  the  HQ  and  
SB  clusters.  Ensure  that  location  information  is  replicated  between  the  clusters  for  
use  with  Enhanced  Locations-­‐Based  Call  Admission  Control  (EL-­‐CAC).  
 
CUCM  9.x  changed  the  way  that  Locations  are  implemented  in  CUCM.  Enhanced  Locations-­‐Based  Call  
Admission  Control  (EL-­‐CAC)  is  now  the  method  of  implementation  that  is  used.  It  still  contains  many  
similarities,  but  does  have  some  key  differences.  The  below  excerpt  from  the  CUCM  9.x  SRND  gives  a  
brief  overview  of  EL-­‐CAC.  
 
Enhanced  Locations  CAC  is  a  model-­‐based  static  CAC  mechanism.  Enhanced  Locations  CAC  involves  
using  the  administration  interface  in  Unified  CM  to  configure  Locations  and  Links  to  model  the  "Routed  
WAN  Network"  in  an  attempt  to  represent  how  the  WAN  network  topology  routes  media  between  
groups  of  endpoints  for  end-­‐to-­‐end  audio,  video,  and  immersive  calls.  Although  Unified  CM  provides  
configuration  and  serviceability  interfaces  in  order  to  model  the  network,  it  is  still  a  "static"  CAC  
mechanism  that  does  not  take  into  account  network  failures  and  network  protocol  rerouting  such  as  
RSVP  CAC.  Therefore,  the  model  needs  to  be  updated  when  the  WAN  network  topology  changes.  
Enhanced  Locations  CAC  is  also  call  oriented,  and  bandwidth  deductions  are  per-­‐call  not  per-­‐stream,  so  
asymmetric  media  flows  where  the  bit-­‐rate  is  higher  in  one  direction  than  in  the  other  will  always  
deduct  for  the  highest  bit  rate.  In  addition,  unidirectional  media  flows  will  be  deducted  as  if  they  were  
bidirectional  media  flows.  
 
The  administrator  builds  the  network  model  using  locations  and  links.  Enhanced  Locations  CAC  
incorporates  the  following  configuration  components:  
 
• Locations  —  A  Location  represents  a  LAN.  It  could  contain  endpoints  or  simply  serve  as  a  transit  
location  between  links  for  WAN  network  modeling.  
• Links  —  Links  interconnect  locations  and  are  used  to  define  bandwidth  available  between  
locations.  Links  logically  represent  the  WAN  link  and  are  configured  in  the  Location  user  
interface  (UI).  
• Weights  —  A  weight  provides  the  relative  priority  of  a  link  in  forming  the  effective  path  
between  any  pair  of  locations.  The  effective  path  is  the  path  used  by  Unified  CM  for  the  
bandwidth  calculations,  and  it  has  the  least  cumulative  weight  of  all  possible  paths.  Weights  are  
used  on  links  to  provide  a  "cost"  for  the  "effective  path"  and  are  pertinent  only  when  there  is  
more  than  one  path  between  any  two  locations.  
• Path  —  A  path  is  a  sequence  of  links  and  intermediate  locations  connecting  a  pair  of  locations.  
Unified  CM  calculates  shortest  paths  (least  cost)  from  each  location  to  all  other  locations  and  
builds  the  paths.  Only  one  "effective  path"  is  used  between  a  pair  of  locations.  
• Effective  Path  —  The  effective  path  is  the  path  with  the  least  cumulative  weight.  
• Bandwidth  Allocation  —  The  amount  of  bandwidth  allocated  in  the  model  for  each  type  of  
traffic:    audio,  video,  and  immersive  video  (TelePresence).  
• Locations  Bandwidth  Manager  (LBM)  —  The  active  service  in  Unified  CM  that  assembles  a  
network  model  from  configured  location  and  link  data  in  one  or  more  clusters,  determines  the  
effective  paths  between  pairs  of  locations,  determines  whether  to  admit  calls  between  a  pair  of  

552 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

locations  based  on  the  availability  of  bandwidth  for  each  type  of  call,  and  deducts  (reserves)  
bandwidth  for  the  duration  of  each  call  that  is  admitted.  
• Locations  Bandwidth  Manager  Hub  —  A  Locations  Bandwidth  Manager  (LBM)  service  that  has  
been  designated  to  participate  directly  in  intercluster  replication  of  fixed  locations,  links  data,  
and  dynamic  bandwidth  allocation  data.  LBMs  assigned  to  an  LBM  hub  group  discover  each  
other  through  their  common  connections  and  form  a  fully-­‐meshed  intercluster  replication  
network.  Other  LBM  services  in  a  cluster  with  an  LBM  hub  participate  indirectly  in  intercluster  
replication  through  the  LBM  hubs  in  their  cluster.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/9x/uc9x/cac.html#wp1043786]    
 
Obviously,  some  of  the  parameters  listed  above  were  discussed  in  the  previous  tasks,  but  there  are  
also  several  new  concepts  here,  such  as  Locations  Bandwidth  Manager  (LBM),  Locations  Bandwidth  
Manager  Hub,  Effective  Path,  etc.  The  key  is  to  understand  how  each  of  the  different  settings  function  
together  to  create  the  CAC  mechanism.  In  building  the  topology  described  in  the  task,  we  will  gain  a  
great  understanding  of  how  this  should  work.  
 
Before  we  jump  into  the  configuration,  let’s  remove  the  existing  CAC  configuration  by  simply  assigning  
HQ  Phone  2  to  the  “HQ_PHONE_LOC”  Location.  Navigate  to  Device  !  Phone  and  click  on  HQ  Phone  2.  
For  the  “Device  Pool”  setting,  select  the  “HQ_PHONE_DP”  from  the  dropdown  box  and  click  the  Save  
and  Reset  buttons  when  complete.  
 

 
 
Next,  before  any  other  Location-­‐configuration  is  completed,  we  must  configure  the  LBM  and  LBM  Hub  
for  both  the  HQ  and  SB  CUCM  clusters.  Remember,  the  LBM  builds  the  topology  for  the  local  CUCM  
cluster  and  the  LBM  Hub  replicates  the  network  topology  (Locations/Links)  between  clusters.  On  the  
HQ  CUCM  cluster,  navigate  to  System  !  Location  Info  !  Location  Bandwidth  Manager  Group  and  click  
the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  group  (e.g.  “HQ_LBMG”)  and  select  the  
“Active/Standby  Members”  that  should  process  the  topology  for  the  local  cluster.  Click  the  Save  button  
when  complete.  Ensure  that  this  is  performed  on  the  SB  CUCM  cluster  as  well.    
 

 
 
   

553 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  System  !  Location  Info  !  Location  Bandwidth  Manager  Hub  Group  and  click  the  
Add  New  button.  Enter  a  descriptive  “Name”  (e.g.  “HQ_LBMHG”)  and  specify  a  “Member”  to  which  
this  CUCM  cluster  should  connect.  In  this  case,  we  would  like  to  make  a  connection  with  the  SB  CUCM  
cluster,  so  the  IP  address  of  the  SB  CUCM  Publisher  should  be  specified  here.    
 

 
 
Next,  select  the  servers  that  should  be  a  part  of  the  LBM  Hub  Group  by  moving  them  from  the  “LBM  
Services  Not  Use  this  LBM  Hub  Group”  list  box  to  the  “LBM  Services  Currently  Use  this  LBM  Hub  
Group”  list  box.  Click  the  Save  button  when  complete.  Make  sure  to  perform  this  step  on  the  SB  CUCM  
cluster  as  well    
 

 
 
The  LBM  service  is  now  active  on  each  CUCM  cluster  and  has  the  ability  to  share  the  topology  between  
clusters.  
 
   

554 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 33.4 Ensure  that  the  HQ  phones  and  SB  phones  have  separate  locations  created  for  them.  
The  network  is  configured  such  that  HQ  has  a  connection  to  datacenters  in  both  
Denver  and  Las  Vegas  that  allows  communication  to  SB.  SB  has  a  connection  to  St.  
Louis  and  Kansas  City  that  allows  communication  with  HQ.  Denver  is  connected  to  
St.  Louis,  and  Las  Vegas  is  connected  to  Kansas  City.  Ensure  that  this  network  is  
modeled  using  E-­‐LCAC  and  has  bandwidth  for  10  total  calls  between  HQ  and  SB.    
 
Now  that  the  LBM  Groups  and  LBM  Hub  Groups  have  been  created,  we  must  create  the  Locations  and  
“build”  the  topology  that  will  be  utilized  to  enforce  CAC  throughout  the  network.  It  sometimes  helps  to  
draw  a  diagram  of  the  network  topology—especially  if  the  wording  in  the  question  is  cryptic.  Here’s  a  
diagram  that  represents  the  requirements  in  the  task.  
 

 
 
As  you  can  see,  HQ  has  two  different  paths  to  reach  the  SB  Location,  one  through  Denver  and  one  
through  Las  Vegas.  SB  can  reach  the  HQ  Location  via  either  St.  Louis  or  Kansas  City.  This  path  can  
actually  be  modeled  within  CUCM  using  Locations  and  Links.  The  trick  is  to  remember  that  no  devices  
(Phones,  Gateways,  etc.)  technically  need  to  be  assigned  to  each  of  these  Locations.  Some  can  be  used  
as  transit  Locations  (Denver,  Las  Vegas,  St.  Louis,  Kansas  City),  for  modeling  purposes  only.  
 
With  that  said,  let’s  now  create  the  Locations  in  CUCM  to  successfully  model  the  network.  Keep  in  
mind  that  the  LBM  service  on  each  CUCM  cluster  builds  a  topology  separately  and  then  shares  it  with  
the  other  cluster.  Based  on  this  fact,  we  have  the  ability  to  build  the  entire  topology  on  one  CUCM  
cluster  so  it  can  be  shared  with  the  other.  This  can  save  a  bit  of  time  since  we  don’t  have  to  build  the  
same  Locations  on  each  cluster.  On  the  HQ  CUCM  cluster,  navigate  to  System  !  Location  Info  !  
Location  and  click  the  Add  New  button.  Enter  the  Location  name  for  the  first  datacenter  (e.g.  
“DENVER_DC_LOC”)  and  keep  the  “Hub_None”  Location  selected  to  create  a  Link.  
 

555 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Leave  the  remaining  Link  settings  at  the  default  values  and  click  the  Save  button.  
 

 
 
Create  the  remaining  datacenter  Locations  (e.g.  “LAS_VEGAS_DC_LOC”,  “ST_LOUIS_DC_LOC”,  and  
“KANSAS_CITY_DC_LOC”)  in  the  same  fashion.  Next,  since  we  already  have  the  “HQ_PHONE_LOC”  
Location  created  to  be  assigned  to  the  phones  at  HQ,  we  must  create  a  Location  for  the  phones  at  SB.  
Take  note  that  this  must  exactly  match  the  name  that  is  used  for  the  Location  on  the  SB  CUCM  cluster  
in  order  for  the  LBM  service  to  consider  it  the  same  Location.  Create  the  Location  using  the  method  
above  with  the  name  “SB_PHONE_LOC”.    
 

 
 
With  the  Locations  created,  we  can  now  configure  the  Links  between  Locations.  Navigate  to  System  !  
Location  Info  !  Location  and  click  the  Find  button.  Let’s  start  by  clicking  the  “DENVER_DC_LOC”  
Location  and  building  out  the  Links.    
 

 
 
The  first  thing  we  should  do,  however,  before  we  add  any  new  Links  is  to  delete  the  existing  link  to  
“Hub_None”  by  checking  the  box  and  clicking  the  Delete  Selected  button.  This  is  because  we  don’t  
want  the  default  hub  Location  interfering  with  the  network  modeling  that  we  are  trying  to  accomplish.  
According  to  the  task  requirements,  the  Denver  datacenter  only  has  connections  to  the  HQ  site  and  the  
St.  Louis  datacenter.  Click  the  Add  button  to  add  a  new  Link.      

556 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Select  the  “HQ_PHONE_LOC”  from  the  list  box  and  enter  a  value  for  the  “Audio  Bandwidth”  
parameter.  Since  a  total  of  10  calls  should  be  allowed  (per  the  task  requirements)  and  the  codec  being  
used  for  calls  between  HQ  and  SB  is  set  to  use  iLBC  (across  the  SIP  ICT),  we  should  enter  a  value  of  310  
kbps  here.  This  is  because  according  to  CUCM,  the  value  for  a  single  iLBC  call  is  31  kbps.  Click  the  Save  
button  when  complete.  
 

 
 
Next,  add  the  link  to  the  St.  Louis  datacenter  (“ST_LOUIS_DC_LOC”)  in  the  same  fashion.  In  this  case,  
we  can  actually  leave  the  “Audio  Bandwidth”  value  at  “Unlimited”  if  so  desired.  Since  the  first  link  on  
the  path  has  already  limited  to  bandwidth  to  310  kbps,  there  is  no  possible  way  that  calls  from  that  
Location  can  exceed  that  value.  The  finished  configuration  for  the  “DENVER_DC_LOC”  Location  should  
appear  as  shown  below.  
 

 
 
Next,  create  the  links  for  each  Location  that  is  configured  in  the  cluster  using  the  same  technique  
outlined  above.  
 
LAS_VEGAS_DC_LOC  
 

 
 
   

557 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
ST_LOUIS_DC_LOC  
 

 
 
KANSAS_CITY_LOC  
 

 
 
HQ_PHONE_LOC  
 

 
 
 
 
 
 
 
 
 
 

558 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

SB_PHONE_LOC  
 

 
 
Take  note  that  the  “HQ_PHONE_LOC”  Location  retained  the  Link  to  “Hub_None”  in  the  configuration.  
If  this  Link  were  not  configured,  HQ  phones  would  not  have  access  to  any  resources  using  that  
Location.    
 
Now  that  all  Locations  have  been  added  on  the  HQ  CUCM  cluster,  the  SB  CUCM  cluster  needs  to  add  a  
Location  as  well;  the  “SB_PHONE_LOC”  Location.  Since  this  Location  will  be  assigned  to  devices  on  the  
cluster,  it  must  be  created  here  as  well.  All  other  Locations  that  were  created  on  the  HQ  CUCM  cluster  
do  not  have  to  be  re-­‐created  here,  since  they  will  eventually  be  shared  with  the  SB  CUCM  cluster  
anyway.  Just  as  configured  for  the  “HQ_PHONE_LOC”,  the  “Hub_None”  Location  should  be  linked  here  
as  well.  
 

 
 
With  this  Location  created,  we  can  now  examine  the  Effective  Path  between  Locations.  This  refers  to  
the  active  path  that  is  chosen  by  the  LBM  service  in  order  to  properly  deduct  bandwidth  along  the  
path.  Remember,  since  we  already  created  the  LBM  Group  and  LBM  Hub  Group,  the  Locations  have  
been  automatically  shared  between  clusters,  so  we  can  go  to  either  CUCM  cluster  to  view  this  
information.  Navigate  to  the  Cisco  Unified  Serviceability  webpage  and  go  to  Tools  !  Locations  !  
Effective  Path.  Select  the  Location  names  from  the  dropdown  box  and  click  the  Find  button.    
 

559 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
As  you  can  see  above,  the  “HQ_PHONE_LOC”  is  actually  communicating  to  the  “SB_PHONE_LOC”  via  
“Hub_None”.  Uh  oh.  This  was  not  intended—what  do  we  do  now?  Believe  or  not,  this  is  actually  a  
useful  feature  for  us  here.  Since  the  “Hub_None”  Location  is  created  on  each  CUCM  cluster,  the  LBM  
service  considers  it  a  shared  Location  (the  names  must  exactly  match).  The  “HQ_PHONE_LOC”  has  a  
direct  connection  to  “Hub_None”  as  does  the  “SB_PHONE_LOC”  Location.  CUCM  then  assumes  that  
since  “Hub_None”  is  a  shared  Location  between  the  clusters,  that  it  must  traverse  that  path  instead.  To  
work  around  this  issue,  we  simply  must  rename  the  “Hub_None”  Location  on  one  of  the  CUCM  
clusters.  At  that  point,  it  will  no  longer  be  considered  a  shared  Location.    
 
On  the  SB  CUCM  cluster,  navigate  to  System  !  Location  Info  !  Location  and  click  the  Find  button.  
Click  on  the  “Hub_None”  Location  to  edit  it.  Change  the  name  of  the  Location  to  something  descriptive  
(e.g.  “SB_Hub_None”)  and  click  the  Save  button.  
 

 
 
With  the  name  of  the  Location  changed,  an  Effective  Path  can  be  chosen  through  the  datacenters.  
Once  again,  navigate  to  the  Cisco  Unified  Serviceability  webpage  and  go  to  Tools  !  Locations  !  
Effective  Path.  Select  the  Location  names  from  the  dropdown  box  and  click  the  Find  button.  
 

560 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
As  you  can  see  from  the  above,  the  path  that  traverses  Las  Vegas  and  Kansas  City  is  now  being  used  as  
the  Effective  Path  for  all  communication  between  HQ  and  SB.  Bandwidth  values  between  the  
datacenters  are  currently  set  to  “Unlimited”  while  the  bandwidth  setting  has  a  maximum  value  of  310  
kbps  from  each  site  to  each  datacenter.      

561 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 33.5 There  should  also  be  bandwidth  for  100  total  calls  between  datacenters.  
 
With  the  network  completely  modeled,  we  can  now  fine-­‐tune  the  configuration  with  bandwidth  values  
between  the  datacenters.  In  reality,  there  could  be  numerous  sites  with  a  connection  through  these  
datacenters,  so  it  would  be  a  good  idea  to  track  the  bandwidth  at  a  value  other  than  “Unlimited”  to  
successfully  deploy  CAC.  
 
Since  the  network  was  modeled  completely  on  the  HQ  CUCM  cluster,  we  must  make  the  required  
changes  there.  Navigate  to  System  !  Location  !  Location  Info  and  click  the  “DENVER_DC_LOC”  
Location.  Click  the  existing  Link  to  the  “ST_LOUIS_DC_LOC”  Location  to  modify  it.  In  the  popup  
window,  configure  the  “Audio  Bandwidth”  for  the  Link  to  use  “3100”  kbps,  since  we  must  allow  for  100  
iLBC  calls.  Click  the  Save  button  when  complete.  
 

 
 
The  Location  settings  for  the  “DENVER_DC_LOC”  should  now  be  displayed  as  shown  below.  
 

 
 
Next,  modify  the  “Audio  Bandwidth”  settings  for  the  remaining  datacenter  locations  on  the  HQ  CUCM  
cluster.  
 
   

562 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

KANSAS_CITY_DC_LOC  
 

 
 
LAS_VEGAS_DC_LOC  
 

 
 
ST_LOUIS_DC_LOC  
 

 
 
Once  the  bandwidth  values  are  modified,  navigate  to  the  Cisco  Unified  Serviceability  webpage  and  go  
to  Tools  !  Locations  !  Effective  Path.  Select  the  site  Location  names  from  the  dropdown  box  and  
click  the  Find  button  to  verify  the  changes  were  successfully  made  to  the  path.  
 

563 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 33.6 When  HQ  calls  SB  and  vice  versa,  location  bandwidth  should  be  deducted  from  all  
locations  on  the  path  between  HQ  and  SB.  This  information  should  be  reflected  in  
both  the  HQ  and  SB  clusters.  The  Shadow  location  should  be  used  in  some  fashion.  
 
Now  that  the  network  is  completely  modeled  and  bandwidth  values  have  been  assigned,  let’s  make  a  
test  call  between  HQ  and  SB.  A  SIP  trunk  must  be  used  here  in  order  to  properly  deduct  bandwidth  
values  along  the  path.  In  this  case,  we  are  in  luck!  We  have  already  configured  the  SIP  trunk  between  
the  HQ  and  SB  CUCM  clusters  in  a  previous  task.  HQ  users  must  dial  a  4-­‐digit  number  to  reach  SB  users  
and  SB  users  must  dial  a  “1”  plus  the  remaining  4  digits  to  reach  an  HQ  user.  
 
Once  again,  navigate  to  the  Cisco  Unified  Serviceability  webpage  and  go  to  Tools  !  Locations  !  
Effective  Path.  Select  the  site  Location  names  from  the  dropdown  box  and  click  the  Find  button.  This  
will  allow  the  monitoring  of  the  bandwidth  that  is  currently  being  utilized.  Make  the  test  call  between  
an  HQ  phone  and  an  SB  phone.  You  will  notice  that  the  call  completes  successfully,  but  does  not  
deduct  the  available  bandwidth  along  the  path  at  all!    
 

 
 
The  reason  for  this  was  the  omission  of  one  key  step  in  the  process—the  configuration  of  the  Shadow  
Location  on  the  SIP  trunk.  
 
The  “Shadow”  location  is  used  to  enable  a  SIP  trunk  to  pass  Enhanced  Locations  CAC  information  such  
as  location  name  and  Video-­‐Traffic-­‐Class,  among  other  things,  required  for  Enhanced  Locations  CAC  to  
function  across  clusters.  In  order  to  pass  this  location  information  across  clusters,  the  SIP  intercluster  
trunk  (ICT)  must  be  assigned  to  the  "shadow"  location.  Similar  to  the  "phantom"  location,  it  cannot  
have  a  link  to  other  locations,  and  therefore  no  bandwidth  can  be  reserved  between  the  shadow  
location  and  other  locations.  Any  device  other  than  a  SIP  ICT  that  is  assigned  to  the  shadow  location  
will  be  treated  as  if  it  was  associated  to  Hub_None.  That  is  important  to  know  because  if  a  device  other  
than  a  SIP  ICT  ends  up  in  the  shadow  location,  bandwidth  deductions  will  be  made  from  that  device  as  
if  it  were  in  Hub_None,  and  that  could  have  varying  effects  depending  on  the  location  and  links  
configuration.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/9x/uc9x/cac.html#wp1487804]    

564 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  make  the  required  configuration  change  on  the  HQ  CUCM  cluster,  navigate  to  Device  !  Trunk  and  
click  on  the  “SB_SIP_ICT_TRUNK”.  Under  the  “Device  Information”  section,  select  the  “Shadow”  option  
from  the  “Location”  dropdown  box.  
 

 
 
Click  the  Save  and  Reset  buttons  when  complete  to  apply  the  configuration.  Make  sure  to  perform  the  
configuration  on  the  SB  CUCM  cluster  as  well.  
 
Now  make  another  test  call  and  observe  the  Effective  Path  information  to  ensure  that  bandwidth  is  
deducted  appropriately.  
 

 
 
   

565 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 33.7 Ensure  that  E-­‐LCAC  prefers  to  traverse  the  Denver/St.  Louis  path.  
 
The  last  piece  of  the  puzzle  for  our  E-­‐LCAC  configuration  is  path  selection.  In  order  to  force  the  LBM  
service  to  select  a  particular  path,  it  must  have  a  lower  cumulative  weight  than  other  paths.  With  that  
said,  the  only  configuration  that  must  be  performed  here  is  to  change  the  Weight  setting  on  one  Link  in  
the  path  to  prefer  one  to  another.  As  shown  above,  the  path  that  is  currently  preferred  is  the  Las  
Vegas/Kansas  City  path,  so  we  can  either  increase  the  Weight  of  this  path  or  lower  the  Weight  of  the  
desired  path.  
 
Navigate  to  System  !  Location  Info  !  Location  and  click  the  “DENVER_DC_LOC”  Location.  Click  on  the  
link  for  the  “HQ_PHONE_LOC”  to  modify  the  Link.  In  the  popup  window,  for  the  “Weight”  parameter,  
set  the  value  to  a  number  less  than  50  (e.g.  “49”)  and  click  the  Save  button.  
 

 
 
Now  navigate  to  the  Cisco  Unified  Serviceability  webpage  and  go  to  Tools  !  Locations  !  Effective  
Path.  Select  the  site  Location  names  from  the  dropdown  box  and  click  the  Find  button.  The  Effective  
Path  should  now  be  updated  to  use  the  Denver/St.  Louis  option.  Keep  in  mind  that  this  may  take  a  few  
minutes  to  be  reflected  within  this  view.  
 

 
 

566 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 34: RSVP Configuration


Task 34.1 Reconfigure  the  phone  device  pools  to  use  <None>  as  the  location.  Create  a  new  SIP  
trunk  between  the  HQ  and  SB  cluster  using  port  5099  for  the  communication.  Users  
should  dial  a  7,  followed  by  the  4-­‐digit  extension  to  reach  users  on  other  clusters.  
 
In  this  section,  we  will  be  configuring  Resource  Reservation  Protocol  (RSVP)  to  perform  Call  Admission  
Control  (CAC)  on  the  network.  In  preparation  for  this,  we  must  remove  the  existing  EL-­‐CAC  
configuration  that  was  applied  in  the  previous  section.  Also,  in  order  to  allow  for  clean  separation  of  
objectives,  we  must  create  a  new  SIP  trunk  to  be  utilized  specifically  for  RSVP.  
 
On  both  the  HQ  and  SB  CUCM  clusters,  navigate  to  System  !  Device  Pool  and  click  on  the  Device  Pool  
assigned  to  the  phones  on  that  cluster  (e.g.  “HQ_PHONE_DP”).  Modify  the  Location  setting  to  use  the  
<None>  Location  and  click  the  Save  button.  Make  sure  to  click  the  Reset  button  to  apply  the  
configuration.  
 

 
 
Next,  before  creating  the  SIP  trunk,  we  must  create  a  new  SIP  Trunk  Security  Profile  to  define  the  port  
on  which  the  connection  should  be  made.  Once  created,  it  can  be  assigned  to  the  SIP  ICT.  On  both  the  
HQ  and  SB  CUCM  clusters,  navigate  to  System  !  Security  !  SIP  Trunk  Security  Profile.  Make  a  copy  of  
the  “Non  Secure  SIP  Trunk  Profile”  and  provide  a  descriptive  “Name”  (e.g.  “Non  Secure  SIP  Trunk  
Profile  -­‐  SB_RSVP_SIP_ICT”).  Modify  the  “Incoming  Port”  setting  to  use  “5099”  so  the  ICT  can  accept  
connection  requests  made  to  that  port  and  click  the  Save  button.  
 

 
 
   

567 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Device  !  Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  Type”  as  “SIP  
Trunk”  and  click  the  Next  button  to  continue.  
 

 
 
Next,  enter  a  descriptive  “Device  Name”  for  the  SIP  trunk  (e.g.  “SB_RSVP_SIP_ICT”)  and  assign  an  
appropriate  Device  Pool  (e.g.  “SB_RSVP_SIP_DP”).  Once  again,  the  best  policy  is  to  create  a  separate  
Device  Pool  for  every  phone,  gateway,  or  trunk  in  the  system,  so  as  to  provide  the  greatest  
configuration  flexibility  down  the  road.  In  this  case,  a  Device  Pool  has  been  created  for  the  specific  
purpose  of  assigning  to  the  SIP  ICT.  
 

 
 
Next,  under  the  “Inbound  Calls”  section,  assign  a  “Calling  Search  Space”  that  has  access  to  the  Partition  
corresponding  to  the  DNs  in  the  system  (e.g.  “GW_TRUNK_CSS”).  
 

 
 
Next,  define  the  IP  address  of  the  remote  system  (e.g.  “10.10.23.11”)  along  with  the  port  that  will  be  
used  to  make  the  outbound  connection  (e.g.  “5099”).    
 

 
 

568 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  select  the  “SIP  Trunk  Security  Profile”  that  was  previously  created  (e.g.  “Non  Secure  SIP  Trunk  
Profile  -­‐  SB_RSVP_SIP_ICT”)  and  the  “Standard  SIP  Profile”  for  the  “SIP  Profile”  setting.    
 

 
 
Click  the  Save  and  Reset  buttons  when  complete  to  apply  the  configuration.  Remember  to  create  the  
trunk  on  the  SB  CUCM  cluster  as  well.  
 
Once  the  SIP  trunk  has  been  created,  create  a  Route  Group  and  Route  List  to  contain  the  newly  created  
SIP  trunk.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Group/Route  List  to  set  the  configuration.  
 
Route  Group  

 
 
Route  List  

 
 

569 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  configure  the  Route  Pattern  for  reaching  the  other  cluster  by  navigating  to  Call  Routing  !  
Route/Hunt  !  Route  Pattern  and  clicking  the  Add  New  button.  Enter  the  “Route  Pattern”  as  “7.2XXX”  
and  select  an  appropriate  “Partition”  from  the  dropdown  list  (e.g.  “SB_PT”).  
 

 
 
Next,  for  the  “Gateway/Route  List”  parameter,  select  the  Route  List  that  was  previously  created  (e.g.  
“SB_RSVP_SIP_RL”).  
 

 
 
Next,  under  the  “Called  Party  Transformations”  section,  select  the  “PreDot”  option  from  the  “Discard  
Digits”  dropdown  box  to  strip  the  “7”  from  the  number  as  it  is  routed  over  the  SIP  ICT.  
 

 
 
Click  the  Save  button  when  the  configuration  is  complete.    
 
To  test  the  configuration,  make  a  call  from  HQ  Phone  1  to  SB  Phone  1  by  dialing  the  number  72001  and  
ensure  that  the  call  completes  successfully.  Next,  call  in  the  reverse  direction  by  dialing  the  number  
71001.  Ensure  that  everything  is  in  working  order.  
 
   

570 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 34.2 Configure  the  G.729  codec  between  HQ  and  SB  over  the  newly  created  trunk.  
 
Now  that  the  SIP  ICT  has  been  created  on  both  the  HQ  and  SB  CUCM  clusters,  we  must  control  the  
codec  selection  by  using  Regions.  If  you  followed  my  suggestion  and  created  a  separate  Device  Pool  for  
the  SIP  trunk  in  the  previous  task,  then  you  have  nothing  to  do  here  but  create  a  Region  and  assign  it  to  
that  Device  Pool.  In  this  case,  the  “SB_RSVP_SIP_DP”  was  created  (“HQ_RSVP_SIP_DP”  on  the  SB  
CUCM  cluster)  and  assigned  to  the  SIP  ICT.  Create  a  Region  for  this  Device  Pool  by  navigating  to  System  
!  Region  Information  !  Region  and  clicking  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  
Region  (e.g.  “SB_RSVP_SIP_REG”)  and  click  the  Save  button  to  continue.  
 

 
 
No  further  configuration  is  necessary  within  the  Region  page  since  the  default  setting  for  interregion  
calls  is  to  use  the  G.729  codec,  which  meets  the  task  requirements.  Assign  the  Region  to  the  trunk  
Device  Pool  and  click  the  Save  and  Reset  buttons  to  apply  the  configuration  to  the  SIP  ICT.  
 

 
 
Make  sure  to  configure  the  Region  settings  on  both  the  HQ  and  SB  CUCM  clusters.  Make  a  test  call  
between  HQ  and  SB  phones  to  verify  that  the  G.729  codec  will  be  in  use.  
 

 
   

571 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 34.3 Configure  the  HQ  and  SB  CUCM  clusters  so  a  maximum  of  10  calls  are  allowed  
between  devices  at  HQ  and  SB.  You  must  use  RSVP-­‐enabled  Locations  to  achieve  this  
task.  You  are  not  allowed  to  use  any  physical  DSP  resources  on  the  HQ  or  SB  routers  
to  achieve  this  task.  
 
RSVP  allows  end  systems  to  request  QoS  guarantees  from  the  network.  The  need  for  network  resource  
reservations  differs  for  data  traffic  versus  for  real-­‐time  traffic,  as  follows:  
 
• Data  traffic  seldom  needs  reserved  bandwidth  because  internetworks  provide  datagram  
services  for  data  traffic.  This  asynchronous  packet  switching  may  not  need  guarantees  of  
service  quality.  End-­‐to-­‐end  controls  between  data  traffic  senders  and  receivers  help  ensure  
adequate  transmission  of  bursts  of  information.  
• Real-­‐time  traffic  (that  is,  voice  or  video  information)  experiences  problems  when  operating  
over  datagram  services.  Because  real-­‐time  traffic  sends  an  almost  constant  flow  of  information,  
the  network  "pipes"  must  be  consistent.  Some  guarantee  must  be  provided  that  service  
between  real-­‐time  hosts  will  not  vary.  Routers  operating  on  a  first-­‐in,  first-­‐out  (FIFO)  basis  risk  
unrecoverable  disruption  of  the  real-­‐time  information  that  is  being  sent.  
 
Data  applications,  with  little  need  for  resource  guarantees,  frequently  demand  relatively  lower  
bandwidth  than  real-­‐time  traffic.  The  almost  constant  high  bit-­‐rate  demands  of  a  video  conference  
application  and  the  bursty  low  bit-­‐rate  demands  of  an  interactive  data  application  share  available  
network  resources.  
 
RSVP  prevents  the  demands  of  traffic  such  as  large  file  transfers  from  impairing  the  bandwidth  
resources  necessary  for  bursty  data  traffic.  When  RSVP  is  used,  the  routers  sort  and  prioritize  packets  
much  like  a  statistical  time-­‐division  multiplexer  (TDM)  would  sort  and  prioritize  several  signal  sources  
that  share  a  single  channel.  
 
RSVP  mechanisms  enable  real-­‐time  traffic  to  reserve  resources  necessary  for  consistent  latency.  A  
video  conferencing  application  can  use  settings  in  the  router  to  propagate  a  request  for  a  path  with  the  
required  bandwidth  and  delay  for  video  conferencing  destinations.  RSVP  will  check  and  repeat  
reservations  at  regular  intervals.  By  this  process,  RSVP  can  adjust  and  alter  the  path  between  RSVP  end  
systems  to  recover  from  route  changes.  
 
Real-­‐time  traffic  (unlike  data  traffic)  requires  a  guaranteed  network  consistency.  Without  consistent  
QoS,  real-­‐time  traffic  faces  the  following  problems:  
 
• Jitter.  A  slight  time  or  phase  movement  in  a  transmission  signal  can  introduce  loss  of  
synchronization  or  other  errors.  
• Insufficient  bandwidth.  Voice  calls  use  a  digital  signal  level  0  (DS-­‐0  at  64  kbps),  video  
conferencing  uses  T1/E1  (1.544  Mbps  or  2.048  Mbps),  and  higher-­‐fidelity  video  uses  much  
more.  
• Delay  variations.  If  the  wait  time  between  when  signal  elements  are  sent  and  when  they  arrive  
varies,  the  real-­‐time  traffic  will  no  longer  be  synchronized  and  transmission  may  fail.  
• Information  loss.  When  signal  elements  drop  or  arrive  too  late,  lost  audio  cause’s  distortions  
with  noise  or  crackle  sounds.  The  lost  video  causes  image  blurring,  distortions,  or  blackouts.  

572 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

[Source:    
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfrsvp.html]  
 
RSVP  is  the  most  accurate  method  of  CAC  that  we  can  use  on  the  voice  network.  It  will  assist  in  
determining  if  it  is  “safe”  to  send  a  call  over  the  network  using  data  from  the  actual  routed  path.  Of  
course,  this  differs  from  the  EL-­‐CAC  method  used  on  CUCM  where  the  number  of  calls  are  counted  and  
are  in  no  way  synchronized  with  the  underlying  routed  network.    
 
The  basic  architecture  of  RSVP  consists  of  Media  Termination  Points  (MTPs)  and  RSVP-­‐aware  routers.  
The  MTPs  act  as  RSVP-­‐agents  that  attempt  to  reserve  network  bandwidth  on  behalf  of  the  phone.  The  
routers  receive  the  bandwidth  requests  and  can  either  permit  or  deny  the  call  across  the  network  
based  on  the  available  bandwidth.  Refer  to  the  following  diagram  for  a  visual  representation.  
 

 
 
With  endpoints  for  multiple  sites  registered  to  the  same  CUCM  cluster,  the  above  diagram  is  possible  
since  the  cluster  is  aware  of  the  status  of  both  endpoints  (since  they  are  locally  registered).  In  other  
words,  no  signaling  is  required  to  devices  that  exist  “outside”  of  the  system.  However,  in  a  situation  
where  a  call  that  requires  RSVP  must  be  completed  between  endpoints  registered  to  different  clusters,  
we  must  provide  signaling  to  that  endpoint  as  well  as  a  mechanism  to  allow  RSVP  to  operate.  In  this  
case,  we  need  to  employ  a  SIP  trunk  and  RSVP  SIP  Preconditions  in  order  to  make  reservations  along  
the  routed  path.  The  same  RSVP  logic  still  applies,  but  the  SIP  ICT  must  be  configured  to  wait  for  RSVP-­‐
approval  before  routing  the  call.    
 
RSVP  SIP  Preconditions  is  based  on  SIP  Preconditions  as  defined  in  RFC  3312  and  RFC  4032,  and  it  
offers  the  ability  for  Cisco  call  processing  products  to  negotiate  a  level  of  Quality  of  Service  and  
perform  call  admission  control  using  the  RSVP  protocol.  The  term  RSVP  SIP  Preconditions  is  used  to  
identify  the  passing  of  policy  information  elements,  or  preconditions,  over  SIP  signaling  to  negotiate  a  
Quality  of  Service  (QoS)  policy.  The  actual  RSVP  message  is  not  signaled  over  the  SIP  trunk;  only  the  
policy-­‐related  information  elements  are.  The  RSVP  messages  are  then  carried  over  by  the  RSVP  Agent  

573 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

or  RSVP-­‐capable  router.  This  use  of  SIP  preconditions  extends  the  negotiation  of  RSVP  Quality  of  
Service  policy  across  Unified  CM  clusters  as  well  as  to  Unified  CM  Express  and  SIP-­‐TDM  Cisco  IOS  
gateways  to  allow  for  synchronization  of  the  RSVP  layer  and  call  control  layer  between  these  various  
call  control  applications.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/9x/uc9x/cac.html#wp1191628]    
 
The  first  step  towards  creating  this  configuration  is  to  register  the  MTPs  that  will  be  used  as  RSVP  
agents  for  calls  between  HQ  and  SB  phones.  On  R1,  we  must  add  to  the  configuration  that  is  already  in  
place  by  creating  another  dspfarm profile.  We  must  specify  a  codec to  be  used  with  the  RSVP  
agent.  In  this  case,  it  will  be  the  G.729  codec,  since  that  is  what  is  used  between  HQ  and  SB.  Since  there  
is  only  one  codec  allowed,  and  G.711  is  the  default  codec,  we  must  remove  it  and  add  the  G.729  codec  
instead.  Next,  we  must  issue  the  codec pass-through  command,  since  it  is  required  to  support  
calls  from  CUCM.  Next,  enter  the  rsvp command  under  the  dspfarm profile.  This  will  enable  
RSVP  support  and  will  be  recognized  by  CUCM  as  such.  Next,  we  must  define  the  maximum
sessions  that  will  be  allowed  to  run  on  the  RSVP  agent.  Remember  to  use  the  software keyword  
here  to  avoid  using  hardware  resources  and  meet  the  requirements  of  the  question.  Lastly,  enter  the  
associate application sccp  command  to  tie  this  profile  to  the  SCCP  application.  We  must  
enter  the  same  commands  on  R2.  
 
R1  
R1(config)#dspfarm profile 4 mtp
R1(config-dspfarm-profile)#codec pass-through
R1(config-dspfarm-profile)#no codec g711ulaw
R1(config-dspfarm-profile)#codec g729r8
R1(config-dspfarm-profile)#rsvp
R1(config-dspfarm-profile)#maximum sessions software 20
R1(config-dspfarm-profile)#associate application SCCP
R1(config-dspfarm-profile)#no shutdown
 
R2  
R2(config)#dspfarm profile 3 mtp
R2(config-dspfarm-profile)#codec pass-through
R2(config-dspfarm-profile)#no codec g711ulaw
R2(config-dspfarm-profile)#codec g729r8
R2(config-dspfarm-profile)#rsvp
R2(config-dspfarm-profile)#maximum sessions software 20
R2(config-dspfarm-profile)#associate application SCCP
R2(config-dspfarm-profile)#no shutdown
 
   

574 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  register  the  MTP  by  adding  it  to  the  previously  configured  SCCP  group.    
 
R1  
R1#sh run | sec sccp
sccp local Loopback0
sccp ccm 10.10.13.12 identifier 1 priority 1 version 7.0
sccp ccm 10.10.13.11 identifier 2 priority 2 version 7.0
sccp
sccp ccm group 1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 3 register R1-VCONF
associate profile 1 register R1-MTP
associate profile 2 register R1-XCODE

R1#conf t
R1(config)#sccp ccm group 1
R1(config-sccp-ccm)#associate profile 4 register R1-RSVP
R1(config-sccp-ccm)#no sccp
R1(config)#sccp

R2  
R2#sh run | sec sccp
sccp local Loopback0
sccp ccm 10.10.23.11 identifier 1 priority 1 version 7.0
sccp
sccp ccm group 1
associate ccm 1 priority 1
associate profile 1 register R2-CONF
associate profile 2 register R2-MTP

R2#conf t
R2(config)#sccp ccm group 1
R2(config-sccp-ccm)#associate profile 3 register R2-RSVP
R2(config-sccp-ccm)#no sccp
R2(config)#sccp

With  the  MTPs  configured  within  IOS,  register  them  to  their  respective  CUCM  clusters  by  navigating  to  
Media  Resources  !  Media  Termination  Point  and  clicking  the  Add  New  button.  Use  the  name  that  was  
specified  in  the  dspfarm profile  to  register  the  MTP  (e.g.  “R1-­‐RSVP”)  and  select  an  appropriate  
Device  Pool.  
 

 
 
   

575 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  place  the  MTP  in  a  Media  Resource  Group  (MRG)  by  navigating  to  Media  Resources  !  Media  
Resource  Group  and  clicking  the  Add  New  button.  Enter  a  descriptive  name  (e.g.  “R1-­‐RSVP_MRG”)  and  
select  the  proper  resource  from  the  list  box.  Click  the  Save  button  when  completed.  
 

 
 
Next,  assign  the  MRG  to  a  Media  Resource  Group  List  (MRGL)  so  the  phones  can  invoke  it.  In  this  case,  
an  MRGL  has  already  been  created  and  assigned  to  the  phones  (e.g.  “HQ_MRGL”),  so  we  must  simply  
add  this  MRG  to  the  list.  Navigate  to  Media  Resources  !  Media  Resource  Group  List  and  click  on  the  
existing  MRGL  (e.g.  “HQ_MRGL”).  Add  the  “R1-­‐RSVP_MRG”  to  the  list  and  click  the  Save  button.  
 

 
 
Remember  to  perform  the  same  steps  on  the  SB  CUCM  cluster.    
 
Next,  we  must  define  Locations  within  CUCM  to  be  assigned  to  both  the  phone  and  the  SIP  ICT.  This  
will  determine  whether  or  not  RSVP  will  be  engaged  as  the  CAC  mechanism.  On  the  HQ  CUCM  cluster,  
navigate  to  System  !  Location  Info  !  Location  and  click  the  Add  New  button.  Since  this  Location  will  
be  assigned  to  the  Device  Pool  of  the  phones,  provide  an  appropriate  name  (e.g.  
“HQ_PHONE_RSVP_LOC”).    
 

 
 
   

576 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Under  the  “Links”  section,  you  may  leave  the  relationship  to  “Hub_None”  and  keep  the  default  
settings.  Click  the  Save  button  when  complete.  
 

 
 
Click  the  Add  New  button  again  to  add  another  Location.  This  time,  create  a  Location  to  be  assigned  to  
the  SB  SIP  ICT  (e.g.  “SB_RSVP_SIP_LOC”).    
 

 
 
Next,  under  the  “Links”  section,  select  the  “HQ_PHONE_RSVP_LOC”  that  was  previously  created  in  
order  to  configure  the  relationship  between  the  SIP  ICT  and  the  HQ  phones.  The  “Weight”  setting  can  
be  left  at  the  default  of  “50”,  since  that  only  pertains  to  EL-­‐CAC  redundant  links.  The  
“Audio/Video/Immersive  Bandwidth”  settings  can  be  set  to  “Unlimited”  in  this  case,  since  CAC  will  be  
controlled  completely  by  RSVP  instead.    
 

 
 
   

577 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lastly,  set  the  “RSVP  Setting”  for  the  “HQ_PHONE_RSVP_LOC”  to  “Mandatory”  to  indicate  that  calls  
should  not  be  placed  unless  the  RSVP  bandwidth  reservation  process  completes  successfully.  
 

 
 
Click  the  Save  button  when  complete.  Remember  to  perform  the  same  steps  on  the  SB  CUCM  cluster  
as  well.    
 
Next,  assign  the  newly  created  Locations  to  the  Device  Pools  of  the  phones  and  ICTs.  Navigate  to  
System  !  Device  Pool  and  click  on  the  “HQ_PHONE_DP”  link  and  set  the  “Location”  parameter  to  
“HQ_PHONE_RSVP_LOC”.  Click  the  Save  and  Reset  buttons  when  complete.  
 

 
 
Modify  the  “SB_RSVP_SIP_DP”  Device  Pool  as  well  to  include  the  proper  “Location”  setting  (e.g.  
“SB_RSVP_SIP_LOC”).  Click  the  Save  and  Reset  buttons  when  complete.  
 

 
 
Make  sure  to  perform  these  steps  on  the  SB  CUCM  cluster  as  well.  
 
With  the  Locations  created  and  assigned,  we  must  now  configure  the  SIP  ICTs  to  support  RSVP  SIP  
Preconditions.  Once  again,  this  step  is  not  necessary  if  the  phones  are  registered  to  the  same  cluster.  
Navigate  to  Device  !  Device  Settings  !  SIP  Profile  and  copy  the  “Standard  SIP  Profile”.  Rename  the  
profile  to  something  more  appropriate  (e.g.  “Standard  SIP  Profile  –  RSVP”).    
 

 
 
Scroll  down  to  the  “Trunk  Specific  Configuration”  section  and  set  the  “RSVP  Over  SIP”  parameter  to  
“E2E”.  This  will  instruct  the  SIP  trunk  to  use  end-­‐to-­‐end  RSVP  when  attempting  call  setup  with  the  
remote  end.    
 

578 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  for  the  “SIP  Rel1XX  Options”  parameter,  select  the  “Send  PRACK  for  all  1XX  Messages”  setting.  
This  will  force  the  SIP  trunk  to  respond  with  an  ACK  when  any  1XX  message  is  received.  
 

 
 
Click  the  Save  button  when  completed.  Perform  this  step  on  the  SB  CUCM  cluster  as  well.  
 
Next,  assign  the  newly  created  SIP  Profile  to  the  SIP  ICT  by  navigating  to  Device  !  Trunk  and  clicking  
on  the  “SB_RSVP_SIP_ICT”  that  was  previously  created.  Scroll  down  to  the  “SIP  Information”  section  
and  set  the  “SIP  Profile”  parameter  to  “Standard  SIP  Profile  –  RSVP”.  
 

 
 
Click  the  Save  and  Reset  buttons  when  completed  to  apply  the  configuration.  Perform  this  step  on  
both  the  HQ  and  SB  CUCM  clusters.  
 
The  final  step  is  to  set  the  RSVP  bandwidth  on  each  hop  in  the  routed  network  so  bandwidth  can  be  
successfully  reserved  along  the  path.  The  easiest  way  to  determine  the  actual  routed  path  that  is  used  
is  to  issue  the  show ip route  command.  Remember,  we  will  need  to  look  for  a  route  to  the  RSVP  
agent  associated  with  the  HQ  and  SB  phones  since  communication  happens  by  way  of  the  associated  
MTPs.  Specifically,  we’ll  need  to  look  at  the  “Loopback  0”  address  since  that  was  used  for  SCCP  media  
resource  registration.    
 
R1  
R1#sh ip route 10.10.2.2
Routing entry for 10.10.2.2/32
Known via "ospf 1", distance 110, metric 65, type intra area
Last update from 10.10.121.2 on Serial0/1/0.102, 00:40:35 ago
Routing Descriptor Blocks:
* 10.10.121.2, from 10.10.2.2, 00:40:35 ago, via Serial0/1/0.102
Route metric is 65, traffic share count is 1

R2  
R2#sh ip route 10.10.1.1
Routing entry for 10.10.1.1/32
Known via "ospf 1", distance 110, metric 65, type intra area
Last update from 10.10.121.1 on Serial0/1/0.201, 00:42:15 ago
Routing Descriptor Blocks:
* 10.10.121.1, from 10.10.1.1, 00:42:15 ago, via Serial0/1/0.201
Route metric is 65, traffic share count is 1

As  you  can  see  from  the  above,  the  interfaces  that  we  must  configure  are  Serial0/1/0.102  on  R1  and  
Serial  0/1/0.201  on  R2  since  traffic  is  routed  “via”  that  interface.  Of  course,  we  must  calculate  the  
maximum  bandwidth  to  be  used  to  meet  the  requirements  of  the  question  as  well.  Since  it  has  been  
defined  that  we  must  support  10  calls  (at  G.729),  we  should  calculate  the  bandwidth  using  that  
information.  
 
   

579 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

When  calculating  the  bandwidth  for  RSVP,  we  must  take  a  couple  different  values  into  account:  the  
initial  and  final  bandwidth.  The  initial  (“worst-­‐case”)  bandwidth  is  estimated  using  a  10  ms  sample  rate  
(40  kbps).  The  final  (actual)  bandwidth  is  chosen  based  on  the  sample  rate  that  is  negotiated  between  
endpoints  (20  ms  by  default;  24  kbps).  The  logic  here  is  that  RSVP  should  reserve  the  maximum  
possible  bandwidth  for  an  audio  call  in  the  case  where  the  10  ms  sample  rate  is  selected.  Then,  after  
the  call  has  been  negotiated,  the  actual  sample  rate  will  be  used.  With  this  in  mind,  since  we  must  
support  10  calls,  we  can  multiply  9  by  24  (216)  to  get  the  value  of  nine  currently  connected  calls  on  the  
link  at  a  20  ms  sample  rate.  Next,  we  must  allow  for  the  tenth  call,  which  RSVP  will  initially  treat  using  
the  “worst-­‐case”  logic  at  40  kbps.  Adding  216  to  40  yields  a  value  of  256  kbps  of  bandwidth  necessary  
for  10  G.729  calls  using  RSVP.  Therefore,  we  must  configure  the  ip rsvp bandwidth 256  
command  on  the  Serial  interfaces  of  both  R1  and  R2.  
 
R1  
R1(config)#interface Serial 0/1/0.102
R1(config-subif)#ip rsvp bandwidth 256
 
R2  
R2(config)#interface Serial 0/1/0.201
R2(config-subif)#ip rsvp bandwidth 256

At  this  point  we  can  finally  make  a  test  call  between  HQ  and  SB  phones.  From  HQ  Phone  1,  dial  72001  
to  dial  SB  Phone  2.  The  call  should  complete  successfully.  While  the  call  is  active,  issue  the  command  
show ip rsvp reservation  from  both  R1  and  R2  to  display  statistics  on  the  call.  
 
R1  
R1#sh ip rsvp reservation
To From Pro DPort Sport Next Hop I/F Fi Serv BPS
10.10.1.1 10.10.2.2 UDP 16384 16384 none none FF LOAD 24K
10.10.2.2 10.10.1.1 UDP 16384 16384 10.10.121.2 Se0/1/0. FF LOAD 24K
 
R2  
R2#sh ip rsvp reservation
To From Pro DPort Sport Next Hop I/F Fi Serv BPS
10.10.1.1 10.10.2.2 UDP 16384 16384 10.10.121.1 Se0/1/0. FF LOAD 24K
10.10.2.2 10.10.1.1 UDP 16384 16384 none none FF LOAD 24K

From  the  above,  we  can  see  that  the  call  is  currently  up  between  the  RSVP  agents  assigned  to  each  
phone.  Also,  the  router  is  currently  using  24  kbps  as  the  bandwidth  value  for  the  connected  call.  If  you  
are  having  issues  getting  the  call  to  complete,  try  using  the  debug ip rsvp resv  command  to  
capture  the  call  setup  activity  and  troubleshoot.    
 
R2  
R2#debug ip rsvp resv
RSVP resv debugging is on
...
Dec 16 23:53:03.412: RSVP: 10.10.1.1_16390->10.10.2.2_16388[0.0.0.0]: start requesting 40 kbps FF
reservation on Serial0/1/0.201, neighbor 10.10.121.1
Dec 16 23:53:03.416: RSVP: 10.10.1.1_16390->10.10.2.2_16388[0.0.0.0]: start requesting 40 kbps FF
reservation on Serial0/1/0.201, neighbor 10.10.121.1
...
Dec 16 23:53:04.492: RSVP: 10.10.1.1_16390->10.10.2.2_16388[0.0.0.0]: start requesting 24 kbps FF
reservation on Serial0/1/0.201, neighbor 10.10.121.1

580 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Seven  Labs  35  -­‐  36  
Version  1.0  

581 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 7: Configuring and Troubleshooting High Availability Features


Lab 35: CUCM Automated Alternate Routing
Task 35.1 Configure  two  new  Device  Pools  on  the  SB  CUCM  cluster,  one  for  SB  Phone  1  and  
one  for  SB  Phone  2.  When  CUCM  CAC  blocks  a  call  originating  from  either  SB  Phone  
1  or  SB  Phone  2,  the  call  must  be  transparently  rerouted  out  of  the  PSTN.  Use  
whatever  CAC  method  you  desire  to  block  the  call.  
 
Cisco  Unified  Communications  Manager  automatically  reroutes  calls  through  the  PSTN  or  other  
networks  when  Cisco  Unified  Communications  Manager  blocks  a  call  due  to  insufficient  location  
bandwidth.  With  automated  alternate  routing,  the  caller  does  not  need  to  hang  up  and  redial  the  
called  party.  The  Automated  Alternate  Routing  (AAR)  feature  enables  Cisco  Unified  Communications  
Manager  to  establish  an  alternate  path  for  the  voice  media  when  the  preferred  path  between  two  
intra-­‐cluster  endpoints  runs  out  of  available  bandwidth,  as  determined  by  the  locations  mechanism  for  
CAC.  
[Source:  
 http://www.cisco.com/c/en/us/support/docs/voice-­‐unified-­‐communications/unified-­‐communications-­‐
manager-­‐version-­‐80/113478-­‐aar-­‐config.html]    
 
Since  AAR  is  only  applicable  on  a  single  cluster,  it  is  necessary  for  us  to  create  two  separate  Device  
Pools  for  the  phones  at  SB.  This  creates  the  “appearance”  of  two  sites  on  the  cluster  and  can  help  us  
explore  the  feature.  First,  navigate  to  System  !  Device  Pool  and  click  on  the  “SB_PHONE_DP”  link.  
Click  the  Copy  button  and  name  the  new  Device  Pool  appropriately  (e.g.  “SB_PHONE_1_DP”).  
 

 
 
Click  the  Save  button  when  complete.  Create  another  copy  to  configure  the  Device  Pool  for  SB  Phone  2  
(e.g.  “SB_PHONE_2_DP”).    
 
Next,  assign  the  Device  Pools  to  each  phone  by  navigating  to  Device  !  Phone  and  clicking  each  phone.  
Set  the  “Device  Pool”  parameter  to  the  newly  created  Device  Pool  corresponding  to  that  phone.  
 

 
 

 
 
Remember  to  click  the  Save  and  Reset  buttons  when  complete.  
 

582 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  create  Locations  in  order  to  deny  a  call  using  CAC.  Navigate  to  System  !  Location  Info  
!  Location  and  click  the  Add  New  button.  Enter  a  descriptive  name  for  the  first  location  (e.g.  
“SB_PHONE_1_LOC”)  and  keep  the  default  settings  (link  to  “Hub_None”).    
 

 
 
Create  a  Location  for  SB  Phone  2  with  the  same  settings  as  well.  
 

 
 
Next,  click  on  the  “SB_PHONE_1_LOC”  and  click  the  Add  button  to  add  a  new  “Link”.  Select  the  
“SB_PHONE_2_LOC”  and  configure  the  “Audio  Bandwidth”  setting  to  use  less  than  that  which  is  
required  for  one  G.711  audio  call  (80  kbps).  This  will  prevent  calls  from  being  made  between  phones.  
 

583 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  assign  the  newly  created  Locations  to  each  Device  Pool.  Click  the  Save  and  Reset  buttons  to  
apply  the  configuration  to  the  phones.  
 

 
 

 
 
At  this  point,  we  have  configured  the  SB  CUCM  cluster  to  deny  all  calls  between  SB  phones  due  to  
insufficient  bandwidth.  Make  a  test  call  between  SB  phones  to  confirm.  
 

 
 
Just  as  we  suspected,  we  are  faced  with  the  “Not  Enough  Bandwidth”  message.  Obviously  this  is  what  
AAR  is  designed  to  fix—routing  around  network  congestion  towards  the  PSTN.  The  first  step  towards  
configuring  AAR  is  to  create  an  AAR  group.  As  long  as  both  the  calling  and  called  device  are  in  the  same  
AAR  Group,  CUCM  will  attempt  to  initiate  a  call  to  the  number  created  by  the  combination  of  the  DN  
and  External  Phone  Number  Mask  on  the  line.  For  example,  if  the  DN  is  2001  and  the  External  Phone  
Number  Mask  is  +1312333XXXX,  CUCM  will  attempt  to  call  the  number  +13123332001.  It  will  use  a  
special  Calling  Search  Space  called  the  AAR  CSS  (assigned  to  the  Phone  or  Device  Pool)  to  provide  
access  to  the  patterns  necessary  to  route  the  call.    
 
To  create  the  AAR  Group,  navigate  to  Call  Routing  !  AAR  Group  and  click  the  Add  New  button.  Enter  a  
descriptive  “Name”  for  the  group  (e.g.  “SB_AAR”)  and  click  the  Save  button.    
 

584 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  AAR  Group  has  been  created,  we  must  also  assign  it  to  the  Device  Pool  of  the  phones  as  
well  as  the  lines.  Navigate  to  System  !  Device  Pool  and  click  on  the  “SB_PHONE_1_DP”.  Under  the  
“Device  Mobility  Related  Information”  section,  set  the  “AAR  Group”  parameter  to  “SB_AAR”  and  click  
the  Save  button.  
 

 
 
Perform  the  same  steps  for  the  “SB_PHONE_2_DP”  Device  Pool.  
 
Next,  navigate  to  Device  !  Phone  and  click  on  “SB  Phone  1”.  Click  on  the  “Line  [1]  -­‐  2001  in  
INTERNAL_PT”  link  to  open  the  “Directory  Number  Configuration”  page.  Under  the  “AAR  Settings”  
section,  set  the  “AAR  Group”  to  “SB_AAR”  and  click  the  Save  button.  Click  the  Apply  Config  button  to  
restart  the  phone  with  the  new  configuration.  
 

 
 
Perform  the  same  steps  on  “SB  Phone  2”.  
 
Next,  we  must  create  the  AAR  CSS  in  order  to  route  calls  to  the  AAR  destination.  Since  this  number  will  
be  dialed  using  a  plus  (+),  we  can  take  advantage  of  the  patterns  that  were  implemented  in  earlier  labs.  
We  just  need  to  select  the  correct  Partition.  A  good  way  to  search  for  this  would  be  to  navigate  to  Call  
Routing  !  Route  Plan  Report  and  search  for  Patterns  that  begin  with  “\+”.  
 

 
 
As  you  can  see  in  the  above,  we  should  probably  select  the  “PLUS_DIAL_PT”  for  the  AAR  CSS  since  that  
is  where  the  patterns  (Translation  Patterns  in  this  case)  exist.    
 
   

585 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Navigate  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  click  the  Add  New  button.  
Enter  a  descriptive  name  for  the  CSS  (e.g.  “AAR_CSS”)  and  select  the  “PLUS_DIAL_PT”  from  the  list  box.  
 

 
 
Click  the  Save  button  when  complete.  
 
With  the  CSS  created,  simply  assign  it  to  the  Device  Pools  for  both  “SB  Phone  1”  and  “SB  Phone  2”  by  
navigating  to  System  !  Device  Pool.  
 

 
 
Click  the  Save  and  Reset  buttons  to  apply  the  configuration  to  the  phones.  
 
With  the  AAR  Group  and  AAR  CSS  configured,  all  that  is  left  is  to  actually  turn  the  feature  on!    We  must  
navigate  to  System  !  Service  Parameters  !  10.10.23.11  !  Cisco  CallManager.  Under  the  
“Clusterwide  Parameters  (System  –  CCM  Automated  Alternate  Routing)”  section,  set  the  “Automated  
Alternate  Routing  Enable”  parameter  to  “True”.  Click  the  Save  button  when  complete.  
 

 
 
   

586 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  make  a  test  call  from  “SB  Phone  1”  to  “SB  Phone  2”  and  observe  the  behavior.  You  will  notice  
that  the  call  will  not  route  successfully,  but  the  phone  will  display  the  “Network  congestion,  rerouting”  
message.  We  will  discuss  the  reason  for  the  call  failure  during  the  next  task.    
 

 
 
   

587 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 35.2 The  Calling  Name  should  be  sent  to  the  PSTN  and  the  Calling  Number  should  be  7-­‐
digits.  The  call  will  not  work;  it  should  be  verified  using  Q931  debug  commands.  
 
As  mentioned  in  the  previous  task,  the  call  does  not  work  when  AAR  is  engaged.  Let’s  have  a  look  at  
the  debug  and  see  what  we’re  up  against.  Enter  the  debug isdn q931  command  on  the  R2  
gateway  and  make  another  test  call.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

...
Dec 17 08:42:46.603: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0088
...
Display i = 'SB Phone 2'
Calling Party Number i = 0x4181, '3332002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '3332001'
Plan:ISDN, Type:Subscriber(local)
Redirecting Number i = 0x000180, '2001'
Plan:Unknown, Type:Unknown
Dec 17 08:42:46.643: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8088
Channel ID i = 0xA98383
Exclusive, Channel 3

Dec 17 08:42:46.651: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x0087


...
Display i = 'SB Phone 2'
Calling Party Number i = 0x4181, '3332002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '3332001'
Plan:ISDN, Type:Subscriber(local)
Redirecting Number i = 0x000080, '2001'
Plan:Unknown, Type:Unknown
...
Dec 17 08:42:46.655: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8087
Channel ID i = 0xA98381
Exclusive, Channel 1
Dec 17 08:42:46.655: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x8087
Cause i = 0x8081 - Unallocated/unassigned number
...
 
According  to  the  above  debug  output,  the  call  is  successfully  exiting  the  ISDN  interface  on  the  R2  
router.  As  expected,  the  call  is  then  being  sent  back  to  this  router  since  the  number  (3332001)  exists  
on  this  circuit.  The  “Unallocated/unassigned  number”  error  is  then  displayed.  
 
Think  back  to  how  inbound  PSTN  calls  were  routed  to  the  SB  CUCM  cluster  from  the  R2  gateway.  
Normal  inbound  calls  match  dial-peer voice 1 pots  upon  entering  the  router,  pass  through  a  
translation-profile,  and  then  get  routed  through  dial-peer voice 2000 voip  
towards  the  SB  CUCM  cluster.  
 
   

588 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
R2#sh run | sec dial-peer voice 1 pots
dial-peer voice 1 pots
translation-profile incoming TRANSLATE-PSTN-INBOUND
incoming called-number .
direct-inward-dial

R2#sh run | sec voice trans


...
voice translation-rule 100
rule 1 /^[2-9]......$/ /+1312\0/ type subscriber subscriber plan isdn isdn
rule 2 /^[2-9]..[2-9]......$/ /+1\0/ type national national plan isdn isdn
rule 3 /.*/ /+\0/ type international international plan isdn isdn
voice translation-rule 101
rule 1 /^1\([2-9]..[2-9]......\)$/ /\1/
...
voice translation-profile TRANSLATE-PSTN-INBOUND
translate calling 100
translate called 101

R2#sh run | sec dial-peer voice 2000


dial-peer voice 2000 voip
destination-pattern 3123332...$
session protocol sipv2
session target ipv4:10.10.23.11
dtmf-relay rtp-nte sip-notify
codec g711ulaw
no vad

Based  on  the  above  output,  we  can  see  that  the  reason  is  failing  is  because  no  rule  exists  to  accept  a  7-­‐
digit  number  from  the  PSTN  within  voice translation-rule 101.  If  we  add  a  rule  that  accepts  
the  number,  the  call  should  succeed.  
 
R2  
R2(config)#voice translation-rule 101
R2(cfg-translation-rule)#rule 2 /^3332...$/ /312\0/
 
Converting  the  number  to  10-­‐digit  format  will  allow  it  to  match  dial-peer voice 2000  and  be  
sent  out  to  the  SB  CUCM  cluster.  Make  another  test  call  and  enter  the  show call active voice  
command  on  R2  to  verify  the  call  legs  are  being  routed  through  the  PSTN.  
 
R2  
R2#sh call active voice
Telephony call-legs: 2
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 4
...
 
   

589 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 35.3 Calls  to  SB  Phone  1  should  ring  the  PSTN  number  “3127764016”  when  there  is  
network  congestion.  However,  the  banner  at  the  top  of  the  screen  of  SB  Phone  1  
should  reflect  the  correct  +E164  DID  number  (+13123332001).  
 
In  order  to  route  the  call  to  a  different  destination  during  network  congestion,  but  maintain  the  same  
external  phone  number  mask,  we  can  set  a  parameter  within  the  “Directory  Number  Configuration”  
page  called  the  “AAR  Destination  Mask”.  This  setting  is  specifically  available  for  routing  the  call  to  an  
alternate  destination  in  the  case  of  network  congestion.  Best  of  all,  setting  it  does  not  affect  the  
display  of  the  phone  at  all.  
 
Navigate  to  Device  !  Phone  and  click  on  “SB  Phone  1”.  Click  on  the  “Line  [1]  -­‐  2001  in  INTERNAL_PT”  
link  to  enter  the  “Directory  Number  Configuration”  page.  Under  the  “AAR  Settings”  section,  set  the  
“AAR  Destination  Mask”  to  “+13127764016”.  This  will  direct  the  CUCM  cluster  to  dial  the  +E.164  
number  of  the  SB  PSTN  phone  during  periods  of  network  congestion.  Once  again,  the  AAR  CSS  dictates  
access  to  patterns  that  support  the  dialed  number.  
 

 
 
Click  the  Save  and  Apply  Config  buttons  to  set  the  configuration.  
 
Make  a  test  call  from  “SB  Phone  2”  to  “SB  Phone  1”  and  ensure  that  the  SB  PSTN  phone  rings.  Issue  the  
debug isdn q931  command  on  R2  to  view  the  details.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Dec 17 10:35:54.853: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x4 0x1, Calling num
3332002
Dec 17 10:35:54.853: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x008B callID = 0x800C switch =
primary-ni interface = User
Dec 17 10:35:54.853: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x008B
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = 'SB Phone 2'
Calling Party Number i = 0x4181, '3332002'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '7764016'
Plan:ISDN, Type:Subscriber(local)
Redirecting Number i = 0x000180, '2001'
Plan:Unknown, Type:Unknown
Dec 17 10:35:54.893: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x808B
Channel ID i = 0xA98383
Exclusive, Channel 3
Dec 17 10:35:55.165: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808B
 

590 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 35.4 When  a  caller  from  a  SB  local  PSTN  number  calls  an  employee  located  at  the  SB  
office  and  subsequently  asks  the  employee  to  be  transferred  to  another  PSTN  
number,  the  transfer  should  be  denied.  
 
To  thoroughly  understand  the  question,  make  a  test  call  from  the  SB  PSTN  Phone  into  “SB  Phone  1”.  
When  the  call  is  answered,  press  the  “Transfer”  softkey  on  the  phone  and  dial  a  PSTN  number,  such  as  
901149307128788  (SC  PSTN  Phone).  When  the  call  is  connected,  press  the  “Transfer”  softkey  again  to  
complete  the  transfer.  The  call  is  then  transferred  successfully  to  the  SC  PSTN  line  on  the  phone.    
 
This  can  be  an  undesired  behavior  in  corporate  environments  due  to  employees  trying  to  “help  
someone  out”  and  transfer  them  (as  a  PSTN  caller)  to  an  international  destination  on  the  company’s  
dime.  Sometimes  it  may  even  happen  without  the  user  realizing  it—an  honest  mistake.  Whatever  the  
reason,  in  this  case,  we  must  deny  this  from  happening.  In  order  to  block  this  behavior,  we  must  first  
begin  with  call  classification.  Route  Patterns  must  have  a  call  classification  assigned—either  “OffNet”  
or  “OnNet”,  with  the  former  being  the  default.  Based  on  this  fact,  depending  on  the  pattern  that  is  
dialed  by  the  user,  the  call  can  be  marked  using  either  option.    
 

 
 
This  option  also  exists  on  Gateways  and  Trunks  so  calls  can  be  classified  as  they  are  routed  inbound.  
Once  again,  the  default  is  to  classify  the  call  as  “OffNet”.    
 

 
 
With  that  said,  both  calls  in  the  above  example  were  classified  as  “OffNet”  since  the  R2  SIP  trunk  
classified  the  inbound  call  and  the  outbound  call  was  classified  using  a  Route  Pattern.  Now,  if  there  
were  only  a  way  to  block  “OffNet”  to  “OffNet”  transfers!    That  is,  in  fact,  what  we  will  have  to  do  to  
meet  the  requirements  of  the  question.    
 
Navigate  to  System  !  Service  Parameters  !  10.10.23.11  !  Cisco  CallManager  and  locate  the  
“Clusterwide  Parameters  (Feature  -­‐  General)”  section.  In  this  section,  we  must  set  the  “Block  OffNet  To  
OffNet  Transfer”  parameter  to  “True”  using  the  dropdown  box.    
 

 
 
Click  the  Save  button  when  complete.  
 
   

591 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  make  another  test  call  and  observe  the  behavior.  At  this  point,  the  transfer  should  be  denied.  
 

 
 
   

592 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 35.5 Return  the  phones  to  the  normal  device  pool  settings  as  configured  in  the  previous  
lab.  
 
In  order  to  reset  the  configuration,  assign  the  “SB_PHONES_DP”  to  each  of  the  SB  Phones  and  click  the  
Save  and  Reset  buttons.  
 

593 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 36: CUCM High Availability


Task 36.1 Register  a  9971  to  the  SB  cluster  and  enable  video  capabilities.  You  may  borrow  this  
phone  from  either  HQ  or  SC  if  necessary  (set  Alternate  TFTP  to  “Yes”  and  change  the  
TFTP  server).    
 
In  preparation  for  the  “High  Availability  Features”  section,  we  must  register  a  9971  phone  to  the  SB  
CUCM  cluster  in  order  to  test  failover  for  SIP  phones  in  addition  to  SCCP  phones.  In  this  case,  let’s  
borrow  SC  Phone  2  for  this  purpose.  On  R3,  issue  the  show cdp neighbors  command  to  copy  the  
MAC  address  of  the  9971  phone.  If  you  are  using  the  rack  phones,  the  phone  should  be  located  on  the  
GigabitEthernet  0/2/1  port.  If  you  are  using  your  own  phones  over  the  VPN,  it  should  be  located  on  the  
GigabitEthernet  0/2/3  port.  
 
R3  
R3#sh cdp ne gi0/2/3 de
-------------------------
Device ID: SEP1C1D86C53EBF
Entry address(es):
IP address: 10.10.31.37
Platform: Cisco IP Phone 9971, Capabilities: Host Two-port Mac Relay
...
 
Next,  on  the  SB  CUCM  cluster,  navigate  to  Device  !  Phone  and  click  the  Add  New  button.  Select  the  
“Phone  Type”  from  the  dropdown  box  as  “Cisco  9971”  and  click  the  Next  button.  
 

 
 
Next,  specify  the  “MAC  Address”  found  above  for  the  phone  (e.g.  “1C1D86C53EBF”),  the  “Device  Pool”  
used  for  the  SB  Phones  (e.g.  “SB_PHONE_DP”),  the  standard  “Phone  Button  Template”,  and  the  
“Calling  Search  Space”  for  the  SB  phones  (e.g.  “PHONE_CSS”).    
 

 
 
   

594 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Make  sure  to  specify  both  the  default  “Device  Security  Profile”  and  “SIP  Profile”  as  well.  
 

 
 
Finally,  under  the  “Product  Specific  Configuration  Layout”  section,  select  “Enabled”  for  both  the  “Cisco  
Camera”  and  “Video  Capabilities”  parameters.    
 

 
 
Click  the  Save  button  to  save  the  configuration  
 
Next,  specify  a  line  by  clicking  the  “Line  [1]  –  Add  a  new  DN”  link  under  the  “Association  Information”  
section  of  the  “Phone  Configuration”  page.  Enter  “2011”  for  the  “Directory  Number”  and  select  the  
“INTERNAL_PT”.  Enter  an  “Alerting  Name”  to  identify  the  phone  as  well.  
 

 
 
Click  the  Save  and  Apply  Config  buttons  when  complete.  
 
Next,  configure  SC  Phone  2  to  register  with  the  SB  CUCM  cluster  by  changing  the  TFTP  server  to  the  IP  
address  of  the  SB  CUCM  server.  On  the  phone,  navigate  to  Settings  !  Administrator  Settings  !  Type  
Password  (“Cisco”  or  “cisco”)  !  Network  Setup  !  Ethernet  Setup  !  IPv4  Setup.  Within  this  menu,  set  
the  “Alternate  TFTP”  parameter  to  “Yes”  and  set  the  “TFTP  Server  1”  parameter  to  “10.10.23.11”.  
 

 
 
The  phone  will  then  register  with  the  SB  CUCM  cluster.  

595 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 36.2 Ensure  that  all  phones  (including  SCCP  and  SIP  phones)  at  the  SB  site  can  still  make  
and  receive  calls  if  there  is  a  WAN  outage.  Ensure  that  SCCP  phone  configuration  
remains  persistent  in  the  R2  configuration.  Keep  in  mind  that  this  requires  a  little  
creativity  since  the  CUCM  server  is  not  connected  over  a  WAN.  To  invoke  SRST,  we  
can  use  an  access  list  on  the  port  that  is  connected  to  the  CUCM  server  at  SB.  
ip access-list extended SRST
deny tcp any any eq 2000
deny udp any any eq 5060
deny tcp any any eq 5060
permit ip any any
 
The  first  step  in  configuring  SRST  is  to  make  sure  that  the  IOS  device  (R2  in  our  case)  is  configured  to  
accept  registration  requests  from  both  SCCP  and  SIP  phones.  This  means  that  we  must  configure  
telephony-service  and  voice register global  on  R2.  
 
To  support  SCCP  phones,  first  issue  the  telephony-service  command  from  global  configuration  
mode.  Next,  enter  the  srst mode auto-provision  command  using  the  all  option.  This  will  
make  sure  that  any  “learned”  configuration  from  the  phones  remains  in  the  running  configuration  of  
the  router  even  when  SRST  is  not  in  operation.  Next,  specify  the  type  of  lines  that  should  be  created  
when  SCCP  phones  register  with  the  router  using  the  srst dn line-mode  command.  I  usually  
specify  octo,  since  this  covers  all  situations,  but  pay  attention  to  your  specific  lab  requirements!    
Next,  specify  the  max-ephones, max-dn,  and  ip source-address  commands,  since  they  are  
required  for  any  CUCME  operation.  Remember  to  keep  the  DN  and  phone  count  as  low  as  possible  to  
conserve  system  resources.  
 
R2  
R2(config)#telephony-service
R2(config-telephony)#srst mode auto-provision all
R2(config-telephony)#srst dn line-mode octo
R2(config-telephony)#max-ephones 10
R2(config-telephony)#max-dn 20
R2(config-telephony)#ip source-address 10.10.21.1 port 2000
 
To  support  SIP  phones,  we  must  first  configure  the  global  SIP  configuration  under  voice service
voip to  bind  control  and  media  traffic  to  the  proper  interface.  We  must  also  configure  the  SIP  
registrar  server  to  support  SIP  phone  registrations.  
 
R2  
R2(config)#voice service voip
R2(conf-voi-serv)#sip
R2(conf-serv-sip)#bind control source-interface Loopback0
R2(conf-serv-sip)#bind media source-interface Loopback0
R2(conf-serv-sip)#registrar server
 
   

596 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  can  configure  the  settings  for  voice register global.  Remember,  by  default  it  is  set  
to  use  SRST  mode,  which  significantly  strips  down  the  required  configuration.  The  only  two  commands  
that  are  necessary  here  are  the  max-dn and max-pool  commands.    
 
R2  
R2(config-class)#voice register global
R2(config-register-global)#max-dn 10
R2(config-register-global)#max-pool 5
 
Once  those  are  defined,  we  must  create  a  voice register pool  so  the  phones  are  able  to  
register  to  the  router.  This  time,  we  will  define  a  network  instead  of  a  MAC  address  using  the  id
network  command.  Optionally,  we  can  specify  a  voice-class, codec, dtmf-relay  
method,  or  any  other  phone-­‐specific  setting  that  we  desire.  
 
R2  
R2(config)#voice class codec 1
R2(config-class)#codec preference 1 g711ulaw
R2(config-class)#codec preference 2 g729r8

R2(config)#voice register pool 1


R2(config-register-pool)#id network 10.10.31.0 mask 255.255.255.0
R2(config-register-pool)#voice-class codec 1
R2(config-register-pool)#dtmf-relay rtp-nte sip-kpml sip-notify
R2(config-register-pool)#no vad
 
Now  that  the  IOS  device  has  been  configured,  we  must  create  the  SRST  Reference  so  the  SB  Phones  
know  where  to  register  if  the  connection  to  CUCM  is  lost.  On  the  SB  CUCM  cluster,  navigate  to  System  
!  SRST  and  click  the  Add  New  button.  Specify  a  descriptive  “Name”  for  the  reference  (e.g.  “SB_SRST”)  
and  leave  the  “Port”  setting  at  the  default  of  “2000”.  Next,  specify  the  “IP  Address”  of  the  SCCP  
reference.  In  this  case,  we  are  referring  to  the  IP  source  address  configured  within  telephony-
service  (e.g.  “10.10.21.1”).  Next,  specify  the  IP  address  for  the  SIP  reference.  This  corresponds  to  
the  IP  address  of  the  interface  used  for  the  bind  commands  under  the  voice service voip  
section  of  the  configuration  (e.g.  “10.10.2.2”).  
 

 
 
Once  configured,  hit  the  Save  button.    
 
Next,  navigate  to  System  !  Device  Pool  and  select  the  “SB_PHONE_DP”.  For  the  “SRST  Reference”  
parameter,  select  the  newly  created  option  of  “SB_SRST”  from  the  dropdown  box.  Click  the  Save  and  
Reset  buttons  to  apply  the  configuration  to  the  phones.  
 

 
 

597 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  phones  have  the  required  configuration  and  SRST  has  been  configured  on  R2,  we  are  
ready  to  use  the  provided  access  list  to  block  communication  to  the  SB  CUCM  server  on  R2.  
 
R2  
R2(config)#ip access-list extended SRST
R2(config-ext-nacl)#deny tcp any any eq 2000
R2(config-ext-nacl)#deny udp any any eq 5060
R2(config-ext-nacl)#deny tcp any any eq 5060
R2(config-ext-nacl)#permit ip any any

R2(config-ext-nacl)#int gi0/1
R2(config-if)#ip access-group SRST in
R2(config-if)#ip access-group SRST out
 
Once  applied,  all  phones  fall  back  into  SRST  mode  based  on  the  configuration.  To  verify  that  the  SCCP  
phones  have  registered,  issue  the  show ephone registered  command  on  R2.    
 
R2  
R2#show ephone registered

ephone-1[0] Mac:001E.F728.3385 TCP socket:[2] activeLine:0 whisperLine:0 REGISTERED in SCCP ver 22/17
max_streams=5
mediaActive:0 whisper_mediaActive:0 startMedia:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0
debug:0 caps:9 privacy:1
IP:10.10.21.23 * 49550 7965 keepalive 9 max_line 6 available_line 3
button 1: cw:1 ccw:(0 0 0 0 0 0 0 0)
dn 1 number 2002 CM Fallback CH1 IDLE CH2 IDLE CH3 IDLE CH4 IDLE
CH5 IDLE CH6 IDLE CH7 IDLE CH8 IDLE
speed dial 1:hqp1@ipexpert.com hqp1@ipexpert.com
speed dial 2:hqp2@ipexpert.com hqp2@ipexpert.com
speed dial 3:sbp1@cucm.com sbp1@cucm.com
Preferred Codec: g711ulaw
Lpcor Type: none

ephone-2[1] Mac:1C1D.862F.0B87 TCP socket:[1] activeLine:0 whisperLine:0 REGISTERED in SCCP ver 22/17
max_streams=5
mediaActive:0 whisper_mediaActive:0 startMedia:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0
debug:0 caps:9 privacy:1
IP:10.10.21.22 * 49551 7965 keepalive 9 max_line 6 available_line 3
button 1: cw:1 ccw:(0 0 0 0 0 0 0 0)
dn 2 number 2001 CM Fallback CH1 IDLE CH2 IDLE CH3 IDLE CH4 IDLE
CH5 IDLE CH6 IDLE CH7 IDLE CH8 IDLE
speed dial 1:hqp1@ipexpert.com hqp1@ipexpert.com
speed dial 2:hqp2@ipexpert.com hqp2@ipexpert.com
speed dial 3:sbp2@cucm.com sbp2@cucm.com
Preferred Codec: g711ulaw
Lpcor Type: none
 
Also,  the  ephone  configuration  should  be  visible  in  the  running  configuration  due  to  the  “auto  
provision”  settings  that  were  applied  under  telephony-service.  
 
R2  
R2#sh run | sec ephone
max-ephones 10
ephone-dn 1 octo-line
number 2002
description +13123332002
name +13123332002
ephone-dn 2 octo-line
number 2001
description +13123332001
name +13123332001
ephone 1
mac-address 001E.F728.3385

598 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

speed-dial 1 hqp1@ipexpert.com label "hqp1@ipexpert.com"


speed-dial 2 hqp2@ipexpert.com label "hqp2@ipexpert.com"
speed-dial 3 sbp1@cucm.com label "sbp1@cucm.com"
button 1:1
ephone 2
mac-address 1C1D.862F.0B87
speed-dial 1 hqp1@ipexpert.com label "hqp1@ipexpert.com"
speed-dial 2 hqp2@ipexpert.com label "hqp2@ipexpert.com"
speed-dial 3 sbp2@cucm.com label "sbp2@cucm.com"
button 1:2
 
To  verify  that  the  SIP  phone  has  registered,  issue  the  show voice register pool 1 brief  
command.    
 
R2  
R2#show voice register pool 1 br
Pool ID IP Address Ln DN Number State
==== =============== =============== == === ==================== ============
1 10.10.31.0 10.10.31.37 2011$ REGISTERED
 
You  can  also  issue  the  show voice register dial-peers  command  as  well.  
 
R2  
R2#sh voice register dial-peers
Dial-peers for Pool 1:

dial-peer voice 40001 voip


destination-pattern 2011$
redirect ip2ip
session target ipv4:10.10.31.37:5060
session protocol sipv2
dtmf-relay rtp-nte sip-kpml sip-notify
digit collect kpml
voice-class codec 1
no vad
after-hours-exempt FALSE  
 
Make  some  test  calls  between  phones  that  are  registered  to  the  R2  router.  These  should  all  work  
successfully.  Now  make  a  test  call  from  the  PSTN.  The  call  does  not  work  in  this  case;  so  let’s  begin  
troubleshooting.    
 
   

599 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Run  the  debug isdn q931  command  from  R2  and  make  another  test  call  from  the  PSTN.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Dec 18 03:47:44.740: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x008E


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'SB PSTN Phone'
Calling Party Number i = 0x4181, '7764016'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '3123332001'
Plan:ISDN, Type:Subscriber(local)
Dec 18 03:47:44.740: ISDN Se0/0/0:23 Q931: Received SETUP callref = 0x808E callID = 0x0003 switch =
primary-ni interface = User
Dec 18 03:47:44.748: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x808E
Channel ID i = 0xA98381
Exclusive, Channel 1
Dec 18 03:47:52.396: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x008E
Cause i = 0x8290 - Normal call clearing
Dec 18 03:47:52.396: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x808E
Dec 18 03:47:52.408: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x008E
 
The  call  appears  to  be  entering  the  ISDN  interface  without  issue.  Let’s  look  at  how  the  call  is  accepted.    
 
R2  
R2#sh run | sec dial-
dial-peer voice 1 pots
translation-profile incoming TRANSLATE-PSTN-INBOUND
incoming called-number .
direct-inward-dial
dial-peer voice 2000 voip
destination-pattern 3123332...$
session protocol sipv2
session target ipv4:10.10.23.11
voice-class codec 1
dtmf-relay rtp-nte sip-notify
no vad

R2#sh run | sec voice trans


...
voice translation-rule 100
rule 1 /^[2-9]......$/ /+1312\0/ type subscriber subscriber plan isdn isdn
rule 2 /^[2-9]..[2-9]......$/ /+1\0/ type national national plan isdn isdn
rule 3 /.*/ /+\0/ type international international plan isdn isdn
voice translation-rule 101
rule 1 /^1\([2-9]..[2-9]......\)$/ /\1/
rule 2 /^3332...$/ /312\0/
...
voice translation-profile TRANSLATE-PSTN-INBOUND
translate calling 100
translate called 101
 
Based  on  the  above,  we  can  see  that  the  call  is  accepted  from  the  PSTN  using  either  11-­‐digit,  10-­‐digit,  
or  7-­‐digit  format.  However,  the  call  is  then  translated  to  a  10-­‐digit  number  and  sent  to  the  SB  CUCM  
server  using  dial-peer voice 2000 voip.  Since  the  DNs  are  registered  as  4-­‐digit  numbers,  
they  will  never  receive  calls  when  in  SRST.    

600 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  fix  this  issue,  we  must  continue  to  accept  calls  in  11/10/7-­‐digit  format,  but  we  should  translate  the  
number  to  4  digits  instead,  to  ensure  routing  to  the  registered  phones  in  SRST.  We  should  also  modify  
the  destination-pattern of dial-peer voice 2000 voip  to  use  a  4-­‐digit  number  
instead.  
 
R2  
R2(config)#voice translation-rule 101
R2(cfg-translation-rule)#rule 1 /^1312333\(2...$\)/ /\1/
R2(cfg-translation-rule)#rule 2 /^312333\(2...$\)/ /\1/
R2(cfg-translation-rule)#rule 3 /^333\(2...$\)/ /\1/

R2(cfg-translation-rule)#dial-peer voice 2000 voip


R2(config-dial-peer)#destination-pattern 2...$
 
Once  the  above  configuration  is  applied,  inbound  calls  from  the  PSTN  should  now  be  successful.  Issue  
the  debug isdn q931  command  on  R2  to  confirm.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Dec 18 04:22:15.401: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x0091


Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'SB PSTN Phone'
Calling Party Number i = 0x4181, '7764016'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '3123332011'
Plan:ISDN, Type:Subscriber(local)
Dec 18 04:22:15.401: ISDN Se0/
R2#0/0:23 Q931: Received SETUP callref = 0x8091 callID = 0x0006 switch = primary-ni interface = User
Dec 18 04:22:15.409: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8091
Channel ID i = 0xA98381
Exclusive, Channel 1
Dec 18 04:22:15.573: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x8091
 
   

601 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 36.3 All  users  should  be  able  to  call  HQ  and  SC  using  their  respective  4-­‐digit  extensions  
(through  the  PSTN).  
 
In  order  to  call  both  the  HQ  and  SC  sites  from  SRST,  dial-peers  must  be  created  to  accommodate  
the  dialing  requirements.  We  must  create  POTS  dial-peers  for  the  4-­‐digit  number  corresponding  to  
each  site,  and  format  the  number  appropriately  to  be  sent  over  the  PSTN.    
 
Since  calls  to  HQ  would  normally  be  considered  a  “National”  call,  we  must  obey  the  PSTN  rules  for  
calling  National  numbers.  According  to  the  Lab  16  requirements  for  PSTN  calling,  the  digit  manipulation  
table  should  appear  as  shown  below.  
 
Digit  Manipulation  Table  
Route  Pattern   1…$  
ANI  Digits  Required   10  
DNIS  Digits  Required   10  
Calling  Party  Number  Type   National  
Called  Party  Number  Type   National  
Special  Requirements   N/A  
 
Based  on  this  information,  let’s  create  new  voice translation-rules  and  profiles  to  
manipulate  the  digits  appropriately.    
 
R2  
R2(config)#voice translation-rule 1001
R2(cfg-translation-rule)#rule 1 /^2...$/ /312333\0/ type any national plan any isdn

R2(config)#voice translation-rule 1002


R2(cfg-translation-rule)#rule 1 /^1...$/ /408222\0/ type any national plan any isdn

R2(config)#voice translation-profile HQ-SRST


R2(cfg-translation-profile)#translate calling 1001
R2(cfg-translation-profile)#translate called 1002
 
Next,  since  calls  to  SC  would  normally  be  considered  “International”  calls,  we  should  adhere  to  the  
PSTN  requirements  for  those  calls  as  well.  The  digit  manipulation  table  should  be  written  as  shown  
below.  
 
Digit  Manipulation  Table  
Route  Pattern   3...$  
ANI  Digits  Required   +E164    
DNIS  Digits  Required   All  digits,  no  “011”  prefix  
Calling  Party  Number  Type   International  
Called  Party  Number  Type   International  
Special  Requirements   N/A  
 
Based  on  the  above  information,  create  new  voice translation-rules  and  profiles  to  
manipulate  the  digits  appropriately.  

602 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
R2  
R2(config)#voice translation-rule 3001
R2(cfg-translation-rule)#rule 1 /^2...$/ /+1312333\0/ type any international plan any isdn

R2(config)#voice translation-rule 3002


R2(cfg-translation-rule)#rule 1 /^3...$/ /4989444\0/ type any international plan any isdn

R2(config)#voice translation-profile SC-SRST


R2(cfg-translation-profile)#translate calling 3001
R2(cfg-translation-profile)#translate called 3002  
 
Next,  create  dial-peers  so  users  can  place  calls  to  the  HQ  and  SC  users.  
 
R2  
R2(config)#dial-peer voice 1000 pots
R2(config-dial-peer)#translation-profile outgoing HQ-SRST
R2(config-dial-peer)#destination-pattern 1...$
R2(config-dial-peer)#port 0/0/0:23

R2(config)#dial-peer voice 3000 pots


R2(config-dial-peer)#translation-profile outgoing SC-SRST
R2(config-dial-peer)#destination-pattern 3...$
R2(config-dial-peer)#port 0/0/0:23
 
Make  test  calls  from  SB  phones  to  each  number  to  ensure  operability.  Issue  the  debug isdn q931  
command  on  R2  to  view  the  output.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

Dec 18 05:02:51.205: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num
3123332001
Dec 18 05:02:51.205: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0084 callID = 0x8005 switch =
primary-ni interface = User
Dec 18 05:02:51.205: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0084
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclusive, Channel 3
Progress Ind i = 0x8183 - Origination address is non-ISDN
Display i = '+13123332001'
Calling Party Number i = 0x2180, '3123332001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '4082221002'
Plan:ISDN, Type:National
Dec 18 05:02:51.245: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8084
Channel ID i = 0xA98383
Exclusive, Channel 3
Dec 18 05:02:51.293: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8084

603 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Dec 18 05:03:54.008: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num
+13123332001
Dec 18 05:03:54.008: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0085 callID = 0x8006 switch =
primary-ni interface = User
Dec 18 05:03:54.008: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0085
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98383
Exclus
R2#ive, Channel 3
Progress Ind i = 0x8183 - Origination address is non-ISDN
Display i = '+13123332001'
Calling Party Number i = 0x1180, '+13123332001'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '49894443001'
Plan:ISDN, Type:International
Dec 18 05:03:54.044: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8085
Channel ID i = 0xA98383
Exclusive, Channel 3
Dec 18 05:03:54.092: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8085
Progress Ind i
R2# = 0x8188 - In-band info or appropriate now available
R2#
Dec 18 05:04:01.512: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0085
Cause i = 0x8090 - Normal call clearing
Dec 18 05:04:01.524: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x8085
Dec 18 05:04:01.524: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0085
 
   

604 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 36.4 All  users  should  be  able  to  call  911,  local,  and  long  distance  PSTN  numbers.  Obey  all  
dial  plan  rules  outlined  in  Lab  16  -­‐  Basic  Dial-­‐Plan  Configuration.  
 
In  SRST,  we  must  maintain  the  dialing  functionality  of  calls  to  the  PSTN  in  order  to  provide  a  seamless  
user  experience.  In  this  case,  the  work  has  already  been  done  for  us,  due  to  the  method  in  which  the  
dial  plan  was  implemented  in  Lab  16.  Since  this  gateway  uses  the  SIP  protocol  to  connect  to  CUCM,  
dial-peers  were  created  to  support  normal  operation.  Those  same  dial-peers  can  be  used  to  
accommodate  SRST  dialing.  Let’s  examine  the  configuration  to  understand  what  was  done.  First,  let’s  
discuss  the  “Emergency  Services”  or  “911”  dialing.    
 
R2  
R2#sh run | sec dial-peer voice 911
dial-peer voice 911 pots
translation-profile outgoing TRANSLATE-EMER-OUTBOUND
destination-pattern 911
clid strip name
port 0/0/0:23
forward-digits all

R2#sh run | sec voice translation-profile TRANSLATE-EMER-OUTBOUND


voice translation-profile TRANSLATE-EMER-OUTBOUND
translate calling 1
translate called 2

R2#sh run | sec voice translation-rule 1


voice translation-rule 1
rule 1 /^\(2...$\)/ /312333\1/ type any subscriber plan any isdn

R2#sh run | sec voice translation-rule 2


voice translation-rule 2
rule 1 /^911/ /\0/ type any subscriber plan any isdn
rule 2 /^9911/ /911/ type any subscriber plan any isdn
 
In  the  above  case,  the  user  must  dial  911  to  match  the  dial-peer.  The  configured  translation-
profile sets  the  ANI  to  10  digits  and  uses  the  plan  and  type  of  ISDN/Subscriber.  It  also  sets  the  
DNIS  to  use  the  originally  dialed  digits  while  adding  the  plan  and  type  of  ISDN/Subscriber.  Verify  the  
configuration  by  making  a  test  call  from  one  of  the  SRST  phones  to  911  and  running  a  debug isdn
q931  command  on  the  R2  gateway.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

...
Calling Party Number i = 0x4180, '3123332001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
...
 
   

605 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  let’s  analyze  the  configuration  for  local  calling  scenarios.  


 
R2  
R2#sh run | sec dial-peer voice 7
dial-peer voice 7 pots
translation-profile outgoing TRANSLATE-LOCAL-OUTBOUND
destination-pattern 9[2-9]......$
port 0/0/0:23

R2#sh run | sec voice translation-profile TRANSLATE-LOCAL


voice translation-profile TRANSLATE-LOCAL-OUTBOUND
translate calling 3
translate called 4

R2#sh run | sec voice translation-rule 3


voice translation-rule 3
rule 1 /^\(2...$\)/ /333\1/ type any subscriber plan any isdn
rule 2 /^\(1...$\)/ /408222\1/ type any national plan any isdn

R2#sh run | sec voice translation-rule 4


voice translation-rule 4
rule 1 /^9\([2-9]......\)$/ /\1/ type any subscriber plan any isdn
 
In  the  above  case,  the  user  must  dial  nine,  any  digit  two  through  nine,  and  any  six  digits  to  match  the  
dial-peer.  The  configured  translation-profile  sets  the  ANI  to  7  digits  and  uses  the  plan  
and  type  of  ISDN/Subscriber.  It  also  sets  the  DNIS  to  use  7  digits  while  adding  the  plan  and  type  of  
ISDN/Subscriber.  Verify  the  configuration  by  making  a  test  call  from  one  of  the  SRST  phones  to  
97764016  and  running  a  debug isdn q931  command  on  the  R2  gateway.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

...
Calling Party Number i = 0x4180, '3332001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '7764016'
Plan:ISDN, Type:Subscriber(local)
...
 
Lastly,  let’s  take  a  look  at  the  configuration  for  long  distance  calling  scenarios.  
 
R2  
R2#sh run | sec dial-peer voice 10
dial-peer voice 10 pots
translation-profile outgoing TRANSLATE-NATL-OUTBOUND
destination-pattern 91[2-9]..[2-9]......$
port 0/0/0:23

R2#sh run | sec voice translation-profile TRANSLATE-NATL


voice translation-profile TRANSLATE-NATL-OUTBOUND
translate calling 5
translate called 6

R2#sh run | sec voice translation-rule 5


voice translation-rule 5
rule 1 /^\(2...$\)/ /312333\1/ type any national plan any isdn

voice translation-rule 6
rule 1 /^91\([2-9]..[2-9]......\)$/ /\1/ type any national plan any isdn
 

606 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  above  case,  the  user  must  dial  nine,  one,  any  digit  two  through  nine,  any  two  digits,  any  digit  
two  through  nine,  and  any  six  digits  to  match  the  dial-peer.  The  configured  translation-
profile  sets  the  ANI  to  10  digits  and  uses  the  plan  and  type  of  ISDN/National.  It  also  sets  the  DNIS  to  
use  10  digits  while  adding  the  plan  and  type  of  ISDN/National.  Verify  the  configuration  by  making  a  test  
call  from  one  of  the  SRST  phones  to  914086131218  and  running  a  debug isdn q931  command  on  
the  R2  gateway.  
 
R2  
R2#debug isdn q931
debug isdn q931 is ON.

...
Calling Party Number i = 0x2180, '3123332001'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '4086131218'
Plan:ISDN, Type:National
...
 
   

607 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 36.5 Return  the  9971  SIP  phone  to  its  original  site  and  remove  the  access  list  from  
interface  GigabitEthernet  0/1.  
 
On  the  R2  router,  remove  the  access  list  by  issuing  the  below  commands.  
 
R2  
R2(config)#int gi0/1
R2(config-if)#no ip access-group SRST in
R2(config-if)#no ip access-group SRST out
 
The  easiest  way  to  return  the  phone  to  its  “normal”  configuration  is  to  erase  both  the  network  and  
security  settings.  Since  we  specified  a  static  TFTP  server,  doing  this  will  remove  that  config  and  look  to  
acquire  it  from  DHCP  instead.  Also,  since  the  phone  was  registered  to  a  CUCM  server,  it  picked  up  an  
ITL  file  in  the  process  that  will  prevent  it  from  registering  back  to  the  CUCME  router.  
 
On  the  phone,  navigate  to  Settings  !  Administrator  Settings  !  Reset  Settings  !  All  Settings  !  Reset.    
 

 
 
 

608 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Eight  Labs  37  -­‐  41  
Version  1.0  

609 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 8: Configuring and Troubleshooting Cisco Unity Connection


Lab 37: CUCM SIP Integration
Task 37.1 Remove  any  remaining  call  admission  control  configuration  from  the  HQ  device  
pools.  
 
Removing  the  CAC  mechanism  here  is  necessary  to  ensure  that  we  can  test  calls  to  the  voicemail  
system  without  the  call  being  accidentally  denied  in  any  way.  On  the  HQ  CUCM  cluster,  navigate  to  
System  !  Device  Pool  and  click  on  the  “HQ_PHONE_DP”.  Set  the  “Location”  parameter  to  “<None>”  
and  click  the  Save  and  Reset  buttons  to  apply  the  configuration.    
 

 
 
   

610 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 37.2 Configure  a  SIP  voicemail  integration  between  the  HQ  CUCM  cluster  and  the  HQ  CUC  
cluster  using  pilot  number  1700.  Ensure  that  users  are  able  to  press  the  messages  
key  to  sign  in  to  their  user  account.    
 
There  are  a  couple  different  ways  to  integrate  CUCM  to  Unity  Connection  (CUC).  The  first  and  
historically  most  common  method  has  been  the  SCCP  integration.  The  SIP  integration,  however,  in  
recent  years  has  probably  overtaken  SCCP  in  popularity  and  ease  of  deployment.  The  first  step  towards  
creating  the  integration  with  CUC  is  to  create  a  SIP  trunk  on  the  HQ  CUCM  server.  Even  before  that,  
however,  we  must  create  a  SIP  Trunk  Security  Profile  to  assign  to  the  SIP  trunk  with  specific  settings  
needed  to  connect  with  CUC.  
 
Navigate  to  System  !  Security  !  SIP  Trunk  Security  Profile  and  click  the  “Non  Secure  SIP  Trunk  
Profile”.  Click  the  Copy  button  to  create  a  new  profile  based  on  the  current  profile.  
 

 
 
Enter  an  appropriate  name  for  the  new  profile  (e.g.  “Non  Secure  SIP  Trunk  Profile  -­‐  VM”)  and  check  the  
box  to  enable  the  “Accept  out-­‐of-­‐dialog  refer”,  “Accept  unsolicited  notification”,  and  “Accept  replaces  
header”  settings.  Each  of  these  settings  is  required  to  support  the  integration  to  CUC.  Click  the  Save  
button  when  complete.  
 

 
 
   

611 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  create  the  SIP  trunk  for  the  integration.  Navigate  to  Device  !  Trunk  and  click  the  Add  
New  button.  Select  the  “Trunk  Type”  as  “SIP  Trunk”  and  click  the  Next  button  to  continue.    
 

 
 
Choose  a  descriptive  name  for  the  SIP  trunk  (e.g.  “HQ_CUC_SIP_TRUNK”)  and  select  an  appropriate  
Device  Pool  from  the  dropdown  box  (e.g.  “HQ_CUC_SIP_DP”).  Once  again,  a  separate  Device  Pool  was  
created  for  the  trunk  to  provide  maximum  flexibility.  
 

 
 
Next,  under  the  “Inbound  Calls”  section,  select  an  appropriate  “Calling  Search  Space”  in  order  to  
provide  access  for  incoming  calls.  Also,  check  the  “Redirecting  Diversion  Header  Delivery  –  Inbound”  
box  in  order  to  support  any  calls  that  happen  to  carry  the  redirecting  number  to  identify  the  user.  
 

 
 
Next,  under  the  “Outbound  Calls”  section,  check  the  “Redirecting  Diversion  Header  Delivery  –  
Outbound”  checkbox  in  order  to  support  outbound  calls  with  the  redirecting  number  field.    
 

 
 
Next,  under  the  “SIP  Information”  section,  enter  the  IP  address  of  the  HQ  CUC  server  (10.10.13.14)  as  
well  as  the  “Destination  Port”  of  the  server  (5060).  For  the  “SIP  Trunk  Security  Profile”  parameter,  
select  the  recently  created  profile  (e.g.  “Non  Secure  SIP  Trunk  Profile  –  VM”).  Next  for  each  of  the  

612 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

“Calling  Search  Space”  parameters  (“Rerouting”,  “Out-­‐of-­‐Dialog  Refer”,  and  “Subscribe”),  select  a  CSS  
that  has  access  to  the  DNs  in  the  system  (e.g.  “GW_TRUNK_CSS”).  These  will  come  into  play  when  calls  
are  redirected  from  the  CUC  system  in  some  fashion.  Lastly,  select  the  “Standard  SIP  Profile”  for  the  
“SIP  Profile”  parameter.    
 

 
 
Click  the  Save  and  Reset  buttons  when  complete.  
 
Now  that  the  SIP  trunk  has  been  created,  the  next  step  is  to  create  a  Route  Group  and  a  Route  List  to  
contain  it.  Navigate  to  Call  Routing  !  Route/Hunt  !  Route  Group  and  click  the  Add  New  button.  
Enter  a  descriptive  name  (e.g.  “HQ_CUC_SIP_RG”)  and  select  the  “HQ_CUC_SIP_TRUNK”  from  the  list.  
Click  the  Save  button  when  complete.  
 

 
 
Next,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  List  and  click  the  Add  New  button.  Enter  a  
descriptive  name  (e.g.  “HQ_CUC_SIP_RL”)  and  select  the  “SUB_PUB_CMG”  from  the  “Cisco  Unified  
Communications  Manager  Group”  dropdown  box.  Click  the  Save  button  to  continue.  
 

613 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  click  the  Add  Route  Group  button  to  select  the  “HQ_CUC_SIP_RG”  and  click  the  Save  button.  
 

 
 
With  the  Route  Group  and  Route  List  created,  we  are  now  ready  to  create  the  Route  Pattern  that  will  
serve  as  the  pilot  number  for  the  CUC  SIP  voicemail  integration.  Navigate  to  Call  Routing  !  
Route/Hunt  !  Route  Pattern  and  click  the  Add  New  button.  For  the  “Route  Pattern”  parameter,  enter  
the  pilot  number  to  be  used  with  CUC,  in  this  case  “1700”.  Also,  select  the  Partition  that  the  pattern  
should  be  placed  within  (e.g.  “VM_PT”)  and  select  the  previously  created  Route  List  from  the  
“Gateway/Route  List”  dropdown  box.  
 

 
 
No  further  configuration  is  necessary  for  the  Route  Pattern,  so  click  the  Save  button  when  completed.  
Next,  we  must  assign  the  newly  created  Route  Pattern  as  a  Voice  Mail  Pilot  in  the  system  in  order  for  
users  to  have  access  to  it  by  pressing  the  Messages  key  on  their  phone.  Navigate  to  Advanced  Features  
!  Voice  Mail  !  Voice  Mail  Pilot  and  click  on  the  “Default”  voicemail  pilot.  Enter  the  “Voice  Mail  Pilot  
Number”  as  “1700”,  select  an  appropriate  “Calling  Search  Space”  that  has  access  to  DNs  within  the  

614 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

system  (e.g.  “INTERNAL_CSS”).  Lastly,  ensure  that  the  “Make  this  the  default  Voice  Mail  Pilot  for  the  
system”  box  is  checked.  
 

 
 
Click  the  Save  button  when  complete.  
 
In  this  case,  since  we  used  the  “Default”  Voice  Mail  Pilot,  we  do  not  have  to  create  or  edit  a  Voice  Mail  
Profile;  all  users  utilize  the  “Default”  Voice  Mail  Profile  automatically.  If  desired,  a  new  Voice  Mail  
Profile  can  be  created  that  selects  the  newly  created  Voice  Mail  Pilot.  At  that  point,  however,  it  must  
be  assigned  within  the  “Directory  Number  Configuration”  page  of  each  phone  that  should  utilize  that  
pilot  number.  
 
Now  that  the  CUCM  side  of  the  integration  is  complete,  let’s  move  on  to  configuring  the  HQ  CUC  
server.  Once  logged  into  Cisco  Unity  Connection  Administration,  navigate  to  Telephony  Integrations  !  
Phone  System  and  click  on  the  link  labeled  “PhoneSystem”.  
 

 
 
The  first  thing  that  should  be  done  is  to  rename  it  to  a  name  that  makes  a  little  more  sense  and  is  
different  from  the  default  (e.g.  “HQ_CUCM”).  Click  the  Save  button.  
 

 
 
Next,  select  the  “Add  a  Port  Group”  option  from  the  “Related  Links”  dropdown  box  and  click  the  Go  
button.  
 

 
 
Ensure  that  the  selected  “Port  Group  Type”  is  set  to  “SIP”.  The  “Display  Name”  parameter  can  be  left  
at  the  default  setting  (e.g.  “HQ_CUCM-­‐1”).  Next,  under  the  “Primary  Server  Settings”  heading,  enter  
the  IP  address  of  the  CUCM  server  in  the  “IPv4  Address  or  Host  Name”  textbox  (e.g.  “10.10.13.11”)  and  
click  the  Save  button.  
 

615 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
With  the  Port  Group  created,  we  must  now  add  Ports  to  the  system  so  the  integration  can  be  utilized.  
Select  the  “Add  Ports”  option  from  the  “Related  Links”  dropdown  box  and  click  the  Go  button.  
 

 
 
Everything  within  this  page  can  be  left  at  the  default  setting,  except  the  “Number  of  Ports”  setting.  
Here,  we  can  specify  whatever  number  we  want,  since  it  was  not  defined  in  the  task  requirements.  In  
this  case,  “4”  was  chosen.  Click  the  Save  button  when  completed  to  create  the  Ports.  
 

 
 
At  this  point,  the  system  has  been  fully  configured  to  accept  incoming  SIP  connections  on  one  of  the  
four  created  ports  in  the  system.  Press  the  Messages  key  on  each  HQ  phone  to  ensure  that  the  
Opening  Greeting  for  Unity  Connection  is  heard.  
 

616 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Information  about  the  call  from  the  perspective  of  CUC  can  be  viewed  in  RTMT  for  Unity  Connection.  
Once  logged  in,  navigate  to  Unity  Connection  !  Port  Monitor.    
 

 
 
Here,  we  can  monitor  the  status  of  the  ports  in  Unity  Connection.  Remember  to  select  a  “Node”  to  
query  (e.g.  “HQCUC”)  and  set  the  “Polling  Rate”  to  a  small  interval  (e.g.  “1”).    
 

 
 

 
 
Once  the  polling  rate  is  set,  click  the  Start  Polling  button  to  view  the  real-­‐time  port  status.  Press  the  
Messages  key  on  one  of  the  HQ  phones  again  and  observe  the  behavior.  
 

 
 
As  you  can  see  in  the  above,  the  opening  greeting  is  being  played.  The  reason,  of  course,  is  that  no  
mailbox  has  been  configured  for  the  user  yet.  
 
   

617 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 37.3 Ensure  that  the  connection  provides  redundancy  with  the  HQ  subscriber  server  as  
primary  and  the  publisher  server  as  backup.  
 
The  CUC  SIP  integration  with  the  HQ  CUCM  server  has  been  successfully  completed,  but  it  has  not  been  
configured  for  redundancy  at  the  moment.  In  CUCM,  we  have  no  way  of  configuring  redundancy  
towards  Unity  Connection  since  there  is  only  one  server.  On  the  Unity  Connection  server,  however,  we  
have  the  ability  to  point  towards  both  CUCM  servers.  
 
On  the  HQ  CUC  server,  navigate  to  Telephony  Integrations  !  Port  Group  and  click  on  the  “HQ_CUCM-­‐
1”  link.  On  the  “Port  Group  Basics”  page,  navigate  to  Edit  !  Servers.    
 

 
 
On  the  “Edit  Servers”  page,  click  the  Add  button  to  add  the  IP  address  of  the  HQ  CUCM  subscriber  
server  (10.10.13.12).  Make  sure  to  use  the  same  ports  as  configured  for  the  primary  server.    
 

 
 
Click  the  Save  button  when  complete.  
 
Next,  navigate  to  Edit  !  Port  Group  Basics  and  click  the  Reset  button  to  reset  the  Port  Group  and  its  
underlying  ports.  
 

 
 
Make  another  test  call  to  ensure  that  the  configuration  was  successful.  
 
Task 37.4 Ensure  that  the  PSTN  phone  can  dial  the  HQ  Unity  Connection  pilot  number  to  hear  
the  opening  greeting.  

618 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
In  order  to  configure  the  system  so  that  the  PSTN  phone  has  access  to  the  HQ  CUC  pilot  number  
(1700),  we  must  ensure  that  the  Partition  that  is  assigned  to  the  Route  Pattern  for  the  pilot  number  
exists  in  the  Calling  Search  Space  that  is  assigned  to  the  inbound  PSTN  gateway.  In  this  case,  HQ  uses  
an  MGCP  gateway  to  access  the  PSTN,  so  the  CSS  assigned  there  should  be  modified  accordingly.  The  
Voice  Mail  Pilot  Number  exists  in  the  “VM_PT”,  as  shown  below.  
 

 
 
The  MGCP  gateway  has  a  CSS  called  “GW_TRUNK_CSS”.  
 

 
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  click  on  the  “GW_TRUNK_CSS”.  
Add  the  “VM_PT”  to  the  “Selected  Partitions”  list  and  click  the  Save  button.  
 

 
 
From  the  PSTN  phone,  call  the  HQ  CUC  Voice  Mail  Pilot  number  and  ensure  that  it  works  correctly.  You  
may  verify  using  the  Port  Monitor  tool  within  RTMT.  
 

 
 
Task 37.5 Ensure  that  users  are  created  first  within  the  HQ  CUCM  and  then  imported  into  the  
HQ  CUC  cluster.  Set  all  passwords  to  “cisco”  and  all  PINs  to  “12345”.  
 

619 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Unity  Connection  provides  the  ability  to  import  users  into  the  system  from  both  CUCM  and  LDAP  
sources.  This  task  requires  that  we  create  the  users  first  within  CUCM  and  then  import  them  into  CUC.  
In  this  case,  the  End  Users  have  already  been  created  for  us  in  a  previous  lab.  To  verify,  navigate  to  
User  Management  !  End  User  and  click  on  the  user  for  HQ  Phone  1  (e.g.  “hqp1”).  Under  the  
“Controlled  Devices”  list  box,  make  sure  that  the  MAC  address  of  the  phone  is  selected.  
 

 
 
Next,  under  the  “Directory  Number  Associations”  section,  make  sure  that  a  “Primary  Extension”  is  
selected.  If  nothing  is  selected  here,  CUC  will  not  be  able  to  recognize  that  a  user  is  available  for  
import.  
 

 
 
Once  all  users  are  created  with  the  HQ  CUCM  server,  we  must  configure  the  Unity  Connection  server.  
Before  we  import  the  users,  we  must  configure  a  couple  of  settings  to  make  it  possible.  First,  navigate  
to  Telephony  Integrations  !  Phone  System  and  click  on  the  “HQ_CUCM”  option.  From  the  “Phone  
System  Basics”  page,  navigate  to  Edit  !  Cisco  Unified  Communications  Manager  AXL  Servers.  Click  the  
Add  New  button  to  add  both  the  HQ  CUCM  Publisher  and  Subscriber  servers  to  the  list  using  port  443.  
Remember  to  specify  the  administrator  username  and  password  of  the  HQ  CUCM  cluster  
(admin/cciecollab).  Click  the  Save  button  when  complete.  
 

 
 
When  configured,  click  the  Test  button  to  make  sure  that  messages  can  be  successfully  sent.  
 

 
 
With  the  AXL  configuration  complete,  we  now  have  the  ability  to  communicate  with  the  HQ  CUCM  
cluster  to  import  the  users.  Before  we  do  that,  however,  we  must  configure  settings  associated  with  
the  user,  like  Authentication  Rules  and  User  Templates.  Editing  the  Authentication  Rules  will  allow  us  
620 ipexpert.com Copyright © by iPexpert. All rights reserved.
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

to  use  more  simplistic  passwords  (since  that  was  required)  and  editing  the  User  Templates  will  allow  us  
to  edit  user  settings  on  a  “template-­‐level”  rather  than  configuring  for  each  individual  user.    
 
First,  navigate  to  System  Settings  !  Authentication  Rules  and  click  on  the  “Recommended  Voice  Mail  
Authentication  Rule”  to  edit  the  rules  for  the  voicemail  PIN.  First,  check  the  “Never  Expires”  checkbox  
to  ensure  that  the  PIN  doesn’t  ever  have  to  be  changed.  Next,  modify  the  “Minimum  Credential  
Length”  to  a  length  that  will  accommodate  the  required  PIN  of  “12345”  (e.g.  “5”).  Next,  change  the  
“Stored  Number  of  Previous  Credentials”  parameter  to  “0”  and  uncheck  the  “Check  for  Trivial  
Passwords”  checkbox.  
 

 
 
When  finished,  click  the  Save  button.  Perform  the  same  steps  for  the  “Recommended  Web  Application  
Authentication  Rule”.  
 
Next,  navigate  to  Templates  !  User  Templates  and  click  on  the  “voicemailusertemplate”.  Within  the  
“Edit  User  Template  Basics”  page,  make  sure  that  the  “Phone  System”  parameter  is  set  to  use  
“HQ_CUCM”  and  the  “Active  Schedule”  is  set  to  use  “All  Hours”.  If  this  is  not  set,  the  “Closed”  greeting  
will  be  invoked  outside  of  defined  working  hours.  Next,  uncheck  the  “Set  for  Self-­‐enrollment  at  Next  
Sign-­‐In”  checkbox  to  avoid  having  to  configure  the  user  mailbox  when  logging  in.  
 

 
 
Next,  navigate  to  Edit  !  Password  Settings  and  select  the  “Voice  Mail”  PIN  from  the  dropdown  box.  
Ensure  that  the  “User  Must  Change  at  Next  Sign-­‐In”  box  is  unchecked  and  the  “Does  Not  Expire”  box  is  
checked.  Click  the  Save  button  when  complete.  Ensure  that  the  same  is  done  for  the  “Web  
Application”  PIN.    

621 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  navigate  to  Edit  !  Change  Password  and  click  on  the  “Voice  Mail”  PIN  from  the  dropdown  box.  
Enter  the  PIN  “12345”  as  required  by  the  task  and  click  the  Save  button.  
 

 
 
Next,  select  “Web  Application”  from  the  dropdown  box  and  enter  the  password  “cisco”.  Click  the  Save  
button  when  complete.  
 
With  the  entire  system  configuration  completed,  we  can  now  import  the  users  from  CUCM.  Navigate  
to  Users  !  Import  Users  and  select  the  “HQ_CUCM”  option  from  the  “Find  End  Users  In”  dropdown  
box.  Click  the  Find  button  to  search.  Both  HQ  CUCM  users  should  be  displayed  below.  
 

 
 
Ensure  that  the  “Based  on  Template”  dropdown  box  contains  the  “voicemailusertemplate”  and  click  
the  Import  All  button  to  import  the  users  into  CUC.  Click  the  OK  button  to  continue.  
 

622 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
When  the  user  import  is  complete,  the  status  will  be  displayed  at  the  top  of  the  page.    
 

 
 
Try  making  a  test  call  into  the  system  from  one  of  the  HQ  phones.  You  should  now  be  presented  with  
the  “Sign  In”  prompt.  Once  again,  this  can  be  confirmed  through  the  Unity  Connection  Port  Monitor  
tool  in  RTMT.  
 

 
 
   

623 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 37.6 Ensure  that  calls  are  forward  to  voicemail  when  the  user  is  busy,  there  is  no  answer,  
or  the  phone  is  unregistered.  
 
In  order  to  configure  these  settings,  we  must  make  a  change  at  the  Directory  Number  level  in  CUCM  
for  both  HQ  phones.    
 
On  the  HQ  CUCM  cluster,  navigate  to  Device  !  Phone  and  click  on  “HQ  Phone  1”.  Select  DN  “1001”  to  
enter  the  “Directory  Number  Configuration”  page.  Under  the  “Call  Forward  and  Call  Pickup  Settings”  
section,  check  the  “Voice  Mail”  checkbox  next  to  the  “Forward  Busy  Internal/External”,  Forward  No  
Answer  Internal/External”,  and  “Forward  Unregistered  Internal/External”.    
 

 
 
Click  the  Save  and  Apply  Config  buttons  when  complete.  Perform  the  same  task  for  the  other  HQ  
phone  as  well.  
 
Make  a  test  call  from  one  HQ  phone  to  the  other  to  ensure  that  the  call  is  forwarded  to  voicemail.  
Verify  using  the  Unity  Connection  Port  Monitor  in  RTMT.  
 

 
 
   

624 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 37.7 Configure  the  system  so  that  the  MWI  light  turns  on  when  there  is  a  message  
waiting  in  the  mailbox  and  turns  off  when  a  user  deletes  a  message  from  the  
mailbox.  
 
With  this  task,  I  decided  that  I  would  give  you  a  break!    Seriously,  we  already  configured  this  setting  
without  really  even  knowing  it  earlier  in  the  lab.  Since  Unity  Connection  uses  Unsolicited  Notify  as  the  
method  for  MWI  notification,  nothing  is  required  except  to  allow  that  message.  If  you  recall  from  the  
SIP  Trunk  Security  Profile  configuration  in  CUCM,  we  allowed  it  by  checking  the  “Accept  unsolicited  
notification”  checkbox.  
 

 
 
All  that  is  left  now  is  to  make  a  test  call  and  ensure  that  MWI  works.  When  the  lamp  is  lit  successfully,  
make  sure  that  you  can  log  into  the  voicemail  box  and  delete  the  message  to  make  the  lamp  turn  off.  
 
   

625 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Lab 38: CUCM SCCP Integration


Task 38.1 Remove  any  remaining  call  admission  control  configuration  from  the  SB  device  
pools.  
 
Removing  the  CAC  mechanism  here  is  necessary  to  ensure  that  we  can  test  calls  to  the  voicemail  
system  without  the  call  being  accidentally  denied  in  any  way.  On  the  SB  CUCM  cluster,  navigate  to  
System  !  Device  Pool  and  click  on  the  “SB_PHONE_DP”.  Set  the  “Location”  parameter  to  “<None>”  
and  click  the  Save  and  Reset  buttons  to  apply  the  configuration.    
 

 
 
   

626 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 38.2 Configure  a  SCCP  voicemail  integration  between  the  SB  CUCM  cluster  and  the  SB  
CUC  cluster  using  pilot  number  2700.  Create  4  voicemail  ports  starting  with  number  
2701.  The  MWI  On/Off  numbers  should  be  2798/2799.  Ensure  that  users  are  able  to  
press  the  messages  key  to  sign  in  to  their  user  account.  
 
There  are  a  couple  different  ways  to  integrate  CUCM  to  Unity  Connection  (CUC).  The  SIP  integration  
was  discussed  with  the  HQ  CUCM  and  HQ  CUC  systems  in  the  previous  lab.  In  this  lab,  we  will  focus  on  
creating  a  SCCP  integration  between  the  SB  CUCM  and  CUC  systems.  The  first  step  towards  creating  
the  SCCP  integration  with  CUC  is  to  create  Voice  Mail  Ports  using  the  Voice  Mail  Port  Wizard.    
 
Navigate  to  Advanced  Features  !  Voice  Mail  !  Cisco  Voice  Mail  Port  Wizard  to  begin.  Select  the  
option  to  “Create  a  new  Cisco  Voice  Mail  Server  and  add  ports  to  it”  and  click  the  Next  button.  
 

 
 
Next,  enter  a  name  for  the  Voice  Mail  Ports;  feel  free  to  keep  the  default  name  of  “CiscoUM1”  if  so  
desired.  This  name  will  serve  as  a  prefix  to  the  actual  port  name  (e.g.  “CiscoUM1-­‐VIx”).    
 

 
 
Next,  we  must  define  the  number  of  ports  to  be  created.  The  requirements  dictate  that  four  should  be  
used,  so  select  that  option  from  the  dropdown  menu  and  click  the  Next  button.  
 

 
 
   

627 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  select  a  “Device  Pool”  for  the  Voice  Mail  Ports.  Using  the  same  methodology  as  practiced  for  
Gateways  and  Trunks  in  CUCM,  a  separate  Device  Pool  should  be  created  specifically  for  interaction  
with  the  Voice  Mail  server  (e.g.  “SB_CUC_SCCP_DP”).  Select  an  appropriate  “Calling  Search  Space”  as  
well,  to  provide  access  to  the  system  DNs  as  well  as  the  Voice  Mail  Pilot  number  (e.g.  
“INTERNAL_CSS”).  Since  no  CAC  is  being  used  for  calls  to  Voice  Mail,  select  the  “Hub_None”  option  
from  the  “Location”  dropdown  box.  Finally,  select  the  “Non  Secure  Voice  Mail  Port”  option  from  the  
“Device  Security  Mode”  dropdown  box  and  click  the  Next  button.  
 

 
 
Next,  select  the  “Beginning  Directory  Number”  for  the  port,  which  should  be  “2701”  per  the  task  
requirements.  Select  the  “Partition”  as  “VM_PT”  and  select  the  same  “Calling  Search  Space”  from  the  
previous  step  (e.g.  “INTERNAL_CSS”).  Leave  the  default  settings  for  everything  else  and  click  the  Next  
button.  
 

 
 
   

628 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  have  the  option  of  adding  the  ports  to  a  Line  Group  within  CUCM.  This  option  is  desirable  
since  it  basically  saves  us  a  step—and  the  time  associated  with  that  step!    Select  the  “Yes.  Add  
directory  numbers  to  a  new  Line  Group”  option  and  click  the  Next  button.  
 

 
 
Next,  enter  the  name  for  the  Line  Group  that  the  wizard  should  create.  In  this  case,  you  may  keep  the  
default  name  if  so  desired  (e.g.  “CiscoUM1”).  Click  the  Next  button  to  continue.  
 

 
 
Finally,  verify  the  information  that  has  been  entered  and  click  the  Finish  button  to  complete  the  
wizard.    
 

 
 
   

629 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

When  the  wizard  is  complete,  it  will  display  the  summary  of  what  was  configured.  Verify  that  
everything  is  correct,  and  click  the  link  to  create  a  new  Hunt  List,  since  that  is  the  next  step  in  the  
process.  
 

 
 
Click  the  Add  New  button  on  the  “Find  and  List  Hunt  Lists”  page.  Enter  a  descriptive  name  (e.g.  
“SB_CUC_SCCP_HL”)  and  select  the  “PUB_CMG”  from  the  “Cisco  Unified  Communications  Manager  
Group”  dropdown  box.  Check  the  “Enable  this  Hunt  List”  and  “For  Voice  Mail  Usage”  checkboxes  as  
well.  Click  the  Save  button  to  continue.  
 

 
 
Next,  click  the  Add  Line  Group  button  to  select  the  “CiscoUM1”  option  and  click  the  Save  button.  
 

 
 

630 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  Line  Group  and  Hunt  List  created,  we  should  now  create  the  Hunt  Pilot  that  will  serve  as  the  
pilot  number  for  the  SB  CUC  SCCP  voicemail  integration.  Navigate  to  Call  Routing  !  Route/Hunt  !  
Hunt  Pilot  and  click  the  Add  New  button.  For  the  “Hunt  Pilot”  parameter,  enter  the  pilot  number  to  be  
used  with  CUC,  in  this  case  “2700”.  Also,  select  the  Partition  that  the  pattern  should  be  placed  within  
(e.g.  “VM_PT”)  and  select  the  previously  created  “Hunt  List”  from  dropdown  box  (e.g.  
“SB_CUC_SCCP_HL”).  
 

 
 
No  further  configuration  is  necessary  for  the  Hunt  Pilot,  so  click  the  Save  button  when  completed.  
 
Next,  we  must  assign  the  newly  created  Hunt  Pilot  as  a  Voice  Mail  Pilot  in  the  system  in  order  for  users  
to  have  access  to  it  by  pressing  the  Messages  key  on  their  phone.  Navigate  to  Advanced  Features  !  
Voice  Mail  !  Voice  Mail  Pilot  and  click  on  the  “Default”  voicemail  pilot.  Enter  the  “Voice  Mail  Pilot  
Number”  as  “2700”,  select  an  appropriate  “Calling  Search  Space”  that  has  access  to  DNs  within  the  
system  (e.g.  “INTERNAL_CSS”).  Lastly,  ensure  that  the  “Make  this  the  default  Voice  Mail  Pilot  for  the  
system”  box  is  checked.  
 

 
 
Click  the  Save  button  when  complete.  
 
In  this  case,  since  we  used  the  “Default”  Voice  Mail  Pilot,  we  do  not  have  to  create  or  edit  a  Voice  Mail  
Profile;  all  users  utilize  the  “Default”  Voice  Mail  Profile  automatically.  If  desired,  a  new  Voice  Mail  
Profile  can  be  created  that  selects  the  newly  created  Voice  Mail  Pilot.  At  that  point,  however,  it  must  
be  assigned  within  the  “Directory  Number  Configuration”  page  of  each  phone  that  should  utilize  that  
pilot  number.  
 

631 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  CUCM  side  of  the  integration  is  complete,  let’s  move  on  to  configuring  the  SB  CUC  server  
for  the  SCCP  integration.  Once  logged  into  Cisco  Unity  Connection  Administration,  navigate  to  
Telephony  Integrations  !  Phone  System  and  click  on  the  link  labeled  “PhoneSystem”.  
 

 
 
The  first  thing  that  should  be  done  is  to  rename  it  to  a  name  that  makes  a  little  more  sense  and  is  
different  from  the  default  (e.g.  “SB_CUCM”).  Click  the  Save  button.  
 

 
 
Next,  select  the  “Add  a  Port  Group”  option  from  the  “Related  Links”  dropdown  box  and  click  the  Go  
button.  
 

 
 
Ensure  that  the  selected  “Port  Group  Type”  is  set  to  “SCCP”.  The  “Display  Name”  parameter  can  be  left  
at  the  default  setting  (e.g.  “SB_CUCM-­‐1”).  Next,  the  “Device  Name  Prefix”  parameter  must  match  
exactly  with  the  configured  settings  in  CUCM  in  order  to  register  successfully  with  the  SB  CUCM  cluster  
(e.g.  “CiscoUM1-­‐VI”).  Next,  enter  the  “MWI  On”  and  “MWI  Off  Extension”  parameters.  The  task  
requirements  dictated  that  these  should  be  “2798”  and  “2799”,  respectively.  Finally,  under  the  
“Primary  Server  Settings”  heading,  enter  the  IP  address  of  the  CUCM  server  in  the  “IPv4  Address  or  
Host  Name”  textbox  (e.g  “10.10.23.11”)  and  click  the  Save  button.  
 

632 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  Port  Group  created,  we  must  now  add  Ports  to  the  system  so  the  integration  can  be  utilized.  
Select  the  “Add  Ports”  option  from  the  “Related  Links”  dropdown  box  and  click  the  Go  button.  
 

 
 
Everything  within  this  page  can  be  left  at  the  default  setting,  except  the  “Number  of  Ports”  setting.  
Here,  we  must  specify  four  ports,  as  dictated  by  the  task  requirements.  Click  the  Save  button  when  
completed  to  create  the  Ports.  
 

 
 
At  this  point,  the  system  has  been  fully  configured  to  accept  incoming  SCCP  connections  on  one  of  the  
four  created  ports  in  the  system.  Press  the  Messages  key  on  each  SB  phone  to  ensure  that  the  Opening  
Greeting  for  Unity  Connection  is  heard.  
 
Information  about  the  call  from  the  perspective  of  CUC  can  be  viewed  in  RTMT  for  Unity  Connection.  
Once  logged  in,  navigate  to  Unity  Connection  !  Port  Monitor.    
 

 
 
Here,  we  can  monitor  the  status  of  the  ports  in  Unity  Connection.  Remember  to  select  a  “Node”  to  
query  (e.g.  “SBCUC”)  and  set  the  “Polling  Rate”  to  a  small  interval  (e.g.  “1”).    
 

 
 

633 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Once  the  polling  rate  is  set,  click  the  Start  Polling  button  to  view  the  real-­‐time  port  status.  Press  the  
Messages  key  on  one  of  the  SB  phones  again  and  observe  the  behavior.  
 

 
 
As  you  can  see  in  the  above,  the  opening  greeting  is  being  played.  The  reason,  of  course,  is  that  no  
mailbox  has  been  configured  for  the  user  yet.  
 
   

634 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 38.3 Ensure  that  the  PSTN  phone  can  dial  the  SB  Unity  Connection  pilot  number  to  hear  
the  opening  greeting.  
 
In  order  to  configure  the  system  so  that  the  PSTN  phone  has  access  to  the  HQ  CUC  pilot  number  
(2700),  we  must  ensure  that  the  Partition  that  is  assigned  to  the  Hunt  Pilot  for  the  pilot  number  exists  
in  the  Calling  Search  Space  that  is  assigned  to  the  inbound  PSTN  gateway.  In  this  case,  SB  uses  a  SIP  
trunk  to  access  the  PSTN  (through  R2),  so  the  CSS  assigned  there  should  be  modified  accordingly.  The  
Voice  Mail  Pilot  Number  exists  in  the  “VM_PT”,  as  shown  below.  
 

 
 
The  SIP  trunk  has  a  CSS  called  “GW_TRUNK_CSS”.  
 

 
 
Navigate  to  Call  Routing  !  Class  of  Control  !  Calling  Search  Space  and  click  on  the  “GW_TRUNK_CSS”.  
Add  the  “VM_PT”  to  the  “Selected  Partitions”  list  and  click  the  Save  button.  
 

 
 
From  the  PSTN  phone,  call  the  SB  CUC  Voice  Mail  Pilot  number  and  ensure  that  it  works  correctly.  You  
may  verify  using  the  Port  Monitor  tool  within  RTMT.  
 

 
 
 

635 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 38.4 Ensure  that  users  are  created  first  within  the  SB  CUCM  and  then  imported  into  the  
SB  CUC  cluster.  Set  all  passwords  to  “cisco”  and  all  PINs  to  “12345”.  
 
Unity  Connection  provides  the  ability  to  import  users  into  the  system  from  both  CUCM  and  LDAP  
sources.  This  task  requires  that  we  create  the  users  first  within  CUCM  and  then  import  them  into  CUC.  
In  this  case,  the  End  Users  have  already  been  created  for  us  in  a  previous  lab.  To  verify,  navigate  to  
User  Management  !  End  User  and  click  on  the  user  for  SB  Phone  1  (e.g.  “sbp1”).  Under  the  
“Controlled  Devices”  list  box,  make  sure  that  the  MAC  address  of  the  phone  is  selected.  
 

 
 
Next,  under  the  “Directory  Number  Associations”  section,  make  sure  that  a  “Primary  Extension”  is  
selected.  If  nothing  is  selected  here,  CUC  will  not  be  able  to  recognize  that  a  user  is  available  for  
import.  
 

 
 
Once  all  users  are  created  with  the  HQ  CUCM  server,  we  must  configure  the  Unity  Connection  server.  
Before  we  import  the  users,  we  must  configure  a  couple  of  settings  to  make  it  possible.  First,  navigate  
to  Telephony  Integrations  !  Phone  System  and  click  on  the  “SB_CUCM”  option.  From  the  “Phone  
System  Basics”  page,  navigate  to  Edit  !  Cisco  Unified  Communications  Manager  AXL  Servers.  Click  the  
Add  New  button  to  add  the  SB  CUCM  Publisher  server  to  the  list  using  port  443.  Remember  to  specify  
the  administrator  username  and  password  of  the  SB  CUCM  cluster  (admin/cciecollab).  Click  the  Save  
button  when  complete.  
 

 
 
When  configured,  click  the  Test  button  to  make  sure  that  messages  can  be  successfully  sent.  
 

 
 

636 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  AXL  configuration  complete,  we  now  have  the  ability  to  communicate  with  the  SB  CUCM  
cluster  to  import  the  users.  Before  we  do  that,  however,  we  must  configure  settings  associated  with  
the  user,  like  Authentication  Rules  and  User  Templates.  Editing  the  Authentication  Rules  will  allow  us  
to  use  more  simplistic  passwords  (since  that  was  required)  and  editing  the  User  Templates  will  allow  us  
to  edit  user  settings  on  a  “template-­‐level”  rather  than  configuring  for  each  individual  user.    
 
First,  navigate  to  System  Settings  !  Authentication  Rules  and  click  on  the  “Recommended  Voice  Mail  
Authentication  Rule”  to  edit  the  rules  for  the  voicemail  PIN.  First,  check  the  “Never  Expires”  checkbox  
to  ensure  that  the  PIN  doesn’t  ever  have  to  be  changed.  Next,  modify  the  “Minimum  Credential  
Length”  to  a  length  that  will  accommodate  the  required  PIN  of  “12345”  (e.g.  “5”).  Next,  change  the  
“Stored  Number  of  Previous  Credentials”  parameter  to  “0”  and  uncheck  the  “Check  for  Trivial  
Passwords”  checkbox.  
 

 
 
When  finished,  click  the  Save  button.  Perform  the  same  steps  for  the  “Recommended  Web  Application  
Authentication  Rule”.  
 
Next,  navigate  to  Templates  !  User  Templates  and  click  on  the  “voicemailusertemplate”.  Within  the  
“Edit  User  Template  Basics”  page,  make  sure  that  the  “Phone  System”  parameter  is  set  to  use  
“SB_CUCM”  and  the  “Active  Schedule”  is  set  to  use  “All  Hours”.  If  this  is  not  set,  the  “Closed”  greeting  
will  be  invoked  outside  of  defined  working  hours.  Next,  uncheck  the  “Set  for  Self-­‐enrollment  at  Next  
Sign-­‐In”  checkbox  to  avoid  having  to  configure  the  user  mailbox  when  logging  in.  
 

 
 
Next,  navigate  to  Edit  !  Password  Settings  and  select  the  “Voice  Mail”  PIN  from  the  dropdown  box.  
Ensure  that  the  “User  Must  Change  at  Next  Sign-­‐In”  box  is  unchecked  and  the  “Does  Not  Expire”  box  is  

637 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

checked.  Click  the  Save  button  when  complete.  Ensure  that  the  same  is  done  for  the  “Web  
Application”  PIN.    
 

 
 
Next,  navigate  to  Edit  !  Change  Password  and  click  on  the  “Voice  Mail”  PIN  from  the  dropdown  box.  
Enter  the  PIN  “12345”  as  required  by  the  task  and  click  the  Save  button.  
 

 
 
Next,  select  “Web  Application”  from  the  dropdown  box  and  enter  the  password  “cisco”.  Click  the  Save  
button  when  complete.  
 
With  the  entire  system  configuration  completed,  we  can  now  import  the  users  from  CUCM.  Navigate  
to  Users  !  Import  Users  and  select  the  “SB_CUCM”  option  from  the  “Find  End  Users  In”  dropdown  
box.  Click  the  Find  button  to  search.  Both  SB  CUCM  users  should  be  displayed  below.  
 

 
Ensure  that  the  “Based  on  Template”  dropdown  box  contains  the  “voicemailusertemplate”  and  click  
the  Import  All  button  to  import  the  users  into  CUC.  Click  the  OK  button  to  continue.  
 

638 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
When  the  user  import  is  complete,  the  status  will  be  displayed  at  the  top  of  the  page.    
 

 
 
Try  making  a  test  call  into  the  system  from  one  of  the  HQ  phones.  You  should  now  be  presented  with  
the  “Sign  In”  prompt.  Once  again,  this  can  be  confirmed  through  the  Unity  Connection  Port  Monitor  
tool  in  RTMT.  
 

 
 
   

639 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 38.5 Ensure  that  calls  are  forwarded  to  voicemail  when  the  user  is  busy,  there  is  no  
answer,  or  the  phone  is  unregistered.    
 
In  order  to  configure  these  settings,  we  must  make  a  change  at  the  Directory  Number  level  in  CUCM  
for  both  SB  phones.    
 
On  the  SB  CUCM  cluster,  navigate  to  Device  !  Phone  and  click  on  “SB  Phone  1”.  Select  DN  “2001”  to  
enter  the  “Directory  Number  Configuration”  page.  Under  the  “Call  Forward  and  Call  Pickup  Settings”  
section,  check  the  “Voice  Mail”  checkbox  next  to  the  “Forward  Busy  Internal/External”,  Forward  No  
Answer  Internal/External”,  and  “Forward  Unregistered  Internal/External”.    
 

 
 
Click  the  Save  and  Apply  Config  buttons  when  complete.  Perform  the  same  task  for  the  other  SB  phone  
as  well.  
 
Make  a  test  call  from  one  SB  phone  to  the  other  to  ensure  that  the  call  is  forwarded  to  voicemail.  
Verify  using  the  Unity  Connection  Port  Monitor  in  RTMT.  
 

 
 
   

640 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 38.6 Configure  the  system  so  that  the  MWI  light  turns  on  when  there  is  a  message  
waiting  in  the  mailbox  and  turns  off  when  a  user  deletes  a  message  from  the  
mailbox.  
 
In  an  earlier  task,  the  MWI  On/Off  numbers  were  configured  within  Unity  Connection.  However,  they  
were  never  configured  within  CUCM.  Unlike  SIP  integrations,  which  use  “Unsolicited  Notify”  as  the  
MWI  mechanism,  SCCP  integrations  actually  require  the  On/Off  numbers  to  be  configured  within  the  
CUCM  server,  since  CUC  actually  dials  the  number  when  a  notification  is  sent.    
 
On  the  SB  CUCM  cluster,  navigate  to  Advanced  Features  !  Voice  Mail  !  Message  Waiting  and  click  
the  Add  New  button.  Enter  “2798”  for  the  “Message  Waiting  Number”,  and  select  the  “VM_PT”  for  the  
“Partition”.  Next,  select  the  “Message  Waiting  Indicator”  radio  button  to  indicate  the  type,  “On”  in  this  
case.  Last,  select  a  “Calling  Search  Space”  that  has  access  to  the  DNs  configured  in  the  system  (e.g.  
“INTERNAL_CSS”).  
 

 
 
Next,  create  the  “MWI  Off”  number  by  following  the  above  procedures.  
 

 
 
All  that  is  left  now  is  to  make  a  test  call  and  ensure  that  MWI  works.  When  the  lamp  is  lit  successfully,  
make  sure  that  you  can  log  into  the  voicemail  box  and  delete  the  message  to  make  the  lamp  turn  off.

641 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 39: CUCME Integration


Task 39.1 Configure  a  SIP  voicemail  integration  between  R3  and  the  HQ  CUC  cluster  using  pilot  
number  3700.  
 
Not  only  does  CUC  provide  a  voicemail  integration  method  for  CUCM  clusters,  but  it  also  can  support  
connections  made  to  other  systems,  including  CUCME.  Much  like  CUCM,  we  can  integrate  CUCME  with  
CUC  using  either  SCCP  or  SIP  methods.  In  this  lab,  we  have  been  tasked  with  configuring  the  SIP  
integration.    
 
As  you  might  imagine,  since  CUCME  is  running  on  an  IOS  router  (R3),  we  must  configure  a  dial-peer  
to  support  the  voicemail  integration.  The  requirements  of  the  question  state  that  the  pilot  number  
must  be  “3700”,  so  the  destination-pattern  must  be  configured  as  such.  Next,  since  this  is  a  SIP  
integration,  we  must  set  the  session protocol  to  SIP  and  configure  the  session target  to  
the  IP  address  of  the  CUC  server.  Also,  we  must  specify  the  dtmf-relay rtp-nte  command  to  use  
RFC  2833  DTMF  relay.  Lastly,  we  must  disable  Voice  Activity  Detection  (VAD).  
 
R3  
R3(config)#dial-peer voice 3700 voip
R3(config-dial-peer)#destination-pattern 3700
R3(config-dial-peer)#session protocol sipv2
R3(config-dial-peer)#session target ipv4:10.10.13.14
R3(config-dial-peer)#dtmf-relay rtp-nte
R3(config-dial-peer)#no vad
 
With  the  dial-peer  configured,  the  next  step  is  to  configure  the  global  voice  settings  on  the  router.  
These  should  have  already  been  set  during  previous  labs,  but  we  should  review  them  just  to  be  certain  
of  the  settings.  
 
R3  
R3#sh run | sec voice service voip
voice service voip
no ip address trusted authenticate
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
bind control source-interface Vlan31
bind media source-interface Vlan31
registrar server expires max 600 min 60
asymmetric payload full
 
As  you  can  see  from  the  above,  the  SIP  source  interface  for  both  control  and  media  traffic  is  set  to  use  
the  VLAN  31  SVI  (10.10.31.1).  This  is  the  address  that  will  be  used  for  all  further  SIP  communication  
from  R3.  We  will  need  to  remember  this  IP  address  during  the  CUC  configuration.  
 
   

642 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  configure  the  HQ  CUC  server  to  support  the  SIP  integration  with  CUCME.  On  the  HQ  
CUC  server,  navigate  to  Telephony  Integrations  !  Phone  System  and  click  the  Add  New  button.  Enter  
a  descriptive  name  for  the  new  phone  system  (e.g.  “R3_CUCME”)  and  click  the  Save  button  to  
continue.  
 

 
 
Since  there  is  no  further  configuration  that  needs  to  be  accomplished  within  the  “Phone  System  
Basics”  page,  select  the  “Add  a  Port  Group”  option  from  the  “Related  Links”  dropdown  box  and  click  
the  Go  button.  
 

 
 
Ensure  that  the  selected  “Port  Group  Type”  is  set  to  “SIP”.  The  “Display  Name”  parameter  can  be  left  
at  the  default  setting  (e.g.  “R3_CUCME-­‐1”).  Next,  under  the  “Primary  Server  Settings”  heading,  enter  
the  IP  address  of  the  CUCME  server  in  the  “IPv4  Address  or  Host  Name”  textbox  (e.g  “10.10.31.1”)  and  
click  the  Save  button.  
 

 
 
With  the  Port  Group  created,  we  must  now  add  Ports  to  the  system  so  the  integration  can  be  utilized.  
Select  the  “Add  Ports”  option  from  the  “Related  Links”  dropdown  box  and  click  the  Go  button.  
 

643 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Everything  within  this  page  can  be  left  at  the  default  setting,  except  the  “Number  of  Ports”  setting.  
Here,  we  can  specify  whatever  number  we  want,  since  it  was  not  defined  in  the  task  requirements.  In  
this  case,  “4”  was  chosen.  Click  the  Save  button  when  completed  to  create  the  Ports.  
 

 
 
At  this  point,  the  system  has  been  fully  configured  to  accept  incoming  SIP  connections  on  one  of  the  
four  created  ports  in  the  system.  From  either  SC  phone,  dial  the  pilot  number  of  3700  to  ensure  that  
the  Opening  Greeting  for  Unity  Connection  is  heard.  
 
Just  as  with  other  integrations,  the  Unity  Connection  Port  Monitor  in  RTMT  can  be  used  to  view  
information  about  the  call  from  the  perspective  of  CUC.    
 

 
 
As  you  can  see  in  the  above,  the  opening  greeting  is  being  played.  The  reason,  of  course,  is  that  no  
mailbox  has  been  configured  for  the  user  yet.  
 
 
   

644 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 39.2 Ensure  that  the  PSTN  phone  can  dial  the  pilot  number  to  hear  the  opening  greeting.  
 
In  order  to  make  sure  that  the  pilot  number  is  dialable  from  the  PSTN,  we  must  perform  a  little  call  
routing  on  R3,  where  the  ISDN  service  is  terminated.  In  this  case,  the  work  should  already  be  done,  
since  it  was  completed  in  a  previous  lab.  Logically  speaking,  we  must  accept  the  call  from  the  PSTN  and  
ensure  that  it  can  match  the  4-­‐digit  dial-peer  created  to  route  voicemail  calls  to  CUC.  In  IOS,  this  
should  be  accomplished  with  a  voice translation profile  (to  format  the  number  
appropriately).  Once  complete,  IOS  can  route  the  call  using  the  4-­‐digit  destination-pattern  
configured  on  the  dial-peer.  
 
R3  
R3#sh run | sec dial-peer voice 1
dial-peer voice 1 pots
translation-profile incoming TRANSLATE-PSTN-INBOUND
incoming called-number .
direct-inward-dial

R3#sh run | sec voice translation-profile TRANSLATE-PSTN-INBOUND


voice translation-profile TRANSLATE-PSTN-INBOUND
translate called 1

R3#sh run | sec voice translation-rule 1


voice translation-rule 1
rule 1 /^89444\(3...$\)/ /\1/

R3#sh run | sec dial-peer voice 3700


dial-peer voice 3700 voip
destination-pattern 3700
session protocol sipv2
session target ipv4:10.10.13.14
dtmf-relay rtp-nte
no vad
 
Make  a  test  call  from  the  PSTN  phone  to  ensure  that  the  pilot  number  can  be  reached.  Use  the  Port  
Monitor  to  verify.  
 

 
 
   

645 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 39.3 Ensure  that  users  are  created  within  the  HQ  CUC  server  with  all  passwords  set  to  
“cisco”  and  all  PINs  set  to  “12345”.  
 
Similar  to  the  previous  labs,  we  must  configure  the  Authentication  Rules  and  User  Templates  in  order  
to  apply  general  settings  to  the  user  before  creation.  This  has  already  been  done  on  the  HQ  CUC  
server,  but  it  is  a  good  idea  to  create  a  separate  user  template  for  the  users  at  SC  as  well.    
 
Navigate  to  Templates  !  User  Templates  and  click  the  Add  New  button.  Ensure  that  the  “Based  on  
Template”  dropdown  box  has  selected  the  “voicemailusertemplate”  as  the  basis  for  this  new  template.  
This  includes  the  default  PINs  and  passwords  of  “12345”  and  “cisco”  as  well  as  the  relationship  to  the  
previously  modified  authentication  rules.  Next,  add  an  “Alias”  that  can  be  used  to  identify  the  template  
(e.g.  “scusertemplate”).  Lastly,  select  the  correct  “Phone  System”  from  the  dropdown  box  to  ensure  
that  all  users  are  associated  with  the  correct  call  agent  (e.g.  “R3_CUCME”).  Click  the  Save  button  when  
complete.    
 

 
 
Since  all  optimal  settings  were  taken  from  the  existing  template,  no  other  modification  to  the  
“scusertemplate”  needs  to  happen  at  this  point.    
 
   

646 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

We  can  now  add  the  users  by  navigating  to  Users  !  Users  and  clicking  the  Add  New  button.  Ensure  
that  the  “Based  on  Template”  dropdown  box  is  set  to  use  the  “scusertemplate”  option  that  was  
previously  created.  Next,  enter  the  “Alias”  for  the  user  as  well  as  the  “First”  and  “Last  Name”.  Finally,  
add  the  “Extension”  or  DN  that  is  assigned  to  the  user  within  CUCME.  Click  the  Save  button  when  
complete.  
 

 
 
Repeat  the  above  step  for  all  users  that  must  be  created  in  the  system.    
 
Once  all  users  are  created,  dial  the  pilot  number  of  “3700”  from  either  SC  phone  and  ensure  that  the  
user  is  prompted  for  a  PIN.  
 

 
 
   

647 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 39.4 Ensure  that  users  are  able  to  press  the  messages  key  to  sign  in  to  their  user  account.    
 
We  must  configure  the  phone  system  to  behave  appropriately  when  a  CUCME  user  presses  the  
Messages  key  to  access  the  voicemail  system.  In  this  case,  since  we  have  both  SCCP  and  SIP  phones,  we  
must  configure  both  telephony-service and voice register global.  In  both  phone  
systems,  the  command  to  enable  this  feature  is  pretty  straightforward.  All  that  is  required  is  to  enter  
the  voicemail  command  followed  by  the  number  that  should  be  dialed,  in  this  case,  3700.  As  
always,  when  configuring  voice register global,  we  must  issue  the  create profile  and  
reset  commands  in  order  to  apply  the  configuration  when  complete.    
 
R3  
R3(config)#telephony-service
R3(config-telephony)#voicemail 3700

R3(config)#voice register global


R3(config-register-global)#voicemail 3700
R3(config-register-global)#create profile
R3(config-register-global)#reset
 
At  this  point,  the  Messages  key  should  be  fully  functional.  
 
   

648 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 39.5 Ensure  that  calls  are  forward  to  voicemail  when  the  user  is  busy,  or  there  is  no  
answer.  
 
Once  again,  this  task  requires  that  the  phone  system  be  configured  to  support  the  required  
functionality.  More  specifically,  it  requires  that  the  voice register  and  ephone DNs  can  
forward  the  call  to  the  appropriate  location  when  the  user  is  busy  or  there  is  no  answer.  With  
telephony-service,  this  can  be  configured  with  a  template  for  the  DN,  while  voice
register global  requires  configuration  per  DN.    
 
To  configure  for  SCCP  phones  using  a  template,  use  the  ephone-dn-template  command.  Enter  
the  call-forward busy/noan commands  to  enable  the  desired  behavior.    
 
Once  the  template  has  been  configured,  it  must  be  applied  to  the ephone-dn  by  issuing  the  
ephone-dn-template  command  under  the  ephone-dn x  tag.  The  following  example  assigns  
the  settings  to  SC  Phone  1.  Remember  to  reset  the  phone  when  the  configuration  is  complete.  
 
R3  
R3(config)#ephone-dn-template 1
R3(config-ephone-dn-template)#call-forward busy 3700
R3(config-ephone-dn-template)#call-forward noan 3700 timeout 20

R3(config)#ephone-dn 1
R3(config-ephone-dn)#ephone-dn-template 1

R3(config)#ephone 1
R3(config-ephone)#reset
 
Next,  for  SIP  phones,  we  must  issue  the  call-forward  commands  (with  slightly  different  syntax)  
under  the  voice register dn x  tag.  
 
R3  
R3(config)#voice register dn 1
R3(config-register-dn)#call-forward b2bua busy 3700
R3(config-register-dn)#call-forward b2bua noan 3700 timeout 20

R3(config)#voice register global


R3(config-register-global)#create profile
R3(config-register-global)#reset
 
With  both  phones  configured,  try  making  a  test  call  to  ensure  that  the  call  is  forwarded  successfully  to  
voicemail  when  the  user  is  unavailable.  
 

 
 
   

649 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 39.6 Configure  the  system  so  that  the  MWI  light  turns  on  when  there  is  a  message  
waiting  in  the  mailbox  and  off  when  a  user  deletes  a  message  from  the  mailbox.  
 
The  last  step  in  the  voicemail  integration  is  to  make  sure  that  the  user  can  get  properly  notified  when  
there  is  a  message  waiting  in  his  or  her  voicemail  box.  Also,  the  message  waiting  lamp  must  turn  off  
when  the  message  has  been  deleted.  Since  CUC  uses  Unsolicited  Notify  as  the  MWI  mechanism,  all  
that  is  needed  on  R3  is  to  configure  the  global  SIP  user  agent  to  accept  these  notifications  by  issuing  
the  mwi-server  command.  If  the  unsolicited  keyword  is  not  added  to  the  end  of  the  command,  
the  MWI  type  will  default  to  Subscribe  Notify  instead.  
 
R3  
R3(config)#sip-ua
R3(config-sip-ua)#mwi-server ipv4:10.10.13.14 unsolicited
 
In  addition,  we  must  enable  the  mwi  command  under  the  voice register dn x  section  of  the  
configuration.  This  is  not  required  for  SCCP  phones.  
 
R3  
R3(config)#voice register dn 1
R3(config-register-dn)#mwi

R3(config)#voice register global


R3(config-register-global)#create profile
R3(config-register-global)#reset  
 
At  this  point,  you  should  leave  a  test  message  on  both  phones  and  ensure  that  the  MWI  light  behaves  
appropriately.  

650 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 40: CUC Features


Task 40.1 Configure  the  HQ  CUC  cluster  to  launch  the  Broadcast  Message  Administrator  when  
the  number  1770  is  dialed.    
 
System  broadcast  messages  are  recorded  announcements  that  are  sent  to  everyone  in  an  organization.  
You  determine  whether  users  can  send  and/or  update  broadcast  messages,  and  set  up  a  way  for  them  
to  do  so  by  using  the  Unity  Connection  Broadcast  Message  Administrator.  (By  default,  Unity  
Connection  users  are  not  enabled  to  send  broadcast  messages.)  
 
Although  system  broadcast  messages  sound  similar  to  regular  voice  messages,  they  are  not  simply  
voice  messages  that  are  sent  to  a  large  distribution  list.  They  are  unique  in  the  following  ways:  
 
• System  broadcast  messages  are  played  immediately  after  users  sign  in  to  Cisco  Unity  
Connection  by  phone—even  before  they  hear  message  counts  for  new  and  saved  messages.  
After  signing  in,  users  hear  how  many  system  broadcast  messages  they  have  and  Unity  
Connection  begins  playing  them.  
• For  each  system  broadcast  message,  the  sender  specifies  how  long  Unity  Connection  
broadcasts  the  message.  The  sender  can  specify  that  a  system  broadcast  message  is  “active”  for  
a  day,  a  week,  a  month—even  indefinitely.  A  user  hears  the  system  broadcast  message  the  first  
time  that  he  or  she  signs  in  to  Unity  Connection  during  the  period  that  the  message  is  active.  
• Users  must  listen  to  a  system  broadcast  message  in  its  entirety  before  Unity  Connection  allows  
them  to  hear  new  and  saved  messages  or  to  change  setup  options.  Users  cannot  fast-­‐forward  
or  skip  a  system  broadcast  message.  
• If  a  user  hangs  up  before  playing  the  entire  system  broadcast  message,  the  message  plays  again  
the  next  time  that  the  user  signs  in  to  Unity  Connection  by  phone  (assuming  that  the  message  is  
still  active).  
• When  a  user  has  finished  playing  a  system  broadcast  message,  the  message  can  either  be  
replayed  or  permanently  deleted.  Users  cannot  respond  to,  forward,  or  save  system  broadcast  
messages.  
• Users  can  receive  an  unlimited  number  of  system  broadcast  messages.  
• Users  receive  system  broadcast  messages  even  when  they  exceed  their  mailbox  size  limits  and  
are  no  longer  able  to  receive  other  messages.  Because  of  the  way  that  the  messages  are  stored  
on  the  Unity  Connection  server,  they  are  not  included  in  the  total  mailbox  size  for  each  user.  
• New  users  hear  all  active  system  broadcast  messages  immediately  after  they  enroll  as  Unity  
Connection  users.  
• By  design,  system  broadcast  messages  do  not  trigger  message  waiting  indicators  (MWIs)  on  
user  phones.  They  also  do  not  trigger  message  notifications  for  alternative  devices,  such  as  a  
pager  or  another  phone.  
• Users  hear  broadcast  messages  only  when  listening  to  messages  by  phone.  Users  do  not  receive  
system  broadcast  messages  when  listening  to  messages  in  the  Cisco  Unity  Connection  Web  
Inbox,  Messaging  Inbox,  an  RSS  reader,  IMAP  clients,  Cisco  Unified  Personal  Communicator,  or  
Cisco  Unified  Messaging  with  IBM  Lotus  Sametime.  

651 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

• When  single  inbox  is  configured,  broadcast  messages  are  excluded  from  synchronization  
between  Unity  Connection  and  Exchange.  
• Unity  Connection  does  not  respond  to  voice  commands  while  playing  broadcast  messages.  
When  using  the  voice-­‐recognition  input  style,  users  will  need  to  use  key  presses  to  either  replay  
or  delete  the  broadcast  message.  
[Source:  
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsa
gx/9xcucsag220.html]  
 
To  configure  access  to  the  Broadcast  Message  Administrator,  we  must  first  determine  the  method  in  
which  it  will  be  reached.  Remember,  CUC  considers  every  call  either  a  “Direct”  or  “Forwarded”  call,  and  
knowing  the  difference  is  important  in  the  configuration  of  the  feature.  If  we  would  like  to  configure  
access  to  the  Broadcast  Message  Administrator  by  way  of  a  direct  call  (i.e.  Number  is  dialed  directly  by  
a  user),  then  we  must  create  a  Direct  Routing  Rule.  We  must  configure  Forwarded  Routing  Rules  if  it  
will  be  accessed  using  a  forwarded  call  (e.g.  Calls  forwarded  by  a  CTI  Route  Point).  In  this  example,  we  
will  configure  Direct  Routing  Rules.  
 
In  the  HQ  CUC  server,  navigate  to  Call  Management  !  Call  Routing  !  Direct  Routing  Rules  and  click  
the  Add  New  button.  Enter  a  descriptive  “Display  Name”  for  the  Direct  Routing  Rule  (e.g.  
“HQ_CUC_Broadcast_Administrator”)  and  click  the  Save  button  to  continue.    
 

 
 
Please  note  that  after  the  Save  button  is  clicked,  the  routing  rule  is  ACTIVE.  This  means  that  every  
single  direct  call  to  CUC  will  be  routed  to  this  rule  until  conditions  are  set.  In  other  words,  be  careful  in  
production,  because  adding  a  CUC  routing  rule  in  the  middle  of  heavy  use  could  end  with  the  
perpetrating  network  engineer  looking  for  a  new  job!    So  ensure  that  these  changes  are  always  
performed  “after  hours”.  The  next  part  of  the  configuration  involves  creating  specific  conditions  so  
that  the  rule  is  only  selected  during  the  desired  circumstances.    
 
Under  the  “Routing  Rule  Conditions”  section,  click  the  Add  New  button.    
 

 
 
   

652 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

For  the  “Dialed  Number”  parameter,  select  the  “Equals”  option  from  the  dropdown  box  and  enter  
“1770”  in  the  textbox.  This  will  ensure  that  the  rule  is  matched  as  long  as  “1770”  is  the  dialed  number.  
 

 
 
Click  the  Save  button  to  apply  the  configuration.  Back  on  the  Direct  Routing  Rule  Configuration  page,  
under  the  “Send  Call  To”  section,  ensure  that  the  “Broadcast  Message  Administrator”  option  is  
selected  for  the  “Conversation”  parameter.  Click  the  Save  button  when  complete.    
 

 
 
With  the  CUC  part  of  the  configuration  complete,  we  must  now  configure  the  call  agent  (HQ  CUCM)  to  
route  calls  to  “1770”  to  the  CUC  server.  Since  a  SIP  integration  has  already  been  configured  between  
the  HQ  CUCM  and  CUC  servers,  the  existing  Voice  Mail  Pilot  Route  Pattern  can  be  copied  and  used  to  
create  the  pattern  to  access  the  Broadcast  Message  Administrator.    
 
On  the  HQ  CUCM  server,  navigate  to  Call  Routing  !  Route/Hunt  !  Route  Pattern  and  click  the  Find  
button.  Search  for  the  existing  Route  Pattern  for  the  Voice  Mail  Pilot  (e.g.  “1700”).  In  the  “Route  
Pattern  Configuration”  window,  click  the  Copy  button.    
 

 
 
Enter  the  new  “Route  Pattern”  as  “1770”  and  change  the  “Description”  if  necessary.  Click  the  Save  
button  when  complete.  
 

 
 
With  the  CUCM  configuration  now  complete,  make  a  test  call  from  an  HQ  phone  and  make  sure  that  
the  greeting  for  the  Broadcast  Message  Administrator  is  played.  
 

653 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 40.2 Ensure  that  HQ  Phone  1  can  send  broadcast  messages  out  to  other  phones  on  the  
cluster.  
 
To  make  sure  that  HQ  Phone  1  is  able  to  send  broadcast  messages,  we  must  edit  the  CUC  user  settings  
in  some  fashion.  Logically  speaking,  you  would  think  that  this  ability  would  be  contained  within  a  roles  
or  permissions  area  of  the  system,  but  this  is  not  so.  To  enable  this  functionality,  navigate  to  Users  !  
Users  and  click  on  “hqp1”.  From  the  “Edit  User  Basics”  page,  navigate  to  Edit  !  Send  Message  Settings  
and  check  the  “User  Can  Send  Broadcast  Messages  to  Users  on  This  Server”  checkbox.  Optionally,  the  
“User  Can  Update  Broadcast  Messages  Stored  on  This  Server”  checkbox  can  be  selected  as  well.  
 

 
 
Click  the  Save  button  when  complete.    
 
To  test  the  configuration,  dial  the  Broadcast  Message  Administrator  number  (1770)  from  any  phone  
and  log  in  using  the  ID  of  “1001”  and  the  PIN  of  “12345”.  Send  a  broadcast  message  and  ensure  that  
other  phones  on  the  system  can  hear  the  message.  Remember,  since  SC  phones  are  currently  utilizing  
the  HQ  CUC  server  for  voicemail,  they  should  receive  the  message  as  well.  
 
   

654 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 40.3 Create  an  auto  attendant  using  the  number  2770  that  can  answer  calls  for  SB  users  
on  the  SB  CUC.  
 
This  task  requires  that  we  create  an  auto  attendant  on  the  SB  CUC  cluster  to  answer  calls  destined  for  
extension  2770.  An  auto  attendant  can  be  created  in  CUC  by  using  an  object  called  a  Call  Handler.  
There  are  three  default  Call  Handlers  already  predefined  within  Unity  Connection.  
 
• Opening  Greeting  -­‐  Acts  as  an  automated  attendant,  playing  the  greeting  that  callers  first  hear  
when  they  call  your  organization,  and  performing  the  actions  you  specify.  The  Opening  Greeting  
Call  Routing  rule  transfers  all  incoming  calls  to  the  Opening  Greeting  call  handler.  By  default,  
the  Opening  Greeting  call  handler  allows  callers  to  press  *  to  reach  the  Sign-­‐In  conversation,  or  
press  #  to  reach  the  Operator  call  handler.  Messages  left  in  the  Opening  Greeting  call  handler  
are  sent  to  the  Undeliverable  Messages  distribution  list.  
• Operator  -­‐  Calls  are  routed  to  this  call  handler  when  callers  press  “0”  or  do  not  press  any  key  
(the  default  setting).  You  can  configure  the  Operator  call  handler  so  that  callers  can  leave  a  
message  or  be  transferred  to  a  live  operator.  By  default,  the  Operator  call  handler  allows  callers  
to  press  *  to  reach  the  Sign-­‐In  conversation,  or  press  #  to  reach  the  Opening  Greeting  call  
handler.  Messages  left  in  the  Operator  call  handler  are  sent  to  the  mailbox  for  the  Operator  
user.  
• Goodbye  -­‐  Plays  a  brief  goodbye  message  and  then  hangs  up  if  there  is  no  caller  input.  By  
default,  the  Goodbye  call  handler  allows  callers  to  press  *  to  reach  the  Sign-­‐In  conversation,  or  
press  #  to  reach  the  Opening  Greeting  call  handler.  If  you  change  the  After  Greeting  action  from  
Hang  Up  to  Take  Message,  messages  left  in  the  Goodbye  call  handler  are  sent  to  the  
Undeliverable  Messages  distribution  list.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/administration/guide/9xcucsa
gx/9xcucsag060.html]  
 
To  configure  the  Call  Handler  that  will  act  as  the  SB  Auto  Attendant,  navigate  to  Call  Management  !  
System  Call  Handlers  within  the  SB  CUC  server  and  click  the  Add  New  button.  Enter  a  descriptive  
“Display  Name”  for  the  Call  Handler  (e.g.  “AA_CH”)  and  enter  “2770”  for  the  “Extension”,  as  required  
within  the  task.  Click  the  Save  button  when  complete.    
 

 
 
   

655 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  CUC  server  configuration  complete,  we  must  now  configure  the  SB  CUCM  server  to  route  calls  
for  “2770”  towards  the  SB  CUC  server.  In  an  earlier  task,  it  was  demonstrated  that  the  Broadcast  
Message  Administrator  could  be  accessed  using  Direct  Routing  Rules  within  CUC.  In  this  example,  we  
still  have  the  ability  to  use  the  “direct”  method  by  copying  the  existing  SCCP  Voice  Mail  Hunt  Pilot  and  
changing  the  number  to  2770,  if  desired.  In  that  case,  however,  we’d  still  need  to  create  a  Direct  
Routing  Rule  to  accommodate  the  dialing  behavior.  Instead,  the  call  can  be  routed  with  the  
“forwarded”  method  using  a  CTI  Route  Point  configured  on  the  SB  CUCM  server.  
 
On  the  SB  CUCM  server,  navigate  to  Device  !  CTI  Route  Point  and  click  the  Add  New  button.  Enter  a  
descriptive  “Device  Name”  for  the  CTI  Route  Point  (e.g.  “SB_CUC_AA_CTI”)  as  well  as  an  appropriate  
“Device  Pool”  (e.g.  “SB_CUC_SCCP_DP”).  Click  the  Save  button  when  complete.  
 

 
 
Next,  under  the  “Association  Information”  section,  click  the  “Line  [1]  –  Add  a  new  DN”  link.  
 

 
 
For  the  “Directory  Number”  field,  enter  the  number  of  the  Call  Handler  that  was  configured  in  CUC  
(e.g.  “2770”)  and  select  an  appropriate  “Route  Partition”  (e.g.  “VM_PT”).  
 

 
 
Next,  scroll  down  to  the  “Call  Forward  and  Call  Pickup  Settings”  section  and  check  the  “Voice  Mail”  
checkbox  for  the  “Forward  All”  setting.  Remember  to  set  a  CSS  with  access  to  the  Voice  Mail  Pilot  
number  (e.g.  “PHONE_CSS”).  
 

 
 
Click  the  Save  button  when  complete.  

656 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

This  configuration  will  essentially  accept  the  call  with  the  CTI  Route  Point  and  forward  it  immediately  
to  the  CUC  server  with  the  redirecting  number  of  “2770”.    
 
Once  the  CUCM  configuration  is  complete,  make  a  test  call  to  2770  and  ensure  that  the  created  Call  
Handler  is  reached.  Once  again,  this  can  be  verified  using  the  Port  Monitor  tool  in  RTMT.  
 

 
 
   

657 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 40.4 The  auto  attendant  should  provide  a  custom  recorded  greeting  with  the  following:    
“Thank  you  for  calling  Site  B.  Please  press  1  for  sales,  2  for  technical  support,  or  3  to  
dial  by  name.”      
 
In  order  to  record  a  greeting  for  a  Call  Handler  in  Unity  Connection,  Cisco  has  included  a  Java-­‐based  
recording  tool  that  can  be  invoked  from  the  web  interface.  Since  this  tool  is  largely  dependent  on  the  
currently  “en  vogue”  Java  version,  its  behavior  is  not  very  consistent.  Nevertheless,  we  must  use  it  to  
record  greetings  in  the  system,  when  required.    
 
In  the  SB  CUC  server,  navigate  to  Call  Management  !  System  Call  Handlers  and  click  on  the  previously  
created  Call  Handler  (e.g.  “AA_CH”).  From  the  “Edit  Call  Handler  Basics”  page,  navigate  to  Edit  !  
Greetings  and  click  on  the  “Standard”  greeting.  Under  the  “Recordings”  section,  click  the  Play/Record  
button  to  launch  the  Java  applet.  After  clicking  through  the  numerous  security  warnings  and  pop-­‐up  
windows,  the  recording  window  should  finally  launch.  
 

 
 
Click  the  Record  button  (red  circle)  to  record  using  the  microphone  of  the  computer.  You  may  also  use  
the  Play  button  (blue  triangle)  to  listen  to  the  recording,  if  desired.  When  you  are  satisfied  with  the  
recording,  click  the  Save  button  to  apply  the  configuration  to  the  Call  Handler.    
 
Once  again,  attempt  a  call  to  “2770”  and  observe  the  behavior.  The  newly  recorded  audio  should  be  
played  when  the  call  is  connected.  
 
   

658 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 40.5 If  the  user  presses  1,  direct  the  call  to  SB  Phone  1.  If  the  user  presses  2,  direct  the  
call  to  SB  Phone  2.  If  the  user  presses  3,  allow  the  caller  to  access  the  “Dial  By  
Name”  directory.  
 
This  task  is  asking  us  to  continue  the  configuration  of  the  existing  Call  Handler  by  adding  “Caller  Input”  
options.  This  will  allow  the  connection  to  other  parts  of  the  CUC  system  as  well  as  external  resources.  
On  the  SB  CUC  server,  navigate  to  Call  Management  !  System  Call  Handlers  and  click  on  the  
previously  created  Call  Handler  (e.g.  “AA_CH”).  From  the  “Edit  Call  Handler  Basics”  page,  navigate  to  
Edit  !  Caller  Input.  On  this  screen,  we  have  the  ability  to  configure  actions  for  user  key  presses  when  
“inside”  the  “AA_CH”  Call  Handler.    
 

 
 
First,  click  the  link  for  key  “1”.  On  the  “Edit  Caller  Input”  page,  select  the  “sbp1”  user  for  the  “User  
With  Mailbox”  option.  In  this  case,  we  also  want  to  “Attempt  Transfer”  so  the  user  has  an  opportunity  
to  answer  the  call.  Click  the  Save  button  when  complete.  
 

 
 

659 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

For  key  “2”,  we  should  basically  configure  the  same  thing—except  that  we  must  change  the  “User  with  
Mailbox”  option  to  use  “sbp2”.  Click  the  Save  button  when  complete.  
 
For  key  “3”,  we  must  configure  access  to  the  “Dial  By  Name”  directory.  This  may  sound  complicated,  
but  all  that  is  involved  is  to  send  the  caller  to  the  “System  Directory  Handler”  by  selecting  that  option  
from  the  “Directory  Handler”  dropdown  box.  From  there,  it  is  possible  to  dial  by  name.  
 

 
 
Click  the  Save  button  when  complete.  
 
With  the  Caller  Input  parameters  configured,  make  a  test  call  to  the  Call  Handler  and  ensure  that  the  
options  work  as  expected.  
 
   

660 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 40.6 Ensure  that  there  is  a  4  second  delay  after  the  greeting  is  heard.  The  greeting  should  
then  be  repeated  up  to  3  times.  
 
Once  again,  this  task  requires  that  we  continue  to  edit  the  existing  Call  Handler  in  the  system.  Navigate  
to  Call  Management  !  System  Call  Handlers  and  click  on  the  previously  created  Call  Handler  (e.g.  
“AA_CH”).  From  the  “Edit  Call  Handler  Basics”  page,  navigate  to  Edit  !  Greetings  and  click  on  the  
“Standard”  greeting.    
 
Under  the  “During  Greeting”  section,  set  the  “Times  to  Re-­‐prompt  Caller”  and  “Delay  between  Re-­‐
prompts”  parameters  to  “3”  and  “4”,  respectively.  This  will  repeat  the  original  greeting  that  is  heard  
and  place  a  four  second  pause  between  the  repeated  greetings.  
 

 
 
Click  the  Save  button  when  complete.  
 
Place  a  call  to  the  Auto  Attendant  to  test  the  functionality.  
 
   

661 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 40.7 Ensure  that  SB  Phone  1  has  access  to  modify  and  enable  greetings  for  the  newly  
created  auto  attendant  by  dialing  extension  2780.  Do  not  use  a  call  handler  to  
accomplish  this.    
 
There  is  an  alternative  method  (other  than  the  Java  applet)  to  manage  greetings  for  Call  Handlers  in  
the  system  called  the  Greetings  Administrator.  Users  that  have  access  must  have  the  “Greeting  
Administrator”  role  assigned  to  their  CUC  account.  Also,  the  Call  Handler  in  question  must  have  an  
extension  assigned  in  order  to  edit  the  greeting.  
 
To  accommodate  the  requirements,  navigate  to  Call  Management  !  Call  Routing  !  Forwarded  
Routing  Rules  and  click  the  Add  New  button.  Provide  a  descriptive  “Display  Name”  for  the  rule  (e.g.  
“SB_CUC_Greetings_Administrator”)  and  click  the  Save  button.  
 

 
 
On  the  “Edit  Forwarded  Routing  Rule”  page  under  the  “Routing  Rule  Conditions”  section,  click  the  Add  
New  button.  For  the  “Dialed  Number”  parameter,  select  the  “Equals”  operator  from  the  dropdown  box  
and  enter  the  number  “2780”.    
 

 
 
Click  the  Save  button  when  complete.  
 
On  the  “Edit  Forwarded  Routing  Rule”  page  under  the  “Send  Call  to”  section,  select  the  “Greetings  
Administrator”  option  from  the  “Conversation”  dropdown  box.  
 

 
 
Click  the  Save  button  when  complete.  
 

662 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Users  !  Users  and  select  the  “sbp1”  user.  On  the  “Edit  User  Basics”  page,  navigate  to  
Edit  !  Roles  and  move  the  “Greeting  Administrator”  role  to  the  “Assigned  Roles”  list  box.  
 

 
 
Click  the  Save  button  when  complete.    
 
With  the  CUC  server  configuration  complete,  the  only  thing  left  is  to  create  the  CTI  Route  Point  to  
forward  the  call  from  the  SB  CUCM  server  to  the  SB  CUC  cluster.  Navigate  to  Device  !  CTI  Route  Point  
and  click  the  Find  button.  
 

 
 
Click  the  Copy  button  next  to  the  CTI  Route  Point  for  the  existing  Auto  Attendant  to  create  a  new  CTI  
Route  Point  based  on  the  existing  one.  Enter  a  descriptive  “Device  Name”  for  the  Greetings  
Administrator  functionality  (e.g.  “SB_CUC_GA_CTI”)  and  click  the  Save  button.  
 

 
 
Next,  click  the  “Line  [1]  -­‐  Add  a  new  DN”  link  and  enter  the  required  “Directory  Number”  of  “2780”.  
Select  an  appropriate  “Route  Partition”  as  well  (e.g.  “VM_PT”).  
 

 
 

663 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  scroll  down  to  the  “Call  Forward  and  Call  Pickup  Settings”  section  and  check  the  “Voice  Mail”  
checkbox  for  the  “Forward  All”  setting.  Remember  to  set  a  CSS  with  access  to  the  Voice  Mail  Pilot  
number  (e.g.  “PHONE_CSS”).  
 

 
 
Click  the  Save  button  when  complete.  
 
With  the  configuration  on  CUC  and  CUCM  complete,  we  can  now  make  a  test  call  into  the  system  to  
access  the  Greetings  Administrator.  Once  again,  this  can  be  verified  by  using  the  Port  Monitor  tool  in  
RTMT.  
 

 
 

664 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 41: Digital Networking Configuration


Task 41.1 Configure  both  the  HQ  CUC  cluster  and  the  SB  CUC  cluster  to  replicate  to  each  other.  
 
Each  Cisco  Unity  Connection  server  (or  cluster)  has  a  maximum  number  of  users  that  it  can  serve.  
When  the  messaging  needs  of  your  organization  require  more  than  one  Connection  server  or  cluster,  
or  you  need  a  way  to  combine  multiple  Connection  directories  or  to  internetwork  Connection  with  
Cisco  Unity,  you  can  link  Connection  servers  or  clusters  together  to  form  sites,  and  link  a  Connection  
site  with  another  Connection  site  or  with  a  Cisco  Unity  site  to  form  a  Cisco  Voicemail  Organization.  
 
You  can  join  two  or  more  Connection  servers  or  clusters  (up  to  a  maximum  of  ten)  to  form  a  well-­‐
connected  network,  referred  to  as  a  Connection  site.  The  servers  that  are  joined  to  the  site  are  
referred  to  as  locations.  (When  a  Connection  cluster  is  configured,  the  cluster  counts  as  one  location  in  
the  site.)  Within  a  site,  each  location  uses  SMTP  to  exchange  directory  synchronization  information  and  
messages  directly  with  every  other  location.  Each  location  is  said  to  be  linked  to  every  other  location  in  
the  site  via  an  intrasite  link.  
 
You  can  use  an  intersite  link  to  connect  one  Cisco  Unity  Connection  site  to  another  Connection  site,  
allowing  you  to  scale  your  organization  from  a  maximum  of  ten  locations  to  a  maximum  of  twenty.  Or,  
you  can  use  an  intersite  link  to  connect  a  9.x  Connection  server  or  site  to  a  Cisco  Unity  server  or  Cisco  
Unity  Digital  Network.  The  linked  sites  are  referred  to  as  a  Cisco  Voicemail  Organization.  
 
To  create  an  intersite  link,  you  select  a  single  location  from  each  site  to  act  as  a  gateway  to  the  other  
site.  All  directory  synchronization  communications  pass  between  the  two  site  gateways,  thereby  
limiting  the  connectivity  requirements  and  bandwidth  usage  to  the  link  between  those  two  site  
gateway  locations.  
 
Only  one  intersite  link  is  supported  per  site.  So,  you  can  link  a  single  Connection  site  to  a  single  Cisco  
Unity  site,  or  a  single  Connection  site  to  another  Connection  site.  
[Source:  
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/networking/guide/9xcucnetx/
9xcucnet010.html]  
 
In  this  particular  version  of  Unity  Connection,  there  are  some  issues  with  successfully  creating  Intrasite  
links.  Normally,  this  would  be  the  preferred  method  of  configuration  when  sharing  information  
between  clusters.  Obviously,  this  presents  a  roadblock  for  us  in  accomplishing  the  required  task  in  the  
commonly  used  approach.  In  this  case,  however,  we  can  still  configure  an  Intersite  link  to  successfully  
share  information  between  clusters.  
 
   

665 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Within  the  HQ  CUC  server,  navigate  to  Networking  !  Links  !  Intersite  Links  and  click  the  Add  button.  
 

 
 
On  the  “New  Intersite  Link”  page,  click  the  “Link  to  Cisco  Unity  Connection  Site  by  Using  Automatic  
Configuration  Exchange  Between  Servers”  option.  A  window  will  then  pop  up  to  confirm.  Click  the  OK  
button.  
 

 
 
Enter  the  “Hostname”  (or  IP  address  in  this  case)  of  the  remote  server  (e.g.  “10.10.23.14”)  along  with  
the  username  and  password  that  should  be  used  to  log  in.  
 

 
 
Under  the  “Transfer  Protocol”  section,  uncheck  the  “User  Secure  Sockets  Layer  (SSL)”  setting  to  avoid  
issues  with  security  certificates.  
 

 
 
   

666 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “Intersite  SMTP  Routing”  section,  ensure  that  the  “Route  to  this  Remote  Site  Through  
the  Remote  Site  Gateway”  radio  button  is  selected.  
 

 
 
Click  the  Save  button  when  the  configuration  is  complete.  Make  sure  to  configure  the  SB  CUC  server  to  
connect  to  the  HQ  CUC  server  as  well.  
 
Once  again,  navigate  to  Networking  !  Links  !  Intersite  Links  and  click  the  Find  button.  In  the  row  for  
the  newly  created  link,  click  the  Sync  button  to  synchronize  data  from  the  remote  server.  
 

 
 
Click  on  the  “sbcuc”  link  to  view  the  status  of  the  synchronization.  
 

 
 
Perform  the  same  task  on  the  SB  CUC  cluster  for  the  “hqcuc”  intersite  Link.  
 

667 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 41.2 Ensure  that  user  information  belonging  to  the  SB  CUC  cluster  can  be  viewed  on  the  
HQ  CUC  cluster  and  vice  versa.  
 
Now  that  the  CUC  servers  are  replicating  data,  we  must  be  able  to  access  the  information  in  some  
fashion.  In  this  case,  it  could  not  be  easier.  All  that  must  be  done  is  to  navigate  to  Users  !  Users  and  
click  the  Find  button.  On  this  page,  you  should  now  see  users  from  the  remote  cluster  (gray  user  icons).  
 
HQ  CUC  

 
 
SB  CUC  

 
 
In  addition  to  user  data,  CUC  can  synchronize  System  Contacts,  System  Distribution  Lists,  Partitions,  
Search  Spaces,  Connection  Locations,  and  VPIM  Locations  between  clusters.  
 
Task 41.3 Ensure  users  can  forward  voicemail  messages  between  clusters.  

668 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
In  order  to  forward  a  voicemail  message,  a  user  must  be  logged  into  their  respective  voicemail  box.  In  
addition,  that  user  must  have  access,  via  the  configured  Search  Space,  to  forward  the  message  to  the  
corresponding  user,  determined  by  Partition.  Since  Partitions  and  Search  Spaces  are  part  of  the  
replicated  information,  all  that  must  be  done  is  to  add  the  Partitions  assigned  to  users  at  the  remote  
cluster  to  the  Search  Spaces  of  users  on  the  local  cluster.    
 
On  the  HQ  CUC  cluster,  navigate  to  Dial  Plan  !  Search  Spaces  and  click  on  the  default  Search  Space  for  
the  cluster  (e.g.  “hqcuc  Search  Space”).  Move  the  default  SB  CUC  Partition  (e.g.  “sbcuc  Partition”)  into  
the  “Assigned  Partitions”  list  box  and  click  the  Save  button.  
 

 
 
On  the  SB  CUC  cluster,  make  sure  to  add  the  default  HQ  CUC  Partition  (e.g.  “hqcuc  Partition”)  to  the  
default  SB  CUC  Search  Space  (e.g.  “sbcuc  Search  Space”).  
 

 
 
Leave  a  voice  message  for  a  user  on  each  cluster.  Log  into  the  voicemail  box  and  follow  the  prompts  to  
forward  the  message  to  the  remote  user.

669 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Nine  Labs  42  -­‐  44  
Version  1.0  

670 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 9: Configuring and Troubleshooting Cisco Unity Express


Lab 42: CUCME Integration
Task 42.1 Configure  R3  to  support  the  CUE  module.  Set  up  the  basic  information  needed  to  
operate  the  CUE  module  including  what  is  needed  to  access  the  web-­‐based  GUI  to  
manipulate  user’s  extensions  and  mailboxes  at  10.10.31.254.    
 
Cisco  Unity  Express  (CUE)  is  a  lightweight  voicemail  server  that  caters  to  smaller,  branch  sites  rather  
than  larger,  centrally  located  sites.  The  entire  system  exists  within  a  module  installed  in  an  IOS  router.  
In  each  pod,  R3  has  been  equipped  with  a  SM-­‐SRE-­‐710-­‐K9  Services  Ready  Engine  (SRE)  to  run  the  CUE  
software.  Cisco  SREs  have  their  own  processors,  storage,  network  interfaces,  and  memory  that  operate  
independently  of  the  host  router  resources.  It  can  be  accessed  through  the  SM1/0  interface  on  the  
router.  
 
The  first  step  in  configuring  the  system  is  to  set  the  IP  address  by  which  it  can  connect  to  the  network.  
The  task  requirements  state  that  this  must  be  defined  as  10.10.31.254.  To  configure  the  SRE  with  the  
correct  IP  addressing  information,  we  must  enter  the  SM1/0  interface  configuration.  As  you  may  have  
noticed,  the  required  address  for  the  CUE  module  exists  within  the  previously  defined  subnet  assigned  
to  the  VLAN  31  SVI.  This  means  that  we  must  define  the  IP  address  of  the  SM1/0  router  interface  as  
unnumbered  for  VLAN  31.  We  are  essentially  “borrowing”  the  IP  Address  of  the  VLAN  31  SVI  for  use  on  
the  SM1/0  router  port.  Next,  we  must  define  the  IP  address  of  the  service  module  by  issuing  the  
service-module ip address  command.  We  must  also  enter  the  service-module ip
default-gateway  command  to  set  the  default  router.  
 
R3  
R3(config)#interface SM1/0
R3(config-if)#ip unnumbered Vlan31
R3(config-if)#service-module ip address 10.10.31.254 255.255.255.0
R3(config-if)#service-module ip default-gateway 10.10.31.1
 
Once  the  interface  configuration  is  complete,  we  must  also  add  a  static  route  to  the  global  
configuration  for  R3.  This  ensures  that  all  web  traffic  can  reach  the  CUE  module  in  the  network.  
Without  this  command,  the  router  would  not  understand  how  to  route  the  traffic.  In  this  case,  we  are  
entering  the  exact  IP  address  of  the  CUE  module  along  with  a  subnet  mask  of  255.255.255.255.  The  
SM1/0  interface  is  also  specified.  This  format  is  commonly  referred  to  as  a  host  route.    
 
R3  
R3(config)#ip route 10.10.31.254 255.255.255.255 SM1/0
 
From  there,  we  have  the  ability  to  create  a  session  to  the  CUE  module  to  begin  the  configuration.  Issue  
the  service-module sm1/0 session  command.  
 
R3  
R3#service-module sm1/0 session
Trying 10.10.31.1, 2067 ... Open
se-10-10-31-254#
 

671 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  first  thing  that  should  be  done  here  is  to  restore  factory  defaults  for  the  module.  You  can  never  be  
sure  of  the  state  that  the  last  student  left  it.  To  begin  the  process,  issue  the  offline command.  This  
will  prevent  the  module  from  processing  calls  and  will  also  provide  additional  configuration  commands.  
Now  issue  the  restore factory default  command  and  press  the  Enter  key  to  confirm.  This  
will  reboot  the  SRE  to  perform  the  changes.  
 
R3  
se-10-10-31-254# offline
!!!WARNING!!!: If you are going offline to do a backup, it is recommended
that you save the current running configuration using the 'write' command,
prior to going to the offline state.

Putting the system offline will disable management interfaces.

Are you sure you want to go offline?[confirm]

se-10-10-31-254(offline)# restore factory default


!!!WARNING!!!: This operation will cause all configuration and data
on the system to be erased. This operation is not reversible.

Do you wish to continue?[confirm]


Restoring the system. Please wait .....done
System will be restored to factory default when it reloads.

Press any key to reload:

System reloading ....


 
When  the  system  returns,  we  must  go  through  the  setup  wizard  to  configure  elements  such  as  the  
username  and  password  as  well  as  the  time  zone  and  NTP  servers.  
 
R3  
IMPORTANT:: Welcome to Cisco Systems Service Engine
IMPORTANT:: post installation configuration tool.
IMPORTANT::
IMPORTANT:: This is a one time process which will guide
IMPORTANT:: you through initial setup of your Service Engine.
IMPORTANT:: Once run, this process will have configured
IMPORTANT:: the system for your location.
IMPORTANT::
IMPORTANT:: If you do not wish to continue, the system will be halted
IMPORTANT:: so it can be safely removed from the router.
IMPORTANT::

Do you wish to start configuration now (y,n)? y


Are you sure (y,n)? y

Enter Hostname
(my-hostname, or enter to use se-10-10-31-254): CUE

Enter Domain Name


(mydomain.com, or enter to use localdomain):
Using localdomain as default

IMPORTANT:: DNS Configuration:


IMPORTANT::
IMPORTANT:: This allows the entry of hostnames, for example foo.cisco.com, instead
IMPORTANT:: of IP addresses like 1.100.10.205 for application configuration. In order
IMPORTANT:: to set up DNS you must know the IP address of at least one of your
IMPORTANT:: DNS Servers.

Would you like to use DNS (y,n)?n

672 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

WARNING: If DNS is not used, IP addresses will be required.

Are you sure (y,n)? y

Enter IP Address of the Primary NTP Server


(IP address, or enter for 10.10.31.1): 10.10.1.1
Found server 10.10.1.1

Enter IP Address of the Secondary NTP Server


(IP address, or enter to bypass):

Please identify a location so that time zone rules can be set correctly.
Please select a continent or ocean.
1) Africa 4) Arctic Ocean 7) Australia 10) Pacific Ocean
2) Americas 5) Asia 8) Europe
3) Antarctica 6) Atlantic Ocean 9) Indian Ocean
#? 8

Please select a country.


1) Aaland Islands 18) Greece 35) Norway
2) Albania 19) Guernsey 36) Poland
3) Andorra 20) Hungary 37) Portugal
4) Austria 21) Ireland 38) Romania
5) Belarus 22) Isle of Man 39) Russia
6) Belgium 23) Italy 40) San Marino
7) Bosnia & Herzegovina 24) Jersey 41) Serbia
8) Britain (UK) 25) Latvia 42) Slovakia
9) Bulgaria 26) Liechtenstein 43) Slovenia
10) Croatia 27) Lithuania 44) Spain
11) Czech Republic 28) Luxembourg 45) Sweden
12) Denmark 29) Macedonia 46) Switzerland
13) Estonia 30) Malta 47) Turkey
14) Finland 31) Moldova 48) Ukraine
15) France 32) Monaco 49) Vatican City
16) Germany 33) Montenegro
17) Gibraltar 34) Netherlands
#? 16

The following information has been given:

Germany

Therefore TZ='Europe/Berlin' will be used.


Is the above information OK?
1) Yes
2) No
#? 1

Local time is now: Tue Dec 30 22:53:21 CET 2014.


Universal Time is now: Tue Dec 30 21:53:21 UTC 2014.
executing app post_install

Enter Call Agent


1) Cisco Unified Communications Manager (CUCM) -- default
2) Cisco Unified Communications Manager Express (CUCME)
#? 2
Setting Call Agent to CUCME

...

IMPORTANT::
IMPORTANT:: Administrator Account Creation
IMPORTANT::
IMPORTANT:: Create an administrator account. With this account,
IMPORTANT:: you can log in to the Cisco Unity Express GUI and
IMPORTANT:: run the initialization wizard.
IMPORTANT::

673 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Enter administrator user ID:


(user ID): admin
Enter password for admin:
(password):
Confirm password for admin by reentering it:
(password):

SYSTEM ONLINE
 
With  the  system  now  online,  we  can  access  the  webpage  for  CUE  administration  by  navigating  to  
10.10.31.254  in  a  web  browser.  
 

 
 
Log  in  using  the  credentials  that  were  used  in  the  initial  system  setup  (e.g.  admin/cciecollab).  After  
logging  in,  an  Initialization  Wizard  is  launched.  Believe  it  or  not,  the  best  option  here  is  to  “Skip  the  
Initialization  Wizard  and  Log  off”.  The  reason  is  because  the  Initialization  Wizard  really  isn’t  all  that  
helpful  to  us.  We  can  perform  the  same  configuration  much  more  quickly  after  it  has  been  bypassed.  
 

 
 
Log  in  again  and  the  system  should  now  be  ready  for  configuration.  
 
   

674 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 42.2 Configure  the  voicemail  pilot  number  to  be  3800  and  ensure  that  it  is  accessible  
from  both  the  SC  phones  as  well  as  the  PSTN  phone.  
 
Now  that  the  webpage  of  the  CUE  module  is  accessible,  we  must  configure  the  basic  settings  by  which  
CUE  can  be  accessed.  From  the  CUE  Administrator  webpage,  navigate  to  Voice  Mail  !  Call  Handling  
and  set  the  “Voice  Mail  Phone  Number”  to  “3800”.  All  other  settings  can  be  left  at  the  default  value.  
Click  the  Apply  button  when  complete.  
 

 
 
Next,  we  must  configure  the  router  to  route  calls  destined  for  3800  to  the  CUE  module.  This,  of  course,  
will  be  accomplished  by  using  a  dial-peer.  The  destination-pattern  should  be  set  to  3800,  
since  that  was  the  pilot  number  that  was  defined  in  the  requirements.  Since  this  is  a  SIP-­‐based  
integration,  the  session protocol  should  be  set  to  use  SIP.  The  session target  command  
should  be  set  to  use  the  IP  address  of  the  CUE  module  at  10.10.31.254.  The  DTMF  relay  method  should  
also  be  set  to  use  SIP  Notify  using  the  dtmf-relay  command.  This  is  the  only  supported  DTMF  relay  
method  on  the  CUE  module.  Next,  the  codec  should  be  set  to  use  G.711  since  that  is  the  only  codec  
supported  for  CUE.  Lastly,  VAD  should  be  disabled  for  all  communication  with  the  CUE  module.  
 
R3  
R3(config)#dial-peer voice 3800 voip
R3(config-dial-peer)#destination-pattern 3800
R3(config-dial-peer)#session protocol sipv2
R3(config-dial-peer)#session target ipv4:10.10.31.254
R3(config-dial-peer)#dtmf-relay sip-notify
R3(config-dial-peer)#codec g711ulaw
R3(config-dial-peer)#no vad
 
Once  the  dial-peer  has  been  configured  within  R3,  place  a  test  call  to  extension  3800  from  any  SC  
phone  to  ensure  that  the  default  greeting  is  heard.  The  system  should  also  be  accessible  from  the  PSTN  
by  dialing  “894443800”  from  the  SC  PSTN  phone.  

675 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 42.3 Configure  users  for  SC  Phone  1  and  SC  Phone  2,  using  a  password  of  “cisco”  and  a  
PIN  of  “12345”.  
 
Next,  we  must  configure  users  for  both  phones  at  SC  using  the  CUE  web  administration  interface.  
Navigate  to  Configure  !  Users  and  click  the  Add  button.  This  will  launch  a  new  window  where  the  user  
can  be  configured.  Enter  the  “User  ID”,  “First  Name”,  and  “Last  Name”  of  the  user.  For  the  “Primary  
Extension”,  select  the  “Other”  radio  button  and  enter  the  extension  of  the  user.  Next,  for  the  
“Password  options”  dropdown  box,  select  “Password  specified  below”  to  enter  the  required  password  
of  “cisco”  for  the  user.  Similarly,  select  the  “PIN  specified  below”  option  from  the  “PIN  options”  
dropdown  box  to  enter  the  required  PIN  of  “12345”.  Lastly,  check  the  “Create  Mailbox”  checkbox  to  
create  a  Voice  Mail  box  for  the  user.    
 

 
 
Click  the  Add  button  to  save  the  configuration.  
 
   

676 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  next  screen  in  the  popup  window  will  configure  the  mailbox  for  the  user.  The  only  thing  that  I  
suggest  modifying  in  this  screen  is  to  change  the  “Play  Tutorial”  dropdown  box  to  “No”,  in  order  to  
bypass  end  user  setup  for  the  voicemail  box.  
 

 
 
Click  the  Add  button  when  complete.    
 
Ensure  that  the  user  for  SC  Phone  2  is  also  configured  within  CUE.  
 
   

677 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 42.4 Ensure  that  calls  are  forward  to  voicemail  when  the  user  is  busy  or  there  is  no  
answer.  
 
This  task  requires  that  the  phone  system  be  configured  to  support  the  required  functionality.  More  
specifically,  it  requires  that  the  voice register  and  ephone  DNs  can  forward  the  call  to  the  
appropriate  location  when  the  user  is  busy  or  there  is  no  answer.  Within  telephony-service,  this  
can  be  configured  with  a  template  for  the  DN,  while  voice register global  requires  
configuration  per  DN.    
 
To  configure  for  SCCP  phones  using  a  template,  use  the  ephone-dn-template  command.  Enter  
the  call-forward busy/noan commands  to  enable  the  desired  behavior.    
 
Once  the  template  has  been  configured,  it  must  be  applied  to  the  ephone-dn  by  issuing  the  
ephone-dn-template  command  under  the ephone-dn x  tag.  The  following  example  assigns  
the  settings  to  SC  Phone  1.  Remember  to  reset  the  phone  when  the  configuration  is  complete.  
 
R3  
R3(config)#ephone-dn-template 1
R3(config-ephone-dn-template)#call-forward busy 3800
R3(config-ephone-dn-template)#call-forward noan 3800 timeout 20

R3(config)#ephone-dn 1
R3(config-ephone-dn)#ephone-dn-template 1

R3(config)#ephone 1
R3(config-ephone)#reset
 
Next,  for  SIP  phones,  we  must  issue  the  call-forward  commands  (with  slightly  different  syntax)  
under  the  voice register dn x  tag.  
 
R3  
R3(config)#voice register dn 1
R3(config-register-dn)#call-forward b2bua busy 3800
R3(config-register-dn)#call-forward b2bua noan 3800 timeout 20

R3(config)#voice register global


R3(config-register-global)#create profile
R3(config-register-global)#reset
 
With  both  phones  configured,  try  making  a  test  call  to  ensure  that  the  call  is  forwarded  successfully  to  
voicemail  when  the  user  is  unavailable.  
 
 
   

678 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 42.5 Configure  the  system  so  that  the  MWI  light  turns  on  when  there  is  a  message  
waiting  in  the  mailbox  and  off  when  a  user  deletes  a  message  from  the  mailbox.  
 
The  last  step  in  the  voicemail  integration  is  to  make  sure  that  the  user  can  get  properly  notified  when  
there  is  a  message  waiting  in  his  or  her  voicemail  box.  Also,  the  message  waiting  lamp  must  turn  off  
when  the  message  has  been  deleted.  CUE  has  the  ability  to  run  three  different  MWI  notification  
mechanisms.    
 
• Subscribe  Notify—Cisco  Unified  Communications  Manager  Express  (CME)  subscribes  to  Cisco  
Unity  Express  using  SUBCRIBE/NOTIFY  SIP  messages  for  MWI  notification  for  each  of  the  
ephone-­‐dns  registered  to  receive  MWI  notifications.  Check  the  box  to  include  envelope  
information  in  the  notifications.  
• Unsolicited  Notify—Cisco  Unified  CME  is  not  required  to  send  a  subscription  request  for  each  
ephone-­‐dn  to  Cisco  Unity  Express  for  MWI  notification.  Cisco  Unity  Express  sends  NOTIFY  SIP  
messages  to  Cisco  Unified  CME  whenever  there  is  a  change  in  the  MWI  status  for  any  ephone-­‐
dn.  
• Outcalling—Used  for  legacy  Cisco  Unified  CME  configurations;  incompatible  with  SRST.  Cisco  
recommends  changing  to  the  Subscribe  -­‐  Notify  method  to  ensure  the  correct  MWI  status  is  
reflected  on  phones  after  interrupted  phone  service  is  restored.  
[Source:  CUE  Help  Pages]  
 
The  easiest  method  to  configure  in  this  case  is  Unsolicited  Notify,  so  since  the  specific  type  is  not  listed  
in  the  requirements,  it  will  be  used  as  the  MWI  mechanism.  Similar  to  CUC,  all  that  is  needed  on  R3  is  
to  configure  the  global  SIP  user  agent  to  accept  these  notifications  by  issuing  the  mwi-server  
command.  If  the  unsolicited  keyword  is  not  added  to  the  end  of  the  command,  the  MWI  type  will  
default  to  Subscribe  Notify  instead.  
 
R3  
R3(config)#sip-ua
R3(config-sip-ua)#mwi-server ipv4:10.10.31.254 unsolicited
 
In  addition,  we  must  enable  the  mwi  command  under  the  voice register dn x  section  of  the  
configuration.  This  is  not  required  for  SCCP  phones.  
 
R3  
R3(config)#voice register dn 1
R3(config-register-dn)#mwi

R3(config)#voice register global


R3(config-register-global)#create profile
R3(config-register-global)#reset  
 
At  this  point,  you  should  leave  a  test  message  on  both  phones  and  ensure  that  the  MWI  light  behaves  
appropriately.  

679 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 43: CUE Features


Task 43.1 Users  should  be  able  to  dial  3850  and  press  option  “2”  to  dial  by  name.  
 
In  order  to  configure  and  support  calls  to  “3850”,  the  first  step  that  must  be  completed  is  to  create  a  
dial-peer  on  R3  to  route  the  call  towards  CUE.  The  destination-pattern  should  be  set  to  
“3850”,  since  that  was  the  number  that  was  defined  in  the  requirements.  Since  this  is  a  SIP-­‐based  
connection,  the  session protocol  should  be  set  to  use  SIP.  The  session target  command  
should  be  set  to  use  the  IP  address  of  the  CUE  module  at  10.10.31.254.  The  DTMF  relay  method  should  
also  be  set  to  use  SIP  Notify  using  the  dtmf-relay  command.  This  is  the  only  supported  DTMF  relay  
method  on  the  CUE  module.  Next,  the  codec  should  be  set  to  use  G.711  since  that  is  the  only  codec  
supported  for  CUE.  Lastly,  VAD  should  be  disabled  for  all  communication  with  the  CUE  module.  
 
R3  
R3(config)#dial-peer voice 3850 voip
R3(config-dial-peer)#destination-pattern 3850
R3(config-dial-peer)#session protocol sipv2
R3(config-dial-peer)#session target ipv4:10.10.31.254
R3(config-dial-peer)#dtmf-relay sip-notify
R3(config-dial-peer)#codec g711ulaw
R3(config-dial-peer)#no vad
 
Once  the  dial-peer  has  been  configured  within  R3,  the  CUE  module  must  be  configured  to  accept  
calls  on  that  extension.  Within  the  CUE  Administration  webpage,  navigate  to  Voice  Mail  !  Auto  
Attendant  and  click  on  the  “autoattendant”  link  to  make  changes  to  the  existing  Auto  Attendant.    
 

 
 
On  the  “Edit  Auto  Attendant”  page,  enter  “3850”  for  the  “Call-­‐In  Number”  field.  This  will  provide  
access  to  the  Auto  Attendant,  which  contains  access  to  the  dial  by  name  directory.  
 

 
 
Place  a  test  call  to  extension  3850  from  any  SC  phone  to  ensure  that  the  greeting  for  the  Auto  
Attendant  is  heard.    
 
 

680 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 43.2 Configure  VoiceView  on  CUE  in  order  for  the  user  to  retrieve  messages  using  the  IP  
Phone  display  and  soft  keys.  This  will  prevent  UnifiedFX  PhoneView  from  working  
properly.  When  completed  with  this  lab,  be  sure  to  add  the  following  configuration  
back  to  both  voice  register  global  and  telephony-­‐service:  
url authentication
http://10.10.31.1/CCMCIP/authenticate.asp PVUSER ipexpert
 
Based  on  the  procedures  that  must  be  followed  to  accomplish  this  task,  the  VoiceView  configuration  
should  only  be  performed  on  phones  that  are  locally  accessible  to  the  student.  For  remote  phones  
connected  through  PhoneView,  this  task  should  not  be  attempted,  because  there  is  no  way  to  test  it!  
 
To  configure  VoiceView,  navigate  to  Voice  Mail  !  VoiceView  Express  !  Service  Configuration.  The  
first  thing  that  you  should  notice  is  that  the  feature  is  enabled  by  default.  The  other  thing  that  you  
should  notice  is  the  URL  that  has  been  provided  to  configure  the  service.  It  will  need  to  be  entered  into  
both  the telephony-service and voice register global  configuration  to  enable  the  
service  on  the  phone.    
 

 
 
On  the  R3  router,  under  the telephony-service  configuration,  enter  the  url services  
command  using  the  provided  URL.  Optionally,  you  can  specify  a  name  for  the  service  as  well,  such  as  
“VoiceView”.  In  addition  to  the  above  URL,  you  must  also  enter  a  URL  for  authentication,  since  users  
will  be  logging  in  to  view  and  listen  to  the  messages  on  the  phone.    
 
R3  
R3(config)#telephony-service
R3(config-telephony)#url services http://10.10.31.254/voiceview VoiceView
R3(config-telephony)#url authentication http://10.10.31.254/voiceview/authentication/authenticate.do
R3(config)#ephone 1
R3(config-ephone)#reset
 
For  SIP  phones,  enter  the  voice register global  configuration  and  specify  the  url service  
command  using  the  aforementioned  URL.  Once  again,  the  url authentication  command  is  
required  for  users  to  log  in.  
 
R3  
R3(config)#voice register global
R3(config-register-global)#url service http://10.10.31.254/voiceview
R3(config-register-global)#url authentication
http://10.10.31.254/voiceview/authentication/authenticate.do
R3(config-register-global)#create profile
R3(config-register-global)#reset

681 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  the  services  configured  in  both  phone  systems,  access  the  service  on  each  phone  in  the  following  
fashion.  
 
7965  (SC  Phone  1)  
Navigate  to  Services  !  VoiceView  and  log  in  using  “3001”  as  the  “Mailbox  ID”  and  “12345”  as  the  
“PIN”.  
 
9971  (SC  Phone  2)  
Navigate  to  Settings  !  CME  Service  URL  and  log  in  using  “3002”  as  the  “Mailbox  ID”  and  “12345”  as  
the  “PIN”  
 
Once  logged  in,  you  should  be  able  to  listen  and  interact  successfully  with  the  CUE  Voice  Mail  box  for  
that  user.  
 
   

682 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 43.3 Configure  the  CUE  Web  Inbox  for  SC  Phone  1  to  repeat  the  greeting  if  the  “1”  key  is  
pressed  and  transfer  to  3040  if  the  “2”  key  is  pressed  while  inside  the  user  mailbox.  
 
Log  into  the  user  webpage  for  SC  Phone  1  by  navigating  to  http://10.10.31.254/user  in  your  browser.  
Log  in  using  the  previously  created  credentials  for  SC  Phone  1.    
 

 
 
Navigate  to  Caller  Input  and  select  the  “Repeat  Greeting”  from  the  dropdown  box  corresponding  to  
Option  1  in  the  list.    
 

 
 
For  Key  2,  select  the  “Transfer  To”  option  from  the  dropdown  list  and  enter  the  number  “3040”  to  send  
the  caller  to  the  previously  configured  voice hunt group  (parallel).  
 

 
 
Click  the  Apply  button  when  complete.  
 
Test  the  configuration  by  calling  SC  Phone  1  and  pressing  both  options  (1  and  2)  while  inside  the  
voicemail  box.  It  should  behave  as  designed.    
 
   

683 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 43.4 Ensure  that  you  have  the  ability  to  record  a  spoken  name  for  SC  Phone  1.  
 
Within  the  CUE  User  webpage,  navigate  to  Preferences  !  Personal  and  locate  the  “Spoken  Name”  
parameter.  Make  sure  to  accept  all  of  the  security  warnings  associated  with  the  launched  Java  applet  
in  order  to  record  the  name.  
 

 
 
Press  the  Record  button  (red  circle)  to  record  the  name  using  the  microphone  on  your  computer.  Press  
the  Stop  button  (gray  square)  when  finished  with  the  recording.    
 

 
 

 
 
Click  the  Apply  button  when  complete.    
 
This  recording  should  now  be  available  when  interacting  with  the  mailbox  of  SC  Phone  1.  
 
   

684 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 43.5 Allow  SC  Phone  1  to  configure  the  CUE  system  using  only  the  telephone  on  
extension  3870.  The  user  should  be  able  to  send  broadcast  messages  using  this  
method.  
 
In  order  to  configure  and  support  calls  to  “3870”,  the  first  step  that  must  be  completed  is  to  create  a  
dial-peer  on  R3  to  route  the  call  towards  CUE.  The  destination-pattern  should  be  set  to  
“3870”,  since  that  was  the  number  that  was  defined  in  the  requirements.  Since  this  is  a  SIP-­‐based  
connection,  the  session protocol  should  be  set  to  use  SIP.  The  session target  command  
should  be  set  to  use  the  IP  address  of  the  CUE  module  at  10.10.31.254.  The  DTMF  relay  method  should  
also  be  set  to  use  SIP  Notify  using  the  dtmf-relay  command.  This  is  the  only  supported  DTMF  relay  
method  on  the  CUE  module.  Next,  the  codec  should  be  set  to  use  G.711  since  that  is  the  only  codec  
supported  for  CUE.  Lastly,  VAD  should  be  disabled  for  all  communication  with  the  CUE  module.  
 
R3  
R3(config)#dial-peer voice 3870 voip
R3(config-dial-peer)#destination-pattern 3870
R3(config-dial-peer)#session protocol sipv2
R3(config-dial-peer)#session target ipv4:10.10.31.254
R3(config-dial-peer)#dtmf-relay sip-notify
R3(config-dial-peer)#codec g711ulaw
R3(config-dial-peer)#no vad
 
Once  the  dial-peer  has  been  configured  within  R3,  the  CUE  module  must  be  configured  to  accept  
calls  on  that  extension.  Within  the  CUE  Administration  webpage,  navigate  to  Voice  Mail  !  Call  
Handling  and  enter  “3870”  as  the  “Call-­‐In  Number”  under  the  “Administration  via  Telephone  Settings”  
heading.    
 

 
 
Click  the  Apply  button  when  complete  to  save  the  configuration.  
 

685 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  allow  SC  Phone  1  permission  to  access  the  Administration  via  Telephone  system  after  
logging  in.  Navigate  to  Configure  !  Users  and  click  on  “scp1”.  Under  the  “Groups”  tab,  click  the  
Subscribe  as  Member  button.  
 

 
 
A  new  window  will  launch  at  this  point.  Click  the  Find  button  to  search  for  available  groups.  
 

 
 
Check  the  box  next  to  the  “Administrators”  Group  ID  and  click  the  Select  Rows  button  to  select  that  
group.  
 

 
 
The  user  will  now  be  assigned  as  a  member  of  the  Administrators  group.  
 

 
 
Now  call  “3870”  from  any  SC  phone  and  log  in  using  the  credentials  for  SC  Phone  1.  Explore  the  system  
and  familiarize  yourself  with  the  options.  

686 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 44: CUCM Integration


Task 44.1 Integrate  the  CUE  module  on  R3  with  the  HQ  CUCM  cluster.  HQ  Phones  should  be  
able  to  dial  1300  to  reach  the  pilot  number  on  CUE.  
 
The  Cisco  Unity  Express  (CUE)  module  not  only  has  the  ability  to  integrate  with  CUCME,  but  it  can  also  
integrate  with  CUCM,  if  so  desired—or  required!    This  integration  is  a  bit  trickier  than  others  we  have  
seen.  In  fact,  this  integration  is  most  like  UCCX  (covered  in  the  labs  ahead)  in  that  it  is  CTI-­‐based.    
 
The  first  step  that  we  must  take  in  configuring  this  integration  is  to  configure  the  CUE  module  to  
integrate  with  CUCM  rather  than  CUCME.  Navigate  to  Administration  !  Control  Panel  and  click  the  
Switch  to  CUCM  button  under  the  “Call  Agent  Integration”  heading.    
 

 
 
After  clicking,  a  new  window  will  pop  up  warning  that  this  will  reboot  the  system.  We  must  accept  it  as  
a  necessary  evil  and  click  the  OK  button.  
 

 
 
This  system  will  now  reboot  while  switching  the  Call  Agent  Integration.  
 

 
 

687 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

While  the  system  is  loading,  navigate  to  the  HQ  CUCM  cluster  to  perform  the  integration  tasks  within  
CUCM.  First,  since  this  is  a  CTI-­‐based  integration,  we  must  create  CTI  ports.  Navigate  to  Device  !  
Phone  and  click  the  Add  New  button.  For  the  “Phone  Type”  dropdown  box,  select  the  “CTI  Port”  option  
and  click  the  Next  button.  
 

 
 
First,  enter  a  descriptive  “Device  Name”  (e.g.  “CUE_VM_1_CTI”),  an  appropriate  “Device  Pool”  (e.g.  
“HQ_PHONE_DP”),  and  a  “Calling  Search  Space”  that  has  access  to  the  user  extensions,  Voice  Mail  
ports,  and  the  Voice  Mail  pilot  (e.g.  “PHONE_CSS”).    
 

 
 
Next,  under  the  “Protocol  Specific  Information”  section,  select  the  standard  “Device  Security  Profile”  
and  click  the  Save  button.  
 

 
 
Next,  we  must  add  a  line  to  the  CTI  Port  by  clicking  the  “Line  [1]  -­‐  Add  a  new  DN”  link.  Define  a  
“Directory  Number”  for  the  CTI  port.  In  this  case,  “1301”  was  used  since  the  requirements  state  that  
the  pilot  number  should  be  “1300”,  but  you  can  use  any  unused  DN  in  the  system.  Next,  an  
appropriate  “Partition”  should  be  chosen  for  the  DN  (e.g.  “VM_PT”).    
 

 
 
Click  the  Save  button  when  complete.  

688 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Create  another  CTI  Port  for  use  with  CUE  by  navigating  to  Device  !  Phone  and  clicking  the  Find  
button.  Locate  the  newly  created  CTI  Port  and  click  the  Super  Copy  button.  This  will  create  an  exact  
copy  of  the  port  so  all  that  must  be  changed  is  the  “Device  Name”  and  “Directory  Number”.  
 

 
 
When  complete,  two  ports  should  be  created  for  use  with  CUE.  
 

 
 
Next,  we  must  create  the  Voice  Mail  Pilot  number  that  will  connect  to  the  CUE  module.  In  this  type  of  
integration,  it  must  be  done  using  a  CTI  Route  Point.  Navigate  to  Device  !  CTI  Route  Point  and  click  
the  Add  New  button.  Once  again,  enter  a  descriptive  “Device  Name”  (e.g.  “CUE_VM_CTI”),  an  
appropriate  “Device  Pool”  (e.g.  “HQ_PHONE_DP”),  and  a  “Calling  Search  Space”  with  access  to  internal  
extensions  and  Voice  Mail  numbers  (e.g.  “PHONE_CSS”).    
 

 
 
Next,  click  the  “Line  [1]  -­‐  Add  a  new  DN”  link  to  add  a  DN  to  the  CTI  Route  Point.  For  the  “Directory  
Number”  field,  enter  the  required  pilot  number  of  “1300”  and  select  an  appropriate  “Partition”  from  
the  dropdown  box  (e.g.  “VM_PT”).    
 

 
 
Click  the  Save  and  Apply  Config  buttons  to  save  the  configuration.    
 
Now  that  the  CTI  Ports  and  CTI  Route  Point  has  been  created,  we  must  create  an  Application  User  with  
the  ability  to  control  the  newly  created  devices.  This  will  serve  as  the  control  mechanism  for  CUE  once  
integrated.  Navigate  to  User  Management  !  Application  User  and  click  the  Add  New  button.  Enter  a  
descriptive  “User  ID”  for  the  user  (e.g.  “cue”)  as  well  as  a  password  (e.g.  “cciecollab”).    
 

 
 

689 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  make  sure  to  move  the  CTI  Ports  and  CTI  Route  Point  to  the  “Controlled  Devices”  list  box  in  order  
for  the  application  user  to  properly  use  the  devices.  
 

 
 
Finally,  ensure  that  the  “Standard  CTI  Enabled”  permission  has  been  added  to  the  user.  
 

 
 
Click  the  Save  button  when  complete.  
 
We  must  also  configure  a  Voice  Mail  Pilot  and  Voice  Mail  Profile  so  the  Messages  key  on  the  phone  can  
be  utilized  and  calls  will  forward  properly  to  the  CUE  module.  First,  navigate  to  Advanced  Features  !  
Voice  Mail  !  Voice  Mail  Pilot  and  click  the  Add  New  button.  Ensure  that  the  “Voice  Mail  Pilot  
Number”  is  entered  as  “1300”  and  an  appropriate  “Calling  Search  Space”  is  chosen  (e.g.  
“INTERNAL_CSS”).  Click  the  Save  button  when  complete.  
 

 
 
Next,  navigate  to  Advanced  Features  !  Voice  Mail  !  Voice  Mail  Pilot  and  click  the  Add  New  button.  
Enter  a  descriptive  “Voice  Mail  Profile  Name”  (e.g.  “CUE_VMP”)  and  select  the  “Voice  Mail  Pilot”  
configured  in  the  previous  step  from  the  dropdown  menu  (e.g.  “1300/INTERNAL_CSS”).  Click  the  Save  
button  when  complete.  
 

 
 
   

690 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Finally,  we  must  assign  the  newly  created  Voice  Mail  Profile  to  the  DNs  in  the  system  by  navigating  to  
Device  !  Phone  and  clicking  on  both  HQ  phones.  From  there,  click  on  the  DN  in  question  and  select  
the  “CUE_VMP”  from  the  “Voice  Mail  Profile”  dropdown  box.  Click  the  Save  and  Apply  Config  buttons  
to  save  the  configuration.  
 

 
 
With  the  CUCM  system  now  fully  configured,  we  can  turn  our  attention  back  to  the  CUE  module.  
Navigate  to  the  CUE  Administration  web  page  and  log  in.  Navigate  to  Configure  !  CUCM  to  begin  the  
configuration.  Enter  the  IP  address  of  the  “Primary  CUCM”  server  in  the  text  box  (e.g.  “10.10.13.11”).  
You  may  also  specify  a  “Secondary  CUCM”  server  if  redundancy  is  required  (e.g.  “10.10.13.12”).  Next,  
enter  a  “Web  User  Name”  (e.g.  “admin”)  and  “Web  Password”  (e.g.  “cciecollab”)  to  log  in  to  the  CUCM  
server  using  AXL.  Finally,  specify  the  “JTAPI  User  Name/Password”  of  the  Application  User  that  was  
created  in  CUCM  (e.g.  “cue/cciecollab”).  
 

 
 
Click  the  Apply  button  when  complete.  A  window  will  then  pop  up  stating  that  the  configuration  was  
successful.    
 

 
 

691 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  “Save  the  Configuration  and  Reload  for  the  changes  to  take  effect”.  In  order  to  
accomplish  this,  navigate  to  Administration  !  Control  Panel  and  click  the  Save  Configuration  button.  
When  the  save  is  complete,  click  the  Reload  button  to  restart  the  module.    
 

 
 
Once  again  we  must  wait  for  the  module  to  reboot  before  continuing  the  configuration.  
 

 
 
When  the  reboot  of  the  module  is  complete,  navigate  to  System  !  CTI  Ports  and  click  the  Expand  to  
also  show  available  ports  on  CUCM  button.  
 

 
 
After  clicking  the  button,  a  new  window  will  launch  that  searches  for  and  displays  the  available  CTI  
ports  on  the  CUCM  server.  Select  the  two  available  ports  and  click  the  Apply  button.  
 

692 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Voice  Mail  !  Call  Handling  and  enter  “1300”  for  the  “Voice  Mail  Phone  Number”.  
This  will  set  the  pilot  number  for  the  system.  Click  the  Apply  button  when  complete.  
 

 
 
Now  that  the  CUE  module  has  been  configured,  the  CTI  Ports  and  CTI  Route  Point  should  show  a  
“Registered”  status  in  CUCM.  
 

 
 

 
 
To  test  that  the  configuration  is  working  as  expected,  press  the  Messages  key  on  either  HQ  Phone  and  
confirm  that  the  opening  greeting  is  heard  on  the  CUE  module.    
 
 
 
   

693 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 44.2 Create  users  on  CUE  for  HQ  Phone  1  and  HQ  Phone  2,  and  assure  both  can  login  
after  pressing  the  messages  key.  
 
Next,  we  must  configure  users  for  both  phones  at  HQ  using  the  CUE  web  administration  interface.  
Navigate  to  Configure  !  Users  and  click  the  Add  button.  This  will  launch  a  new  window  where  the  user  
can  be  configured.  Enter  the  “User  ID”,  “First  Name”,  and  “Last  Name”  of  the  user.  For  the  “Primary  
Extension”,  enter  the  DN  of  the  user.  Next,  for  the  “Password  options”  dropdown  box,  select  
“Password  specified  below”  to  enter  the  password  for  the  user  (e.g.  “cisco”).  Similarly,  select  the  “PIN  
specified  below”  option  from  the  “PIN  options”  dropdown  box  to  enter  a  PIN  (e.g.  “12345”).  Lastly,  
check  the  “Create  Mailbox”  checkbox  to  create  a  Voice  Mail  box  for  the  user.    
 

 
 
Click  the  Add  button  to  save  the  configuration.  The  next  screen  in  the  popup  window  will  configure  the  
mailbox  for  the  user.  The  only  thing  that  I  suggest  modifying  in  this  screen  is  to  change  the  “Play  
Tutorial”  dropdown  box  to  “No”,  in  order  to  bypass  end  user  setup  for  the  voicemail  box.  
 

 
 
Click  the  Add  button  when  complete.    
 
Ensure  that  the  user  for  HQ  Phone  2  is  also  configured  within  CUE.  You  may  now  log  into  each  mailbox  
as  well  as  send/receive  messages.  

694 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 44.3 MWI  should  be  fully  operational  for  both  users.  
 
For  this  specific  type  of  integration,  there  is  no  need  to  set  an  MWI  mechanism.  All  notifications  will  be  
sent  through  the  CTI  integration  on  CUCM.  In  other  words,  there  is  nothing  more  to  do  here!  
 
Test  the  configuration  by  leaving  Voice  Mail  messages  with  users  on  the  system  to  ensure  that  the  
MWI  light  turns  on.  Log  into  each  individual  Voice  Mail  box  and  ensure  that  the  MWI  light  turns  off  
when  the  message  is  deleted.    

695 ipexpert.com Copyright © by iPexpert. All rights reserved.


iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Ten  Labs  45  -­‐  47  
Version  1.0  

696 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 10: Configuring and Troubleshooting Quality of Service (QoS)


Lab 45: Link Efficiency Mechanisms
Task 45.1 The  speed  of  both  PVCs  between  HQ  and  SB/SC  is  768  kbps.  Configure  multilink  PPP  
with  LFI  between  HQ  and  SB.    
 
To  understand  how  LFI  using  MLP  works,  it  helps  to  understand  the  problem  it  addresses.  The  
complete  end-­‐to-­‐end  delay  target  for  real-­‐time  packets,  especially  voice  packets,  is  150  to  200  
milliseconds  (ms).  The  IP-­‐based  datagram  transmission  techniques  for  audio  transmission  do  not  
adequately  address  the  problems  posed  by  limited  bandwidth  and  the  very  stringent  telephony  delay  
bound  of  150  ms.  
 
Unacceptable  queuing  delays  for  small  real-­‐time  packets  exist  regardless  of  use  of  QoS  features  such  as  
Resource  Reservation  Protocol  (RSVP)  and  weighted  fair  queuing  (WFQ),  and  use  of  voice  compression  
algorithms  such  as  code  excited  linear  prediction  (CELP)  compression,  which  reduces  the  inherent  bit  
rate  from  64  kbps  to  as  low  as  8  kbps.  Despite  these  measures,  real-­‐time  delay  continues  to  exist  
because  per-­‐packet  header  overhead  is  too  large  and  large  maximum  transmission  units  (MTUs)  are  
needed  to  produce  acceptable  bulk  transmission  efficiency.  
 
A  large  MTU  of  1500  bytes  takes  215  ms  to  traverse  a  56-­‐kbps  line,  which  exceeds  the  delay  target.  
Therefore,  to  limit  the  delay  of  real-­‐time  packets  on  relatively  slow  bandwidth  links—links  such  as  56-­‐
kbps  Frame  Relay  or  64-­‐kbps  ISDN  B  channels—a  method  for  fragmenting  larger  packets  and  queuing  
smaller  packets  between  fragments  of  the  large  packet  is  needed.  MLP  helps  to  solve  this  problem  
through  LFI.  
 
MLP  provides  a  method  of  splitting,  recombining,  and  sequencing  datagrams  across  multiple  logical  
data  links.  The  LFI  scheme  is  relatively  simple:  Large  datagrams  are  multilink  encapsulated  and  
fragmented  to  packets  of  a  size  small  enough  to  satisfy  the  delay  requirements  of  the  delay-­‐sensitive  
traffic;  small  delay-­‐sensitive  packets  are  not  multilink  encapsulated,  but  are  interleaved  between  
fragments  of  the  large  datagram.  
 
MLP  allows  the  fragmented  packets  to  be  sent  at  the  same  time  over  multiple  point-­‐to-­‐point  links  to  
the  same  remote  address.  The  multiple  links  come  up  in  response  to  a  dialer  load  threshold  that  you  
define.  The  load  can  be  calculated  on  inbound  traffic,  outbound  traffic,  or  on  either,  as  needed  for  the  
traffic  between  the  specific  sites.  MLP  provides  bandwidth  on  demand  and  reduces  transmission  
latency  across  WAN  links.  
[Source:  
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcflem.html#wp10
00888]  
 
In  configuring  Multilink  PPP  (MLP),  we  are  basically  creating  a  virtual  interface  that  can  be  utilized  by  
multiple  physical  interfaces  on  the  router  if  so  desired.  On  this  virtual  interface,  we  will  configure  the  
Link  Fragmentation  and  Interleaving  (LFI)  “link  efficiency  mechanism”.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     697  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  begin  the  configuration,  connect  to  R1  (HQ)  and  enter  the  configuration  for  the  Serial  sub-­‐interface  
that  points  towards  R2  (SB).  From  there,  enter  the  frame-relay interface-dlci <DLCI>  
command  to  edit  the  existing  Data  Link  Connection  Identifier  (DLCI)  that  allows  communication  
between  the  two  routers.  Attach  the  ppp Virtual-Template <Identifier>  tag  to  the  end  of  
the  frame-relay  command  to  define  the  type  and  number  of  the  new  PPP  virtual  interface.  Once  
this  command  is  entered,  the  Virtual-­‐Access  1  interface  becomes  active,  which  provides  status  on  the  
state  of  the  virtual  interface.  
 
R1  
R1(config)#interface Serial 0/1/0.102
R1(config-subif)#frame-relay interface-dlci 102 ppp Virtual-Template 1

Jan 5 22:29:23.099: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up  


 
You  will  notice  at  this  point  that  OSPF  neighbor  relationships  and  other  persistent  connections  made  
across  the  WAN  to  SB  will  drop.  This  is  because  the  router  is  now  expecting  all  Layer  2  and  3  traffic  to  
traverse  the  newly  created  Virtual  Template  1  interface.  With  this  in  mind,  we  must  now  move  the  IP  
address  that  is  assigned  to  the  Serial  0/1/0.102  sub-­‐interface  to  the  Virtual-­‐Template  1  interface.  
 
R1  
R1(config)#interface Serial 0/1/0.102
R1(config-subif)#no ip address

R1(config)#interface Virtual-Template 1
R1(config-if)#ip address 10.10.121.1 255.255.255.252
 
Next,  we  must  perform  the  same  configuration  on  R2  to  bring  the  WAN  connection  back  up.  
 
R2  
R2(config)#interface Serial 0/1/0.201
R2(config-subif)#frame-relay interface-dlci 201 ppp Virtual-Template 1

.Jan 5 22:38:21.150: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up


.Jan 5 22:38:22.002: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state
to up
R2(config-fr-dlci)#exit
R2(config-subif)#no ip address

R2(config)#interface Virtual-Template 1
R2(config-if)#ip address 10.10.121.2 255.255.255.252

.Jan 5 22:38:47.858: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.1.1 on Virtual-Access1 from LOADING to


FULL, Loading Done  
 
The  virtual  interface  now  shows  as  “up”  between  the  two  routers  and  pings  can  be  successfully  
exchanged.  
 
R1  
R1#sh ip int br | i Vir
Virtual-Access1 10.10.121.1 YES manual up up
Virtual-Access2 unassigned YES unset down down
Virtual-Template1 10.10.121.1 YES manual down down

R1#ping 10.10.121.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.121.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     698  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
R2#sh ip int br | in Vir
Virtual-Access1 10.10.121.2 YES manual up up
Virtual-Access2 unassigned YES unset down down
Virtual-Template1 10.10.121.2 YES manual down down

R2#ping 10.10.121.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.121.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
 
Next,  we  must  configure  the  interface  to  perform  LFI  to  meet  the  requirements  of  the  task.  First,  we  
should  define  the  bandwidth  to  be  used  by  the  interface.  In  this  case,  768  kbps  should  be  
configured,  based  on  the  task  requirements.  Next,  we  must  enable  the  interface  for  MLP  by  entering  
the  ppp multilink  command.  After  enabling  MLP  on  the  interface,  we  must  enter  the  ppp
multilink interleave  command  in  order  to  enable  packet  interleaving  for  all  traffic  flows  
exiting  the  interface.  Finally,  we  need  to  issue  the  ppp multilink fragment delay <time>  
command  in  order  to  create  fragmented  packets  after  a  twenty  millisecond  delay.  There  was  no  value  
defined  in  the  question  here,  so  any  value  would  work,  but  “20”  was  chosen  since  voice  packets  are  
sampled  every  20  ms  by  default.  
 
R1  
R1(config)#interface Virtual-Template1
R1(config-if)#bandwidth 768
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink interleave
R1(config-if)#ppp multilink fragment delay 20
 
Once  again,  we  must  perform  the  same  steps  on  the  R2  router  to  complete  the  configuration.  
 
R2  
R2(config)#interface Virtual-Template1
R2(config-if)#bandwidth 768
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink interleave
R2(config-if)#ppp multilink fragment delay 20  
 
Enter  the  show ppp multilink  command  to  verify  the  status  of  the  configuration.  
 
R1  
R1#sh ppp multilink

Virtual-Access3
Bundle name: R2
Remote Endpoint Discriminator: [1] R2
Local Endpoint Discriminator: [1] R1
Bundle up for 00:22:56, total bandwidth 768, load 1/255
Receive buffer limit 12192 bytes, frag timeout 1000 ms
Interleaving disabled
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x27CC received sequence, 0x1631 sent sequence
Member links: 1 (max 255, min not set)
Vi1, since 00:22:56, 1920 weight, 1496 frag size
No inactive multilink interfaces

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     699  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R2  
R2#show ppp multilink

Virtual-Access3
Bundle name: R1
Remote Endpoint Discriminator: [1] R1
Local Endpoint Discriminator: [1] R2
Bundle up for 00:10:52, total bandwidth 768, load 6/255
Receive buffer limit 12192 bytes, frag timeout 1000 ms
Interleaving disabled
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0xA7B received sequence, 0x12A2 sent sequence
Member links: 1 (max 255, min not set)
Vi1, since 00:10:52, 1920 weight, 1496 frag size
No inactive multilink interfaces
 
In  the  above  output,  we  can  see  that  there  is  a  problem.  Interleaving  does  not  appear  to  be  
functioning,  even  though  it  has  been  configured.  This  is  because  we  have  not  configured  some  type  of  
outbound  queuing  policy  on  the  Virtual-­‐Template  1  interface.  Without  a  queuing  policy  configured,  
interleaving  will  not  be  enabled.  In  this  case,  let’s  just  create  a  basic  fair-­‐queuing  policy  in  order  to  
activate  the  feature.  From  global  configuration  mode,  enter  the  policy-map  command  to  create  a  
new  Modular  QoS  Command  Line  Interface  (MQC)  policy.  Enter  the  class-default  command  to  
configure  the  default  queue.  Next,  enter  the  fair-queue  command  to  enable  fair  queuing  for  this  
class.  Finally,  assign  the  policy-map  to  the  Virtual-­‐Template  1  interface  in  the  outbound  direction  
by  entering  the  service-policy output  command.  
 
R1  
R1(config)#policy-map INTERLEAVE
R1(config-pmap)#class class-default
R1(config-pmap-c)#fair-queue

R1(config)#interface Virtual-Template 1
R1(config-if)#service-policy output INTERLEAVE
 
We  must  also  perform  the  same  task  on  R2.  
 
R2  
R2(config)#policy-map INTERLEAVE
R2(config-pmap)#class class-default
R2(config-pmap-c)#fair-queue

R2(config)#interface Virtual-Template 1
R2(config-if)#service-policy output INTERLEAVE  
 
When  the  configuration  is  complete,  enter  the  show ppp multilink  command  to  verify  the  
status  of  the  configuration.  
 
R1  
R1#sh ppp multilink
...
Interleaving enabled
...

R2  
R2#sh ppp multilink
...
Interleaving enabled
...

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     700  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 45.2 Classify  traffic  as  voice  (EF),  video  (AF41),  or  signaling  (CS3),  and  provide  queuing  
using  MQC.  The  policy  should  prioritize  30%  of  the  link  for  voice  traffic.  Video  should  
use  30%  and  signaling  should  use  10%.  All  remaining  link  bandwidth  should  use  
WFQ.  Ensure  that  cRTP  is  used  between  HQ  and  SB.    
 
This  task  requires  that  we  configure  QoS  policies  on  R1  and  R2  to  prioritize  voice  traffic  and  queue  both  
signaling  and  video  traffic  according  to  Differentiated  Services  Code  Point  (DSCP)  values  assigned  to  the  
IP  packets.  In  this  case,  voice  traffic  should  be  classified  using  the  expedited  forwarding  (EF)  class,  
video  traffic  should  use  the  assured  forwarding  (AF)  class  (AF41),  and  signaling  traffic  should  use  the  
class  selector  (CS)  class  (CS3).  Once  classified,  a  policy  should  be  created  to  apply  queuing  policies  to  
each  class.  Finally,  it  should  be  assigned  to  the  WAN  interface  in  the  outbound  direction.  
 
To  begin  the  configuration,  enter  the  class-map  command  to  classify  each  of  the  three  different  
types  of  traffic.  This  should  be  performed  on  both  R1  and  R2.  
 
R1  
R1(config)#class-map VOICE
R1(config-cmap)#match dscp ef

R1(config)#class-map SIGNALING
R1(config-cmap)#match dscp cs3

R1(config)#class-map VIDEO
R1(config-cmap)#match dscp af41
 
R2  
R2(config)#class-map VOICE
R2(config-cmap)#match dscp ef

R2(config)#class-map SIGNALING
R2(config-cmap)#match dscp cs3

R2(config)#class-map VIDEO
R2(config-cmap)# match dscp af41  
 
With  each  class-map  defined  on  both  routers,  the  next  step  is  to  create  a  policy-map  utilizing  
the  created  class-maps  on  each  router.    
 
Under  the  class VOICE  heading,  the  priority  command  should  be  utilized  to  create  a  Low  
Latency  Queue  (LLQ)  for  all  traffic  in  the  class.  This  means  that  whenever  voice  traffic  enters  the  policy,  
it  is  prioritized  over  any  other  existing  traffic.  The  value  defined  in  the  priority  command  also  
performs  policing  to  ensure  that  traffic  does  not  exceed  the  configured  priority.  The  percent  
keyword  should  also  be  used  in  order  to  meet  the  requirements  of  the  question.  This  allows  the  policy  
to  use  a  percentage  of  the  defined  bandwidth  on  the  interface  to  which  the  policy  is  applied.  The  
eventual  value  should  be  230  kbps  since  that  is  30%  of  768  kbps.  Next,  the  RTP  header  compression  
function  should  be  enabled  using  the  compress header ip rtp  command  in  order  to  meet  the  
requirements  of  the  question.    
 
R1  
R1(config)#policy-map MLP
R1(config-pmap)#class VOICE
R1(config-pmap-c)#priority percent 30
R1(config-pmap-c)#compress header ip rtp

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     701  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Under  the  class SIGNALING  heading,  the  bandwidth percent  command  should  be  used  to  
reserve  10%  of  the  interface  bandwidth  to  signaling  traffic  passing  through  the  policy.  Remember,  we  
have  not  applied  the  policy  to  an  interface  yet,  so  this  value  has  yet  to  be  determined  (will  be  76  kbps).    
 
R1  
R1(config-pmap-c)#class SIGNALING
R1(config-pmap-c)#bandwidth percent 10

Under  the  class VIDEO  heading,  the  bandwidth percent  command  should  be  used  to  reserve  
30%  of  the  interface  bandwidth  to  video  traffic  passing  through  the  policy  (will  be  230  kbps).    

R1(config-pmap-c)#class VIDEO
R1(config-pmap-c)#bandwidth percent 30

Lastly,  under  the  class class-default heading,  the  fair-queue  command  should  be  used  
to  provide  fair  queuing  services  for  all  other  types  of  traffic  passing  through  the  policy.    

R1(config-pmap-c)#class class-default
R1(config-pmap-c)#fair-queue  
 
Remember  to  perform  the  same  configurations  on  R2  to  enable  the  policy.  
 
R2  
R2(config)#policy-map MLP
R2(config-pmap)#class VOICE
R2(config-pmap-c)#priority percent 30
R2(config-pmap-c)#compress header ip rtp

R2(config-pmap)#class SIGNALING
R2(config-pmap-c)#bandwidth percent 10

R2(config-pmap)#class VIDEO
R2(config-pmap-c)#bandwidth percent 30

R2(config-pmap)#class class-default
R2(config-pmap-c)#fair-queue
 
The  last  step  in  the  process  is  to  apply  the  policy  to  an  interface  on  each  router.  In  this  case,  since  the  
policy  offers  queuing  services  for  traffic  between  HQ  and  SB,  we  must  apply  it  to  the  Virtual-­‐Template  
1  interface  (MLP)  on  R1  and  R2.  Issue  the  service-policy output  command  to  configure.  
Remember  to  remove  the  existing  service-policy  command  from  the  policy-map  that  was  
previously  applied.  
 
R1  
R1(config)#interface Virtual-Template 1
R1(config-if)#no service-policy output INTERLEAVE
R1(config-if)#service-policy output MLP
 
R2  
R2(config)#interface Virtual-Template 1
R2(config-if)#no service-policy output INTERLEAVE
R2(config-if)#service-policy output MLP  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     702  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  policy  has  been  configured  and  applied  to  the  proper  interface,  issue  the  show
policy-map interface  command  to  view  statistics  about  the  policy  and  ensure  that  it  is  
functioning  properly.  Make  a  couple  of  calls  between  sites  to  ensure  that  the  counters  increment  for  
each  class.  
 
R1  
R1#sh policy-map interface
Virtual-Access3

Service-policy output: MLP

queue stats for all priority classes:


Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 1682/57869

Class-map: VOICE (match-all)


1682 packets, 117514 bytes
5 minute offered rate 4000 bps, drop rate 0000 bps
Match: dscp ef (46)
Priority: 30% (230 kbps), burst bytes 5750, b/w exceed drops: 0

compress:
header ip rtp
UDP/RTP (compression on, IPHC, RTP)
Sent: 2053 total, 2030 compressed,
72879 bytes saved, 63531 bytes sent
2.14 efficiency improvement factor
99% hit ratio, five minute miss rate 0 misses/sec, 0 max
rate 0 bps

Class-map: SIGNALING (match-all)


0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: dscp cs3 (24)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 10% (76 kbps)

Class-map: VIDEO (match-all)


0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: dscp af41 (34)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 30% (230 kbps)

Class-map: class-default (match-any)


1007 packets, 108257 bytes
5 minute offered rate 4000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
(pkts output/bytes output) 1007/106017
Fair-queue: per-flow queue limit 16 packets
Virtual-Template1

Service-policy output: MLP

Service policy content is displayed for cloned interfaces only such as vaccess and sessions

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     703  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 45.3 Configure  FRF.12  on  the  link  between  HQ  and  SC  such  that  the  serialization  delay  is  
appropriate  for  the  768  kbps  link  speed.    
 
FRF.12  is  an  implementation  agreement  that  supports  voice  and  other  real-­‐time  delay-­‐sensitive  data  
on  low-­‐speed  links.  The  standard  accommodates  variations  in  frame  sizes  in  a  manner  that  allows  a  
mixture  of  real-­‐time  and  non-­‐real-­‐time  data.  
 
FRF.12  stipulates  that,  when  fragmentation  is  on  for  a  data-­‐link  connection  identifier  (DLCI),  there  is  
fragmentation  of  only  data  frames  that  exceed  the  specified  fragmentation  size.  This  arrangement  
allows  small  VoIP  packets,  which  are  not  fragmented  due  to  the  size,  to  be  interleaved  as  frames  
between  large  data  packets  that  have  been  fragmented  into  smaller  frames.  This  improves  the  
serialization  delay  for  packets  that  leave  the  router.  As  a  result,  voice  packets  do  not  wait  for  the  
process  of  large  data  packets.  
 
In  a  VoIP  implementation,  Frame  Relay  (Layer  2  protocol)  cannot  distinguish  between  VoIP  and  data  
frames.  FRF.12  fragments  all  packets  that  are  larger  than  the  fragment  size  setting.  Configure  the  
fragmentation  size  on  the  DLCI  such  that  voice  frames  are  not  fragmented.  You  can  configure  the  
fragment  size  under  the  Cisco  IOS®  Software  map-­‐class  frame-­‐relay  command  with  the  issue  of  the  
frame-­‐relay  fragment  fragment_size  command.  The  fragment  size  is  in  bytes,  and  the  default  is  53.  
[Source:  
 http://www.cisco.com/c/en/us/support/docs/voice/voice-­‐over-­‐frame-­‐relay-­‐vofr/9232-­‐fr-­‐frag.html]  
 
Turn  on  fragmentation  for  low  speed  links  (less  than  768  kbps).  Set  the  fragment  size  so  that  voice  
packets  are  not  fragmented  and  does  not  experience  a  serialization  delay  greater  than  20  ms.  Set  the  
fragmentation  size  based  on  the  lowest  port  speed  between  the  routers.  For  example,  if  there  is  a  hub  
and  spoke  Frame  Relay  topology  where  the  hub  has  a  T1  speed  and  the  remote  routers  have  64  K  port  
speeds,  the  fragmentation  size  needs  to  be  set  for  the  64  K  speed  on  both  routers.  Any  other  PVCs  that  
share  the  same  physical  interface  need  to  configure  the  fragmentation  to  the  size  used  by  the  voice  
PVC.  Use  this  chart  to  determine  the  fragmentation  size  values.  
 
Lowest  Link  Speed  in  Path     Recommended  Fragmentation  Size  
(for  10  ms  Serialization)  
56  Kbps     70  bytes  
64  Kbps     80  bytes  
128  Kbps     160  bytes  
256  Kbps     320  bytes  
512  Kbps     640  bytes  
768  Kbps     1000  bytes  
1536  Kbps     1600  bytes  
 
[Source:  
 http://www.cisco.com/c/en/us/support/docs/voice/voice-­‐quality/12156-­‐voip-­‐ov-­‐fr-­‐qos.html#topic9]  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     704  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  this  task,  we  are  going  to  enable  FRF.12  on  the  DLCI  between  R1  (HQ)  and  R3  (SC)  in  order  to  
fragment  packets  larger  than  1000  bytes  (per  the  above  table).  In  order  to  accomplish  this,  we  must  
create  a  map-class.  A  map-class  is  the  configuration  method  that  is  used  to  assign  QoS  policies  
and  parameters  to  a  Frame-­‐Relay  DLCI.  Under  the  map-class  heading,  enter  the  frame-relay
fragment  command  to  define  the  fragment  size.  
 
R1  
R1(config)#map-class frame-relay FR
R1(config-map-class)#frame-relay fragment 1000
 
R3  
R3(config)#map-class frame-relay FR
R3(config-map-class)#frame-relay fragment 1000
 
After  the  map-class  is  defined,  it  must  be  assigned  to  the  DLCI  between  HQ  and  SC  on  each  router.    
 
R1  
R1(config)#interface Serial 0/1/0.103
R1(config-subif)#frame-relay interface-dlci 103
R1(config-fr-dlci)#class FR
 
R3  
R3(config)#interface Serial0/1/0.301 point-to-point
R3(config-subif)#frame-relay interface-dlci 301
R3(config-fr-dlci)#class FR      
 
Enter  the  show frame-relay fragment  command  to  verify  the  status  of  the  configuration.  
 
R1  
R1#show frame-relay fragment
interface dlci frag-type size in-frag out-frag dropped-frag

R3  
R3#show frame-relay fragment
interface dlci frag-type size in-frag out-frag dropped-frag
 
In  the  above  output,  we  can  see  that  there  is  a  problem.  Fragmentation  does  not  appear  to  be  
functioning,  even  though  it  has  been  configured.  This  is  because  we  have  not  configured  some  type  of  
outbound  shaping  policy  on  the  map-class.  Without  a  shaping  policy  configured,  FRF.12  will  not  be  
enabled.  In  this  case,  let’s  just  create  a  basic  policy  in  order  to  activate  the  feature.  From  global  
configuration  mode,  enter  the  policy-map  command  to  create  a  new  MQC  policy.  Enter  the  
class-default  command  to  configure  the  default  class.  Next,  enter  the  shape average  
command  to  enable  shaping  for  the  specified  bandwidth  value.  This  will  buffer  traffic  that  exceeds  the  
configured  value  in  an  effort  to  provide  smooth  traffic  patterns  as  opposed  to  harsh  spikes  in  traffic.  
Finally,  assign  the  policy-map  to  the  map-class  in  the  outbound  direction  by  entering  the  
service-policy output  command.  
 
R1  
R1(config)#policy-map FRAGMENT
R1(config-pmap)#class class-default
R1(config-pmap-c)#shape average 768k

R1(config)#map-class frame-relay FR
R1(config-map-class)#service-policy output FRAGMENT

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     705  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

We  must  also  perform  the  same  task  on  R3.  


 
R3  
R3(config)#policy-map FRAGMENT
R3(config-pmap)#class class-default
R3(config-pmap-c)#shape average 768k

R3(config)#map-class frame-relay FR
R3(config-map-class)#service-policy output FRAGMENT  
 
When  the  configuration  is  complete,  enter  the  show frame-relay fragment  command  again  to  
verify  the  status  of  the  configuration.  
 
R1  
R1#show frame-relay fragment
interface dlci frag-type size in-frag out-frag dropped-frag
Se0/1/0.103 103 end-to-end 1000 0 0 0

R3  
R3#show frame-relay fragment
interface dlci frag-type size in-frag out-frag dropped-frag
Se0/1/0.301 301 end-to-end 1000 0 0 0
 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     706  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 45.4 You  must  designate  to  the  Priority  Queue  enough  bandwidth  to  carry  10  calls  at  
G.729  between  HQ  and  SC.  You  are  not  permitted  to  use  the  keyword  “percent”  
when  assigning  the  bandwidth  guarantee  within  the  Priority  Queue.  
 
This  task  is  asking  us  to  configure  a  Low  Latency  Queue  (LLQ)  to  support  10  voice  calls  using  G.729  
between  the  HQ  and  SC  site.  Since  we  are  not  permitted  to  use  the  percentage  commands,  we  must  
calculate  the  bandwidth  by  using  a  couple  different  formulas.  A  great  place  to  get  this  information  is  at  
the  following  link:    http://www.cisco.com/c/en/us/support/docs/voice/voice-­‐quality/7934-­‐bwidth-­‐
consume.html.    
 
First,  we  must  calculate  the  Total  Packet  Size  (TPS)  by  adding  the  IP,  UDP,  and  RTP  headers  (40  bytes)  
to  the  Layer  2  header  (7  bytes  for  MLP)  and  the  Payload  Size  (20  bytes  for  G.729).  
 
TPS  =  IP/UDP/RTP  +  L2  +  Payload  
TPS  =  40  +  7  +  20  
TPS  =  67  bytes  
 
Next,  we  must  calculate  the  Packets  Per  Second  (PPS)  value  by  dividing  the  Codec  Bit  Rate  (8000  bps  
for  G.729)  by  the  Payload  Size  (160  bits  for  G.729).  
 
PPS  =  Codec  Bit  Rate/Payload  Size  
PPS  =  8000/160  
PPS  =  50  packets  per  second  
 
Finally,  to  get  the  per  call  bandwidth  value,  we  can  multiply  the  TPS  by  the  PPS  value  and  multiply  
again  by  eight  in  order  to  convert  the  final  value  to  bits  per  second.  
 
BW  =  TPS  x  PPS  x  8  
BW  =  67  x  50  x  8  
BW  =  26800  bits  per  second  
 
This  results  in  a  per  call  bandwidth  value  of  26.8  kbps.  When  multiplied  by  the  required  number  of  calls  
(10),  we  can  see  that  the  total  bandwidth  dedicated  to  the  voice  LLQ  should  be  268  kbps.  
 
Now  that  we  have  the  value,  all  that  is  left  is  to  configure  the  policy-map.  On  R3,  class-maps  
have  not  yet  been  created,  so  that  should  be  done  as  well.  
 
R1  
R1(config)#policy-map LLQ
R1(config-pmap)#class VOICE
R1(config-pmap-c)#priority 268

   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     707  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3  
R3(config)#class-map VIDEO
R3(config-cmap)#match dscp af41

R3(config)#class-map match-all VOICE


R3(config-cmap)#match dscp ef

R3(config)#class-map SIGNALING
R3(config-cmap)#match dscp cs3

R3(config)#policy-map LLQ
R3(config-pmap)#class VOICE
R3(config-pmap-c)#priority 268
 
Next,  we  must  assign  the  LLQ  policy  to  the  interface  in  some  fashion.  In  the  previous  task,  the  
“FRAGMENT”  policy  was  created  and  assigned  to  the  map-class,  which  was  then  assigned  to  the  
frame-relay interface-DLCI.  With  those  elements  configured,  we  can  simply  assign  the  
“LLQ”  policy  as  a  nested  policy  under  the  existing  “FRAGMENT”  policy.  The  hierarchy  appears  as  
follows:  
 
• Serial  0/1/0  
o Serial  0/1/0.103  
" Frame-­‐Relay  Interface-­‐DLCI  103  
• Map-­‐Class  FR  
o Policy-­‐Map  FRAGMENT  
" Policy-­‐Map  LLQ  
 
R1  
R1(config)#policy-map FRAGMENT
R1(config-pmap)#class class-default
R1(config-pmap-c)#service-policy LLQ
 
R3  
R3(config)#policy-map FRAGMENT
R3(config-pmap)#class class-default
R3(config-pmap-c)#service-policy LLQ
 
With  the  policy  created  and  assigned,  run  the  show policy-map interface  command  to  view  
the  details.  Make  a  few  calls  and  take  note  of  the  statistics.  
 
R1  
R1#sh policy-map interface Serial0/1/0.103
Serial0/1/0.103: DLCI 103 -

Service-policy output: FRAGMENT

Class-map: class-default (match-any)


6267 packets, 571256 bytes
5 minute offered rate 3000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 6267/571256
shape (average) cir 768000, bc 3072, be 3072
target shape rate 768000

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     708  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Service-policy : LLQ

queue stats for all priority classes:


Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 1475/94400

Class-map: VOICE (match-all)


1475 packets, 94400 bytes
5 minute offered rate 3000 bps, drop rate 0000 bps
Match: dscp ef (46)
Priority: 268 kbps, burst bytes 6700, b/w exceed drops: 0

Class-map: class-default (match-any)


100 packets, 11996 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

queue limit 64 packets


(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 100/11996
 
R3  
R3#sh policy-map interface
Serial0/1/0.301: DLCI 301 -

Service-policy output: FRAGMENT

Class-map: class-default (match-any)


7837 packets, 665782 bytes
5 minute offered rate 7000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 7837/665782
shape (average) cir 768000, bc 3072, be 3072
target shape rate 768000

Service-policy : LLQ

queue stats for all priority classes:


Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 3081/198304

Class-map: VOICE (match-all)


3081 packets, 198304 bytes
5 minute offered rate 7000 bps, drop rate 0000 bps
Match: dscp ef (46)
Priority: 268 kbps, burst bytes 6700, b/w exceed drops: 0

Class-map: class-default (match-any)


127 packets, 14366 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

queue limit 64 packets


(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 127/14366
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     709  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 45.5 You  must  designate  100  kbps  and  320  kbps  for  signaling  and  video,  respectively.  You  
must  also  assign  10%  of  the  remaining  bandwidth  to  the  best  effort  queue.  You  are  
not  allowed  to  use  the  keyword  “percent”  or  “remaining  percent”  when  assigning  
the  bandwidth  guarantee.  
 
This  task  is  simply  adding  more  classes  to  the  existing  LLQ  policy  on  both  R1  and  R3.  In  this  case,  we  
must  allocate  100  kbps  for  signaling  and  320  kbps  for  video.  Also,  in  the  default  class,  we  must  specify  
a  value  equal  to  10%  of  the  remaining  bandwidth  without  using  the  percent  keyword.  
 
Since  classes  have  already  been  defined  on  both  routers,  all  that  is  left  is  to  modify  the  existing  “LLQ”  
policy  to  include  the  required  bandwidth  values  of  the  additional  classes.  Of  course  we  should  enter  
“100”  and  “320”  for  the  “SIGNALING”  and  “VIDEO”  classes,  but  the  bandwidth  value  that  should  be  
configured  under  the  default  class  has  yet  to  be  determined.  The  total  bandwidth  available  is  768  kbps,  
according  to  the  configuration  in  the  “FRAGMENT”  policy.  The  total  bandwidth  currently  being  used  by  
the  policy  is  688  kbps  (268  +  100  +  320).  That  leaves  a  total  remaining  bandwidth  value  of  80  kbps.  
According  to  the  requirements,  10%  of  that  remaining  bandwidth  should  be  used  in  the  “best  effort”  or  
default  class.  This  means  that  the  bandwidth  value  configured  in  the  default  class  should  be  8  kbps.  
 
R1  
R1(config)#policy-map LLQ
R1(config-pmap)#class SIGNALING
R1(config-pmap-c)#bandwidth 100

R1(config-pmap)#class VIDEO
R1(config-pmap-c)#bandwidth 320

R1(config-pmap)#class class-default
R1(config-pmap-c)#bandwidth 8
 
R3  
R3(config)#policy-map LLQ
R3(config-pmap)#class SIGNALING
R3(config-pmap-c)#bandwidth 100

R3(config-pmap)#class VIDEO
R3(config-pmap-c)#bandwidth 320

R3(config-pmap)#class class-default
R3(config-pmap-c)#bandwidth 8

With  the  policy-maps  now  updated,  run  the  show policy-map interface  command  to  
view  the  real-­‐time  details  of  the  policy.  Make  a  few  test  calls  and  observe  the  counters.  
 
R3  
R3#sh policy-map int
Serial0/1/0.301: DLCI 301 -

Service-policy output: FRAGMENT

Class-map: class-default (match-any)


122671 packets, 70576036 bytes
5 minute offered rate 731000 bps, drop rate 216000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 64/33051/0

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     710  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

(pkts output/bytes output) 89620/51030471


shape (average) cir 768000, bc 3072, be 3072
target shape rate 768000

Service-policy : LLQ

queue stats for all priority classes:


Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 15816/1018135

Class-map: VOICE (match-all)


15816 packets, 1018135 bytes
5 minute offered rate 12000 bps, drop rate 0000 bps
Match: dscp ef (46)
Priority: 268 kbps, burst bytes 6700, b/w exceed drops: 0

Class-map: SIGNALING (match-all)


34 packets, 22071 bytes
5 minute offered rate 1000 bps, drop rate 0000 bps
Match: dscp cs3 (24)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 34/22071
bandwidth 100 kbps

Class-map: VIDEO (match-all)


101313 packets, 68950341 bytes
5 minute offered rate 717000 bps, drop rate 209000 bps
Match: dscp af41 (34)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 62/33051/0
(pkts output/bytes output) 68262/49404776
bandwidth 320 kbps

Class-map: class-default (match-any)


879 packets, 132377 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 879/132377
bandwidth 8 kbps  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     711  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 46: Classification and Marking


Task 46.1 On  all  switches  in  the  network,  ensure  that  COS  values  3,  4,  and  5  are  mapped  to  
DSCP  CS3,  DSCP  AF41,  and  DSCP  EF,  respectively.  
 
The  first  step  in  applying  any  QoS  policy  is  to  properly  classify  the  type  of  traffic  that  is  traversing  the  
network  and  mark  it  to  a  specific  DSCP  value.  Once  marked,  that  value  can  be  used  throughout  the  
enterprise  to  determine  the  type  of  treatment  that  it  should  receive.  For  example,  a  packet  marked  
with  AF31  will  generally  have  a  higher  priority  that  a  packet  marked  as  AF11  and  will  be  treated  
accordingly.  Remember  though,  the  treatment  of  packets  marked  with  a  specific  value  is  not  
necessarily  guaranteed,  since  treatment  can  only  be  recommended  and  not  enforced.  Of  course,  the  
requirements  of  the  question  will  play  a  big  role  in  determining  how  packets  are  treated!  
 
In  Cisco  switches  (both  the  3750  and  EHWIC  models),  it  is  important  to  use  the  DSCP  values  when  
present,  but  it  is  also  important  to  accept  COS  values  (Layer  2  QoS)  and  convert  them  to  the  proper  
DSCP  value.  This  task  requires  that  we  assign  any  COS  value  of  3,  4,  or  5  to  DSCP  values  of  CS3,  AF41,  
and  EF.  To  do  this,  we  must  understand  not  only  the  command  to  do  so,  but  also  the  calculations  to  
arrive  at  the  proper  DSCP  value.  For  example,  each  of  the  aforementioned  DSCP  values  is  known  as  
per-­‐hop  behaviors  (PHB),  which  exist  in  order  to  organize  the  values  more  efficiently.  Each  PHB  value  
has  a  corresponding  decimal  value  that  can  also  be  used  when  referring  to  it.  For  example,  the  decimal  
value  of  AF41  is  34.  How  do  we  arrive  at  that,  you  ask?    First  of  all,  think  of  each  number  in  the  PHB  as  
a  separate  value.  We  must  take  those  separate  values  and  break  them  down  to  their  binary  equivalent.    
 
In  the  chart  below,  we  have  an  8-­‐bit  binary  number  describing  the  DSCP  value  along  with  descriptive  
headers  that  have  organized  the  numbers  in  a  specific  fashion.  From  right  to  left,  there  are  two  
“Unused”  bits,  which  are  not  involved  in  the  calculation  at  all.  Next  is  the  “Always  0”  bit,  which  ensures  
that  the  decimal  DSCP  value  is  never  an  “odd”  number.  That  leaves  five  remaining  bits  with  which  to  
describe  the  value.  As  stated  above,  we  must  split  the  number  into  two  separate  values  for  the  time  
being.  The  number  4  in  binary  is  expressed  below  using  3-­‐bits  and  is  written  as  “100”.  The  number  1  in  
binary  is  expressed  below  using  2-­‐bits  and  is  written  as  “01”.  When  combining  the  two  values,  the  
resulting  string  is  “10001”.  When  adding  the  “Always  0”  value  as  the  first  bit  (rightmost)  in  the  binary  
string,  the  resulting  string  becomes  “100010”,  which  converts  to  a  decimal  value  of  34.    
 
AF   4   1   Always  “0”   Unused  
Binary  
1   0   0   0   1   X   Unused   Unused  
Value  
Individual  
4   2   1   2   1   X   Unused   Unused  
Value  
Total  
32   16   8   4   2   1   Unused   Unused  
Value  
Actual  
32   0   0   0   2   0   Unused   Unused  
Value  
 

712 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Obviously,  that  was  the  “roundabout”  way  to  arrive  at  the  answer.  It’s  good  to  know  where  the  
numbers  come  from!    There  is  a  much  quicker  way  to  calculate  the  correct  value,  however.  The  
formula  is  8x  +  2y  where  “x”  is  the  first  value  (4)  and  “y”  is  the  second  value  (1).  We  can  quickly  see  
that  the  math  works  out:  8(4)  +  2(1)  =  34.  Once  again,  it  is  important  to  know  these  calculations  for  the  
configuration  of  QoS  policy  settings.  
 
To  configure  the  3750  switch  (SW1)  to  map  COS  3,  4,  and  5,  to  CS3  (DSCP  24),  AF41  (DSCP  34),  and  EF  
(DSCP  46),  respectively,  we  must  first  enter  the  command  mls qos  in  the  global  configuration  to  
enable  QoS  on  the  switch.  Next,  we  must  define  the  mls qos map cos-dscp  command  in  order  
to  assign  the  appropriate  values.  It  was  not  required  in  the  question,  but  a  “best  practice”  
configuration  is  to  leave  the  existing  maps  at  the  default  value  and  only  change  that  which  is  required  
in  the  question.  To  accomplish  this,  enter  the  show mls qos map cos-dscp  command  to  view  
the  settings.  Based  on  the  output,  the  only  two  values  that  must  be  modified  are  COS  4  and  COS  5,  
since  they  currently  map  to  the  incorrect  DSCP  value.  Set  the  correct  values  to  34  and  46,  respectively.  
 
SW1  
SW1(config)#mls qos

SW1#sh mls qos maps cos-dscp


Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56

SW1(config)#mls qos map cos-dscp 0 8 16 24 34 46 48 56


 
On  each  of  the  other  two  switches  (EHWICs  on  R2  and  R3);  we  can  paste  the  exact  map  into  the  global  
configuration  as  well.  There  is  no  need  to  enable  QoS  using  the  mls qos  command  on  these  devices.    
 
R2  
R2(config)#mls qos map cos-dscp 0 8 16 24 34 46 48 56
 
R3  
R3(config)#mls qos map cos-dscp 0 8 16 24 34 46 48 56  
 
Issue  the  show mls qos maps cos-dscp  command  on  each  device  to  check  the  status.  
 
SW1  
SW1#show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 34 46 48 56
 
R2  
R2#show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 34 46 48 56
 
R3  
R3#show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 34 46 48 56  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     713  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 46.2 Configure  the  phone  interfaces  on  the  3750  switch  to  trust  the  markings  provided  by  
the  phone.  
 
In  order  to  configure  the  phone  switchports  to  trust  the  markings  provided  by  the  phones,  we  must  
configure  a  “trust”  state  between  the  switchport  and  the  phone.  To  configure,  issue  the  mls qos
trust device cisco-phone  command  under  the  switchport  in  question.  Once  the  command  is  
entered,  the  switch  determines  whether  a  Cisco  phone  is  connected  based  on  the  CDP  information  
that  is  received  from  the  phone.  Once  the  phone  is  recognized,  the  “trust”  state  is  configured  and  all  
markings  provided  by  the  phone  are  trusted.  This  can  be  very  beneficial,  since  it  can  be  hard  to  classify  
traffic  using  other  mechanisms,  such  as  access-­‐lists  and  NBAR.    
 
SW1  
SW1(config)#interface FastEthernet 1/0/13
SW1(config-if)#mls qos trust device cisco-phone

SW1(config)#interface FastEthernet 1/0/14


SW1(config-if)#mls qos trust device cisco-phone

Jan 6 09:13:14.721: %SWITCH_QOS_TB-5-TRUST_DEVICE_DETECTED: cisco-phone detected on port Fa1/0/13,


port's configured trust state is now operational

Jan 6 09:13:52.151: %SWITCH_QOS_TB-5-TRUST_DEVICE_DETECTED: cisco-phone detected on port Fa1/0/14,


port's configured trust state is now operational
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     714  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 46.3 Ensure  that  all  traffic  received  from  the  PC  port  on  the  phone  is  rewritten  to  COS  1  
on  the  3750  switch.    
 
Cisco  phones  have  the  ability  to  connect  a  PC  to  the  “Computer/PC  Port”  of  the  phone  in  order  to  gain  
access  to  the  network.  This  can  be  very  beneficial  for  implementations,  since  only  one  cable  needs  to  
be  physically  dropped  at  the  location  instead  of  two.  If  PCs  are  connected  to  phones  in  the  network,  it  
is  important  to  understand  the  QoS  implications  of  that  scenario.  By  default,  no  frames  sent  to  the  
switch  by  the  PC  are  trusted  and  every  packet  is  re-­‐written  to  a  value  of  COS  0,  or  “best  effort”.    
 
In  order  to  meet  the  requirements  of  the  question  and  re-­‐write  the  COS  value  to  “1”  instead,  we  must  
issue  the  switchport priority extend  command  under  the  interface  connected  to  the  
phone.  We  have  the  option  to  either  trust  all  traffic  coming  from  the  PC  port  or  we  can  set  a  specific  
COS  value.  In  this  case,  let’s  set  a  specific  value.    
 
SW1  
SW1(config)#interface FastEthernet 1/0/13
SW1(config-if)#switchport priority extend cos 1

SW1(config)#interface FastEthernet 1/0/14


SW1(config-if)#switchport priority extend cos 1
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     715  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 46.4 Use  NBAR  to  classify  traffic  at  each  phone  port  on  R2  and  R3.  Voice  traffic,  signaling  
traffic,  and  video  traffic  should  be  marked  at  EF,  CS3,  and  AF41,  respectively.  
 
Network  Based  Application  Recognition  (NBAR)  is  a  very  powerful  tool  for  analyzing  and  classifying  
network  traffic  of  all  types.  It  uses  known  packet  signatures,  ports,  payload  types,  and  other  methods  
to  identify  the  traffic  in  question.  It  can  be  deployed  with  ease  using  the  standard  MQC  syntax.  In  this  
case  we  will  use  it  to  classify  voice,  signaling,  and  video  traffic  on  the  network.    
 
First,  we  must  classify  voice  traffic  using  NBAR.  Since  we  know  that  all  voice  traffic  utilizes  RTP,  we  can  
use  that  protocol  to  help  identify  the  traffic.  However,  we  cannot  simply  say  that  all  RTP  traffic  is  
equivalent  to  voice  traffic,  since  video  traffic  utilizes  RTP  as  well.  Therefore,  we  must  get  specific  by  
using  RTP  payload  types.  NBAR  has  this  functionality  built-­‐in  for  RTP  by  utilizing  the  match
protocol rtp audio  and  match protocol rtp video  commands.  The  former  contains  
RTP  payload  types  0  –  23  and  the  latter  contains  RTP  payload  types  24  –  34.  Being  that  we  can  simply  
use  the  “RTP  Audio”  traffic  type,  identifying  the  voice  traffic  becomes  much  easier.  Navigate  to  this  link  
to  learn  more  about  NBAR  and  RTP  payload  types:  
http://www.cisco.com/en/US/products/ps6612/products_white_paper09186a0080110040.shtml.    
 
We  must  now  create  a  class  for  the  voice  traffic  identified  by  NBAR  by  using  the  class-map  
command.  
 
R2  
R2(config)#class-map NBAR-VOICE
R2(config-cmap)#match protocol rtp audio
 
R3  
R3(config)#class-map NBAR-VOICE
R3(config-cmap)#match protocol rtp audio  
 
Next,  we  must  identify  the  signaling  traffic  used  and  place  it  inside  another  class.  Once  again,  the  
match protocol  command  should  be  used  along  with  the  protocol  in  question.  It  is  also  a  good  
idea  in  this  case  to  use  the  match-any  tag  within  the  class-map  since  multiple  protocols  should  
be  matched.  
 
R2  
R2(config)#class-map match-any NBAR-SIGNALING
R2(config-cmap)#match protocol skinny
R2(config-cmap)#match protocol sip
R2(config-cmap)#match protocol mgcp
R2(config-cmap)#match protocol h323
R2(config-cmap)#match protocol rsvp
 
R3  
R3(config)#class-map match-any NBAR-SIGNALING
R3(config-cmap)#match protocol skinny
R3(config-cmap)#match protocol sip
R3(config-cmap)#match protocol mgcp
R3(config-cmap)#match protocol h323
R3(config-cmap)#match protocol rsvp
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     716  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Last,  we  must  classify  the  video  traffic,  although  it  is  not  as  simple  as  issuing  the  match protocol
rtp video command.  As  mentioned  previously,  this  only  includes  RTP  payload  types  24  –  34,  which  
does  not  happen  to  include  H.264,  the  common  video  codec  used  throughout  the  CCIE  Collaboration  
network.  As  we  learned  in  previous  labs,  H.264  uses  a  dynamic  RTP  payload  type,  which  can  be  hard  to  
pinpoint  between  disparate  systems.  Since  we  are  only  using  CUCM  and  IOS-­‐based  devices,  however,  
we  know  the  different  payload  types  that  will  most  likely  be  used  for  communication.  For  CUCM,  either  
“97”  or  “126”  will  be  used  as  the  preferred  RTP  payload  type.  In  IOS-­‐based  systems,  dial-peers  use  
RTP  payload  type  “119”  by  default.  Therefore,  we  must  account  for  all  of  these  payload  types  in  the  
class-map  to  successfully  identify  H.264  video  traffic.    
 
R2  
R2(config-cmap)#class-map match-any NBAR-VIDEO
R2(config-cmap)#match protocol rtp payload-type 97
R2(config-cmap)#match protocol rtp payload-type 119
R2(config-cmap)#match protocol rtp payload-type 126

R3  
R3(config)#class-map match-any NBAR-VIDEO
R3(config-cmap)#match protocol rtp payload-type 97
R3(config-cmap)#match protocol rtp payload-type 119
R3(config-cmap)#match protocol rtp payload-type 126
 
Now  that  the  NBAR-­‐based  class-maps  have  been  configured,  we  must  create  a  policy-map  on  
both  R2  and  R3  to  mark  the  traffic  is  it  enters  the  router  from  the  phone  switchports.  Under  each  
class  heading,  the  set dscp  command  is  being  used  to  configure  the  correct  value  for  the  class.  
 
R2  
R2(config)#policy-map MARK
R2(config-pmap)#class NBAR-VOICE
R2(config-pmap-c)#set dscp ef

R2(config-pmap)#class NBAR-VIDEO
R2(config-pmap-c)#set dscp af41

R2(config-pmap)#class NBAR-SIGNALING
R2(config-pmap-c)#set dscp cs3

R3  
R3(config)#policy-map MARK
R3(config-pmap)#class NBAR-VOICE
R3(config-pmap-c)#set dscp ef

R3(config-pmap)#class NBAR-VIDEO
R3(config-pmap-c)#set dscp af41

R3(config-pmap)#class NBAR-SIGNALING
R3(config-pmap-c)#set dscp cs3  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     717  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  last  step  in  the  process  is  to  apply  the  policy-map  to  an  interface.  In  this  case,  since  policy-
maps  cannot  be  applied  directly  to  EHWIC  switchports,  it  must  be  applied  on  the  Voice  VLAN  SVI  
associated  with  the  phones  at  each  site.  Also,  since  we  are  marking  traffic  that  is  entering  the  router,  
we  must  use  the  service-policy input  command  in  application  of  the  policy.  
 
R2  
R2(config)#int vlan 21
R2(config-if)#service-policy input MARK

R3  
R3(config)#int vlan 31
R3(config-if)#service-policy input MARK  
 
As  always,  we  can  now  issue  the  show policy-map interface  command  to  view  the  details  of  
the  policy  and  display  real-­‐time  information.  
 
R2  
R2#sh policy-map interface vlan 21
Vlan21

Service-policy input: MARK

Class-map: NBAR-VOICE (match-all)


11020 packets, 815480 bytes
5 minute offered rate 22000 bps, drop rate 0000 bps
Match: protocol rtp audio
QoS Set
dscp ef
Packets marked 11021

Class-map: NBAR-VIDEO (match-any)


0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol rtp payload-type "97"
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol rtp payload-type "126"
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol rtp payload-type "119"
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp af41
Packets marked 0

Class-map: NBAR-SIGNALING (match-any)


169 packets, 13264 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol skinny
169 packets, 13264 bytes
5 minute rate 0 bps
Match: protocol sip
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol mgcp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol h323
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol rsvp
0 packets, 0 bytes

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     718  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

5 minute rate 0 bps


QoS Set
dscp cs3
Packets marked 169

Class-map: class-default (match-any)


867 packets, 94772 bytes
5 minute offered rate 3000 bps, drop rate 0000 bps
Match: any

R3  
R3#sh policy-map interface vlan31
Vlan31

Service-policy input: MARK

Class-map: NBAR-VOICE (match-all)


9490 packets, 707530 bytes
5 minute offered rate 22000 bps, drop rate 0000 bps
Match: protocol rtp audio
QoS Set
dscp ef
Packets marked 9490

Class-map: NBAR-VIDEO (match-any)


12191 packets, 7866516 bytes
5 minute offered rate 145000 bps, drop rate 0000 bps
Match: protocol rtp payload-type "97"
12191 packets, 7866516 bytes
5 minute rate 145000 bps
Match: protocol rtp payload-type "126"
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol rtp payload-type "119"
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp af41
Packets marked 12191

Class-map: NBAR-SIGNALING (match-any)


203 packets, 38021 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: protocol skinny
129 packets, 10622 bytes
5 minute rate 0 bps
Match: protocol sip
74 packets, 27399 bytes
5 minute rate 0 bps
Match: protocol mgcp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol h323
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol rsvp
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp cs3
Packets marked 203

Class-map: class-default (match-any)


77 packets, 9727 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     719  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 46.5 Enable  AutoQoS  on  the  3750  switch  for  the  phone  ports  and  observe  the  
configuration.  Ensure  that  the  above  tasks  still  function  properly.  
 
Of  course,  the  last  task  would  be  to  enable  automatic  QoS,  right?    I  normally  shy  away  from  anything  
that  is  done  automatically  in  most  cases,  but  I  think  this  can  actually  be  a  very  useful  tool.  Let’s  enable  
AutoQoS  on  the  SW1  phone  ports  and  see  what  happens.  First,  take  a  snippet  of  the  interface  
configuration  so  we  can  keep  track  of  the  changes.    
 
SW1  
SW1#sh run int fa1/0/13
Building configuration...

Current configuration : 242 bytes


!
interface FastEthernet1/0/13
description *** REMOTE HQ PHONE ***
switchport access vlan 12
switchport mode access
switchport voice vlan 11
switchport priority extend cos 1
mls qos trust device cisco-phone
spanning-tree portfast
end

SW1#sh run int fa1/0/14


Building configuration...

Current configuration : 242 bytes


!
interface FastEthernet1/0/14
description *** REMOTE HQ PHONE ***
switchport access vlan 12
switchport mode access
switchport voice vlan 11
switchport priority extend cos 1
mls qos trust device cisco-phone
spanning-tree portfast
end
 
To  implement  AutoQoS,  enter  the  interface  configuration  of  one  of  the  phone  ports.  There  are  several  
options  to  choose  from  under  the  auto qos voip  command  heading.  We  can  either  choose  to  
trust  Cisco  phones,  Cisco  softphones,  or  to  simply  trust  all  markings  from  all  devices.  
 
SW1  
SW1(config-if)#auto qos voip ?
cisco-phone Trust the QoS marking of Cisco IP Phone
cisco-softphone Trust the QoS marking of Cisco IP SoftPhone
trust Trust the DSCP/CoS marking

In  this  case,  we  will  configure  AutoQoS  to  trust  Cisco  phones  by  entering  the  auto qos voip
cisco-phone  command  under  one  of  the  phone  switchports.  
 
SW1  
SW1(config)#int fa1/0/13
SW1(config-if)#auto qos voip cisco-phone

   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     720  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Let’s  take  a  look  at  the  configuration  that  was  added  by  the  AutoQoS  process.  
 
SW1  
SW1#sh run
Building configuration...

...
mls qos map policed-dscp 24 26 46 to 0
mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue input bandwidth 90 10
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66
mls qos srr-queue input buffers 67 33
mls qos srr-queue input cos-map queue 1 threshold 2 1
mls qos srr-queue input cos-map queue 1 threshold 3 0
mls qos srr-queue input cos-map queue 2 threshold 1 2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3 3 5
mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue input dscp-map queue 1 threshold 3 32
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61
mls qos
!
...
!
class-map match-all AutoQoS-VoIP-RTP-Trust
match ip dscp ef
class-map match-all AutoQoS-VoIP-Control-Trust
match ip dscp cs3 af31
!
!
policy-map AutoQoS-Police-CiscoPhone
class AutoQoS-VoIP-RTP-Trust
set dscp ef
police 320000 8000 exceed-action policed-dscp-transmit
class AutoQoS-VoIP-Control-Trust
set dscp cs3
police 32000 8000 exceed-action policed-dscp-transmit
!

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     721  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

interface FastEthernet1/0/13
description *** REMOTE HQ PHONE ***
switchport access vlan 12
switchport mode access
switchport voice vlan 11
switchport priority extend cos 1
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
!

As  you  can  see,  it  added  quite  a  bit  of  configuration  to  the  switch:  policed-dscp  map,  cos-dscp  
map,  srr-queues,  queue-sets,  class-maps,  policy-maps,  etc.  The  point  of  running  
AutoQoS  is  this—the  majority  of  the  settings  is  optimized  for  use  on  the  3750  and  can  be  used  to  
provide  a  template  for  entering  the  required  configuration.  For  example,  AutoQoS  includes  the  
command:  mls qos map cos-dscp 0 8 16 24 32 46 48 56.  In  regards  to  the  COS-­‐DSCP  
map  question  earlier  in  the  lab,  we  now  only  need  to  change  one  value  (COS  4  –  34)  instead  of  two—
and  the  syntax  of  the  command  was  provided  for  us  by  simply  running  AutoQoS.    
 
The  requirements  of  this  task  state  that  all  previously  configured  tasks  must  still  function  properly  as  
well.  In  order  to  accomplish  this,  we  must  modify  the  COS-­‐DSCP  map  to  use  the  originally  configured  
values  of  the  previous  task  and  remove  the  mls qos trust cos  command  from  the  phone  
switchport,  since  markings  from  the  attached  PC  should  use  COS  1  (we  should  not  trust  PC  markings).  
 
SW1  
SW1(config)#mls qos map cos-dscp 0 8 16 24 34 46 48 56
SW1(config)#int fa1/0/13
SW1(config-if)#no mls qos trust cos

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     722  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 47: Congestion Management


Task 47.1 Configure  interfaces  FastEthernet  1/0/11  and  FastEthernet  1/0/13  on  the  3750  
switch  such  that  when  it  experiences  congestion  at  layer  2,  it  shares  bandwidth  
amongst  all  4  queues  equally.    
 
As  detailed  in  the  previous  section,  the  easiest  thing  to  do  is  to  simply  configure  AutoQoS  as  the  first  
step  and  then  modify  the  automatically  generated  configuration  as  the  next  step.  On  the  Fa1/0/11  and  
Fa1/0/13  interfaces,  enter  the  auto qos voip cisco-phone  command  to  implement  AutoQoS.  
 
SW1  
SW1(config)#interface FastEthernet 1/0/11
SW1(config-if)#auto qos voip cisco-phone

SW1(config)#interface FastEthernet 1/0/13


SW1(config-if)#auto qos voip cisco-phone
 
As  you  can  see  from  the  below  configuration,  the  four  queues  to  which  the  task  is  referring  are  the  
Shaped  Round  Robin  (SRR)  Output  Queues.  Each  COS  and  DSCP  value  is  placed  into  a  particular  queue  
and  threshold.  In  the  default  configuration,  queue  1  would  contain  voice  traffic  (DSCP  EF),  queue  2  
would  contain  signaling  traffic  (DSCP  CS3),  and  queue  3  would  contain  video  traffic  (DSCP  AF41).  The  
task  does  not  require  that  the  values  inside  of  each  queue  be  re-­‐configured.  It  only  requires  that  
bandwidth  is  shared  amongst  all  4  queues  equally,  which  is  a  configuration  that  should  be  performed  
at  the  switchport  level.    
 
SW1  
SW1#sh run
Building configuration...
...
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7
...
 
   

723 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  begin,  show  the  configuration  for  the  Fa1/0/11  and  Fa1/0/13  switchports.  
 
SW1  
SW1#sh run
Building configuration...
...
interface FastEthernet1/0/11
switchport access vlan 12
switchport mode access
switchport voice vlan 11
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
...
interface FastEthernet1/0/13
description *** REMOTE HQ PHONE ***
switchport access vlan 12
switchport mode access
switchport voice vlan 11
switchport priority extend cos 1
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
...
 
Based  on  the  above  configuration,  we  can  see  that  the  srr-queue bandwidth share  command  
has  been  entered  using  ratios  of  10,  10,  60,  and  20  for  queues  1,  2,  3,  and  4,  respectively.  These  
numbers  are  all  relative  to  one  another  and  do  not  need  to  add  up  to  100  (although  that  can  make  the  
math  easier).  In  order  to  ensure  that  bandwidth  is  shared  amongst  all  4  queues  equally,  we’ll  need  to  
make  some  changes  to  the  AutoQoS  configuration.  All  that  needs  to  be  done  in  this  case  is  to  set  all  4  
values  to  an  equal  number.  For  example  if  the  ratios  were  set  to  28,  28,  28,  and  28,  this  would  
successfully  answer  the  question.  This  is  because  each  queue  is  receiving  28/112  or  25%  priority  on  the  
interface.  Modify  the  srr-queue bandwidth share  command  accordingly.  
 
SW1  
SW1(config)#int range fa1/0/11,fa1/0/13
SW1(config-if-range)#srr-queue bandwidth share 1 1 1 1  
 
The  last  thing  that  must  be  changed  is  to  remove  the  priority-queue out  command  that  was  
automatically  included  by  AutoQoS.    
 
When  you  configure  the  priority-­‐queue  out  command,  the  shaped  round  robin  (SRR)  weight  ratios  are  
affected  because  there  is  one  fewer  queue  participating  in  SRR.  This  means  that  weight1  in  the  srr-­‐
queue  bandwidth  share  or  the  srr-­‐queue  bandwidth  shape  interface  configuration  command  is  ignored  
(not  used  in  the  ratio  calculation).  The  expedite  queue  is  a  priority  queue,  and  it  is  serviced  until  empty  
before  the  other  queues  are  serviced.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     724  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Follow  these  guidelines  when  the  expedite  queue  is  enabled  or  the  egress  queues  are  serviced  based  
on  their  SRR  weights:  
 
• If  the  egress  expedite  queue  is  enabled,  it  overrides  the  SRR  shaped  and  shared  weights  for  
queue  1.  
• If  the  egress  expedite  queue  is  disabled  and  the  SRR  shaped  and  shared  weights  are  configured,  
the  shaped  mode  overrides  the  shared  mode  for  queue  1,  and  SRR  services  this  queue  in  
shaped  mode.  
• If  the  egress  expedite  queue  is  disabled  and  the  SRR  shaped  weights  are  not  configured,  SRR  
services  the  queue  in  shared  mode.    
[Source:  
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-­‐
2_55_se/commmand/reference/3750cr/cli1.html#wpxref43281]  
 
SW1  
SW1(config)#int range fa1/0/11,fa1/0/13
SW1(config-if-range)#no priority-queue out  
 
With  the  priority  queue  disabled,  bandwidth  can  now  be  shared  amongst  all  four  queues  equally.  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     725  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 47.2 Configure  interfaces  FastEthernet  1/0/12  and  FastEthernet  1/0/14  on  the  3750  
switch  such  that  queues  1  and  4  are  policed  to  use  2  Mbps  of  bandwidth  per  queue.  
 
In  this  task,  we  must  configure  both  the  Fa1/0/12  and  Fa1/0/14  interfaces  to  police  all  traffic  in  the  
queue  to  a  rate  of  2  Mbps.  To  perform  this  task,  we  can  use  the  srr-queue bandwidth shape  
command.  This  command  can  be  used  in  combination  with  the  srr-queue bandwidth share  
command,  if  so  desired.  The  shape  command  will  always  take  priority,  however.  Enter  the  interface  
configuration  for  Fa1/0/12  and  Fa1/0/14.  Since  we  are  concerned  with  queues  1  and  4,  we  must  
modify  the  first  and  last  values  in  the  srr-queue bandwidth shape  command.  The  way  in  
which  numbers  must  be  entered  is  admittedly  a  little  strange,  however.  For  example,  a  value  of  7  Mbps  
per  second  should  be  entered  as  “14”  within  the  parameters.  This  is  because  the  entered  value  is  
considered  to  be  1/14  or  7.1%  of  the  total  interface  bandwidth  (100  Mbps).  Entering  a  value  of  7  
instead  would  result  in  a  policed  value  of  14  Mbps  (1/7  or  14.3%  of  100  Mbps).  Once  again,  make  sure  
to  remove  the  priority-queue out  command  if  configured.  
 
SW1  
SW1(config)#int range fa1/0/12,fa1/0/14
SW1(config-if-range)#srr-queue bandwidth shape 50 0 0 50
SW1(config-if-range)#no priority-queue out
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     726  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 47.3 Update  the  QoS  policy  for  the  link  between  HQ  and  SC  to  implement  policing  for  the  
video  class.  Traffic  should  be  policed  to  320  kbps  and  should  use  two  token  buckets  
with  the  Tc  value  at  10ms.  Any  traffic  exceeding  the  policy  should  still  be  sent  (with  a  
CS1  marking)  and  any  traffic  violating  the  policy  should  be  dropped.    
 
Policers  and  shapers  usually  identify  traffic  descriptor  violations  in  an  identical  manner.  They  usually  
differ,  however,  in  the  way  they  respond  to  violations,  for  example:  
 
• A  policer  typically  drops  traffic.  (For  example,  the  CAR  rate-­‐limiting  policer  will  either  drop  the  
packet  or  rewrite  its  IP  precedence,  resetting  the  type  of  service  bits  in  the  packet  header.)  
• A  shaper  typically  delays  excess  traffic  using  a  buffer,  or  queuing  mechanism,  to  hold  packets  
and  shape  the  flow  when  the  data  rate  of  the  source  is  higher  than  expected.  (For  example,  GTS  
and  Class-­‐Based  Shaping  use  a  weighted  fair  queue  to  delay  packets  in  order  to  shape  the  flow,  
and  DTS  and  FRTS  use  either  a  priority  queue,  a  custom  queue,  or  a  FIFO  queue  for  the  same,  
depending  on  how  you  configure  it.)  
 
Traffic  shaping  and  policing  can  work  in  tandem.  For  example,  a  good  traffic  shaping  scheme  should  
make  it  easy  for  nodes  inside  the  network  to  detect  misbehaving  flows.  This  activity  is  sometimes  
called  policing  the  traffic  of  the  flow.  
 
A  token  bucket  is  a  formal  definition  of  a  rate  of  transfer.  It  has  three  components:  a  burst  size,  a  mean  
rate,  and  a  time  interval  (Tc).  Although  the  mean  rate  is  generally  represented  as  bits  per  second,  any  
two  values  may  be  derived  from  the  third  by  the  relation  shown  as  follows:  
 
Mean  Rate  =  Burst  Size  /  Time  Interval  
 
Here  are  some  definitions  of  these  terms:  
 
• Mean  rate—Also  called  the  committed  information  rate  (CIR),  it  specifies  how  much  data  can  
be  sent  or  forwarded  per  unit  time  on  average.  
• Burst  size—Also  called  the  Committed  Burst  (Bc)  size,  it  specifies  in  bits  (or  bytes)  per  burst  how  
much  traffic  can  be  sent  within  a  given  unit  of  time  to  not  create  scheduling  concerns.  (For  a  
shaper,  such  as  GTS,  it  specifies  bits  per  burst;  for  a  policer,  such  as  CAR,  it  specifies  bytes  per  
burst.)  
• Time  interval—Also  called  the  measurement  interval,  it  specifies  the  time  quantum  in  seconds  
per  burst.  
 
By  definition,  over  any  integral  multiple  of  the  interval,  the  bit  rate  of  the  interface  will  not  exceed  the  
mean  rate.  The  bit  rate,  however,  may  be  arbitrarily  fast  within  the  interval.  
 
A  token  bucket  is  used  to  manage  a  device  that  regulates  the  data  in  a  flow.  For  example,  the  regulator  
might  be  a  traffic  policer,  such  as  CAR,  or  a  traffic  shaper,  such  as  FRTS  or  GTS.  A  token  bucket  itself  has  
no  discard  or  priority  policy.  Rather,  a  token  bucket  discards  tokens  and  leaves  to  the  flow  the  problem  
of  managing  its  transmission  queue  if  the  flow  overdrives  the  regulator.  (Neither  CAR  nor  FRTS  and  GTS  
implement  either  a  true  token  bucket  or  true  leaky  bucket.)  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     727  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  token  bucket  metaphor,  tokens  are  put  into  the  bucket  at  a  certain  rate.  The  bucket  itself  has  a  
specified  capacity.  If  the  bucket  fills  to  capacity,  newly  arriving  tokens  are  discarded.  Each  token  is  
permission  for  the  source  to  send  a  certain  number  of  bits  into  the  network.  To  send  a  packet,  the  
regulator  must  remove  from  the  bucket  a  number  of  tokens  equal  in  representation  to  the  packet  size.  
 
If  not  enough  tokens  are  in  the  bucket  to  send  a  packet,  the  packet  either  waits  until  the  bucket  has  
enough  tokens  (in  the  case  of  GTS)  or  the  packet  is  discarded  or  marked  down  (in  the  case  of  CAR).  If  
the  bucket  is  already  full  of  tokens,  incoming  tokens  overflow  and  are  not  available  to  future  packets.  
Thus,  at  any  time,  the  largest  burst  a  source  can  send  into  the  network  is  roughly  proportional  to  the  
size  of  the  bucket.  
 
Note  that  the  token  bucket  mechanism  used  for  traffic  shaping  has  both  a  token  bucket  and  a  data  
buffer,  or  queue;  if  it  did  not  have  a  data  buffer,  it  would  be  a  policer.  For  traffic  shaping,  packets  that  
arrive  that  cannot  be  sent  immediately  are  delayed  in  the  data  buffer.  
 
For  traffic  shaping,  a  token  bucket  permits  burstiness  but  bounds  it.  It  guarantees  that  the  burstiness  is  
bounded  so  that  the  flow  will  never  send  faster  than  the  token  bucket's  capacity,  divided  by  the  time  
interval,  plus  the  established  rate  at  which  tokens  are  placed  in  the  token  bucket.  See  the  following  
formula:  
 
(Token  bucket  capacity  in  bits  /  Time  interval  in  seconds)  +  Established  rate  in  bps  =    
Maximum  flow  speed  in  bps  
 
This  method  of  bounding  burstiness  also  guarantees  that  the  long-­‐term  transmission  rate  will  not  
exceed  the  established  rate  at  which  tokens  are  placed  in  the  bucket.  
[Source:  
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpolsh.html]  
 
In  this  task,  we  must  update  the  existing  policy-map  (LLQ)  on  both  the  R1  and  R3  routers  to  also  
include  a  policing  mechanism  for  video  traffic.  We  must  police  traffic  to  320  kbps  (CIR),  keep  the  Tc  
value  (time  interval)  at  10ms,  and  use  two  token  buckets  (Bc  and  Be).  Furthermore,  we  should  transmit  
the  traffic  upon  conformance  to  the  policy,  remark  the  traffic  to  CS1  if  it  exceeds  the  policy,  and  drop  
any  violating  traffic.  Believe  it  or  not,  this  can  all  be  accomplished  using  one  command,  albeit  lengthy.  
Under  the  “VIDEO”  class  of  the  policy-map LLQ  heading,  enter  the  police  command  to  begin  
the  configuration.  Enter  the  keyword  of  cir 320000  within  the  police  command  to  set  the  
Committed  Information  Rate  to  320  kbps.  Next,  define  the  Bc  (Committed  Burst)  and  Be  (Excess  Burst)  
values  as  3200  to  ensure  that  the  Tc  value  is  set  to  10  ms,  as  defined  in  the  task  requirements  (Tc  =  
Bc/CIR).  Last,  set  the  conform,  exceed,  and  violate  actions  for  the  policer.  
 
R1  
R1(config)#policy-map LLQ
R1(config-pmap)#class VIDEO
R1(config-pmap-c)#police cir 320000 bc 3200 be 3200 conform-action transmit exceed-action set-dscp-
transmit cs1 violate-action drop
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     728  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

R3  
R3(config)#policy-map LLQ
R3(config-pmap)#class VIDEO
R3(config-pmap-c)#police cir 320000 bc 3200 be 3200 conform-action transmit exceed-action set-dscp-
transmit cs1 violate-action drop
 
As  always,  you  may  use  the  show policy-map interface  command  to  view  the  policy  in  
action.  Set  up  a  video  call  between  HQ  Phone  1  and  SC  Phone  2  to  view  the  statistics.  
 
SW1  
R3#show policy-map interface
Serial0/1/0.301: DLCI 301 -

Service-policy output: FRAGMENT

Class-map: class-default (match-any)


4783101 packets, 2363825622 bytes
5 minute offered rate 630000 bps, drop rate 411000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 2/856291/0
(pkts output/bytes output) 3892342/1833055253
shape (average) cir 768000, bc 3072, be 3072
target shape rate 768000

Service-policy : LLQ
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 1373029/88490582

Class-map: VOICE (match-all)


1373029 packets, 88490582 bytes
5 minute offered rate 7000 bps, drop rate 0000 bps
Match: dscp ef (46)
Priority: 268 kbps, burst bytes 6700, b/w exceed drops: 0

Class-map: SIGNALING (match-all)


4840 packets, 3217586 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: dscp cs3 (24)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 4840/3217586
bandwidth 100 kbps

Class-map: VIDEO (match-all)


3373889 packets, 2269037453 bytes
5 minute offered rate 626000 bps, drop rate 411000 bps
Match: dscp af41 (34)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/856291/0
(pkts output/bytes output) 2483130/1738267084
bandwidth 320 kbps
police:
cir 320000 bps, bc 3200 bytes, be 3200 bytes
conformed 19484 packets, 13065123 bytes; actions:
transmit
exceeded 475 packets, 277078 bytes; actions:
set-dscp-transmit cs1
violated 34572 packets, 24653838 bytes; actions:
drop
conformed 221000 bps, exceeded 6000 bps, violated 411000 bps

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     729  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Eleven  Labs  48  -­‐  51    
Version  1.0  

730 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 11: Configuring and Troubleshooting Cisco Unified IM & Presence


Lab 48: CUCM Integration
Task 48.1 Configure  the  HQ  CUCM  cluster  to  integrate  with  and  publish  presence  information  
to  the  HQ  IM&P  server.  
 
Cisco  IM  and  Presence  consists  of  many  components  that  enhance  the  value  of  a  Cisco  Unified  
Communications  system.  The  main  presence  component  of  the  solution  is  the  Cisco  IM  and  Presence  
Service,  which  incorporates  the  Jabber  Extensible  Communications  Platform  and  supports  SIP/SIMPLE  
and  Extensible  Messaging  and  Presence  Protocol  (XMPP)  for  collecting  information  regarding  a  user's  
availability  status  and  communications  capabilities.  The  user's  availability  status  indicates  whether  or  
not  the  user  is  actively  using  a  particular  communications  device  such  as  a  phone.  The  user's  
communications  capabilities  indicate  the  types  of  communications  that  user  is  capable  of  using,  such  
as  video  conferencing,  web  collaboration,  instant  messaging,  or  basic  audio.  
 
The  aggregated  user  information  captured  by  the  Cisco  IM  and  Presence  Service  enables  Cisco  Jabber,  
Cisco  Unified  Communications  Manager  applications,  and  third-­‐party  applications  to  increase  user  
productivity.  These  applications  help  connect  colleagues  more  efficiently  by  determining  the  most  
effective  form  of  communication.  
[Source:    
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/9x/uc9x/presence.html]  
 
The  IM  and  Presence  server  is  the  main  focus  of  this  section,  as  it  must  be  configured  properly  in  order  
to  provide  messaging  services  to  users  running  the  Cisco  Jabber  client.  Integration  with  CUCM  is  a  main  
focus  here  as  well  to  provide  presence  information  from  the  user  assigned  devices  as  well  as  softphone  
capabilities  and  deskphone  control.    
 
The  first  step  in  configuring  the  integration  between  CUCM  and  IM&P  is  to  create  a  SIP  trunk  for  
publishing  presence  information.  It  is  possible  to  configure  the  integration  without  a  SIP  trunk,  but  that  
would  make  it  impossible  to  share  presence  information  between  servers.  To  begin  the  configuration,  
log  on  to  the  HQ  CUCM  cluster,  navigate  to  System  !  Security  !  SIP  Trunk  Security  Profile,  and  click  
the  Find  button.  Click  on  the  “Non  Secure  SIP  Trunk  Profile”  and  click  the  Copy  button  to  make  a  copy  
of  the  profile.    
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     731  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Enter  a  descriptive  “Name”  for  the  profile  (e.g.  “Non  Secure  SIP  Trunk  Profile  -­‐  IMP”).  Next,  check  the  
boxes  corresponding  to  the  “Accept  presence  subscription”,  “Accept  out-­‐of-­‐dialog  refer”,  “Accept  
unsolicited  notification”,  and  “Accept  replaces  header”  settings.  These  are  required  in  order  for  the  
presence  exchange  to  function  correctly.  
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  navigate  to  Device  !  Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  Type”  as  “SIP  
Trunk”  and  click  the  Next  button  to  continue.  
 

 
 
Enter  a  descriptive  “Device  Name”  for  the  trunk  (e.g.  “HQ_IMP_SIP_TRUNK”)  and  select  an  appropriate  
“Device  Pool”  (e.g.  “HQ_IMP_SIP_DP”).  Once  again,  the  assigned  Device  Pool  was  created  specifically  
for  the  purposes  of  the  IM&P  integration  to  provide  maximum  flexibility  in  configuration.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     732  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  under  the  “SIP  Information”  section,  configure  the  “Destination”  IP  address  as  the  address  of  the  
HQ  IM&P  server  (10.10.13.15).  Select  the  “Non  Secure  SIP  Trunk  Profile  –  IMP”  from  the  “SIP  Trunk  
Security  Profile”  dropdown  box  and  the  “Standard  SIP  Profile”  from  the  “SIP  Profile”  dropdown  box.  
 

 
 
Click  the  Save  and  Reset  buttons  when  complete  to  apply  the  configuration.  
 
Next,  we  must  configure  the  CUCM  Service  Parameters  to  add  the  newly  created  SIP  trunk  as  the  “IM  
and  Presence  Publish  Trunk”.  This  information  will  eventually  be  shared  with  the  IM&P  server  during  
the  initial  setup.  Navigate  to  System  !  Service  Parameters  !  10.10.13.11  !  Cisco  CallManager  and  
locate  the  parameter  entitled  “IM  and  Presence  Publish  Trunk”  under  the  “Clusterwide  Parameters  
(Device  -­‐  SIP)”  section.  Select  the  “HQ_IMP_SIP_TRUNK”  from  “IM  and  Presence  Publish  Trunk”  
dropdown  box.  
 

 
 
In  addition  to  this  parameter,  locate  the  “Default  Inter-­‐Presence  Group  Subscription”  parameter  under  
the  “Clusterwide  Parameters  (System  -­‐  Presence)”  section.  Set  the  value  to  “Allow  Subscription”  in  
order  to  ensure  the  presence  information  passes  successfully  between  groups,  if  configured.  This  
parameter  will  not  “make  or  break”  the  configuration  at  the  moment,  but  can  be  set  as  an  “insurance  
policy”  should  Presence  Groups  be  configured  in  the  future.  
 

 
 
Click  the  Save  button  to  apply  the  configuration.  
 
Next,  we  must  configure  a  UC  Service  and  Service  Profile  on  CUCM  in  order  to  connect  to  the  HQ  IM&P  
server.  Navigate  to  User  Management  !  User  Settings  !  UC  Service  and  click  the  Add  New  button.  In  
the  “UC  Service  Type”  dropdown  box,  select  “IM  and  Presence”  and  click  the  Next  button.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     733  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  enter  a  descriptive  “Name”  for  the  UC  Service  (e.g.  “HQ_IMP”)  and  enter  the  “Host  Name/IP  
Address”  of  the  HQ  IM&P  server  (10.10.13.15).  Click  the  Save  button  when  complete.    
 

 
 
Next,  create  the  Service  Profile  by  navigating  to  User  Management  !  User  Settings  !  Service  Profile  
and  clicking  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  profile  (e.g.  “IMP_SP”).  
 

 
 
Next,  under  the  “IM  and  Presence  Profile”  section,  select  the  “HQ_IMP”  service  from  the  “Primary”  
dropdown  box  and  click  the  Save  button  to  complete  the  configuration.  
 

 
 
Next,  navigate  to  User  Management  !  End  User  and  click  on  one  of  the  users  that  should  be  imported  
into  the  IM&P  server.  Under  the  “Service  Settings”  section,  ensure  that  the  “Enable  User  for  Unified  
CM  IM  and  Presence  (Configure  IM  and  Presence  in  the  associated  UC  Service  Profile)”  checkbox  is  
selected  and  the  “IMP_SP”  option  is  selected  from  the  “UC  Service  Profile”  dropdown  box.  
 

 
 
Click  the  Save  button  when  complete.  Perform  this  task  for  both  users  in  the  system.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     734  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  HQ  CUCM  cluster  has  been  configured,  we  must  configure  the  HQ  IM&P  server  to  
integrate  with  the  HQ  CUCM  cluster.  To  begin  the  configuration  of  the  HQ  IM&P  server,  navigate  to  the  
IP  address  of  10.10.13.15  using  a  web  browser.  
 

 
 
Click  the  “Cisco  Unified  Communications  Manager  IM  and  Presence”  link  to  continue.  At  this  point,  the  
server  will  prompt  for  a  username  and  password.  Enter  the  credentials  as  admin/cciecollab  and  click  
the  Login  button  to  continue.  
 

 
 
Upon  login,  you  should  be  greeted  with  the  “Post  Install  Setup”  screen,  which  will  assist  in  configuring  
the  integration  to  the  HQ  CUCM  cluster.  Provide  the  “Hostname”  of  the  HQ  CUCM  server  as  well  as  the  
“IP  address”  and  click  the  Next  button  to  continue.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     735  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  next  screen  prompts  for  the  AXL  username  and  password  on  the  HQ  CUCM  cluster.  This  
information  is  necessary  to  collect  user  and  system  level  information  from  CUCM.  You  may  specify  the  
username  and  password  of  admin/cciecollab  here.  Click  the  Next  button  to  continue.  
 

 
 
Next,  the  “Security  Password”  is  required  in  order  for  the  HQ  IM&P  server  to  become  a  de-­‐facto  
member  of  the  CUCM  cluster.  Essentially,  this  is  providing  direct  access  to  the  CUCM  database.  Enter  
the  password  of  “cciecollab”  and  click  the  Next  button  to  continue.  
 

 
 
As  the  last  step,  verify  that  the  entered  information  is  complete  and  click  the  Confirm  button.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     736  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

After  the  Post  Install  Setup  has  completed,  click  the  Topology  button  to  continue  to  the  system  
configuration.  
 

 
 
 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     737  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 48.2 Ensure  that  the  HQ  IM&P  server  communicates  with  all  other  servers  using  the  IP  
address  and  not  the  hostname.  
 
With  the  initial  set  up  of  the  HQ  IM&P  server  completed,  we  can  now  move  on  to  perhaps  the  most  
important  part  of  the  configuration—changing  the  hostname  to  an  IP  address.  I  rank  the  importance  of  
this  configuration  very  high  because  if  it  is  not  done  correctly,  it  can  cause  major  issues  down  the  road.    
 
After  logging  into  the  server,  navigate  to  System  !  Cluster  Topology  to  get  the  system  overview.  
Below  the  name  of  the  server  (HQIMP),  click  the  “Edit”  link  to  change  the  configuration.  
 

 
 
Replace  the  server  name  (HQIMP)  in  the  “Fully  Qualified  Domain  Name/IP  Address”  textbox  with  the  IP  
address  of  the  server  (10.10.13.15)  and  click  the  Save  button.  
 

 
 
That  wasn’t  so  bad  was  it?    Changing  the  IP  address  was  pretty  easy!    Not  so  fast,  my  friends.  The  last  
thing  that  we  need  to  do  for  this  change  to  take  full  effect  is  to  REBOOT  the  server.  If  this  step  is  left  
out  or  forgotten,  you  will  never  get  this  integration  to  work  correctly.  Changing  the  hostname  of  the  
server  causes  a  great  deal  of  internal  confusion  within  the  IM&P  server.  Once  again,  make  sure  to  
REBOOT  after  this  change  is  made.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     738  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

To  reboot  the  server,  SSH  into  10.10.13.15  and  issue  the  utils system restart  command  from  
the  admin:  prompt.  You  should  regain  access  to  the  web  interface  within  about  5  minutes.  
 
HQ-­‐IMP  
ssh -l admin 10.10.13.15
admin@10.10.13.15's password:
Command Line Interface is starting up, please wait ...

Welcome to the Platform Command Line Interface

VMware Installation:
1 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
2048 Mbytes RAM

admin:utils system restart

Do you really want to restart ?

Enter (yes/no)? yes

Appliance is being Restarted ...


Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...


 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     739  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 48.3 Ensure  that  the  domain  is  set  to  ipexpert.com  for  all  IM&P  communication.  
 
The  domain  setting  within  IM&P  can  be  a  little  tricky  to  configure.  Unfortunately,  you  cannot  just  
configure  the  setting  and  go  on  your  merry  way.  You  must  first  ensure  that  the  following  services  are  
completely  stopped.  
 
• Cisco  SIP  Proxy  
• Cisco  Presence  Engine  
• Cisco  XCP  Router  
 
If  the  server  is  being  configured  for  the  first  time,  chances  are  that  the  services  are  all  deactivated.  
Unfortunately,  however,  the  Cisco  XCP  Router  service  is  configured  to  be  automatically  activated  and  
must  be  manually  stopped  to  continue.  To  shut  down  the  service,  navigate  to  Cisco  Unified  IM  and  
Presence  Serviceability  in  the  “Navigation”  dropdown  box  and  click  the  Go  button.  
 

 
 
From  the  Cisco  Unified  IM  and  Presence  Serviceability  webpage,  navigate  to  Tools  !  Control  Center  -­‐  
Network  Services  and  select  the  Cisco  XCP  Router  service  under  the  “IM  and  Presence  Services”  
section.  
 

 
 
Click  the  Stop  button  to  temporarily  turn  off  the  service.  When  the  operation  has  completed,  a  status  
will  be  displayed  regarding  the  service  at  the  top  of  the  window.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     740  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  all  three  services  now  stopped,  return  back  to  Cisco  Unified  CM  IM  and  Presence  Administration  
and  navigate  to  System  !  Cluster  Topology  and  click  the  “Settings”  gear  icon.  
 

 
 
At  this  menu,  we  can  now  change  the  “Cluster-­‐Wide  Topology  Settings”  to  update  the  domain.  Set  the  
“Cluster  ID”  parameter  to  use  the  hostname  of  the  server  (e.g.  “HQIMP”)  and  enter  the  “IM  and  
Presence  Domain”  to  the  required  value  of  “ipexpert.com”.    
 

 
 
Click  the  Save  button  when  complete.  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     741  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 48.4 Activate  all  services  and  configure  any  remaining  IM&P  settings  on  the  HQ  IM&P  
server.  Test  the  configuration  by  sending  instant  messages  between  both  HQ  Jabber  
clients.  
 
With  both  the  CUCM  and  IM&P  servers  configured  it  is  now  necessary  to  activate  all  services  by  
navigating  to  Cisco  Unified  IM  and  Presence  Serviceability  !  Tools  !  Service  Activation.  Click  the  
“Check  All  Services”  option  and  click  the  Save  button  to  continue.    
 

 
 
Now  that  the  services  have  been  activated,  return  to  the  Cisco  Unified  CM  IM  and  Presence  
Administration  page  and  navigate  to  System  !  Cluster  Topology.  You  should  now  see  users  assigned  to  
the  server.  
 

 
 
To  configure  the  remaining  pieces  of  the  integration,  navigate  to  Presence  !  Gateways  and  click  the  
Add  New  button.  Enter  the  information  for  the  HQ  CUCM  cluster  here  in  order  to  allow  presence  
communication  between  systems.  Click  the  Save  button  when  complete.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     742  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Presence  !  Routing  !  Settings  to  configure  the  Preferred  Proxy  Listener.  Since  we  
have  configured  a  SIP  trunk  to  IM&P,  we  should  select  the  “Default  Cisco  SIP  Proxy  TCP  Listener”.  Click  
the  Save  button  to  complete  the  configuration.  
 

 
 
Following  the  save,  click  the  Restart  All  Proxy  Services  button  to  refresh  the  Cisco  SIP  Proxy  service.  
 

 
 
At  this  time,  you  should  be  able  to  log  into  a  Cisco  Jabber  client  and  send  instant  messages  between  
users.  Open  an  RDP  session  to  PCs  at  both  10.10.13.17  (HQ  Test  PC)  and  10.10.23.17  (SB  Test  PC).  From  
there,  launch  the  Jabber  client  by  right  clicking  on  the  Jabber  desktop  icon  and  selecting  the  “Run  as  
Administrator”  option.  This  will  ensure  that  the  proper  privileges  are  used  when  using  the  client.  
 

 
 
Once  the  Jabber  client  launches,  click  the  “Manual  setup  and  sign-­‐in”  link  below  the  Sign  In  button.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     743  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Ensure  that  the  “Cisco  IM  &  Presence”  radio  button  is  selected  and  the  “Server  address”  is  entered  as  
“10.10.13.15”.  Click  the  Save  button  when  complete.  
 

 
 
Next,  sign  into  the  Jabber  client  with  the  username  and  password  of  one  of  the  configured  users  in  the  
system  (e.g.  hqp1/cisco).    
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     744  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
After  signing  in,  the  username  and  domain  should  be  displayed  along  with  the  presence  status  of  the  
client.    
 

 
 
Sign  in  with  the  other  HQ  account  (e.g.  hqp2/cisco)  on  the  SB  test  PC.  
 

 
 
On  one  of  the  Jabber  clients,  add  a  contact  by  navigating  to  File  !  New  !  Custom  contact.  
 

 
 
Enter  the  “Display  Name”,  “Chat  (IM  address)”,  and  “Add  to”  (Category)  for  the  contact  and  click  the  
Create  button.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     745  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  double  click  the  name  of  the  contact  to  send  a  test  instant  message  between  the  two  Jabber  
clients.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     746  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 49: Jabber for Windows


Task 49.1 Ensure  that  both  the  HQ  CUCM  and  HQ  IM&P  servers  are  configured  to  allow  the  
Jabber  client  to  control  the  corresponding  deskphone.  
 
In  the  previous  section,  the  HQ  IM&P  server  was  integrated  with  the  HQ  CUCM  server  and  instant  
messaging  between  two  Jabber  clients  was  achieved.  In  this  section,  we  will  focus  on  the  calling  
capabilities  of  the  Jabber  client  using  CUCM.  This  task  specifically  will  focus  on  Jabber  Deskphone  
Control.  In  order  to  successfully  control  a  CUCM-­‐registered  phone  using  the  Jabber  client,  we  must  
configure  CTI  control  of  that  phone  from  the  End  User  account.  Similar  to  the  way  in  which  the  
CUE/CUCM  Voice  Mail  or  UCCX  integration  works,  we  must  utilize  CTI  to  control  interactions  between  
the  two  servers  with  some  type  of  user  account.  
 
To  begin  the  configuration,  we  must  create  UC  Services  for  CTI  and  allocate  them  to  the  existing  
Service  Profile  assigned  to  each  End  User.  Navigate  to  User  Management  !  User  Settings  !  UC  
Service  and  click  the  Add  New  button.  Select  the  “UC  Service  Type”  as  “CTI”  from  the  dropdown  box  
and  click  the  Next  button.  
 

 
 
Add  a  descriptive  “Name”  for  the  service  (e.g.  “HQ_PUB_CTI”)  as  well  as  the  “Host  Name/IP  Address”  
of  the  corresponding  CUCM  server  at  HQ.  (e.g.  “10.10.13.11”).  Click  the  Save  button  when  complete.  
 

 
 
Add  a  “CTI”  server  for  the  HQ  CUCM  Subscriber  in  the  same  fashion,  to  configure  redundancy.  
 

 
 

747 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  update  the  Service  Profile  by  navigating  to  User  Management  !  User  Settings  !  Service  Profile  
and  clicking  the  Find  button.  Click  on  the  existing  Service  Profile  (e.g.  “IMP_SP”)  to  edit  the  
configuration.  Under  the  “CTI  Profile”  section,  assign  the  previously  created  CTI  services  to  the  profile  
and  click  the  Save  button.  The  order  of  the  servers  should  match  the  configured  phone  registration  
CUCM  group  for  consistency.  
 

 
 
Next,  navigate  to  User  Management  !  End  User  to  enable  CTI  for  each  IM&P  user.  Click  on  one  of  the  
users  (e.g.  “hqp1”)  and  scroll  to  the  “Device  Information”  section.  In  the  “Controlled  Devices”  list  box,  
make  sure  that  the  corresponding  phone  is  listed  (this  was  configured  in  previous  labs).  If  there  is  no  
phone  listed,  add  it  by  clicking  the  Device  Association  button.  
 

 
 
Next,  click  the  Line  Appearance  Association  for  Presence  button.  This  will  launch  a  new  window  that  
will  prompt  the  selection  of  lines  to  be  associated  with  the  End  User.  Once  a  line  is  associated,  
presence  status  for  that  line  can  be  shared  with  the  HQ  IM&P  server.  
 

 
 
Click  the  Save  button  to  apply  the  configuration  and  return  to  the  End  User  page.  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     748  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  scroll  to  the  “Permissions  Information”  section  and  click  the  Add  to  Access  Control  Group  
button.  In  the  new  window,  select  the  “Standard  CCM  End  Users”  and  “Standard  CTI  Enabled”  
permissions.  If  the  associated  End  User  phone  is  a  9971,  you  must  also  add  the  “Standard  CTI  Allow  
Control  of  Phones  supporting  Connected  Xfer  and  conf”  in  order  for  CTI  control  to  work  properly.    
 

 
 
Click  the  Add  Selected  button  to  save  the  configuration  and  return  to  the  End  User  page.  Click  the  Save  
button  on  the  End  User  page  to  save  the  configuration  for  the  End  User.  Update  the  other  HQ  user  in  
the  same  fashion  to  ensure  that  CTI  deskphone  control  can  be  enabled  and  presence  status  can  be  
shared.  
 
Next,  we  must  configure  the  HQ  IM&P  server  to  allow  deskphone  control  for  each  user.  From  the  Cisco  
Unified  CM  IM  and  Presence  Administration  webpage,  navigate  to  Application  !  Legacy  Clients  !  
Settings  and  enter  the  IP  Address  of  “Primary  TFTP  Server”  (e.g.  “10.10.13.12”)  and  “Backup  TFTP  
Server”  (e.g.  “10.10.13.11”).  You  may  have  noticed  the  note  at  the  top  of  the  page:  “The  Proxy  Listener  
is  only  applicable  to  SIP  Clients;  it  does  not  apply  to  Cisco  Jabber  8.x."  The  TFTP  Servers  apply  to  Cisco  
Jabber  8.x  and  previous  clients.”    This  is  rather  confusing  because  these  settings  are  an  absolute  
requirement  for  CTI  deskphone  control  (and  softphones)  to  function  properly  in  our  version  of  Jabber  
(9.7).  Moral  of  the  story—ignore  the  note  and  configure  the  settings.  Click  the  Save  button  when  
complete.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     749  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Next,  configure  the  CTI  hosts  by  navigating  to  Application  !  Legacy  Clients  !  CCMCIP  Profile  and  
clicking  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  profile  (e.g.  “HQ_CCMCIP”)  and  enter  
the  IP  addressing  information  for  the  “Primary/Backup  CCMCIP  Host”.  Next,  click  the  Add  Users  to  
Profile  button  and  select  the  users  that  should  have  deskphone  control  enabled.  Click  the  Save  button  
when  complete.  
 

 
 
At  this  point,  log  in  to  the  Jabber  client  for  both  users  with  the  HQ  and  SB  test  PCs.  You  should  see  the  
phone  icon  at  the  bottom  right  hand  corner  of  the  client  that  allows  deskphone  control.  Make  a  few  
calls  to  test  the  feature.  Note  that  the  presence  status  within  Jabber  has  changed  when  on  a  call.    
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     750  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Task 49.2 Configure  the  system  so  Jabber  clients  can  make  calls  to  other  users  in  the  system.  
 
This  task  requires  that  we  now  configure  a  softphone  for  the  Jabber  client  in  addition  to  the  previously  
enabled  Deskphone  Control.  To  do  this,  we  must  create  a  new  Client  Services  Framework  (CSF)  device  
within  the  HQ  CUCM  cluster  and  associate  it  with  the  End  User.  
 
Navigate  to  Device  !  Phone  and  click  the  Add  New  button.  Select  the  “Cisco  Unified  Client  Services  
Framework”  option  from  the  “Phone  Type”  dropdown  box  and  click  the  Next  button.  
 

 
 
Enter  the  “Device  Name”  with  the  prefix  of  “CSF”  followed  by  the  username  of  the  End  User  (e.g.  
“CSFhqp1”)  and  assign  an  appropriate  “Device  Pool”  for  the  device  (e.g.  “HQ_PHONE_DP”).  Assign  a  
“Calling  Search  Space”  to  the  device  as  well  (e.g.  “PHONE_CSS”)  and  click  the  Save  button  when  
complete.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     751  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  click  the  “Line  [1]  -­‐  Add  a  new  DN”  link  under  the  “Association  Information”  section  to  associate  a  
line  with  the  CSF  device.  Enter  the  “Directory  Number”  and  “Partition”  for  the  CSF  device  on  the  
Directory  Number  Configuration  page.  This  should  be  the  same  DN/Partition  used  for  the  user’s  
physical  phone  (e.g.  “1001/INTERNAL_PT”).    
 

 
 
Next,  scroll  down  to  the  “Line  1  on  Device  CSFhqp1”  section  and  enter  the  Display  (Caller  ID)  of  the  
device.  
 

 
 
Finally,  scroll  down  to  the  bottom  of  the  page  and  click  the  Associated  End  Users  button.  
 

 
 
In  the  popup  window,  select  a  user  (e.g.  “hqp1”)  and  click  the  Add  Selected  button  to  associate  the  
user.  This  will  allow  the  sharing  of  presence  status  when  the  CSF  device  is  used.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     752  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Click  the  Save  and  Apply  Config  buttons  to  save  the  configuration.  
 
Next,  we  must  associate  the  newly  configured  CSF  device  with  the  End  User.  Navigate  to  User  
Management  !  End  User  and  click  on  the  “hqp1”  user.  Under  the  “Device  Information”  section,  click  
the  Device  Association  button  and  select  the  newly  created  CSF  device.  
 

 
 
Click  the  Save  Selected/Changes  button  to  save  the  configuration.  
 
The  “Controlled  Devices”  listbox  for  the  End  User  should  now  be  updated  to  reflect  the  changes.  
 

 
 
Make  sure  to  perform  all  required  CUCM  configuration  for  the  other  user  at  HQ  as  well.  
With  the  configuration  complete,  log  into  the  Jabber  client  for  both  users  with  the  HQ  and  SB  test  PCs.  
You  should  now  see  the  square  phone  icon  at  the  bottom  right  hand  corner  of  the  client  as  an  available  
audio  communication  option  (in  addition  to  the  Deskphone  Control  option).    
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     753  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Make  a  few  calls  with  the  softphone  to  test  the  feature.  The  audio  should  be  played  through  the  
computer  speakers  for  the  call.    
 

 
 
 
 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     754  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 49.3 Configure  the  Jabber  client  to  support  URI  dialing.  
 
In  order  to  configure  the  Jabber  client  to  support  URI  dialing,  we  must  create  a  configuration  file  called  
the  “jabber-­‐config.xml”  file.  Cisco  couldn’t  have  made  it  as  easy  as  checking  a  box,  right?    In  order  to  
create  this  file,  our  most  helpful  resource  is  the  Cisco  documentation.  Remember,  we  have  access  to  it  
in  the  lab,  so  as  long  as  we  familiarize  ourselves  with  the  path  to  locate  the  various  pieces  of  
documentation,  it  can  be  very  useful.  To  find  the  correct  format  for  the  “jabber-­‐config.xml”  file,  
navigate  to  the  Cisco  documentation  at  the  following  link:    
http://www.cisco.com/cisco/web/psa/default.html?mode=prod.    
 

 
 
From  there,  navigate  to  Unified  Communications  !  Unified  Communications  Applications  !  
Messaging  !  Jabber  for  Windows  and  click  the  “Install  and  Upgrade  Guides”  link.  Click  the  link  for  the  
“Cisco  Jabber  for  Windows  9.7  Installation  and  Configuration  Guide”  to  load  the  document.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     755  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Within  the  document,  click  the  “Configure  Cisco  Jabber”  section  and  locate  the  “Example  
Configuration”  link.    
 

 
 
Within  the  “Example  Configuration”  section  a  copy  of  the  configuration  file  exists  that  should  be  used  
to  configure  the  Jabber  client.  Copy  the  entire  XML  text  and  paste  it  into  Notepad++  (available  in  the  
lab).  Immediately  save  the  file  as  “jabber-­‐config.xml”.  This  will  allow  Notepad++  to  mark  up  the  file  
with  the  correct  color-­‐coding  to  make  it  easier  to  decipher.  
 

 
 
Next,  go  back  to  the  documentation  and  locate  the  “Policies  Parameters”  section.  Click  on  “Common  
Policies”  and  locate  the  “EnableSIPURIDialling”  parameter.  Take  note  that  the  value  of  this  parameter  
can  either  be  “true”  or  “false”.  
 

 
 
Copy  the  parameter  and  go  back  to  the  Notepad++  application.  Locate  the  “<Policies>”  XML  tag  and  
replace  one  of  the  existing  parameters  with  the  “EnableSIPURIDialing”  parameter.  Enter  a  value  of  
“true”  between  the  XML  tags.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     756  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
All  other  configuration  elements  that  exist  between  the  “<config>”  tags  can  now  be  deleted  to  leave  
the  newly  configured  parameter  as  the  only  element  in  the  XML  file.  
 

 
 
Make  sure  to  save  the  file  again  to  update  the  configuration.  
 
With  the  file  now  created,  we  must  upload  it  to  both  TFTP  servers  in  the  HQ  CUCM  cluster  and  restart  
the  “Cisco  TFTP”  service  to  apply  the  changes.  This  will  allow  the  Jabber  client  to  download  the  newly  
created  configuration  file  and  load  it  upon  logging  in.  
 
Log  in  to  the  Cisco  Unified  OS  Administration  webpage  and  navigate  to  Software  Upgrades  !  TFTP  File  
Management.  Click  the  Upload  button  to  upload  a  new  file.  Click  the  Browse…  button  and  locate  the  
newly  created  “jabber-­‐config.xml”  file.  Place  it  in  the  root  “Directory”  by  entering  the  “/”  character.    
 

 
 
Click  the  Upload  File  button  when  complete.  You  should  receive  a  status  message  indicating  that  the  
file  was  uploaded  successfully.  
 

 
 
Upload  the  “jabber-­‐config.xml”  file  to  the  HQ  CUCM  Subscriber  TFTP  server  as  well.      

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     757  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  log  in  to  the  Cisco  Unified  Serviceability  webpage  and  navigate  to  Tools  !  Control  Center  –  
Feature  Services  !  10.10.13.11  and  click  the  radio  button  for  the  “Cisco  TFTP”  service  under  the  “CM  
Services”  heading.    
 

 
 
Click  the  Restart  button  to  restart  the  service.    
 

 
 
Perform  the  same  step  for  the  HQ  CUCM  Subscriber  server  as  well.  
 
Log  in  to  the  Jabber  client  and  test  the  configuration  by  entering  a  “dialable”  Directory  URI  into  the  
“Search  or  Call”  field.  Upon  entering  the  URI,  hit  the  Enter  button  and  Jabber  will  now  be  able  to  dial  
the  number.  This  method  should  work  using  either  softphone  or  deskphone  mode.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     758  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 49.4 Configure  the  Jabber  client  to  support  local  CUCM  directory  lookups.  
 
By  default,  the  Jabber  client  does  not  support  directory  lookups  for  the  CUCM  cluster  (UDS).  To  
support  local  CUCM  directory  lookups,  we  must  once  again  edit  the  “jabber-­‐config.xml”  file  and  re-­‐
upload  it  to  the  HQ  CUCM  TFTP  servers.  
 
Within  the  “Cisco  Jabber  for  Windows  9.7  Installation  and  Configuration  Guide”  discussed  in  the  
previous  section,  click  on  the  “Integrate  with  Directory  Sources”  section  and  locate  the  “UDS  
Integration”  link  under  the  “Directory  Server  Configuration  Examples”  heading.  Copy  the  XML  
configuration  and  paste  it  into  the  “jabber-­‐config.xml”  file,  loaded  into  Notepad++.  Next,  remove  the  
“<UdsServer>”  and  “<UdsPhotoUriWithToken>”  parameters  to  leave  only  the  “<DirectoryServerType>”  
parameter.  
 

 
 
The  entire  configuration  should  now  appear  as  shown  below.  
 

 
 
Save  the  “jabber-­‐config.xml”  file  to  apply  the  configuration.  
 
With  the  file  now  created,  upload  it  to  both  TFTP  servers  in  the  HQ  CUCM  cluster  and  restart  the  “Cisco  
TFTP”  service  to  apply  the  changes,  as  detailed  in  the  previous  section.  This  will  allow  the  Jabber  client  
to  download  the  newly  created  configuration  file  and  load  it  upon  logging  in.  
 
Shut  down  the  Jabber  client  and  re-­‐launch  it.  Log  in  again  using  the  username  and  password  of  an  HQ  
user.  When  the  client  launches,  type  the  name  of  a  user  in  the  “Search  or  Call”  field  of  the  client  and  
ensure  that  it  is  able  to  find  users  in  the  system.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     759  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 49.5 Configure  the  Jabber  client  to  make  successful  video  calls  to  all  video  phones  
configured  in  the  system.  
 
In  order  for  the  Jabber  client  to  make  video  calls,  the  first  thing  that  is  necessary  is  to  have  a  camera  
connected  to  the  system.  Unfortunately,  at  the  time  of  the  writing  of  this  document,  cameras  were  not  
available  on  the  test  PCs  for  use  with  the  Jabber  client.  In  order  to  test  video  calls,  you  must  install  
Jabber  on  a  PC  or  laptop  that  makes  use  of  a  camera.    
 
Other  than  a  camera  being  installed,  we  must  ensure  that  the  CUCM  CSF  device  supports  video  calling.  
Navigate  to  Device  !  Phone  and  click  on  one  of  the  created  CSF  devices  in  the  system  (e.g.  
“CSFhqp1”).  Under  the  “Product  Specific  Configuration  Layout”  section,  make  sure  that  the  “Video  
Calling”  parameter  is  set  to  “Enabled”,  which  should  be  the  case,  by  default.  
 

 
 
Log  in  to  the  Jabber  client  and  ensure  that  video  calling  works  by  making  a  test  call  to  HQ  Phone  1  or  
SC  Phone  2.  The  example  below  displays  the  Apple  version  of  the  Jabber  client  on  a  video  call.  
 

 
 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     760  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 50: SB Presence and Jabber Configuration


Task 50.1 Configure  the  SB  CUCM  cluster  to  integrate  with  and  publish  presence  information  
to  the  SB  IM&P  server.  
 
The  first  step  in  configuring  the  integration  between  CUCM  and  IM&P  is  to  create  a  SIP  trunk  for  
publishing  presence  information.  It  is  possible  to  configure  the  integration  without  a  SIP  trunk,  but  that  
would  make  it  impossible  to  share  presence  information  between  servers.  To  begin  the  configuration,  
log  on  to  the  SB  CUCM  cluster,  navigate  to  System  !  Security  !  SIP  Trunk  Security  Profile,  and  click  
the  Find  button.  Click  on  the  “Non  Secure  SIP  Trunk  Profile”  and  click  the  Copy  button  to  make  a  copy  
of  the  profile.    
 

 
 
Enter  a  descriptive  “Name”  for  the  profile  (e.g.  “Non  Secure  SIP  Trunk  Profile  -­‐  IMP”).  Next,  check  the  
boxes  corresponding  to  the  “Accept  presence  subscription”,  “Accept  out-­‐of-­‐dialog  refer”,  “Accept  
unsolicited  notification”,  and  “Accept  replaces  header”  settings.  These  are  required  in  order  for  the  
presence  exchange  to  function  correctly.  
 

 
 
Click  the  Save  button  when  complete.    
 
Next,  navigate  to  Device  !  Trunk  and  click  the  Add  New  button.  Select  the  “Trunk  Type”  as  “SIP  
Trunk”  and  click  the  Next  button  to  continue.  
 

 
 

761 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Enter  a  descriptive  “Device  Name”  for  the  trunk  (e.g.  “SB_IMP_SIP_TRUNK”)  and  select  an  appropriate  
“Device  Pool”  (e.g.  “SB_IMP_SIP_DP”).  Once  again,  the  assigned  Device  Pool  was  created  specifically  
for  the  purposes  of  the  IM&P  integration  to  provide  maximum  flexibility  in  configuration.  
 

 
 
Next,  under  the  “SIP  Information”  section,  configure  the  “Destination”  IP  address  as  the  address  of  the  
SB  IM&P  server  (10.10.23.15).  Select  the  “Non  Secure  SIP  Trunk  Profile  –  IMP”  from  the  “SIP  Trunk  
Security  Profile”  dropdown  box  and  the  “Standard  SIP  Profile”  from  the  “SIP  Profile”  dropdown  box.  
 

 
 
Click  the  Save  and  Reset  buttons  when  complete  to  apply  the  configuration.  
 
Next,  we  must  configure  the  CUCM  Service  Parameters  to  add  the  newly  created  SIP  trunk  as  the  “IM  
and  Presence  Publish  Trunk”.  This  information  will  eventually  be  shared  with  the  IM&P  server  during  
the  initial  setup.  Navigate  to  System  !  Service  Parameters  !  10.10.23.11  !  Cisco  CallManager  and  
locate  the  parameter  entitled  “IM  and  Presence  Publish  Trunk”  under  the  “Clusterwide  Parameters  
(Device  -­‐  SIP)”  section.  Select  the  “SB_IMP_SIP_TRUNK”  from  “IM  and  Presence  Publish  Trunk”  
dropdown  box.  
 

 
 
In  addition  to  this  parameter,  locate  the  “Default  Inter-­‐Presence  Group  Subscription”  parameter  under  
the  “Clusterwide  Parameters  (System  -­‐  Presence)”  section.  Set  the  value  to  “Allow  Subscription”  in  
order  to  ensure  the  presence  information  passes  successfully  between  groups,  if  configured.  This  
parameter  will  not  “make  or  break”  the  configuration  at  the  moment,  but  can  be  set  as  an  “insurance  
policy”  should  Presence  Groups  be  configured  in  the  future.  
 

 
 
Click  the  Save  button  to  apply  the  configuration.  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     762  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  configure  a  UC  Service  and  Service  Profile  on  CUCM  in  order  to  connect  to  the  SB  IM&P  
server.  Navigate  to  User  Management  !  User  Settings  !  UC  Service  and  click  the  Add  New  button.  In  
the  “UC  Service  Type”  dropdown  box,  select  “IM  and  Presence”  and  click  the  Next  button.  
 

 
 
Next,  enter  a  descriptive  “Name”  for  the  UC  Service  (e.g.  “SB_IMP”)  and  enter  the  “Host  Name/IP  
Address”  of  the  SB  IM&P  server  (10.10.23.15).  Click  the  Save  button  when  complete.    
 

 
 
Next,  create  the  Service  Profile  by  navigating  to  User  Management  !  User  Settings  !  Service  Profile  
and  clicking  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  profile  (e.g.  “IMP_SP”).  
 

 
 
Next,  under  the  “IM  and  Presence  Profile”  section,  select  the  “SB_IMP”  service  from  the  “Primary”  
dropdown  box  and  click  the  Save  button  to  complete  the  configuration.  
 

 
 
Next,  navigate  to  User  Management  !  End  User  and  click  on  one  of  the  users  that  should  be  imported  
into  the  IM&P  server.  Under  the  “Service  Settings”  section,  ensure  that  the  “Enable  User  for  Unified  
CM  IM  and  Presence  (Configure  IM  and  Presence  in  the  associated  UC  Service  Profile)”  checkbox  is  
selected  and  the  “IMP_SP”  option  is  selected  from  the  “UC  Service  Profile”  dropdown  box.  
 

 
 
Click  the  Save  button  when  complete.  Perform  this  task  for  both  users  in  the  system.  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     763  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Now  that  the  SB  CUCM  cluster  has  been  configured,  we  must  configure  the  SB  IM&P  server  to  
integrate  with  the  SB  CUCM  cluster.  To  begin  the  configuration  of  the  SB  IM&P  server,  navigate  to  the  
IP  address  of  10.10.23.15  using  a  web  browser.  
 

 
 
Click  the  “Cisco  Unified  Communications  Manager  IM  and  Presence”  link  to  continue.  At  this  point,  the  
server  will  prompt  for  a  username  and  password.  Enter  the  credentials  as  admin/cciecollab  and  click  
the  Login  button  to  continue.  
 

 
 
Upon  login,  you  should  be  greeted  with  the  “Post  Install  Setup”  screen,  which  will  assist  in  configuring  
the  integration  to  the  SB  CUCM  cluster.  Provide  the  “Hostname”  of  the  SB  CUCM  server  as  well  as  the  
“IP  address”  and  click  the  Next  button  to  continue.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     764  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

The  next  screen  prompts  for  the  AXL  username  and  password  on  the  SB  CUCM  cluster.  This  
information  is  necessary  to  collect  user  and  system  level  information  from  CUCM.  You  may  specify  the  
username  and  password  of  admin/cciecollab  here.  Click  the  Next  button  to  continue.  
 

 
 
Next,  the  “Security  Password”  is  required  in  order  for  the  SB  IM&P  server  to  become  a  de-­‐facto  
member  of  the  SB  CUCM  cluster.  Essentially,  this  is  providing  direct  access  to  the  CUCM  database.  
Enter  the  password  of  “cciecollab”  and  click  the  Next  button  to  continue.  
 

 
 
As  the  last  step,  verify  that  the  entered  information  is  complete  and  click  the  Confirm  button.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     765  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

After  the  Post  Install  Setup  has  completed,  click  the  Topology  button  to  continue  to  the  system  
configuration.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     766  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 50.2 Ensure  that  the  SB  IM&P  server  communicates  with  all  other  servers  using  the  IP  
address  and  not  the  hostname.  
 
With  the  initial  set  up  of  the  SB  IM&P  server  completed,  we  can  now  move  on  to  perhaps  the  most  
important  part  of  the  configuration—changing  the  hostname  to  an  IP  address.  I  rank  the  importance  of  
this  configuration  very  high  because  if  it  is  not  done  correctly,  it  can  cause  major  issues  down  the  road.  
 
After  logging  into  the  server,  navigate  to  System  !  Cluster  Topology  to  get  the  system  overview.  
Below  the  name  of  the  server  (SBIMP),  click  the  “Edit”  link  to  change  the  configuration.  
 

 
 
Replace  the  server  name  (SBIMP)  in  the  “Fully  Qualified  Domain  Name/IP  Address”  textbox  with  the  IP  
address  of  the  server  (10.10.23.15)  and  click  the  Save  button.  
 

 
 
That  wasn’t  so  bad  was  it?    Changing  the  IP  address  was  pretty  easy!    Not  so  fast,  my  friends.  The  last  
thing  that  we  need  to  do  for  this  change  to  take  full  effect  is  to  REBOOT  the  server.  If  this  step  is  left  
out  or  forgotten,  you  will  never  get  this  integration  to  work  correctly.  Changing  the  hostname  of  the  
server  causes  a  great  deal  of  internal  confusion  within  the  IM&P  server.  Once  again,  make  sure  to  
REBOOT  after  this  change  is  made.  
 
To  reboot  the  server,  SSH  into  10.10.23.15  and  issue  the  utils system restart  command  from  
the  admin:  prompt.  You  should  regain  access  to  the  web  interface  within  about  5  minutes.  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     767  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
SB-­‐IMP  
ssh -l admin 10.10.23.15
admin@10.10.23.15's password:
Command Line Interface is starting up, please wait ...

Welcome to the Platform Command Line Interface

VMware Installation:
2 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
Disk 2: 80GB
4096 Mbytes RAM

admin:utils system restart

Do you really want to restart ?

Enter (yes/no)? yes

Appliance is being Restarted ...


Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...  


 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     768  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 50.3 Ensure  that  the  domain  is  set  to  cucm.com  for  all  IM&P  communication.  
 
The  domain  setting  within  IM&P  can  be  a  little  tricky  to  configure.  Unfortunately,  you  cannot  just  
configure  the  setting  and  go  on  your  merry  way.  You  must  first  ensure  that  the  following  services  are  
completely  stopped.  
 
• Cisco  SIP  Proxy  
• Cisco  Presence  Engine  
• Cisco  XCP  Router  
 
If  the  server  is  being  configured  for  the  first  time,  chances  are  that  the  services  are  all  deactivated.  
Unfortunately,  however,  the  Cisco  XCP  Router  service  is  configured  to  be  automatically  activated  and  
must  be  manually  stopped  to  continue.  To  shutdown  the  service,  navigate  to  Cisco  Unified  IM  and  
Presence  Serviceability  in  the  “Navigation”  dropdown  box  and  click  the  Go  button.  
 

 
 
From  the  Cisco  Unified  IM  and  Presence  Serviceability  webpage,  navigate  to  Tools  !  Control  Center  -­‐  
Network  Services  and  select  the  Cisco  XCP  Router  service  under  the  “IM  and  Presence  Services”  
section.  
 

 
 
Click  the  Stop  button  to  temporarily  turn  off  the  service.  When  the  operation  has  completed,  a  status  
will  be  displayed  regarding  the  service  at  the  top  of  the  window.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     769  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

With  all  three  services  now  stopped,  return  back  to  Cisco  Unified  CM  IM  and  Presence  Administration  
and  navigate  to  System  !  Cluster  Topology  and  click  the  “Settings”  gear  icon.  
 

 
 
At  this  menu,  we  can  now  change  the  “Cluster-­‐Wide  Topology  Settings”  to  update  the  domain.  Set  the  
“Cluster  ID”  parameter  to  use  the  hostname  of  the  server  (e.g.  “SBIMP”)  and  enter  the  “IM  and  
Presence  Domain”  to  the  required  value  of  “cucm.com”.    
 

 
 
Click  the  Save  button  when  complete.  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     770  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 50.4 Activate  all  services  and  configure  any  remaining  IM&P  settings  on  the  SB  IM&P  
server.  Test  the  configuration  by  sending  instant  messages  between  both  SB  Jabber  
clients.  
 
With  both  the  CUCM  and  IM&P  servers  configured  it  is  now  necessary  to  activate  all  services  by  
navigating  to  Cisco  Unified  IM  and  Presence  Serviceability  !  Tools  !  Service  Activation.  Click  the  
“Check  All  Services”  option  and  click  the  Save  button  to  continue.    
 

 
 
Now  that  the  services  have  been  activated,  return  to  the  Cisco  Unified  CM  IM  and  Presence  
Administration  page  and  navigate  to  System  !  Cluster  Topology.  You  should  now  see  users  assigned  to  
the  server.  
 

 
 
To  configure  the  remaining  pieces  of  the  integration,  navigate  to  Presence  !  Gateways  and  click  the  
Add  New  button.  Enter  the  information  for  the  SB  CUCM  cluster  here  in  order  to  allow  presence  
communication  between  systems.  Click  the  Save  button  when  complete.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     771  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  Presence  !  Routing  !  Settings  to  configure  the  Preferred  Proxy  Listener.  Since  we  
have  configured  a  SIP  trunk  to  IM&P,  we  should  select  the  “Default  Cisco  SIP  Proxy  TCP  Listener”.  Click  
the  Save  button  to  complete  the  configuration.  
 

 
 
Following  the  save,  click  the  Restart  All  Proxy  Services  button  to  refresh  the  Cisco  SIP  Proxy  service.  
 

 
 
At  this  time,  you  should  be  able  to  log  into  a  Cisco  Jabber  client  and  send  instant  messages  between  
users.  Open  an  RDP  session  to  PCs  at  both  10.10.13.17  (HQ  Test  PC)  and  10.10.23.17  (SB  Test  PC).  From  
there,  launch  the  Jabber  client  by  right  clicking  on  the  Jabber  desktop  icon  and  selecting  the  “Run  as  
Administrator”  option.  This  will  ensure  that  the  proper  privileges  are  used  when  using  the  client.  
 

 
 
Once  the  Jabber  client  launches,  click  the  “Manual  setup  and  sign-­‐in”  link  below  the  Sign  In  button.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     772  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Ensure  that  the  “Cisco  IM  &  Presence”  radio  button  is  selected  and  the  “Server  address”  is  entered  as  
“10.10.23.15”.  Click  the  Save  button  when  complete.  
 

 
 
Next,  sign  into  the  Jabber  client  with  the  username  and  password  of  one  of  the  configured  users  in  the  
system  (e.g.  sbp1/cisco).    
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     773  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

After  signing  in,  the  username  and  domain  should  be  displayed  along  with  the  presence  status  of  the  
client.  
 

 
 
Sign  in  with  the  other  SB  account  (e.g.  sbp2/cisco)  on  the  SB  test  PC.  
 

 
 
On  one  of  the  Jabber  clients,  add  a  contact  by  navigating  to  File  !  New  !  Custom  contact.  
 

 
 
Enter  the  “Display  Name”,  “Chat  (IM  address)”,  and  “Add  to”  (Category)  for  the  contact  and  click  the  
Create  button.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     774  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Now  double  click  the  name  of  the  contact  to  send  a  test  instant  message  between  the  two  Jabber  
clients.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     775  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 50.5 Ensure  that  SB  Jabber  users  can  make  calls  directly  from  the  client  as  well  as  the  
deskphone  of  the  user  (via  Jabber).  Ensure  that  the  Jabber  client  supports  URI  
dialing,  CUCM  directory  lookups,  and  video  calling.  
 
This  task  specifically  will  focus  on  Jabber  Deskphone  Control.  In  order  to  successfully  control  a  CUCM-­‐
registered  phone  using  the  Jabber  client,  we  must  configure  CTI  control  of  that  phone  from  the  End  
User  account.  Similar  to  the  way  in  which  the  CUE/CUCM  Voice  Mail  or  UCCX  integration  works,  we  
must  utilize  CTI  to  control  interactions  between  the  two  servers  with  some  type  of  user  account.  
 
To  begin  the  configuration,  we  must  create  UC  Services  for  CTI  and  allocate  them  to  the  existing  
Service  Profile  assigned  to  each  End  User.  Navigate  to  User  Management  !  User  Settings  !  UC  
Service  and  click  the  Add  New  button.  Select  the  “UC  Service  Type”  as  “CTI”  from  the  dropdown  box  
and  click  the  Next  button.  
 

 
 
Add  a  descriptive  “Name”  for  the  service  (e.g.  “SB_PUB_CTI”)  as  well  as  the  “Host  Name/IP  Address”  of  
the  corresponding  CUCM  server  at  SB  (e.g.  “10.10.23.11”).  Click  the  Save  button  when  complete.  
 

 
 
Next,  update  the  Service  Profile  by  navigating  to  User  Management  !  User  Settings  !  Service  Profile  
and  clicking  the  Find  button.  Click  on  the  existing  Service  Profile  (e.g.  “IMP_SP”)  to  edit  the  
configuration.  Under  the  “CTI  Profile”  section,  assign  the  previously  created  CTI  service  to  the  profile  
and  click  the  Save  button.    
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     776  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  navigate  to  User  Management  !  End  User  to  enable  CTI  for  each  IM&P  user.  Click  on  one  of  the  
users  (e.g.  “sbp1”)  and  scroll  to  the  “Device  Information”  section.  In  the  “Controlled  Devices”  list  box,  
make  sure  that  the  corresponding  phone  is  listed  (this  was  configured  in  previous  labs).  If  there  is  no  
phone  listed,  add  it  by  clicking  the  Device  Association  button.  
 

 
 
Next,  click  the  Line  Appearance  Association  for  Presence  button.  This  will  launch  a  new  window  that  
will  prompt  the  selection  of  lines  to  be  associated  with  the  End  User.  Once  a  line  is  associated,  
presence  status  for  that  line  can  be  shared  with  the  SB  IM&P  server.  
 

 
 
Click  the  Save  button  to  apply  the  configuration  and  return  to  the  End  User  page.  
 
Next,  scroll  to  the  “Permissions  Information”  section  and  click  the  Add  to  Access  Control  Group  
button.  In  the  new  window,  select  the  “Standard  CCM  End  Users”  and  “Standard  CTI  Enabled”  
permissions.  If  the  associated  End  User  phone  is  a  9971,  you  must  also  add  the  “Standard  CTI  Allow  
Control  of  Phones  supporting  Connected  Xfer  and  conf”  in  order  for  CTI  control  to  work  properly.    
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     777  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Add  Selected  button  to  save  the  configuration  and  return  to  the  End  User  page.  Click  the  Save  
button  on  the  End  User  page  to  save  the  configuration  for  the  End  User.  Update  the  other  SB  user  in  
the  same  fashion  to  ensure  that  CTI  deskphone  control  can  be  enabled  and  presence  status  can  be  
shared.  
 
Next,  we  must  configure  the  SB  IM&P  server  to  allow  deskphone  control  for  each  user.  From  the  Cisco  
Unified  CM  IM  and  Presence  Administration  webpage,  navigate  to  Application  !  Legacy  Clients  !  
Settings  and  enter  the  IP  Address  of  “Primary  TFTP  Server”  (e.g.  “10.10.23.11”).  You  may  have  noticed  
the  note  at  the  top  of  the  page:  “The  Proxy  Listener  is  only  applicable  to  SIP  Clients;  it  does  not  apply  to  
Cisco  Jabber  8.x."  The  TFTP  Servers  apply  to  Cisco  Jabber  8.x  and  previous  clients.”    This  is  rather  
confusing  because  these  settings  are  an  absolute  requirement  for  CTI  deskphone  control  (and  
softphones)  to  function  properly  in  our  version  of  Jabber  (9.7).  Moral  of  the  story—ignore  the  note  and  
configure  the  settings.  Click  the  Save  button  when  complete.  
 

 
 
Next,  configure  the  CTI  hosts  by  navigating  to  Application  !  Legacy  Clients  !  CCMCIP  Profile  and  
clicking  the  Add  New  button.  Enter  a  descriptive  “Name”  for  the  profile  (e.g.  “SB_CCMCIP”)  and  enter  
the  IP  addressing  information  for  the  “Primary/Backup  CCMCIP  Host”.  Next,  click  the  Add  Users  to  
Profile  button  and  select  the  users  that  should  have  deskphone  control  enabled.  Click  the  Save  button  
when  complete.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     778  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

At  this  point,  log  in  to  the  Jabber  client  for  both  users  with  the  HQ  and  SB  test  PCs.  You  should  see  the  
phone  icon  at  the  bottom  right  hand  corner  of  the  client  that  allows  deskphone  control.  Make  a  few  
calls  to  test  the  feature.  Note  that  the  presence  status  within  Jabber  has  changed  when  on  a  call.    
 

 
 
Next,  we  must  configure  a  softphone  for  the  Jabber  client  in  addition  to  the  previously  enabled  
Deskphone  Control.  To  do  this,  we  must  create  a  new  Client  Services  Framework  (CSF)  device  within  
the  SB  CUCM  cluster  and  associate  it  with  the  End  User.  
 
Navigate  to  Device  !  Phone  and  click  the  Add  New  button.  Select  the  “Cisco  Unified  Client  Services  
Framework”  option  from  the  “Phone  Type”  dropdown  box  and  click  the  Next  button.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     779  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Enter  the  “Device  Name”  with  the  prefix  of  “CSF”  followed  by  the  username  of  the  End  User  (e.g.  
“CSFsbp1”)  and  assign  an  appropriate  “Device  Pool”  for  the  device  (e.g.  “SB_PHONE_DP”).  Assign  a  
“Calling  Search  Space”  to  the  device  as  well  (e.g.  “PHONE_CSS”)  and  click  the  Save  button  when  
complete.  
 

 
 
Next,  click  the  “Line  [1]  -­‐  Add  a  new  DN”  link  under  the  “Association  Information”  section  to  associate  a  
line  with  the  CSF  device.  Enter  the  “Directory  Number”  and  “Partition”  for  the  CSF  device  on  the  
Directory  Number  Configuration  page.  This  should  be  the  same  DN/Partition  used  for  the  user’s  
physical  phone  (e.g.  “2001/INTERNAL_PT”).    
 

 
 
Next,  scroll  down  to  the  “Line  1  on  Device  CSFsbp1”  section  and  enter  the  Display  (Caller  ID)  of  the  
device.  
 

 
 
Finally,  scroll  down  to  the  bottom  of  the  page  and  click  the  Associated  End  Users  button.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     780  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  popup  window,  select  a  user  (e.g.  “sbp1”)  and  click  the  Add  Selected  button  to  associate  the  
user.  This  will  allow  the  sharing  of  presence  status  when  the  CSF  device  is  used.  
 

 
 
Click  the  Save  and  Apply  Config  buttons  to  save  the  configuration.  
 
Next,  we  must  associate  the  newly  configured  CSF  device  with  the  End  User.  Navigate  to  User  
Management  !  End  User  and  click  on  the  “sbp1”  user.  Under  the  “Device  Information”  section,  click  
the  Device  Association  button  and  select  the  newly  created  CSF  device.  
 

 
 
Click  the  Save  Selected/Changes  button  to  save  the  configuration.  
 
The  “Controlled  Devices”  list  box  for  the  End  User  should  now  be  updated  to  reflect  the  changes.  
 

 
 
Make  sure  to  perform  all  required  CUCM  configuration  for  the  other  user  at  SB  as  well.  
With  the  configuration  complete,  log  into  the  Jabber  client  for  both  users  with  the  HQ  and  SB  test  PCs.  
You  should  now  see  the  square  phone  icon  at  the  bottom  right  hand  corner  of  the  client  as  an  available  
audio  communication  option  (in  addition  to  the  Deskphone  Control  option).    
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     781  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Make  a  few  calls  with  the  softphone  to  test  the  feature.  The  audio  should  be  played  through  the  
computer  speakers  for  the  call.    
 

 
 
Now  that  the  Jabber  client  is  set  up  for  both  softphone  and  deskphone  mode,  we  must  configure  the  
client  to  support  URI  Dialing  and  CUCM  Directory  Lookups.  In  order  to  accomplish  this,  we  must  create  
the  “jabber-­‐config.xml”  file  using  the  “Cisco  Jabber  for  Windows  9.7  Installation  and  Configuration  
Guide”  available  on  cisco.com.  Use  the  previous  lab  as  a  guide  for  the  documentation  if  you  are  not  
familiar  with  the  file.  The  final  “jabber-­‐config.xml”  file  should  appear  as  shown  below.  
 

 
 
With  the  file  created,  upload  it  to  the  TFTP  server  in  the  SB  CUCM  cluster  and  restart  the  “Cisco  TFTP”  
service  to  apply  the  changes,  as  detailed  in  the  previous  lab.  This  will  allow  the  Jabber  client  to  
download  the  newly  created  configuration  file  and  load  it  upon  logging  in.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     782  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Shut  down  the  Jabber  client  and  re-­‐launch  it.  Log  in  again  using  the  username  and  password  of  an  SB  
user.  Test  the  URI  dialing  and  directory  lookup  functionality.  
 

 
 

 
 
In  order  for  the  Jabber  client  to  make  video  calls,  the  first  thing  that  is  necessary  is  to  have  a  camera  
connected  to  the  system.  Unfortunately,  at  the  time  of  the  writing  of  this  document,  cameras  were  not  
available  on  the  test  PCs  for  use  with  the  Jabber  client.  In  order  to  test  video  calls,  you  must  install  
Jabber  on  a  PC  or  laptop  that  makes  use  of  a  camera.    
 
Other  than  a  camera  being  installed,  we  must  ensure  that  the  CUCM  CSF  device  supports  video  calling.  
Navigate  to  Device  !  Phone  and  click  on  one  of  the  created  CSF  devices  in  the  system  (e.g.  
“CSFsbp1”).  Under  the  “Product  Specific  Configuration  Layout”  section,  make  sure  that  the  “Video  
Calling”  parameter  is  set  to  “Enabled”,  which  should  be  the  case,  by  default.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     783  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Log  in  to  the  Jabber  client  and  ensure  that  video  calling  works  by  making  a  test  call  to  HQ  Phone  1  or  
SC  Phone  2.  The  example  below  displays  the  Apple  version  of  the  Jabber  client  on  a  video  call.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     784  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 51: Federation


Task 51.1 Configure  an  XMPP  federation  between  the  HQ  IM&P  and  SB  IM&P  clusters.  
 
In  the  previous  labs,  only  one  IM  and  Presence  server  was  utilized  in  conjunction  with  a  CUCM  server  
to  provide  softphone  and  deskphone  services,  along  with  instant  messaging  capability.  Configuring  an  
XMPP  federation  will  allow  the  sending  and  receiving  of  instant  messages  between  clients  connected  
to  two  separate  IM&P  servers.  Dialing  functionality  within  the  Jabber  client  will,  of  course,  still  utilize  
the  CUCM  dial  plan  to  route  calls,  but  instant  messages  between  servers  will  use  the  XMPP  federation.  
 
The  first  step  in  configuration  is  to  log  into  the  HQ  and  SB  IM&P  servers  and  configure  the  XMPP  
federation  settings.  Navigate  to  Presence  !  Inter-­‐Domain  Federation  !  XMPP  Federation  !  Settings  
to  reach  the  “XMPP  Federation  Settings”  page.  Set  the  “XMPP  Federation  Node  Status”  dropdown  box  
to  “On”  to  enable  it.  Next,  select  the  “Security  Mode”  as  “No  TLS”  to  avoid  certificate  issues.  Last,  set  
the  “Dialback  Secret”  for  the  connection.  The  remote  server  “Dialback  Secret”  must  match  what  is  
configured  here  for  the  federation  to  work  properly.  Click  the  Save  button  when  complete.  
 

 
 
The  next  step  is  to  start  the  XMPP  Federation  Connection  Manager  service  to  enable  the  federation.  
Navigate  to  Cisco  Unified  IM  and  Presence  Serviceability  and  click  the  radio  button  for  the  “Cisco  XCP  
XMPP  Federation  Connection  Manager”  service.    
 

 
 
   

785 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Start  button  to  activate  the  service.    


 

 
 
Once  the  service  has  been  activated,  the  below  status  message  should  be  received.  
 

 
 
Make  sure  that  each  task  has  been  performed  on  both  the  HQ  and  SB  IM&P  servers.    
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     786  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 51.2 Ensure  that  the  DNS  server  is  configured  correctly  to  support  this  configuration.  
 
After  the  configuration  has  been  performed  on  the  IM&P  server,  a  DNS  server  must  be  configured  to  
support  the  XMPP  federation.  The  DNS  server  will  act  to  resolve  requests  for  the  XMPP  Service  for  each  
of  the  IM&P  servers.  It  will  return  an  IP  address  to  the  requesting  server  that  can  be  used  to  connect  to  
the  remote  IM&P  server.  
 

 
 
To  configure  the  DNS  server,  start  an  RDP  session  to  the  Windows  server  at  10.10.13.16  and  login  with  
the  administrator/ccieCollab1  credentials.  After  logging  in,  navigate  to  Start  !  All  Programs  !  
Administrative  Tools  !  DNS  to  the  load  the  “DNS  Manager”  console.  
 

 
 
Right  click  on  the  “Forward  Lookup  Zones  folder”  and  click  the  “New  Zone...”  option.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     787  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Next  button  to  continue  in  the  “New  Zone  Wizard”.  Ensure  that  “Primary  Zone”  is  selected  
and  click  the  Next  button  to  continue.  
 

 
 
Next,  leave  the  default  option  of  “To  all  DNS  servers  running  on  domain  controllers  in  this  domain:  
ipexpert.com”  selected  and  click  the  Next  button.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     788  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  define  the  “Zone  Name”  as  “cucm.com”  and  click  the  Next  button.  
 

 
 
Next,  leave  the  default  option  of  “Allow  only  secure  dynamic  updates”  selected  and  click  the  Next  
button  to  continue.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     789  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  next,  screen,  click  the  Finish  button  to  complete  the  wizard.  
 

 
 
After  creating  the  “cucm.com”  zone,  the  “Forward  Lookup  Zones”  folder  should  appear  as  shown  
below.  
 

 
 
Next,  right  click  on  the  Reverse  Lookup  Zones  folder  and  select  the  “New  Zone...”  option.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     790  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Next  button  to  begin  the  “New  Zone  Wizard”.  Keep  the  default  option  of  “Primary  zone”  
selected  and  click  the  Next  button  to  continue.    
 

 
 
Next,  keep  the  default  option  of  “To  all  DNS  servers  running  on  domain  controllers  in  this  domain:  
ipexpert.com”  selected  and  click  the  Next  button  to  continue.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     791  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  select  the  “IPv4  Reverse  Lookup  Zone”  option  and  click  the  Next  button  to  continue.  
 

 
 
Next,  define  the  network  ID  of  the  Reverse  Lookup  Zone.  Since  this  record  is  being  created  for  the  
“ipexpert.com”  domain  (at  HQ),  the  “Network  ID”  should  be  specified  as  “10.10.13”.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     792  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  leave  the  default  option  of  “Allow  only  secure  dynamic  updates”  selected  and  click  the  Next  
button  to  continue.  
 

 
 
Click  the  Finish  button  to  confirm  the  configuration  and  save  it.  
 

 
 
Create  a  “Reverse  Lookup  Zone”  for  the  SB  Network  ID  of  “10.10.23”  as  well.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     793  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  click  on  the  “ipexpert.com”  folder  under  “Forward  Lookup  Zones”.  Locate  the  existing  “ldap”  
record  and  double  click  it.  Check  the  “Update  associated  pointer  (PTR)  record”  box  and  click  the  OK  
button.  This  will  create  a  PTR  record  in  the  “10.10.13”  Reverse  Lookup  zone  for  the  “ldap”  Host  (A)  
record.    
 

 
 
To  view  the  created  record,  right  click  on  the  “13.10.10.in-­‐addr.arpa”  folder  under  “Reverse  Lookup  
Zones”  and  select  the  “Refresh”  option  from  the  dropdown  menu.  
 

 
 
You  should  now  see  the  PTR  record  listed  within  the  folder.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     794  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  click  on  the  “ipexpert.com”  folder  under  “Forward  Lookup  Zones”,  right  click  within  the  white  
space  of  the  folder,  and  select  the  “New  Host  (A  or  AAAA)...”  option  from  the  dropdown  menu.  
 

 
 
Enter  a  “Name”  for  the  HQ  IM&P  server  (e.g.  “hqimp”)  and  enter  the  corresponding  IP  address  
(“10.10.13.15”).  Check  the  “Create  associated  pointer  (PTR)  record”  box  to  create  a  PTR  record  in  the  
“10.10.13”  Reverse  Lookup  Zone.  
 

 
 
Create  the  “sbimp”  Host  (A)  record  in  the  “cucm.com”  domain  as  well.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     795  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  click  on  the  “ipexpert.com”  domain,  right  click  within  the  white  space  of  the  folder,  and  select  
the  “Other  New  Records...”  option  from  the  menu.  
 

 
 
Scroll  through  the  list  of  records  and  select  the  “Service  Location  (SRV)”  record.    
 

 
 
Click  the  Create  Record...  button  to  continue.  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     796  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  “New  Resource  Record”  window,  enter  the  “Service”  as  “_xmpp-­‐server”  and  the  “Protocol”  as  
“_tcp”.  The  “Port  Number”  should  be  entered  as  “5269”  and  the  “Host  Offering  this  service”  should  
correspond  to  the  recently  created  hostname  of  the  HQ  IM&P  server  (e.g.  “hqimp.ipexpert.com”).  Click  
the  OK  button  when  complete.  
 

 
 
Create  the  SRV  record  for  SB  IM&P  server  within  the  “cucm.com”  domain  as  well.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     797  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

From  one  of  the  test  PCs,  launch  a  command  prompt  by  opening  the  Start  Menu  and  typing  cmd  at  the  
“Search  Programs  and  Files”  prompt.  Type  the  nslookup  command  to  enter  the  DNS  server  
resolution  mode.  Type  the  set type=srv  command  to  look  specifically  for  “Service  Location”  
records.  Next,  type  the  hostname  of  the  HQ  IM&P  XMPP  service  (“_xmpp-­‐server._tcp.ipexpert.com”).  
The  command  should  return  the  hostname  of  the  HQ  IM&P  server  as  well  as  the  corresponding  IP  
address.  Make  sure  that  the  same  can  be  done  for  the  SB  IM&P  XMPP  service.  
 
HQ  TPC1  Command  Prompt  
C:\Users\admin>nslookup
Default Server: ldap.ipexpert.com
Address: 10.10.13.16

> set type=srv


> _xmpp-server._tcp.ipexpert.com
Server: ldap.ipexpert.com
Address: 10.10.13.16

_xmpp-server._tcp.ipexpert.com SRV service location:


priority = 0
weight = 0
port = 5269
svr hostname = hqimp.ipexpert.com
hqimp.ipexpert.com internet address = 10.10.13.15

> _xmpp-server._tcp.cucm.com
Server: ldap.ipexpert.com
Address: 10.10.13.16

_xmpp-server._tcp.cucm.com SRV service location:


priority = 0
weight = 0
port = 5269
svr hostname = sbimp.cucm.com
sbimp.cucm.com internet address = 10.10.23.15
 
The  required  DNS  configuration  is  now  complete.  The  next  step  is  to  configure  both  the  HQ  and  SB  
IM&P  servers  to  resolve  hostnames  using  the  newly  configured  server  at  10.10.13.16.  SSH  into  each  
server  and  use  the  set network dns  and  set network domain  commands  to  configure  the  
server.  
 
HQ-­‐IMP  
ssh -l admin 10.10.13.15
admin@10.10.13.15's password:
Command Line Interface is starting up, please wait ...

Welcome to the Platform Command Line Interface

VMware Installation:
1 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
2048 Mbytes RAM

admin:set network dns primary 10.10.13.16

WARNING: Changing this setting will invalidate software license


on this server. The license will have to be re-hosted.
Continue(y/n):
Continue (y/n)?y

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     798  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

*** R E M I N D E R ***
The DNS domain is not set. Please configure the DNS domain after DNS server configuration

*** W A R N I N G ***
This will cause the system to temporarily lose network connectivity

Continue (y/n)?y

trying to restart network...

admin:set network domain ipexpert.com

*** W A R N I N G ***
Adding/deleting or changing domain name on this server will break
database replication. Once you have completed domain modification
on all systems that you intend to modify, please reboot all the
servers in the cluster. This will ensure that replication keeps
working correctly. After the servers have rebooted, please
confirm that there are no issues reported on the Cisco Unified
Reporting report for Database Replication.

The server will now be rebooted. Do you wish to continue.

Security Warning : This operation will regenerate


all CUP Certificates including any third party
signed Certificates that have been uploaded.

Continue (y/n)?y

trying to restart system...

Warning: Restart could take up to 5 minutes...


 
SB-­‐IMP  
ssh -l admin 10.10.23.15
admin@10.10.23.15's password:
Command Line Interface is starting up, please wait ...

Welcome to the Platform Command Line Interface

VMware Installation:
2 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
Disk 2: 80GB
4096 Mbytes RAM

admin:set network dns primary 10.10.13.16

WARNING: Changing this setting will invalidate software license


on this server. The license will have to be re-hosted.
Continue(y/n):
Continue (y/n)?y

*** R E M I N D E R ***
The DNS domain is not set. Please configure the DNS domain after DNS server configuration

*** W A R N I N G ***
This will cause the system to temporarily lose network connectivity

Continue (y/n)?y

trying to restart network...

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     799  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

admin:set network domain cucm.com


*** W A R N I N G ***
Adding/deleting or changing domain name on this server will break
database replication. Once you have completed domain modification
on all systems that you intend to modify, please reboot all the
servers in the cluster. This will ensure that replication keeps
working correctly. After the servers have rebooted, please
confirm that there are no issues reported on the Cisco Unified
Reporting report for Database Replication.

The server will now be rebooted. Do you wish to continue.

Security Warning : This operation will regenerate


all CUP Certificates including any third party
signed Certificates that have been uploaded.

Continue (y/n)?y

trying to restart system...

Warning: Restart could take up to 5 minutes...


 
After  the  changes  to  the  DNS  server  and  Domain,  both  servers  will  reboot.  You  should  regain  access  to  
the  webpage  within  about  5  minutes.  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     800  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 51.3 Ensure  that  Jabber  clients  at  HQ  can  exchange  instant  messages  and  add  contacts  
with  Jabber  clients  at  SB  through  the  federation.  
 
With  both  IM&P  servers  and  the  DNS  server  configured,  we  should  now  be  able  to  add  contacts  to  the  
Jabber  clients  and  exchange  instant  messages.  Within  HQ  TPC1,  launch  the  Jabber  client  and  log  in  
using  the  account  of  an  HQ  user  (e.g.  “hqp1”).  On  SB  TPC1,  launch  the  Jabber  client  and  log  in  using  the  
account  of  an  SB  user  (e.g  “sbp1”).  From  the  HQ  Jabber  client,  navigate  to  File  !  New  !  Custom  
contact  to  add  a  contact  from  the  SB  site.  
 

 
 
Enter  a  “Display  Name”  for  the  contact  (e.g.  “Peter  Griffin  (sbp1)”)  and  enter  the  “Chat  (IM  address)”  
(e.g.  “sbp1@cucm.com”).  Click  the  Create  button  when  complete.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     801  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

When  the  contact  is  created  at  HQ,  the  SB  Jabber  client  should  receive  a  “Status  Request”  requesting  
permission  to  share  status  with  the  “hqp1”  user.  Optionally,  you  may  check  the  “Add  to  my  contact  
list”  box  to  automatically  add  “hqp1”  as  a  contact.  Click  the  Allow  button  to  continue.  
 

 
 
When  the  SB  Jabber  client  clicks  the  Allow  button,  the  HQ  Jabber  client  should  receive  a  “Status  
Request”  as  well.  Click  the  Allow  button  to  share  presence  information.  
 

 
 
The  presence  status  should  now  be  displayed  within  the  Jabber  client  on  each  site.  
 

 
 

 
 
You  can  always  change  the  Display  Name  of  the  contact,  if  so  desired.  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     802  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  double  click  the  name  of  the  contact  to  exchange  instant  messages.  
 

 
 
 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     803  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

   

CCIE  Collaboration  
Technology-­‐Focused  Detailed  Solution  Guide  
Section  Twelve  Labs  52  -­‐  54  
Version  1.0  

804 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Section 12: Configuring and Troubleshooting Unified Contact Center


Express
Lab 52: CUCM Integration
Task 52.1 Create  another  DN  for  UCCX  usage  on  line  2  of  all  HQ  phones.  Extensions  should  be  
in  the  range  1151  –  115X.  
 
We  have  the  ability  to  utilize  the  same  extension  that  is  currently  configured  on  Line  1  of  all  HQ  phones  
with  UCCX,  but  it  considered  “best  practice”  to  use  a  separate  extension.  Remember  though,  the  CCIE  
Lab  is  not  a  test  of  best  practices,  so  be  prepared  to  use  either  methodology!      
 
Navigate  to  Device  !  Phone  and  click  one  of  the  HQ  phones  (e.g.  “HQ  Phone  1”).  Click  the  “Line  [2]  -­‐  
Add  a  new  DN”  link  to  add  a  new  DN  to  the  existing  phone.    
 

 
 
Enter  the  “Directory  Number”  in  the  text  box  (e.g.  “1151”)  and  select  a  “Partition”  from  the  dropdown  
box  (e.g.  “INTERNAL_PT”).  Click  the  Save  and  Apply  Config  buttons  to  save  the  configuration.  
 

 
 
Configure  the  new  “Directory  Number”  (e.g.  “1152”)  for  “HQ  Phone  2”  as  well.  
 

 
 
Each  phone  should  be  updated  as  shown  below.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     805  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Task 52.2 Ensure  that  the  AXL,  CTI,  and  RmCm  Subsystems  are  configured  to  integrate  with  the  
HQ  CUCM.  
 
The  three  subsystems  defined  in  the  question  must  be  configured  on  the  HQ  UCCX  server  in  order  to  
integrate  with  the  HQ  CUCM  cluster.  The  AXL  subsystem  will  allow  access  for  UCCX  to  create,  modify,  
and  delete  configuration  elements  from  the  CUCM  system  as  well  as  gather  necessary  information  for  
the  server  to  operate.  The  CTI  subsystem  will  allow  the  control  of  UCCX  (CTI)  ports  as  well  as  UCCX  
Triggers  (CTI  Route  Points)  within  the  system.  Lastly,  the  RmCm  Subsystem  will  allow  the  management  
of  resources  within  UCCX.  
 
Within  the  Cisco  Unified  CCX  Administration  page,  navigate  to  System  !  Cisco  Unified  CM  
Configuration.  Move  the  two  HQ  servers  from  the  “Available  AXL  Service  Providers”  list  box  to  the  
“Selected  AXL  Service  Providers”  list  box.  Also,  enter  the  “User  Name”  and  “Password”  for  the  HQ  
CUCM  server  (e.g.  “admin/cciecollab”).  
 

 
 
Next,  move  the  two  HQ  servers  from  the  “Available  CTI  Managers”  list  box  to  the  “Selected  CTI  
Managers”  list  box.  Also,  enter  a  “User  Prefix”  (e.g.  “jtapi”)  to  be  created  on  the  HQ  CUCM  cluster  as  
well  as  a  “Password”  for  the  account.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     806  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     807  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  move  the  two  HQ  servers  from  the  “Available  CTI  Managers”  list  box  to  the  “Selected  CTI  
Managers”  list  box.  Also,  enter  the  “User  Id”  (e.g.  “rmcm”)  and  “Password”  to  be  created  on  CUCM.  
 

 
 
Click  the  Update  button  when  complete.  
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     808  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 52.3 Ensure  that  the  appropriate  users  are  created  on  CUCM  to  support  the  UCCX  
integration.  
 
After  the  UCCX  subsystems  are  configured,  login  to  the  HQ  CUCM  cluster  to  verify  that  the  users  
corresponding  to  those  subsystems  were  created  successfully.  Navigate  to  User  Management  !  
Application  User  and  click  the  Find  button.  The  two  accounts  created  by  the  UCCX  server  should  exist  
in  the  list.  
 

 
 
Click  on  the  “jtapi_1”  account  to  view  the  details.  Scroll  down  to  the  “Permissions  Information”  section  
and  note  the  assigned  group  of  “Standard  CTI  Enabled”.  This  exists  in  order  for  the  account  to  
eventually  control  the  UCCX  (CTI)  Ports  and  UCCX  Triggers  (CTI  Route  Points)  in  the  system.  
 

 
 
Next,  click  on  the  “rmcm”  account  and  scroll  down  to  the  “Permissions  Information”  section.  Once  
again,  the  “Standard  CTI  Enabled”  group  has  been  selected.  However,  since  this  user  exists  solely  to  
control  agent  phones,  we  must  add  another  group  specifically  to  support  the  9971  phones.  Click  the  
Add  to  Access  Control  Group  button  to  select  more  groups.  Check  the  box  for  the  “Standard  CTI  Allow  
Control  of  Phones  supporting  Connected  Xfer  and  conf”  group  and  click  the  Add  Selected  button.  
 

 
 
Click  the  Save  button  on  the  End  User  page  to  save  the  configuration.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     809  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 52.4 Ensure  that  UCCX  automatically  creates  CTI  Ports  on  the  HQ  CUCM.  
 
In  order  for  callers  to  connect  to  the  UCCX  system,  ports  need  to  exist  to  accept  and  place  calls.  The  
UCCX  server  will  automatically  create  these  ports  as  CTI  Ports  within  CUCM.  To  get  started,  log  into  the  
UCCX  server  and  navigate  to  Subsystems  !  Unified  CM  Telephony  !  Call  Control  Group  and  click  the  
Add  New  button.  Enter  a  short  “Description”  of  the  CTI  Port  (e.g.  “UCCX  CTI  Port”)  and  define  the  
“Number  of  Ports”  that  should  be  configured  in  the  system  (e.g.  “4”).  No  number  was  specified  in  the  
task,  so  any  number  of  ports  can  be  used  here.    
 

 
 
Next,  specify  a  “Device  Name  Prefix”  to  be  used  for  every  UCCX  port  in  the  system  (e.g.  “UCCX”).  
Specify  a  “Starting  Directory  Number”  as  well.  Nothing  was  defined  in  the  task  requirements,  so  any  
number  that  is  not  used  will  work  just  fine  (e.g.  “1101”).  This  will  create  CTI  ports  with  DNs  1101,  1102,  
1103,  and  1104  in  the  system.  Next,  select  an  appropriate  “Device  Pool”  from  the  dropdown  box  (e.g.  
“HQ_PHONE_DP”).  Please  note  that  UCCX  can  only  communicate  using  the  G.711  codec  by  default,  so  
use  a  Device  Pool  in  which  it  is  allowed  for  proper  functionality.  Enter  a  “Calling  Search  Space”  that  has  
access  to  the  UCCX  Pilot  number  (not  created  yet)  and  any  other  areas  of  the  system  deemed  
necessary  for  UCCX  access  (e.g.  “PHONE_CSS”).  Next,  select  a  “Partition”  in  which  the  configured  DNs  
can  reside.  In  this  example,  a  specific  Partition  called  “UCCX_PT”  was  selected.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     810  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  Show  More…  button  to  configure  additional  parts  of  the  CTI  Port.  Enter  the  “Alerting  Name  
ASCII”  field  as  “UCCX”  to  display  the  correct  Caller  ID  when  calling  other  users.  Next,  set  the  
“User/Network  Hold  Audio  Source”  to  select  a  specific  audio  file  to  use  (e.g.  “1-­‐SampleAudioSource”).  
Next,  set  the  “Display”  field  to  “UCCX”  as  well.  Finally,  if  entering  a  number  for  the  “External  Phone  
Number  Mask”  field,  be  careful  not  to  use  a  “+”  as  it  will  cause  problems  with  CTI  Port  registration.  
 

 
 
Click  the  Add  button  to  create  the  CTI  Ports  in  UCCX  and  CUCM.    
 

 
 
After  the  port  creation  is  complete,  within  the  HQ  CUCM  cluster,  navigate  to  Device  !  Phone  and  click  
the  Find  button.  You  should  see  the  CTI  Ports  for  UCCX  configured  and  registered.  
 

 
 
Next,  navigate  to  User  Management  !  Application  User  and  click  on  the  “jtapi_1”  user.  Now  listed  in  
the  “Controlled  Devices”  list  should  be  the  newly  created  UCCX  ports.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     811  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 52.5 When  dialing  the  number  1100,  it  should  trigger  a  UCCX  ICD  script  in  the  system.  
 
In  order  to  create  a  UCCX  Trigger  (CTI  Route  Point),  we  must  first  create  an  Application  with  which  the  
Trigger  can  be  associated.  Creating  a  basic  Application  can  allow  this  to  be  quickly  configured.  Within  
UCCX,  navigate  to  Applications  !  Application  Management  and  click  the  Add  New  button.  Select  the  
“Cisco  Script  Application”  from  the  “Application  Type”  dropdown  box  and  click  the  Next  button.  
 

 
 
Next,  specify  a  “Name”  for  the  Application  (e.g.  “ICD_SCRIPT”),  enter  a  “Maximum  Number  of  
Sessions”  (e.g.  “4”),  and  select  a  “Script”  from  the  dropdown  box  (e.g.  “SSCRIPT[icd.aef]”).  Click  the  
Add  button  to  create  the  script.  
 

 
 
After  the  script  has  been  created,  we  now  have  the  opportunity  to  create  a  Trigger  by  clicking  the  “Add  
a  new  trigger”  link  on  the  left  side  of  the  page.  
 

 
 
After  clicking  the  link,  a  new  window  will  launch  that  allows  configuration  of  the  Trigger.  Select  the  
“Unified  CM  Telephony  Trigger”  option  from  the  “Trigger  Type”  dropdown  box  and  click  the  Next  
button  to  continue.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     812  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  in  a  similar  fashion  to  the  Unified  CM  Telephony  Call  Control  Group  configuration,  we  must  
configure  the  device  and  directory  number  that  will  be  automatically  created  in  CUCM.  Enter  the  
“Directory  Number”  for  the  Trigger  as  “1100”,  as  defined  in  the  task  requirements.  
 

 
 
Next,  select  the  “Language”  that  should  be  used  for  the  Trigger  from  the  dropdown  box  (e.g.  “English  
(United  States)  [en_US]”).  A  descriptive  “Device  Name”  should  also  be  specified  for  the  Trigger  (e.g.  
“UCCX_TRIGGER”)  as  well  as  a  “Description”  (e.g.  “Trigger  for  UCCX”).  Lastly,  the  previously  created  
“Call  Control  Group”  should  be  specified,  in  order  to  take  advantage  of  the  CTI  Ports  for  the  integration  
(e.g.  “UCCX  CTI  Port  (5)”).    
 

 
 
Click  the  Show  More...  button  for  more  configuration  options.  
 
Under  the  “CTI  Route  Point  Information”  section,  enter  the  “Alerting  Name  ASCII”  as  “UCCX”  and  select  
an  appropriate  “Device  Pool”  for  the  Trigger  (e.g.  “HQ_PHONE_DP”).  Remember,  UCCX  only  uses  
G.711,  so  the  Region  setting  within  the  Device  Pool  must  allow  it.    
 

 
 
Next,  under  the  “Directory  Number  Settings”  heading,  select  a  “Partition”  from  the  dropdown  box  (e.g.  
“UCCX_PT”)  as  well  as  a  “Calling  Search  Space”  that  has  access  to  internal  extensions,  UCCX  Ports,  and  
anything  else  that  may  be  required  (e.g.  “PHONE_CSS”).  
 

 
 
When  configured,  click  the  Add  button  to  add  the  Trigger  to  the  UCCX  configuration.  

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     813  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

After  the  Trigger  has  been  added  within  UCCX,  we  must  verify  that  the  CTI  Route  Point  was  
automatically  created  within  CUCM.  Navigate  to  Device  !  CTI  Route  Point  in  the  HQ  CUCM  cluster  and  
click  the  Find  button.  You  should  see  a  CTI  Route  Point  name  “UCCX_TRIGGER”  registered  to  the  
cluster.  
 

 
 
Next,  navigate  to  User  Management  !  Application  User  and  click  the  “jtapi_1”  user.  Under  the  
“Device  Information”  section  in  the  “Controlled  Devices”  list  box,  make  sure  that  the  “UCCX_TRIGGER”  
is  now  listed  in  addition  to  the  UCCX  CTI  Ports.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     814  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 52.6 Configure  the  newly  created  extension  of  the  users  on  the  HQ  CUCM  cluster  to  
participate  as  resources  for  the  UCCX  server.  
 
In  order  to  configure  the  End  Users  to  participate  as  agents  in  the  UCCX  server,  we  must  navigate  to  
User  Management  !  End  User  within  the  HQ  CUCM  server  and  set  the  “IPCC  Extension”.  Locate  the  
“hqp1”  user  and  scroll  down  to  the  “Directory  Number  Associations”  section.  Set  the  “IPCC  Extension”  
to  the  newly  created  Directory  Number  for  the  phone  (e.g.  “1151  in  INTERNAL_PT”)  
 

 
 
Click  the  Save  button  when  complete.    
 
Make  sure  to  configure  the  same  for  the  “hqp2”  user.  
 

 
 
Next,  on  the  UCCX  server,  navigate  to  Subsystems  !  RmCm  !  Resources  and  ensure  that  the  
configured  users  are  displayed  as  resources  in  the  system.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     815  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 52.7 Ensure  that  all  UCCX  phones  are  configured  with  a  One-­‐Button  Login  to  the  UCCX  
system.  
 
Since  we  will  not  have  access  to  the  Cisco  Agent  Desktop  during  the  lab  exam,  we  must  configure  the  
deskphone  of  the  UCCX  Agent  to  login  to  the  server  using  the  One-­‐Button  Login  service.  This  will  
enable  the  user  to  simply  launch  the  service  from  the  phone  without  entering  any  authentication  
information.  A  very  detailed  set  of  procedures  for  configuration  (using  CCM  4.1  –  YES!)  can  be  found  at  
the  following  link,  which  is  accessible  during  the  lab  exam  through  the  Cisco  documentation:  
http://www.cisco.com/c/en/us/support/docs/voice-­‐unified-­‐communications/unified-­‐contact-­‐center-­‐
express/60134-­‐1-­‐button-­‐login-­‐ip-­‐phone-­‐agnts.html    
 
To  configure,  navigate  to  Device  !  Device  Settings  !  Phone  Services  on  the  HQ  CUCM  cluster  and  
click  the  Add  New  button.  Enter  the  “Service  Name”  for  the  One-­‐Button  Login  service  (e.g.  “UCCX  
OBL”).  Next,  enter  the  “Service  URL”  for  the  UCCX  server  (shown  below).    
http://10.10.13.13:6293/ipphone/jsp/sciphonexml/IPAgentLogin.jsp”    
 
This  is  the  address  to  which  the  phone  will  connect  when  the  button  is  pressed.  Next,  select  the  
“Enable”  checkbox  to  activate  the  service.  Click  the  Save  button  when  complete.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     816  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

After  the  service  is  created,  click  the  New  Parameter  button  under  the  “Service  Parameter  
Information”  section.  Enter  the  “Parameter  Name”  and  “Parameter  Display  Name”  as  “Ext”  and  enter  
the  “Parameter  Description”  as  “UCCX  Extension”.  Click  the  Save  button  when  complete.  
 

 
 
Click  the  Add  New  button  at  the  top  of  the  screen  to  add  another  parameter.  Enter  the  “Parameter  
Name”  and  “Parameter  Display  Name”  as  “ID”  and  enter  the  “Parameter  Description”  as  “UCCX  ID”.  
Click  the  Save  button  when  complete.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     817  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Once  again,  click  the  Add  New  button  at  the  top  of  the  screen  to  add  another  parameter.  Enter  the  
“Parameter  Name”  and  “Parameter  Display  Name”  as  “Pwd”  and  enter  the  “Parameter  Description”  as  
“UCCX  Password”.  Also,  make  sure  to  check  the  “Parameter  is  a  Password”  checkbox.  Click  the  Save  
and  Close  button  when  complete.  
 

 
 
Click  the  Save  button  on  the  “IP  Phone  Services  Configuration”  page  to  save  the  service  configuration.  
 
Next,  to  assign  the  service  to  phones  in  the  system,  navigate  to  Device  !  Phone  and  click  on  one  of  
the  HQ  phones  (e.g.  “HQ  Phone  1”).  Under  the  “Related  Links”  dropdown  box,  click  the  
“Subscribe/Unsubscribe  Services”  option  and  click  the  Go  button.  
 

 
 
Next,  in  the  “Select  a  Service”  dropdown  box,  select  the  newly  created  “UCCX  OBL”  service  and  click  
the  Next  button.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     818  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

On  the  next  screen,  enter  the  “Ext”  as  the  newly  created  UCCX  extension  for  the  phone  (e.g.  “1151”)  
along  with  the  “ID”  (e.g.  “hqp1”)  and  “Pwd”  (e.g.  “cisco”)  of  the  user.    
 

 
 
Click  the  Subscribe  button  when  complete.    
 
Repeat  the  same  steps  to  subscribe  the  “UCCX  OBL”  service  to  “HQ  Phone  2”  as  well.  
 

 
 
 
The  service  configuration  should  now  be  reflected  on  the  phone  screen  for  “HQ  Phone  1”  and  “HQ  
Phone  2”.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     819  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
The  last  step  in  the  configuration  is  to  associate  the  UCCX  Agent  devices  (phones)  with  the  “rmcm”  
Application  User.  This  will  allow  the  resources  to  log  in  and  participate  in  a  Contact  Service  Queue  
(CSQ).  Navigate  to  User  Management  !  Application  User  and  click  the  “rmcm”  user.  Add  the  MAC  
Addresses  of  “HQ  Phone  1”  and  “HQ  Phone  2”  to  the  “Controlled  Devices”  list  box  and  click  the  Save  
button.  
 

 
 
With  the  phones  successfully  associated  with  the  “rmcm”  user,  each  phone  should  now  have  the  ability  
to  login  using  the  UCCX  One-­‐Button  Login  service.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     820  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     821  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 53: ICD Functionality


Task 53.1 Configure  the  skills,  “Football”,  “Baseball”,  “Basketball”,  and  “Hockey”.  
 
Skills-­‐based  queuing  in  UCCX  takes  into  account  the  competency  of  the  agent  before  making  a  decision  
on  whether  or  not  to  include  that  agent  into  a  Contact  Service  Queue  (CSQ).  The  alternative  to  this  
mechanism  is  the  Resource  Group  based  model,  which  allows  the  administrator  to  manually  configure  
the  agents  that  will  participate  in  the  CSQ.  The  task  has  required  that  we  configure  the  above  skills  in  
order  to  support  the  Skills-­‐based  queuing  method.  
 
In  UCCX,  navigate  to  Subsystems  !  RmCm  !  Skills  and  click  the  Add  New  button.  Enter  the  name  of  
the  skill  in  the  “Skill  Name”  field  and  click  the  Save  button.  
 

 
 
Follow  this  procedure  for  all  skills  in  the  task  requirements.  
 

 
 
 
   

822 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 53.2 Ensure  that  hqp1  has  the  following  levels  of  proficiency  in  each  skill:    Football  –  5,  
Baseball  –  3,  Basketball  –  7,  Hockey  –  6.  
 
In  order  to  configure  the  proficiency  levels  for  each  resource,  we  must  navigate  to  Subsystems  !  
RmCm  !  Resources.  Click  on  the  name  of  the  resource  (e.g.  “Homer  Simpson”).  Within  the  “Resource  
Configuration”  page,  click  the  name  of  an  “Unassigned  Skill”  in  the  list  box  (e.g.  “Baseball”)  and  click  
the  arrow  to  move  it  to  the  “Assigned  Skills”  list  box.  
 

 
 
Next,  highlight  the  skill  and  set  the  “Competency  Level”  to  the  proper  level  for  the  user  (e.g.  “3”).  
 

 
 
Perform  the  same  steps  for  the  three  remaining  skills  and  click  the  Update  button  to  save  the  
configuration.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     823  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 53.3 Ensure  that  hqp2  has  the  following  levels  of  proficiency  in  each  skill:    Football  –  9,  
Baseball  –  7,  Basketball  –  3,  Hockey  –  4.  
 
Make  sure  that  the  same  procedures  as  detailed  in  the  previous  task  are  performed  to  assign  the  
proper  levels  of  proficiency  for  each  skill  to  the  “hqp2”  user.    
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     824  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 53.4 Name  the  CSQ  “Sports_CSQ”  and  ensure  that  the  minimum  competence  level  in  all  
configured  skills  allows  all  agents  to  qualify  for  the  CSQ.  
 
Next,  we  must  create  the  Contact  Service  Queue  (CSQ)  that  will  be  assigned  to  the  Application  in  the  
system  and  can  make  the  decision  on  which  agents  are  qualified  to  participate  in  the  queue.  Within  
UCCX,  navigate  to  Subsystems  !  RmCm  !  Contact  Service  Queues  and  click  the  Add  New  button.  
Enter  the  “Contact  Service  Queue  Name”  as  “Sports_CSQ”,  as  defined  in  the  task  requirements.  Next,  
make  sure  that  the  “Resource  Skills”  option  is  selected  from  the  “Resource  Pool  Selection  Model”  and  
click  the  Next  button  to  continue.  
 

 
 
On  the  next  screen,  select  all  skills  from  the  “Select  Required  Skills”  list  box  and  click  the  Add  button.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     825  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  enter  the  “Minimum  Competence”  level  for  all  of  the  listed  skills.  Remember,  both  HQ  agents  
must  be  able  to  participate  in  the  CSQ,  so  the  levels  must  be  set  in  order  for  this  to  happen.  
 

 
 
Click  the  Update  button  to  complete  the  configuration.  
 
On  the  “Contact  Service  Queues”  page,  we  can  see  the  name  of  the  CSQ,  the  Selection  Model,  and  the  
required  proficiency  levels  that  were  created.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     826  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 53.5 The  engine  should  send  every  agent  into  the  state  of  “Work”  for  15  seconds  before  
then  automatically  returning  to  a  state  of  “Ready”.  
 
This  task  requires  that  we  configure  the  system  to  send  the  UCCX  Agent  into  the  “Work”  state  for  15  
seconds  after  a  call  has  ended  in  order  to  perform  any  necessary  tasks  following  the  conversation.  
After  15  seconds  has  elapsed,  the  agent  should  automatically  transition  to  the  “Ready”  state.  
 
To  configure  this  feature,  we  must  edit  the  previously  created  CSQ  by  navigating  to  Subsystems  !  
RmCm  !  Contact  Service  Queues.  Click  on  the  “Sports_CSQ”  link  to  edit  the  configuration.  For  the  
“Automatic  Work”  setting,  select  the  “Enabled”  radio  button.  Following  a  call,  this  will  automatically  
place  the  agent  in  the  “Work”  state.  Next,  for  the  “Wrapup  Time”  setting,  select  the  “Enabled”  radio  
button  and  enter  a  value  of  15  “Seconds”.  This  will  place  the  agent  in  the  “Work”  state  for  15  seconds.  
 

 
 
Click  the  Next  button  to  continue.  On  the  next  page,  click  the  Update  button  to  save  the  CSQ.  
 
Next,  navigate  to  Subsystems  !  RmCm  !  Resources  and  click  on  one  of  the  agents  (e.g.  “Homer  
Simpson”).  Ensure  that  the  “Automatic  Available”  setting  has  been  set  to  “Enabled”.  If  the  setting  were  
“Disabled”,  the  agent  would  transition  to  a  “Not  Ready”  state  following  the  automatic  “Work”  period  
of  15  seconds.  Click  the  Update  button  to  save  the  configuration.    
 

 
 
Make  sure  that  the  same  step  is  performed  for  the  “hqp2”  UCCX  agent.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     827  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide  

Lab 54: UCCX Script Customization


Task 54.1 Open  the  default  “icd.aef”  script  and  save  a  copy  locally  on  the  machine  under  the  
name  “sports-­‐icd.aef”.    
 
To  configure  the  script  for  UCCX,  it  is  a  good  idea  to  start  with  a  previously  configured  script  or  
template  to  save  time  in  setting  everything  up.  In  this  case,  the  task  has  required  that  we  copy  the  
default  “icd.aef”  script  and  save  a  local  copy  using  the  “sports-­‐icd.aef”  name.  
 
Open  the  UCCX  Editor  on  HQ  TPC1  using  the  shortcut  on  the  desktop  and  log  in  using  the  
admin/cciecollab  credentials.  
 

 
 
To  create  a  new  script,  click  the  “File”  menu  and  select  the  “New…”  option.  
 

 
 
   

828 ipexpert.com Copyright © by iPexpert. All rights reserved.


 
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

In  the  “Templates”  window,  click  the  “Queuing”  tab  and  select  the  “Simple_Queuing”  option  from  the  
list  box.  This  will  select  the  default  “icd.aef”  script  as  required  in  the  task.  Click  the  OK  button  to  
continue.  
 

 
 
Next,  click  the  “File”  menu  and  select  the  “Save  As…”  option.  
 

 
 
Name  the  file  “sports-­‐icd.aef”,  as  required  in  the  task,  and  click  the  Save  button  to  continue.  
 

 
 
The  script  should  appear  in  the  UCCX  editor  as  shown  below.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     829  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Task 54.2 Ensure  that  any  call  coming  from  the  PSTN  number  in  Germany  (+49307128788)  is  
redirected  to  the  auto  attendant  previously  configured  on  the  HQ  CUC  cluster  in  0.  
 
In  order  to  determine  whether  or  not  an  incoming  call  has  originated  from  the  PSTN  phone  number  at  
SC,  we  must  collect  the  ANI  of  the  call  in  some  fashion.  Once  we  have  the  ANI  of  the  call,  it  can  be  
compared  against  the  script  to  determine  if  the  number  matches  or  not.  A  great  way  to  get  the  calling  
number  would  be  to  run  the  debug isdn q931  command  on  the  R1  (HQ)  gateway.  This  will  display  
the  ANI  of  the  call  within  the  “Calling  Party  Number”  value.    
 
R1  
R1#debug isdn q931
debug isdn q931 is ON.
R1#
Jan 10 00:04:45.440: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x00A9
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'SC PSTN Phone'
Calling Party Number i = 0x1181, '49307128788'
Plan:ISDN, Type:International
Called Party Number i = 0x91, '14082221001'
Plan:ISDN, Type:International
Jan 10 00:04:45.452: ISDN Se0/0/0
R1#:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x80A9
Channel ID i = 0xA98381
Exclusive, Channel 1
Jan 10 00:04:45.520: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x80A9
 
As  shown  in  the  above,  the  format  of  the  number  is  “49307128788”—E.164  without  the  plus.  Based  on  
that  information,  we  can  design  the  script  logic  to  match  that  number.  Within  the  UCCX  Editor,  the  left  
pane  displays  all  of  the  available  methods  or  “steps”  that  can  be  used  within  the  script.  The  step  that  
will  be  used  to  retrieve  the  ANI  of  the  call  is  entitled  “Get  Call  Contact  Info”,  located  under  the  “Call  
Contact”  folder.    
 

 
 
Drag  the  “Get  Call  Contact  Info”  step  into  the  script  directly  below  the  existing  “Play  Prompt”  step.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     830  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Next,  we  must  create  a  variable  to  store  the  result  of  the  “Get  Call  Contact  Info”  step.  In  order  to  
determine  the  type  of  variable,  right  click  on  the  step  and  click  the  “Properties”  option.  
 

 
 
For  the  “Calling  Number”  attribute,  double  click  in  the  “Variables”  column  and  take  note  of  the  current  
variables  that  are  listed  within  the  dropdown  box.  Determining  the  type  of  the  displayed  variables  will  
clue  us  in  as  to  what  variable  should  be  created  to  store  the  “Calling  Number”  attribute.  
 

 
 
In  the  bottom  left  hand  corner  of  the  UCCX  editor,  locate  the  variables  pane.  All  of  the  variables  
currently  defined  in  the  system  are  listed  here.  The  two  variables  available  from  the  “Calling  Number”  
attribute  were  “CSQ”  and  “resourceID”.  Based  on  the  below,  we  can  see  that  they  are  defined  using  
the  “String”  type.  This  means  that  we  must  create  a  “String”  variable  to  store  the  calling  number.  
 

 
 
Click  the  New  Variable  button  (blue  arrow)  to  add  a  variable  to  the  system.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     831  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Select  the  “String”  option  from  the  “Type”  dropdown  box  and  enter  a  “Name”  for  the  variable.  It  is  a  
good  habit  to  prefix  the  name  of  the  variable  with  the  type  in  order  to  quickly  identify  it  in  the  script  
(e.g.  “stringANI”).  Click  the  OK  button  when  complete.  
 

 
 
Next,  launch  the  “Properties”  window  for  the  “Get  Call  Contact  Info”  step  again  and  assign  the  
“stringANI”  variable  to  the  “Calling  Name”  attribute.  Click  the  OK  button  when  complete.  
 

 
 
Within  the  script  window,  the  change  is  reflected.  
 

 
 
Next,  locate  the  “If”  step  under  the  “General”  folder  and  drag  it  under  the  “Get  Call  Contact  Info”  step.    
 

 
 
Right  click  the  “If”  step  and  click  the  “Properties”  option.  From  there,  click  the  blue  arrow  to  open  the  
Expression  Editor.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     832  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Select  the  “stringANI”  variable  from  the  “All  Variables”  dropdown  box  to  add  it  to  the  expression.  
 

 
 

 
 
Next,  select  the  “Boolean”  tab  to  display  all  available  operators.  Click  the  button  for  the  “Equality  
Operator”  (e.g.  “?  ==  ?”)  to  insert  it  into  the  “Condition”  text  box.    
 

 
 

 
 
Next,  enter  the  ANI  string  (with  quotes)  to  be  matched  in  the  “Condition”  text  box  (e.g.  
“49307128788”).  
 

 
 
Click  the  OK  button  to  save  and  exit  the  Expression  Editor.  Then  click  the  OK  button  again  to  save  the  
“Condition”  to  the  script.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     833  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  we  must  configure  an  option  to  send  the  call  to  the  CUC  Auto  Attendant  from  Task  40.3  (2770  on  
SB  CUC).  Locate  the  “Call  Redirect”  step  under  the  “Call  Contact”  folder  and  drag  it  under  the  “True”  
option  of  the  “If”  step.  
 

 
 
Right  click  the  “Call  Redirect”  step  and  set  the  “Destination”  to  “2770”.  Click  the  OK  button  to  save  the  
configuration.  
 

 
 
The  script  should  now  be  displayed  as  shown  below.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     834  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Task 54.3 When  callers  arrive  in  the  queue,  ensure  that  they  hear  a  prompt  that  will  tell  them  
how  many  resources  are  currently  logged  in.  For  example,  the  prompt  should  state,  
“There  are  currently  4  resources  logged  in”.  However,  assure  that  the  grammar  is  
correct  for  the  prompt.  If  there  is  1  resource  logged  in,  the  prompt  should  state  for  
example,  “There  is  currently  1  resource  logged  in”.  The  prompt  must  be  built  
programmatically.    
 
This  task  requires  that  we  make  use  of  one  of  the  Unity  Connection  servers  in  order  to  record  prompts  
for  use  within  the  UCCX  script.  We  must  record  a  total  of  four  prompts  as  shown  below.  
 
1. Plural  Prompt  –  “There  are  currently”  
2. Singular  Prompt  –  “There  is  currently”  
3. Plural  Prompt  –  “Resources  logged  in”  
4. Singular  Prompt  –  “Resource  logged  in”  
 
To  record  these  prompts,  log  into  the  Cisco  Unity  Connection  Administration  webpage  on  one  of  the  
CUC  servers  and  navigate  to  Call  Management  !  System  Call  Handlers  !  Opening  Greeting  !  Edit  !  
Greetings  !  Alternate  and  click  the  Play/Record  button  under  the  “Recordings”  section.    
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     835  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

This  will  launch  a  Java  applet;  make  sure  to  accept  all  the  warnings  in  order  to  load  the  recording  
interface  successfully.  
 

 
 
Hit  the  record  button  to  record  the  first  prompt.  When  completed,  click  the  “Options”  menu  on  the  top  
left  of  the  applet  and  select  the  “Save  Recording  As...”  option.  Save  the  file  to  the  Desktop  or  another  
easily  accessible  folder.  
 

 
 
Continue  to  record  the  remaining  prompts  using  the  above  procedure.  
 
Once  the  prompts  have  been  created  and  saved,  they  must  be  uploaded  to  the  UCCX  server.  From  the  
Cisco  Unified  CCX  Administration  page,  navigate  to  Applications  !  Prompt  Management  and  click  on  
the  “en_US”  folder.  Click  the  Upload  Prompts  button  to  launch  a  new  window  for  the  upload.  Browse  
for  the  file  and  click  the  Upload  button  to  save  it  to  the  UCCX  server.    
 

 
 
After  clicking  the  Upload  button,  the  server  should  display  the  status  of  the  transfer.  
 

 
 
Make  sure  to  upload  the  rest  of  the  recorded  prompts.  Each  WAV  file  will  be  displayed  in  the  “en_US”  
folder  as  shown  below  when  complete.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     836  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Next,  we  must  configure  the  script  to  interact  with  the  newly  created  prompt  files.  We  should  create  
variables  (of  type  “Prompt”)  in  the  system  so  they  can  be  easily  called  from  the  script.  From  the  UCCX  
Editor,  add  a  new  variable  and  select  the  “Prompt”  option  from  the  “Type”  dropdown  box.  Next,  
specify  a  descriptive  “Name”  for  the  variable  (e.g.  “promptCurrentlyPlural”)  so  it  can  be  easily  
identified.  Next,  click  the  blue  arrow  in  the  “Value”  field  to  open  the  Expression  Editor.  
 

 
 
Click  the  “Prompt”  tab  on  the  bottom  of  the  Expression  Editor  window  and  click  the  Browse  Prompts…  
button  to  locate  the  recently  uploaded  prompts.  
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     837  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  “Prompt  Repository”  at  the  top  left  of  the  “Paste  Prompt…”  window.  Within  the  window,  
double  click  on  the  “en_US”  folder  and  click  on  the  “there-­‐are-­‐currently.wav”  file.  Click  the  Paste  
button  to  add  it  to  the  Expression  Editor.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     838  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  OK  button  in  the  Expression  Editor  to  save  the  configuration.  Click  the  OK  button  again  to  
save  the  variable.  
 

 
 
Create  the  remaining  three  prompt  variables  in  the  system  as  well.  
 

 
 
Now  that  the  variables  have  been  created,  we  must  programmatically  determine  how  to  use  them.  
Within  the  UCCX  Editor,  locate  the  “Get  Reporting  Statistic”  step  from  the  “ACD”  folder  and  drag  it  
under  the  “Queued”  section  of  the  “Select  Resource”  step.  
 

 
 
Next,  we  must  create  a  variable  to  store  the  information  gathered  from  the  “Get  Reporting  Statistic”  
step.  Enter  the  “Properties”  menu  (by  right  clicking  the  step)  to  set  the  configuration.  Under  the  
“Report  Object”  dropdown  box,  select  the  “CSQ  IPCC  Express”  option.  This  will  gather  statistics  based  
only  upon  the  specific  CSQ  of  the  script.  Next,  select  the  “Logged-­‐In  Resources”  option  from  the  “Field”  
dropdown  box.  For  the  “Row  Identifier”  field,  enter  the  CSQ  that  will  be  used  to  generate  the  statistics.  
In  this  case,  a  variable  called  “CSQ”  was  used.  Pull  down  the  “Result  Statistic”  dropdown  box,  to  
determine  the  type  of  variable  that  is  needed.  In  this  case  “DelayWhileQueued”  is  displayed,  which  is  a  
variable  of  type  “Integer”.    
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     839  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
We  must  now  create  an  “Integer”  variable  to  store  the  Logged-­‐In  Resources  statistic.  You  may  
temporarily  assign  the  “DelayWhileQueued”  variable  and  click  the  OK  button  so  as  to  not  lose  
configuration,  if  desired.    
 
From  the  “New  Variable”  window,  select  the  “int”  option  from  the  “Type”  dropdown  box.  Next,  enter  a  
descriptive  “Name”  for  the  variable  (e.g.  “intResourcesLoggedIn”)  and  click  the  OK  button.  The  variable  
should  now  be  displayed  in  the  window.    
 

 
 
Once  again,  enter  the  “Properties”  window  for  the  “Get  Reporting  Statistic”  step  and  modify  the  
“Result  Statistic”  dropdown  box  to  use  the  newly  created  “intResourcesLoggedIn”  variable.  Click  the  
OK  button  when  complete.  
 

 
 
The  step  should  now  be  displayed  in  the  script  as  shown  below.  
 

 
 
Next,  we  must  create  a  prompt  to  speak  the  number  that  the  “Get  Reporting  Statistic”  step  generates.  
To  do  this,  we  will  use  the  “Create  Generated  Prompt”  step  found  under  the  “Prompt”  folder.  Drag  it  
into  position,  directly  under  the  “Get  Reporting  Statistic”  step.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     840  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
Next,  create  a  variable  that  can  contain  the  result  of  the  “Create  Generated  Prompt”  step.  In  this  case,  
it  will  be  type  “Prompt”.  In  the  “New  Variable”  window,  select  the  “Prompt”  option  from  the  “Type”  
dropdown  box  and  specify  a  descriptive  “Name”  for  the  variable  (e.g.  “promptResourcesLoggedIn”).    
 

 
 
Next,  enter  the  “Properties”  of  the  “Create  Generated  Prompt”  step.  Select  “number”  as  the  
“Generator  Type”  from  the  dropdown  box.  Next,  for  the  “Argument”  value,  click  the  Set…  button  to  
assign  the  “intResourcesLoggedIn”  variable.  This  will  configure  the  generator  to  speak  the  number  that  
is  populated  within  the  variable.  Next,  specify  the  “Override  Language”  as  the  “L[en_US]”  to  use  the  
English  language  for  the  generated  prompt.  Lastly,  assign  the  newly  created  
“promptResourcesLoggedIn”  variable  to  the  “Output  Prompt”  dropdown  box.  Click  the  OK  button  to  
save  the  configuration.  
 

 
 
Next,  we  must  create  the  condition  in  which  the  prompts  will  be  played.  Singular  prompts  of  course  
should  be  limited  to  a  value  of  one,  while  plural  prompts  should  be  anything  greater  than  one.  For  the  
number  zero,  think  about  the  resulting  prompts  to  decide  the  category  in  which  it  should  be  placed.    
 
“There  are  zero  resources  logged  in.”  versus  “There  is  zero  resource  logged  in.”  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     841  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Obviously  the  first  option  is  better  in  this  case,  so  zero  should  be  considered  plural  for  our  purposes.  
The  best  way  to  describe  the  situation  programmatically  would  be  to  use  the  “If”  step.  For  example,  if  
the  number  of  resources  logged  in  is  equal  to  one,  the  singular  prompt  should  be  played.  Otherwise,  
the  plural  prompts  should  be  played.  To  begin,  drag  the  “If”  step  (from  the  “General”  folder)  under  the  
“Create  Generated  Prompt”  step.  Enter  the  “Expression  Editor”  for  the  “If”  step  and  select  the  
“intResourcesLoggedIn”  variable.  Next,  select  the  “Equality  Operator”  from  the  “Boolean”  tab  (i.e.  “?  
==  ?”).  Finally  enter  the  number  “1”  to  complete  the  statement.  Click  the  OK  button  when  complete.  
 

 
 
Click  the  OK  button  again  to  save  the  “If”  step.  It  should  be  displayed  in  the  script  as  shown  below.  
 

 
 
Under  the  “True”  condition,  we  must  play  the  singular  prompt  while  the  “False”  condition  should  play  
the  plural  prompt.  Locate  the  “Play  Prompt”  variable  under  the  “Media”  folder  and  drag  it  under  the  
“True”  condition.    
 

 
 
Enter  the  “Properties”  of  the  “Play  Prompt”  step  and  click  the  “Prompt”  tab.  Click  the  blue  arrow  to  
enter  the  “Expression  Editor”.  
 

 
 
First,  click  the  “Prompt”  tab  and  select  the  “promptCurrentlySingular”  variable  to  start  the  prompt.  
Next,  click  the  “Prompt  Concatenation”  option  (?  +  ?)  to  add  to  the  existing  prompt.  Next,  select  the  
“promptResourcesLoggedIn”  variable.  Add  another  “Prompt  Concatenation”  followed  by  the  last  
variable  of  “promptResourceSingular”.        
 

 
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     842  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Click  the  OK  button  when  complete.  


Click  the  OK  button  again  on  the  “Play  Prompt”  step  to  save  the  configuration  to  the  script.  
 

 
 
Next,  create  the  plural  prompt  using  the  same  above  steps  for  the  “False”  condition.  
 

 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     843  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 54.4 Assure  that  a  user  in  the  queue  hears  the  Queue  Prompt  every  15  seconds.  The  
logged  in  resources  prompt  should  only  be  played  once.  
 
The  next  part  of  the  script  is  basically  already  built  for  us,  in  this  case.  Under  the  “queueLoop”  label,  
the  “Play  Prompt”  step  has  been  added  to  play  the  default  Queue  Prompt.  The  following  step  is  the  
one  that  must  be  modified.  The  “Delay”  step  uses  the  “DelayWhileQueued”  variable  to  determine  the  
amount  of  seconds  that  the  caller  should  wait  in  the  queue  before  playing  the  Queue  Prompt  again.    
 

 
 
By  default,  the  value  of  the  “DelayWhileQueued”  variable  is  set  to  30  seconds.  To  meet  the  
requirements  of  the  script,  modify  the  value  of  the  variable  to  15  instead.  Click  the  OK  button  when  
complete.  
 

 
 
To  meet  the  last  requirement  of  the  task,  make  sure  that  the  “If”  step  that  is  used  to  play  the  
Singular/Plural  Prompts  exists  outside  of  the  “queueLoop”  label.  If  it  is  placed  under  the  label,  the  
prompt  will  be  heard  every  15  seconds  rather  that  just  once.  
 

 
 
 
   

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     844  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

Task 54.5 Upload  the  script  and  assure  that  it  is  activated  when  a  user  dials  the  extension,  
1100.  
 
The  last  step  in  the  configuration  is  to  upload  the  script  to  the  UCCX  server  and  associate  it  with  the  
previously  created  application.  Before  we  do  that,  however,  we  should  validate  the  script  to  ensure  
that  there  are  no  errors  to  be  found.  Within  the  UCCX  Editor,  navigate  to  Tools  !  Validate.  If  the  
validation  is  successful,  a  message  will  be  displayed  stating  as  such.  
 

 
 
Now  that  the  script  is  complete,  save  the  script  to  a  known  location  and  log  into  the  UCCX  server.  
 

 
 
Within  the  UCCX  server,  navigate  to  Applications  !  Script  Management  and  click  the  Upload  Scripts  
button.  Browse  for  the  newly  created  script  and  click  the  Upload  button  to  save  it  to  the  UCCX  server.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     845  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Once  the  script  is  successfully  uploaded,  navigate  to  Applications  !  Application  Management  and  click  
on  the  existing  application  in  the  system  (e.g.  “ICD_SCRIPT”).  For  the  “Script”  dropdown  box,  select  the  
“SCRIPT[sports-­‐icd.aef]”  option.  Next,  check  the  box  for  the  “CSQ”  parameter  and  enter  “Sports_CSQ”  
to  assign  the  previously  created  Contact  Service  Queue  to  the  script.  Click  the  Update  button  when  
complete.    
 

 
 
Since  the  script  is  already  associated  with  the  Trigger  at  extension  “1100”,  the  script  can  be  entered  by  
dialing  the  number  from  the  PSTN  phone  to  test.  Remember  to  test  from  the  SC  PSTN  phone  to  ensure  
that  the  SB  CUC  Auto  Attendant  is  reached.  
 
If  the  script  is  not  functioning  properly,  a  great  tool  is  available  within  the  UCCX  Editor  called  “Reactive  
Script”  debugging.  This  allows  the  administrator  to  step  through  the  script  and  find  errors  that  may  be  
occurring.  From  the  UCCX  Editor,  navigate  to  Debug  !  Reactive  Script…  to  launch  the  debugger.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     846  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Select  the  “Script  Name”  and  the  “Wait  Time”  from  the  dropdown  boxes  to  configure  the  debugger.  
 

 
 
Click  OK  button  to  start  the  process.  
 
Call  into  the  script  from  any  phone  and  observe  the  behavior.  The  script  will  answer  the  call  and  allow  
the  administrator  to  step  through  the  entire  script,  line  by  line.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     847  
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide

 
 
Pay  specific  attention  to  the  variables  when  debugging  the  live  script,  as  they  can  provide  valuable  
insight  as  to  why  a  script  might  be  failing.  
 

iPexpert,  Inc.                                                                                CCIE  Collaboration  Technology  Focused  Detailed  Solution  Guide     848  

You might also like