Professional Documents
Culture Documents
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
1:
Labs
1-‐2
Version
1.0
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
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
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
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):
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
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
Version :
sip9971.9-4-1SR1-2
advertisement version: 2
Duplex: full
Power drawn: 13.588 Watts
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
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
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
System Description:
Cisco IP Phone 9971, V1, sip9971.9-3-2-10
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
System Description:
Cisco IP Phone 7965G,V4, SCCP45.9-3-1SR1-1S
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
---------------------------------------------
System Description:
Cisco IP Phone 9971, V1, sip9971.9-4-1SR1-2
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
---------------------------------------------
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
System Description:
Cisco IP Phone 7962G,V15, SCCP42.9-3-1SR1-1S
System Description:
Cisco IP Phone 7965G,V8, SCCP45.9-3-1SR1-1S
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
System Description:
Cisco IP Phone 7965G,V8, SCCP45.9-3-1SR1-1S
System Description:
Cisco IP Phone 9971, V1, sip9971.9-4-1SR1-2
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
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
R3
R3#sh vlan-switch brief
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
R3
R3#sh vlan-switch brief
SW1
SW1#show vlan brief
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
R3
R3#sh vlan-switch brief
SW1
SW1#show vlan brief
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.
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
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.
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
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
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.
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.
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
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:
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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
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
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
R3
R3(config)#ntp server 10.10.1.1
SW1
SW1(config)#ntp server 10.10.1.1
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.
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.
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.
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
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
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.
R3
(CUCME)
R3(config)#voice register global
R3(config-register-global)#ntp-server 10.10.1.1 mode directedbroadcast
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.
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).
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!
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
2:
Labs
3-‐9
Version
1.0
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Remember
to
click
the
Save
button
followed
by
the
Reset
button
to
apply
the
new
configuration
to
the
phone.
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.
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.
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.
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”.
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.
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.
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.
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.
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).
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.
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.
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
“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
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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
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.
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.
• 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
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.
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
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
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
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
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.
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
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).
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
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
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.
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.
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
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
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.
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.
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
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.).
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
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.
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
voice register dn 1
number 3002
name SC Phone 2
Once
registered
and
configured
with
the
above
commands,
the
phone
should
be
accessible
from
PhoneView
as
shown
below:
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
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-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
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
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
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
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.
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
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)#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.
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.
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
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"
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.
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
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.
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!
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
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!
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
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.
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)#presence
R3(config-presence)#presence call-list
The
phone
should
then
display
presence
status
as
shown
below.
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
3:
Labs
10-‐15
Version
1.0
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
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
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
...
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
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
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
1 T1 0/0/0 GOOD T1
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...
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
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
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
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.
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
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
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
%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply
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.
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.
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
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.
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.
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).
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.
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
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.
R2
R2#sh run int s0/0/0:23
Building configuration...
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.
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
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.
R2
R2(config)#voice class codec 1
R2(config-class)# codec preference 1 g711ulaw
R2(config-class)# codec preference 2 g729r8
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
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.
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”).
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.
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
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
a=fmtp:101 0-16
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
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.
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
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
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
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...
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.
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
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
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”.
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.
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
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
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/
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
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
On
the
9971,
navigate
to
Settings
Button
!
Administrator
Settings
!
Status
!
Call
Statistics
to
view
the
codec
in
use.
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.
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.
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.
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
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.
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.
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).
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.
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).
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.
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.
On
the
9971,
navigate
to
Settings
Button
!
Administrator
Settings
!
Status
!
Call
Statistics
to
view
the
codec
in
use.
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.
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.
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.
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.
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.
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”).
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.
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.
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!
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.
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.
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.
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”.
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)
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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.
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
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.
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
Four:
Labs
16-‐29
Version
1.0
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.
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.
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.
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
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.
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.
On
the
SB
CUCM
cluster,
we
must
also
add
a
Route
Group
and
Route
List
for
the
R2
SIP
gateway.
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.
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”.
At
this
point,
both
clusters
should
be
configured
and
ready
to
route
calls
using
the
Standard
Local
Route
Group.
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”).
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.
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.
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
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
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
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
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
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
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”).
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.
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
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
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”).
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.
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
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
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
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”).
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.
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
R2(cfg-translation-rule)#voice translation-rule 8
R2(cfg-translation-rule)#rule 1 /^9011\(.*\)$/ /\1/ type any international plan any isdn
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 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
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.
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.
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.
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
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
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”).
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.
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
R2(cfg-translation-rule)#voice translation-rule 10
R2(cfg-translation-rule)# rule 1 /^91\(866.......$\)/ /\1/ type any national plan any isdn
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
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.
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.
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.
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
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.
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
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
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
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(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
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
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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
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.
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.
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
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
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
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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).
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
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).
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.
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.
As
you
can
see,
call
presentations
for
both
types
of
calls
are
now
correct.
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.
The
configuration
for
the
“91866XXXXXXX”
Translation
Pattern
is
below.
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.
All
calls
are
now
configured
to
route
correctly,
based
on
the
task
requirements.
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.
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.
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.
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.
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
...
“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.
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.
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.
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.
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”).
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!
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.
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.
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.
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.
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
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.
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.
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.
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.
• 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.
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.
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.
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!
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”).
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.
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.
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!
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.
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.
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”.
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.
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.
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.
Next,
select
the
“Time
of
Day
Start”
and
“Time
of
Day
End”
from
the
dropdown
box.
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.
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
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.
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.
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
Create
the
Time
Schedule
Create
the
Partition
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.
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”).
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]
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
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.
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]
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.
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
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.
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.
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.
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.
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.
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.
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
...
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.
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.
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.
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.
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.
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.
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
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.
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
Now
make
another
call
into
the
MVA
number.
You
should
be
able
to
successfully
log
in
at
this
point.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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”.
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.
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
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.
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.
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.
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
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”.
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
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.
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.
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.
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.
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.
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”.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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
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
- none -
- none –
The
next
task
will
configure
the
CCD
service
to
share
patterns
between
the
CUCM
and
CUCME
systems.
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”).
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
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.
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
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
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 -
- 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
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 -
- 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.
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
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
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
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
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
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
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
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
...
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 '#'
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
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.
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.
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.
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.
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.
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."
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.
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
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
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
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
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
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.
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
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
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.
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
5:
Labs
30-‐32
Version
1.0
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
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.
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-dspfarm-profile)#no shutdown
The
conference
bridge
will
be
tested
in
the
next
task.
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.
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.
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
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
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
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
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.
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
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.
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”.
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
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
...
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
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
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.
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.
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.
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.
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.
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 :
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.
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.
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
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 :
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.
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.
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.
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.
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.
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
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
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
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
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Length: 0
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
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
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
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
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
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
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
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
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
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
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
v=0
o=CiscoSystemsSIP-GW-UserAgent 780 8080 IN IP4 10.10.31.1
s=SIP Call
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
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
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.
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
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
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
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
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
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
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
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
R3(config-dspfarm-profile)#no shutdown
Test the configuration by starting another Meet-Me conference. Listen for the different “join” and
“leave” tones.
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.
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
Six
Labs
33
-‐
34
Version
1.0
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).
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.
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.
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.
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.
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
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.
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.
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.
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.
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
ST_LOUIS_DC_LOC
KANSAS_CITY_LOC
HQ_PHONE_LOC
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.
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.
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.
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.
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.
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]
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.
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.
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.
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”).
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
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.
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.
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.
[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
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
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.
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”).
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.
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.
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.
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
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
Seven
Labs
35
-‐
36
Version
1.0
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.
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.
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.
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.
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.
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.
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
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
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
...
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
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.
Now
make
another
test
call
and
observe
the
behavior.
At
this
point,
the
transfer
should
be
denied.
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.
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”).
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.
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
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
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.
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
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.
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/
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
R2(config)#voice translation-rule 3001
R2(cfg-translation-rule)#rule 1 /^2...$/ /+1312333\0/ type any international plan any isdn
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
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
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
...
Calling Party Number i = 0x4180, '3123332001'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '911'
Plan:ISDN, Type:Subscriber(local)
...
...
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
voice translation-rule 6
rule 1 /^91\([2-9]..[2-9]......\)$/ /\1/ type any national plan any isdn
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
...
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.
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
Eight
Labs
37
-‐
41
Version
1.0
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.
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
“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.
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
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.
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.
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.
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.
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”.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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”).
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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
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
• 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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”).
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.
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.
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.
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.
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.
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
Nine
Labs
42
-‐
44
Version
1.0
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.
Enter Hostname
(my-hostname, or enter to use se-10-10-31-254): CUE
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
Germany
...
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::
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.
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.
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.
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.
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
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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”).
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.
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.
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.
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.
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.
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.
CCIE
Collaboration
Technology-‐Focused
Detailed
Solution
Guide
Section
Ten
Labs
45
-‐
47
Version
1.0
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
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
R2(config)#interface Virtual-Template 1
R2(config-if)#ip address 10.10.121.2 255.255.255.252
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
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
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
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 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 -
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
Service-policy : LLQ
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 -
iPexpert,
Inc.
CCIE
Collaboration
Technology
Focused
Detailed
Solution
Guide
710
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide
Service-policy : LLQ
iPexpert,
Inc.
CCIE
Collaboration
Technology
Focused
Detailed
Solution
Guide
711
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
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
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
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
iPexpert,
Inc.
CCIE
Collaboration
Technology
Focused
Detailed
Solution
Guide
718
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide
R3
R3#sh policy-map interface vlan31
Vlan31
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...
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
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 : 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
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
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 ...
VMware Installation:
1 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
2048 Mbytes RAM
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
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.
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
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.
“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 ...
VMware Installation:
2 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
Disk 2: 80GB
4096 Mbytes RAM
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
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.
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
> _xmpp-server._tcp.cucm.com
Server: ldap.ipexpert.com
Address: 10.10.13.16
VMware Installation:
1 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
2048 Mbytes RAM
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
*** 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.
Continue (y/n)?y
VMware Installation:
2 vCPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Disk 1: 80GB
Disk 2: 80GB
4096 Mbytes RAM
*** 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
iPexpert,
Inc.
CCIE
Collaboration
Technology
Focused
Detailed
Solution
Guide
799
iPexpert's Cisco CCIE Collaboration Technology Workbook (Vol. 1) - Detailed Solutions Guide
Continue (y/n)?y
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
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
Follow
this
procedure
for
all
skills
in
the
task
requirements.
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
To
create
a
new
script,
click
the
“File”
menu
and
select
the
“New…”
option.
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
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