Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
In this section we explore three methods of configuring endpoints on a CM Express system: configuring optional settings,
rebooting IP Phones, and troubleshooting and verifying the configuration.
Providing Firmware
IP Phone firmware files ship with the CM Express software or can be downloaded from cisco.com. For the router to serve
the firmware to the phones, the tftp-server fiashifilename command is used. You must enter this command for every
firmware file needed. Some phones require more than one file to be loaded—for example, the 791 IG requires six separate
files.
Telephony Service Configuration
Manual setup of the CM Express system is done using the CLI. From the global config, the command telephony-service
enables config-telephony mode. This prompt is where your first steps of defining the max-ephones and max-ephone-dn
settings (described earlier) would take place.
Phone Firmware Loads
The firmware files that were copied into Flash and made available to the phones via TFTP must be associated with the
phones; this is done using the load model firmware-file command. Filenames are case sensitive, and the file extension
should not be included in the command. (Tip: Use the Cut-and-Paste function of your terminal client to prevent annoying
typos!) For Java-based phones, it is only necessary to load the TERMnn.x-y-x-w.loads or SCCPnn.x-y-x-w.loads
firmware filename (without the .loads extension), although the other files must be available via TFTP. The following is a
sample command set:
load 7960-7940 P00303020214
load 7920 cmterm_7920.4.0-01-08
load 7941 TERM41.7-0-3-0S
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Defining Source IP and Port
The CM Express software uses SCCP to communicate with the phones. (SIP signaling is also possible but is not covered
in this document.) The command ip source-address ip-address [port port] defines the IP address of the router that will
be used as the source for SCCP messages. The default SCCP TCP port is 2000 and does not normally need to be
changed, but the option is available if the situation should require it.
Autoregistration
The autoregistration function is enabled by default; this allows a phone to be discovered and registered to an available
ephone slot (provided the ip source-address command is configured). The command no auto-reg-ephone prevents a
phone from registering unless its MAC address is explicitly configured already. CM Express records the MACs of all
phones that attempt to register but are blocked by autoregistration being disabled; use the show ephone
attempted-registrations command to see the list and the clear telephony-service ephone attempted-registrations
command to see and clear the list.
Create XML Config Files
The create cnf-files command takes the configurations (including the firmware load, the source IP address, and port we
just defined) and builds an XML config file for each phone. This is a necessary step, and one that you may repeat from
time to time, for example, if you upgrade firmware or make other changes to the phone configuration.
DID Configurations
It is common to have a range of DID numbers (fully qualified E.164 numbers) that allow outside callers to reach internal
extensions directly; usually, the DIDs have the four-digit internal extension as the last four digits. CM Express supports
this configuration with the dialplan-pattern command. This function expands extension numbers to full E.164 numbers
and converts incoming E.164 numbers to local extensions. The command is also needed to register the range of numbers
the command specifies with a gatekeeper; in fact, once configured, the range is automatically registered if a gatekeeper
is configured. You can disable this with the no-reg keyword. The full syntax is dialplan-pattern tag pattern
Automated Deployment of Endpoints
In some cases, it is desirable to automate the deployment of phones. The telephony-service auto-assign command will
dynamically create ephones as physical phones are connected to the system, assigning an available ephone-dn to the
ephone. The ephone-dns must all be the same type (that is, single line or dual line). You must have a range of ephone-dns
configured, but it is no longer necessary to create each ephone and associate it manually.
The auto assign start-dn to stop-dn [type phone-type] [cfw number timeout seconds] command syntax specifies the
range of ephone-dns to use for a given phone model, the Call Forward Busy number to use (typically the voice-mail port),
and timeout values. You can enter multiple commands to specify ranges for your different phone types; if no phone type
is specified, any phone that registers will be assigned an ephone-dn from the specified range. The 7914 sidecar is not
supported by this command; phones with this add-on must have it manually added. The auto-assign cannot be used for
ephone-dns that serve paging, MoH, intercom or MWI functions. Nor can it be used for shared-line implementations.
Changes must be performed manually at the CLI, followed by resetting the affected phones. The following is a sample of
how the command can be used:
t e l e p h o n y - s e r v i ce
auto assign 11 to 20 type 7920
auto assign 21 to 30 type 7940
auto assign 31 to 40 type 7960
auto assign 41 to 50
ephone-dn 1 d u a l - l i ne
number 5301
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
extension-length length extension-pattern pattern [no-reg]. The pattern uses the same wildcards as dial peers. A
sample configuration to set up a dial plan pattern for extensions 5300-5399 and expand them to the DID range of
867-555-5300-867-555-5399 would look like this:
t e l e p h o n y - s e r v i ce
d i a l p l a n - p a t t e r n 1 86755553.. e x t e n s i o n - l e n g t h 4 extension p a t t e r n 5 3 ..
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
The preceding output assigns ephone-dns from 11 to 20 to 7920s, 21 to 30 to 7940s, 31 to 40 to 7960s, and 41 to 50 to
any other type of phone (including those already specified, if there are no more ephone-dns in their range).
Location Customization
CM Express supports phone display language, time display, and ring cadence localization. The user-locale languagecode
command will change the language displayed on all 7940 and 7960 phones; the 7920 is not affected and must be
configured with its individual language capability local to the phone. The network-locale language-code command will
change the call progress tones and ring cadence (again with the exception of the 7920).
Following are language codes supported for User Locale:
• DE: Germany
• DK: Denmark
• ES: Spain
• FR: France
• IT: Italy
• NL: Netherlands
• NO: Norway
• PT: Portugal
• RU: Russian Federation
• SE: Sweden
• US: United States (default)
• JA:Japan
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Following are language codes supported for Network Locale:
• AT: Austria
• CA: Canada
• CH: Switzerland
• DE: Germany
• DK: Denmark
• ES: Spain
• FR: France
• GB: United Kingdom
• IT: Italy
• JA: Japan
• NL: Netherlands
• NO: Norway
• PT: Portugal
• RU: Russian Federation
• SE: Sweden
• US: United States (default)
To change the time display format, use the time-format {12 I 24} command. To change the date format, use date-format
{mm-dd-yy I dd-mm-yy I yy-dd-mm I yy-mm-dd}.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Rebooting IP Phones
There are two commands available to reboot IP Phones, each with a slightly different behavior. The reset command
causes a hard reboot of the phone and invokes DHCP and TFTP. Use reset when changing firmware, user/network
locales, or URLs. The reset command can be executed to reset a single phone at the config-ephone prompt, or at the
config-telephony prompt to reset one or more phones. The full syntax is reset {all [time-interval] I cancel I mac-address
Isequence-all}. The command options work as follows:
• all: Resets all phones.
• time-interval: Changes the interval between the router resetting the phones in sequence (default = 15sec).
• cancel: Stops the reset process.
• mac-address: Resets a specific phone.
• sequence-all: The router waits for one phone to reset and reregister before resetting the next phone to prevent the
phones from overloading the TFTP server. This can be time consuming; the router waits 4 minutes as a timeout
before resetting the next phone, whether or not the reregistration of the previous has finished.
The restart command causes a soft (warm) reboot and is useful for minor configuration changes, such as buttons, lines,
and speed-dial modifications. This command can also be executed either at the config-ephone prompt or at the configtelephony
prompt. The syntax is restart {all [time-interval] I mac-address}, with the command parameters the same as
the reset command.
Troubleshooting Endpoints
Check the following when troubleshooting:
• Verify IP addressing: Use the Settings button on the phone to check the configuration of the IP phone. The TFTP
Server IP should be the CM Express router.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Verify the files in flash memory: Verify that the correct firmware files are in the flash memory of the Cisco Unified
Communications Manager Express router using the show flash command.
• Debug the TFTP server: Use debug tftp events to ensure that the Cisco Unified Communications Manager
Express router is correctly providing the firmware and XML files.
• Verify the firmware installation of the phones: Use the debug ephone register command to verify which
firmware is being installed.
• Verify that the locale is correct: Use the show telephony-service tftp-bindings command to view the files that the
TFTP server is providing.
• Verify the phone setup: Use the show ephone command to view the status of the ephones and whether they are
registered correctly.
• Review the configuration: Use the show running-config command to verify the ephone-dn configuration.
Thursday, December 16, 2010
Introducing Cisco Unified Communications Manager Express Best Cisco CCIE Course Training Institute in Delhi Gurgaon India
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Unified CM Express is a router-based call agent that scales up to 240 phones, depending on platform capacity. The
system extends the benefits of Unified Communications to small businesses.
Unified CM Express supports a wide range of TP Phone, system, and trunk features, as well as voice-mail integration with
Unity, Unity Express, and third-party systems using H.323 or analog DTMF signaling. For a complete feature list, refer to
the Unified Communications Manager Express 4.2 Data Sheets on cisco.com.
Unified CM Express runs on the ISR platforms, including the 2800 and 3800 series, and on the 3700 series Multiservice
Access Routers. The appropriate IOS IP Voice feature set, along with IP Phone licenses and firmware, and flash and
RAM appropriate for the install are required. The optional GUI files may be installed for simplified configuration and
administration but are not required.
Unified CM Express supports all current-generation IP Phones.
Defining Ephone and Ephone-DN
An ephone is an Ethernet phone, and an ephone-dn is an Ethernet phone directory number. In CM Express, an ephone is a
logical configuration and settings for a physical phone, and the ephone-dn is a destination number that can be assigned to
multiple ephones.
An ephone-dn always has a primary directory number, and it may have a secondary one as well. When you create an
ephone-dn, you can specify it as single line (the default) or dual line. A single line can terminate one call; a dual line can
terminate two calls at the same time. This is necessary for call waiting, consultative transfer, and conferencing features
to work. When you create an ephone-dn, the router automatically creates POTS dial peers to match. The following
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
configuration creates a dual-line ephone-dn with a primary and secondary number. The number 20 in the configuration is
the tag, which is simply a unique identifier:
Router(config)#ephone-dn 20 d u a l - l i ne
Router(config-ephone-dn)#number 5309 secondary 8675309
There is a maximum number of ephone-dns that a given platform will support; this is controlled by the hardware capacity
and by licensing. The max-dn <max-dn-value> command must be set to create ephone-dns; the default is zero. Be aware
that the router immediately reserves memory for the number of dns you specify, whether they are created or not; you
should configure only what you will actually need.
An ephone is the logical configuration of a physical phone. Each ephone is given a tag to uniquely identify it. The MAC
address of the phone ties it to the ephone configuration. CM Express will detect all phone models except the 7914
sidecar, which must be specified manually. Each different model of IP Phone has a different number of buttons, to which
various functions can be applied; the top button is always numbered " 1 , " with the others following in numerical order.
The button command allows you to specify which button does what. The following configuration creates a basic ephone
for a 7960 with a 7914 sidecar; the button 1:20 command assigns button 1 the dn (5309) assigned to ephone-dn 20 from
the previous example:
r o u t e r ( c o n f i g ) # ephone 20
r o u t e r ( c o n f i g - e p h o n e ) # mac-address AAAA.BBBB.CCCC
r o u t e r ( c o n f i g - e p h o n e ) # type 7960 addon 1 7914
r o u t e r ( c o n f i g - e p h o n e ) # button 1:20
Types of ephone-dns
Six types of ephone-dns are configurable in CM Express:
• Single line: This ephone-dn creates a single virtual port. Although you can specify a secondary number, the phone
can terminate only one call at a time, so it cannot support call waiting. It should be used when there is one phone
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
button for each PSTN line that comes into the system. It is useful for things like paging, intercom, call-park slots,
MoH feeds, and MWI.
Router(config)#ephone-dn 1
Router(config-ephone-dn)#number 1001
• Dual line: The dual-line ephone-dn can support two call terminations at the same time and can have a primary and a
secondary number. It should be used when a single button supports call features like call waiting, transfer, and
conferencing. It should not be used for lines dedicated to intercom, paging, MoH feeds, MWI, or call park. It can be
used in combination with single-line ephone-dns on the same phone.
Router(config)#ephone-dn 2 d u a l - l i ne
Router(config-ephone-dn)#number 1002
• Dual number: This ephone-dn has a primary and secondary number, making it possible to dial two separate
numbers to reach the phone. It can be either a single- or dual-line ephone-dn; it should be used when you want to
have two numbers for the same button without using more than one ephone-dn.
• Shared ephone-dn: The same ephone-dn and number appears on two separate phones as a shared line, meaning that
either phone can use the line, but once in use the other cannot then make calls on that line. The line will ring on all
phones that share the ephone-dn, but only one can pick up. If the call is placed on hold, any one of the other phones
sharing the line can pick it up.
• Multiple ephone-dns on one or more ephones: This configuration allows multiple calls to the same extension to be
handled simultaneously on a single phone; for example, using three dual-line ephone-dns with the same number will
terminate six calls on the phone. By using multiple ephone-dns on multiple phones, all the phones can answer the
same number. This is not a shared line because the phones will ring in succession, and a call on hold can be
answered only by the phone that placed it on hold. Controlling the hunting behavior (the order in which buttons or
phones ring) is done with the preference and huntstop commands, as explained in the "Hunting Configuration"
section that follows.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Overlay ephone-dn: An overlay consists of two or more ephone-dns (up to 25) applied to the same button; all these
ephone-dns must be either single or dual line. (You can't mix the types.) The call coverage is similar to a shared-line
setup, except that a call to the number on one phone does not block the use of the same number on another phone.
You can overlay up to 10 lines on a single button and then configure the same overlay set on 10 phones, with the
result that all 10 phones could answer calls to the same number. The button command with the overlay separator
creates the overlay set. The overlay separator can be o, which designates an overlay set without call waiting, or c,
which designates call waiting. The command button lo30,31>32,33,34,35 c o n f j g u r e s ephone-dns 30, 31, 32, 33, 34,
and 35 on button 1 without call waiting.
Hunting Configuration
Hunting allows a call to search for an available line to ring. This is commonly used in environments where call coverage
is needed to answer the same number, such as a call center or help desk. The preference command sets the order in
which the call will be tried on a list of ephone-dns; the huntstop command stops the hunting when it reaches that
ephone-dn; from this point, it is typical to send the call to voice mail.
The default is huntstop enabled. This can prevent calls from rolling over to the next ephone-dn, so the no huntstop
command must be used to allow the desired hunting behavior.
If dual-line ephone-dns are configured, the default behavior is for the call to hunt from the first line to the second. This
causes the same phone to ring twice for the same call.
The following configuration creates an ephone with two ephone-dns that both terminate calls to 1003. The huntstop
configuration sends calls to the first channel of ephone-dn 3, then the second channel of ephone-dn 3, then the first
channel of ephone-dn 4, then the second channel of ephone-dn 4.
Router(config)#ephone-dn 3 d u a l - l i ne
Router(config-ephone-dn)#number 1003
Router(config-ephone-dn)#preference 0
Router(config-ephone-dn)#no huntstop
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Router(config)#ephone-dn 4 d u a l - l i ne
Router(config-ephone-dn)#number 1003
Router(config-ephone-dn)#preference 1
Router(config-ephone-dn)#huntstop
Router(config)#ephone 3
Router(config-ephone)#mac-address AAAA.BBBB.CCCC
Router(config-ephone)#button 1:3 2:4
This is not necessarily the behavior we want; it is more common to use the second channel of an ephone-dn for transfer,
call waiting, or conferencing. We can force the call to hunt from channel 1 of the first ephone-dn directly to channel 1 of
the second ephone-dn instead, using the hunststop channel command. The following configuration will send the call
from channel 1 of ephone-dn 5 (on button 2) to channel 1 of ephone-dn 6 (on button 3), then to channel 2 of ephone-dn 6
(also on button 3):
Router(config)#ephone-dn 5 d u a l - l i ne
Router(config-ephone-dn#number 1004
Router(config-ephone-dn#preference 0
Router(config-ephone-dn#huntstop channel
Router(config)#ephone-dn 6 d u a l - l i ne
Router(config-ephone-dn#number 1004
Router(config-ephone-dn#preference 1
Router(config-ephone-dn#no huntstop channel
Router(config)#ephone 4
Router(config-ephone#mac-address AAAA.BBBB.CCCC
Router(config-ephone#button 2:5 3:6
In a call-coverage scenario, we would want the call to hunt to an agent who is not already on the phone. Here we configure
the call to hunt from channel 1 on the first phone to channel 1 on the second phone:
Router(config)#ephone-dn 5 d u a l - l i ne
Router(config-ephone-dn#number 1004
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Router(config-ephone-dn#preference 0
Router(config-ephone-dn#huntstop channel
Router(config)#ephone-dn 6 d u a l - l i ne
Router(config-ephone-dn#number 1004
Router(config-ephone-dn#preference 1
Router(config-ephone-dn#huntstop channel
Router(config)#ephone 4
Router(config-ephone#mac-address AAAA.BBBB.CCCC
Router(config-ephone#button 2:5
Router(config)#ephone 5
Router(config-ephone#mac-address DDDD.EEEE.FFFF
Router(config-ephone#button 2:6
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Unified CM Express is a router-based call agent that scales up to 240 phones, depending on platform capacity. The
system extends the benefits of Unified Communications to small businesses.
Unified CM Express supports a wide range of TP Phone, system, and trunk features, as well as voice-mail integration with
Unity, Unity Express, and third-party systems using H.323 or analog DTMF signaling. For a complete feature list, refer to
the Unified Communications Manager Express 4.2 Data Sheets on cisco.com.
Unified CM Express runs on the ISR platforms, including the 2800 and 3800 series, and on the 3700 series Multiservice
Access Routers. The appropriate IOS IP Voice feature set, along with IP Phone licenses and firmware, and flash and
RAM appropriate for the install are required. The optional GUI files may be installed for simplified configuration and
administration but are not required.
Unified CM Express supports all current-generation IP Phones.
Defining Ephone and Ephone-DN
An ephone is an Ethernet phone, and an ephone-dn is an Ethernet phone directory number. In CM Express, an ephone is a
logical configuration and settings for a physical phone, and the ephone-dn is a destination number that can be assigned to
multiple ephones.
An ephone-dn always has a primary directory number, and it may have a secondary one as well. When you create an
ephone-dn, you can specify it as single line (the default) or dual line. A single line can terminate one call; a dual line can
terminate two calls at the same time. This is necessary for call waiting, consultative transfer, and conferencing features
to work. When you create an ephone-dn, the router automatically creates POTS dial peers to match. The following
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
configuration creates a dual-line ephone-dn with a primary and secondary number. The number 20 in the configuration is
the tag, which is simply a unique identifier:
Router(config)#ephone-dn 20 d u a l - l i ne
Router(config-ephone-dn)#number 5309 secondary 8675309
There is a maximum number of ephone-dns that a given platform will support; this is controlled by the hardware capacity
and by licensing. The max-dn <max-dn-value> command must be set to create ephone-dns; the default is zero. Be aware
that the router immediately reserves memory for the number of dns you specify, whether they are created or not; you
should configure only what you will actually need.
An ephone is the logical configuration of a physical phone. Each ephone is given a tag to uniquely identify it. The MAC
address of the phone ties it to the ephone configuration. CM Express will detect all phone models except the 7914
sidecar, which must be specified manually. Each different model of IP Phone has a different number of buttons, to which
various functions can be applied; the top button is always numbered " 1 , " with the others following in numerical order.
The button command allows you to specify which button does what. The following configuration creates a basic ephone
for a 7960 with a 7914 sidecar; the button 1:20 command assigns button 1 the dn (5309) assigned to ephone-dn 20 from
the previous example:
r o u t e r ( c o n f i g ) # ephone 20
r o u t e r ( c o n f i g - e p h o n e ) # mac-address AAAA.BBBB.CCCC
r o u t e r ( c o n f i g - e p h o n e ) # type 7960 addon 1 7914
r o u t e r ( c o n f i g - e p h o n e ) # button 1:20
Types of ephone-dns
Six types of ephone-dns are configurable in CM Express:
• Single line: This ephone-dn creates a single virtual port. Although you can specify a secondary number, the phone
can terminate only one call at a time, so it cannot support call waiting. It should be used when there is one phone
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
button for each PSTN line that comes into the system. It is useful for things like paging, intercom, call-park slots,
MoH feeds, and MWI.
Router(config)#ephone-dn 1
Router(config-ephone-dn)#number 1001
• Dual line: The dual-line ephone-dn can support two call terminations at the same time and can have a primary and a
secondary number. It should be used when a single button supports call features like call waiting, transfer, and
conferencing. It should not be used for lines dedicated to intercom, paging, MoH feeds, MWI, or call park. It can be
used in combination with single-line ephone-dns on the same phone.
Router(config)#ephone-dn 2 d u a l - l i ne
Router(config-ephone-dn)#number 1002
• Dual number: This ephone-dn has a primary and secondary number, making it possible to dial two separate
numbers to reach the phone. It can be either a single- or dual-line ephone-dn; it should be used when you want to
have two numbers for the same button without using more than one ephone-dn.
• Shared ephone-dn: The same ephone-dn and number appears on two separate phones as a shared line, meaning that
either phone can use the line, but once in use the other cannot then make calls on that line. The line will ring on all
phones that share the ephone-dn, but only one can pick up. If the call is placed on hold, any one of the other phones
sharing the line can pick it up.
• Multiple ephone-dns on one or more ephones: This configuration allows multiple calls to the same extension to be
handled simultaneously on a single phone; for example, using three dual-line ephone-dns with the same number will
terminate six calls on the phone. By using multiple ephone-dns on multiple phones, all the phones can answer the
same number. This is not a shared line because the phones will ring in succession, and a call on hold can be
answered only by the phone that placed it on hold. Controlling the hunting behavior (the order in which buttons or
phones ring) is done with the preference and huntstop commands, as explained in the "Hunting Configuration"
section that follows.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Overlay ephone-dn: An overlay consists of two or more ephone-dns (up to 25) applied to the same button; all these
ephone-dns must be either single or dual line. (You can't mix the types.) The call coverage is similar to a shared-line
setup, except that a call to the number on one phone does not block the use of the same number on another phone.
You can overlay up to 10 lines on a single button and then configure the same overlay set on 10 phones, with the
result that all 10 phones could answer calls to the same number. The button command with the overlay separator
creates the overlay set. The overlay separator can be o, which designates an overlay set without call waiting, or c,
which designates call waiting. The command button lo30,31>32,33,34,35 c o n f j g u r e s ephone-dns 30, 31, 32, 33, 34,
and 35 on button 1 without call waiting.
Hunting Configuration
Hunting allows a call to search for an available line to ring. This is commonly used in environments where call coverage
is needed to answer the same number, such as a call center or help desk. The preference command sets the order in
which the call will be tried on a list of ephone-dns; the huntstop command stops the hunting when it reaches that
ephone-dn; from this point, it is typical to send the call to voice mail.
The default is huntstop enabled. This can prevent calls from rolling over to the next ephone-dn, so the no huntstop
command must be used to allow the desired hunting behavior.
If dual-line ephone-dns are configured, the default behavior is for the call to hunt from the first line to the second. This
causes the same phone to ring twice for the same call.
The following configuration creates an ephone with two ephone-dns that both terminate calls to 1003. The huntstop
configuration sends calls to the first channel of ephone-dn 3, then the second channel of ephone-dn 3, then the first
channel of ephone-dn 4, then the second channel of ephone-dn 4.
Router(config)#ephone-dn 3 d u a l - l i ne
Router(config-ephone-dn)#number 1003
Router(config-ephone-dn)#preference 0
Router(config-ephone-dn)#no huntstop
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Router(config)#ephone-dn 4 d u a l - l i ne
Router(config-ephone-dn)#number 1003
Router(config-ephone-dn)#preference 1
Router(config-ephone-dn)#huntstop
Router(config)#ephone 3
Router(config-ephone)#mac-address AAAA.BBBB.CCCC
Router(config-ephone)#button 1:3 2:4
This is not necessarily the behavior we want; it is more common to use the second channel of an ephone-dn for transfer,
call waiting, or conferencing. We can force the call to hunt from channel 1 of the first ephone-dn directly to channel 1 of
the second ephone-dn instead, using the hunststop channel command. The following configuration will send the call
from channel 1 of ephone-dn 5 (on button 2) to channel 1 of ephone-dn 6 (on button 3), then to channel 2 of ephone-dn 6
(also on button 3):
Router(config)#ephone-dn 5 d u a l - l i ne
Router(config-ephone-dn#number 1004
Router(config-ephone-dn#preference 0
Router(config-ephone-dn#huntstop channel
Router(config)#ephone-dn 6 d u a l - l i ne
Router(config-ephone-dn#number 1004
Router(config-ephone-dn#preference 1
Router(config-ephone-dn#no huntstop channel
Router(config)#ephone 4
Router(config-ephone#mac-address AAAA.BBBB.CCCC
Router(config-ephone#button 2:5 3:6
In a call-coverage scenario, we would want the call to hunt to an agent who is not already on the phone. Here we configure
the call to hunt from channel 1 on the first phone to channel 1 on the second phone:
Router(config)#ephone-dn 5 d u a l - l i ne
Router(config-ephone-dn#number 1004
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Router(config-ephone-dn#preference 0
Router(config-ephone-dn#huntstop channel
Router(config)#ephone-dn 6 d u a l - l i ne
Router(config-ephone-dn#number 1004
Router(config-ephone-dn#preference 1
Router(config-ephone-dn#huntstop channel
Router(config)#ephone 4
Router(config-ephone#mac-address AAAA.BBBB.CCCC
Router(config-ephone#button 2:5
Router(config)#ephone 5
Router(config-ephone#mac-address DDDD.EEEE.FFFF
Router(config-ephone#button 2:6
Quality of Service Best Cisco CCSP Course Training Institute in Delhi Gurgaon India
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Quality of service (QoS) is possibly the single most important feature to deploy to ensure a successful VoIP system. This
section defines and describes why QoS is needed and explains how to configure and deploy a QoS solution using both the
Modular QoS Command Line (MQC) and AutoQoS.
QoS Definition
QoS is defined as
The ability of the network to provide better or "special" service to a set of users and applications at the expense of other users and
applications.
Voice and video traffic is very sensitive to delayed packets, lost packets, and variable delay (jitter). The effects of these
problems manifest as choppy audio, missing sounds, echo, or unacceptably long pauses in the conversation that cause
overlap, or one talker interrupting the other. QoS configurations provide bandwidth guarantees while minimizing delay
and jitter for priority traffic like VoIP. They do so not by creating additional bandwidth, but by controlling how the available
bandwidth is used by the different applications and protocols on the network. In effect, this often means that data
applications and protocols are restricted from accessing bandwidth when VoIP traffic needs it. This does not have much of
an impact on the data traffic, however, because it is generally not as delay or drop-sensitive as VoIP traffic.
The areas that QoS can address to improve and guarantee voice quality are the following:
• Bandwidth
• Delay (including delay variation or jitter)
• Packet loss
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Bandwidth
A VoIP call follows a single path from end to end. That path may include a variety of LAN and WAN links. The slowest
link represents the available bandwidth for the entire path—often referred to as a bottleneck because of the congestion the
slow link can cause.
If congestion is occurring, there are several ways to fix the problem:
• Increase the bandwidth: If bandwidth is unlimited, congestion cannot occur. Realistically, however, increasing
bandwidth is costly and is usually unnecessary if QoS is applied instead.
• Queuing: QoS employs advanced queuing strategies, which classify different traffic types and organize the classes
into queues that are emptied in order of priority. The queuing strategies commonly used in Cisco Unified
Communications include the following:
• Weighted fair queuing (WFQ): WFQ dynamically assigns bandwidth to traffic flows as they arrive at the
router interface. No configuration is necessary; the strategy is enabled by default on router links of Tl speed
and below. This strategy is not appropriate for VoIP because it does not provide a bandwidth guarantee for the
voice traffic, but instead allocates bandwidth fairly based on flow sizes (hence the name). VoIP needs a Priority
queue (PQ) that guarantees it the bandwidth it needs, at the expense of all other traffic.
• Class-based weighted fair queuing (CBWFQ): CBWFQ extends the WFQ algorithm to include user-defined
classes for traffic. Instead of the router dynamically interpreting traffic flows and building queues for them, the
admin classifies the traffic and assigns it to queues of configurable size and bandwidth allocation. There is still
no priority queue, however, so CBWFQ is not appropriate for VoIP.
• Low-latency queuing (LLQ): LLQ extends the CBWFQ system with the addition of a PQ. The PQ is typically
reserved for voice traffic, and if any packets show up in the PQ, all packets in the queue are immediately sent
while packets of other traffic types are held in their respective queues. This is the preferred queuing method for
VoIP networks.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Compression: Several strategies are available to make the data that needs to be sent smaller so that it consumes less
bandwidth:
• Payload compression: By compacting the contents of a packet, the total size is somewhat reduced. This
compression method does not affect the headers, which makes it appropriate for links that require the header to
be readable to route the packet correctly (Frame Relay and ATM as examples).
• Link compression: On point-to-point links where the header information is not needed to route the packet, link
compression may be used.
• Header compression: By specifying the use of compressed RTP (cRTP), the Layer 3 and 4 headers of a VoIP
packet are dramatically reduced, from 40 to as little as 2 bytes. TCP header compression is also available for
non-VoIP traffic using TCP transport.
Compression takes time and CPU resources, adding delay; this must be factored in to the decision of what strategies are
appropriate for a given link.
Delay
Reducing end-to-end delay is a primary goal of QoS. Delay is calculated by adding the cumulative delay totals from
source to destination and will be expressed as one-way or round-trip. Delay is classified in the following ways:
• Fixed delay is predictable and constant. Sources of fixed delay include the following:
• Propagation delay: The amount of time it takes for the signal to transit the link. This is effectively the speed of
light as it moves through copper or optical media. Light travels just less than a foot in one-billionth of a second,
so long-distance links can impose significant delay that cannot be eliminated. L.A. to New York links routinely
see 40 ms one-way propagation delay.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Serialization delay: This is the time it takes to load bits onto the media; this relates directly to the speed of the
link and cannot be altered unless that speed is changed.
• Variable delay includes processing and queuing delays; these will vary depending on the traffic load, the router
performance, and many other factors that are not easily predictable or constant.
Minimizing delay employs the same strategies as improving bandwidth:
• Increase link speed.
• Use Priority queuing (such as LLQ) for delay-sensitive traffic.
• Employ appropriate compression techniques.
Packet Loss
Ideally, no packets of any type will be lost, but this is not realistic. We do need to minimize packet loss for VoIP traffic
because it has no mechanism to retransmit lost packets (unlike TCP, for example). Packets are lost for a variety of
reasons:
• Tail drop: When an output queue is full, no more arriving packets can be placed in the queue. Any packets that
arrive when the queue is full are dropped from the last position (tail) of the queue and cannot be recovered. This is
the most common source of packet loss.
• Input drop: If the input queue fills up, arriving packets are dropped and lost. This is rare, and it usually indicates an
overloaded router CPU.
• Overrun: Also the result of CPU congestion, overruns happen when the router cannot assign the packet to a free
buffer space.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Ignore: There is no buffer space available.
• Frame errors: Problems in transmission created CRC errors, giant or runt frames. This is usually related to EMI or
failing interface hardware.
Minimizing loss can be achieved with QoS mechanisms like LLQ and compression or by increasing link speed. Some
additional and complementary strategies known as Link Efficiency mechanisms will help to prevent congestion:
• Traffic shaping: Delays packets and sends them at a configured maximum rate. For example, if an FTP server is
generating a 512 kbps stream, shaping could limit the output to 256 kbps, delaying the transmission of the excess
traffic. This will add significant delay and might cause packets to be dropped, so it is not desirable to shape VoIP
traffic, but shaping data traffic is an effective tool to complement voice QoS settings.
• Traffic policing: Drops packets in excess of a configured threshold. These packets may be retransmitted if the traffic
is using TCP, but because VoIP does not, policing should not be applied to VoIP traffic. Again, policing is an effective
complement to QoS configurations.
QoS Requirements for VoIP
There are some accepted targets for delay, loss, and jitter for VoIP traffic. These are the targets that QoS and Link
Efficiency mechanisms help us reach:
• Delay should be less than 150 ms one way.
• Jitter (the variation in the delay between packets) should be less than 30 ms one way.
• Packet loss should be less than 1 percent.
• Each VoIP call requires between 17 kbps and 106 kbps of priority bandwidth, depending on the codec, compression,
and Layer 2 in use; it also requires another 150 bps per call for signaling traffic.
QoS Requirements for Data Traffic
Although data requirements are not as strict as those of VoIP, it is appropriate to classify the enterprise data traffic into
four or five classes and assign each a certain amount of bandwidth in its particular queue. The Cisco QoS classification
tools include Network-Based Application Recognition (NBAR), which makes it simple to classify traffic that would
otherwise be difficult or impossible.
The classifications you create will compose the QoS policy for the organization. The policy will reflect the actual needs
of both voice and data traffic on the network and will be a living document that will adapt to changes in the organization
and the applications it uses for business. A QoS policy is developed using the following process:
1. Perform a network audit to determine the current state of traffic on the network. Determine whether congestion problems
already exist, and list all applications discovered in current use.
2. Perform a business audit to determine where the applications in use fit into the business model. Some apps will be
characterized as critical to the business, some as routine, and some as trivial or perhaps even undesirable. It is not
uncommon to discover that the business executive had no idea some apps were in use, and a decision needs to be
made about how to treat all applications discovered, legitimate or otherwise.
3. Determine the level of service required for each app. This will range from Priority for voice and video, through
Mission Critical, Urgent, Routine and Scavenger, and even Disallowed. The names are not important; the ones used
here serve only to identify the relative importance of the apps as they are classified. Every business audit will generate
a slightly different picture of what is vital to the business and what is to be disallowed.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• The requirements for video are similar; bandwidth consumption is calculated as [video codec output] + 20 percent.
For example: a typical 384 kbps video stream should be allocated 460 kbps of priority bandwidth.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
4. Build the classification scheme to match the audit findings. Use the business audit and the executive's decisions to
create a classification scheme that lines up with the business needs.
5. Define the QoS settings for each traffic class. This may include a minimum and maximum bandwidth allocation, a
priority for each class, queuing strategies, and link efficiency methods, as appropriate.
AutoQoS
QoS configuration is one of the more advanced skills in the IOS CLI environment. Although it is essentially simple in
architecture, the many commands needed are intimidating and time consuming. AutoQoS is a feature available on voiceenabled
IOS platforms to greatly simplify and automate QoS configurations. AutoQoS generates traffic classes and
service policies using predefined templates, making an in-depth understanding of the commands unnecessary. In any environment
where there is a lack of skill or time, AutoQoS is a benefit. The autogenerated configuration adapts to changes
(such as the relocation of an IP Phone) and is manually customizable to meet specific requirements after the automated
config is completed. Auto QoS is available on all voice-enabled routers and switches with the correct IOS feature set.
Router AutoQoS is limited to the following interfaces:
• Serial PPP or HDLC links
• Frame Relay point-to-point links only
• ATM PVCs, both low- and high-speed
QoS Trust Boundary
One of the important concepts in QoS is the trust boundary—the point at which the QoS marking of a packet or frame is
believed by the switch or router. If it is trusted, the packet is treated according to the QoS marking and corresponding
policy. If it is not trusted, it may be re-marked and treated differently.
Ideally, we want to place the trust boundary as close to the source (the devices generating the traffic) as possible. This
means that the trust boundary should actually be between the IP Phone and the attached PC, because generally we do not
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
trust the PC, but we do trust the phone. If there is no phone, the trust boundary is between the switch and the PC. The
switch must be able to recognize and configure the trust boundary; if it cannot, we must move the boundary up to the
gateway router.
AutoQoS can automatically detect and configure the trust boundary by sensing a connected Cisco IP Phone and applying
the necessary QoS commands.
Configuring AutoQoS
The single command auto qos voip [trust] [fr-atm] enables AutoQoS at the interface. The keyword trust causes the
DSCP markings of packets to be trusted for classification purposes. If trust is not configured, traffic is classified using
NBAR, and the packets are DSCP marked as appropriate. The fr-atm keyword is used on Frame Relay and ATM pointto-
point links. The AutoQoS configurations are based on the configured bandwidth of the interface when AutoQoS is first
run; lowering the bandwidth after AutoQoS is run will not change the AutoQoS configurations, so AutoQoS must be
removed and reapplied if the bandwidth statement is changed.
On a switch interface, the keyword [ciscophone] enables the trusted boundary feature when the switch detects a Cisco
phone through its CDP messages. When a phone is detected, the QoS marking of packets is trusted; when no phone is
detected, the markings are not trusted.
Using the [trust] keyword on a switch interface causes the inbound QoS marking of packets to be trusted regardless of
whether a phone is detected.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Quality of service (QoS) is possibly the single most important feature to deploy to ensure a successful VoIP system. This
section defines and describes why QoS is needed and explains how to configure and deploy a QoS solution using both the
Modular QoS Command Line (MQC) and AutoQoS.
QoS Definition
QoS is defined as
The ability of the network to provide better or "special" service to a set of users and applications at the expense of other users and
applications.
Voice and video traffic is very sensitive to delayed packets, lost packets, and variable delay (jitter). The effects of these
problems manifest as choppy audio, missing sounds, echo, or unacceptably long pauses in the conversation that cause
overlap, or one talker interrupting the other. QoS configurations provide bandwidth guarantees while minimizing delay
and jitter for priority traffic like VoIP. They do so not by creating additional bandwidth, but by controlling how the available
bandwidth is used by the different applications and protocols on the network. In effect, this often means that data
applications and protocols are restricted from accessing bandwidth when VoIP traffic needs it. This does not have much of
an impact on the data traffic, however, because it is generally not as delay or drop-sensitive as VoIP traffic.
The areas that QoS can address to improve and guarantee voice quality are the following:
• Bandwidth
• Delay (including delay variation or jitter)
• Packet loss
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Bandwidth
A VoIP call follows a single path from end to end. That path may include a variety of LAN and WAN links. The slowest
link represents the available bandwidth for the entire path—often referred to as a bottleneck because of the congestion the
slow link can cause.
If congestion is occurring, there are several ways to fix the problem:
• Increase the bandwidth: If bandwidth is unlimited, congestion cannot occur. Realistically, however, increasing
bandwidth is costly and is usually unnecessary if QoS is applied instead.
• Queuing: QoS employs advanced queuing strategies, which classify different traffic types and organize the classes
into queues that are emptied in order of priority. The queuing strategies commonly used in Cisco Unified
Communications include the following:
• Weighted fair queuing (WFQ): WFQ dynamically assigns bandwidth to traffic flows as they arrive at the
router interface. No configuration is necessary; the strategy is enabled by default on router links of Tl speed
and below. This strategy is not appropriate for VoIP because it does not provide a bandwidth guarantee for the
voice traffic, but instead allocates bandwidth fairly based on flow sizes (hence the name). VoIP needs a Priority
queue (PQ) that guarantees it the bandwidth it needs, at the expense of all other traffic.
• Class-based weighted fair queuing (CBWFQ): CBWFQ extends the WFQ algorithm to include user-defined
classes for traffic. Instead of the router dynamically interpreting traffic flows and building queues for them, the
admin classifies the traffic and assigns it to queues of configurable size and bandwidth allocation. There is still
no priority queue, however, so CBWFQ is not appropriate for VoIP.
• Low-latency queuing (LLQ): LLQ extends the CBWFQ system with the addition of a PQ. The PQ is typically
reserved for voice traffic, and if any packets show up in the PQ, all packets in the queue are immediately sent
while packets of other traffic types are held in their respective queues. This is the preferred queuing method for
VoIP networks.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Compression: Several strategies are available to make the data that needs to be sent smaller so that it consumes less
bandwidth:
• Payload compression: By compacting the contents of a packet, the total size is somewhat reduced. This
compression method does not affect the headers, which makes it appropriate for links that require the header to
be readable to route the packet correctly (Frame Relay and ATM as examples).
• Link compression: On point-to-point links where the header information is not needed to route the packet, link
compression may be used.
• Header compression: By specifying the use of compressed RTP (cRTP), the Layer 3 and 4 headers of a VoIP
packet are dramatically reduced, from 40 to as little as 2 bytes. TCP header compression is also available for
non-VoIP traffic using TCP transport.
Compression takes time and CPU resources, adding delay; this must be factored in to the decision of what strategies are
appropriate for a given link.
Delay
Reducing end-to-end delay is a primary goal of QoS. Delay is calculated by adding the cumulative delay totals from
source to destination and will be expressed as one-way or round-trip. Delay is classified in the following ways:
• Fixed delay is predictable and constant. Sources of fixed delay include the following:
• Propagation delay: The amount of time it takes for the signal to transit the link. This is effectively the speed of
light as it moves through copper or optical media. Light travels just less than a foot in one-billionth of a second,
so long-distance links can impose significant delay that cannot be eliminated. L.A. to New York links routinely
see 40 ms one-way propagation delay.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Serialization delay: This is the time it takes to load bits onto the media; this relates directly to the speed of the
link and cannot be altered unless that speed is changed.
• Variable delay includes processing and queuing delays; these will vary depending on the traffic load, the router
performance, and many other factors that are not easily predictable or constant.
Minimizing delay employs the same strategies as improving bandwidth:
• Increase link speed.
• Use Priority queuing (such as LLQ) for delay-sensitive traffic.
• Employ appropriate compression techniques.
Packet Loss
Ideally, no packets of any type will be lost, but this is not realistic. We do need to minimize packet loss for VoIP traffic
because it has no mechanism to retransmit lost packets (unlike TCP, for example). Packets are lost for a variety of
reasons:
• Tail drop: When an output queue is full, no more arriving packets can be placed in the queue. Any packets that
arrive when the queue is full are dropped from the last position (tail) of the queue and cannot be recovered. This is
the most common source of packet loss.
• Input drop: If the input queue fills up, arriving packets are dropped and lost. This is rare, and it usually indicates an
overloaded router CPU.
• Overrun: Also the result of CPU congestion, overruns happen when the router cannot assign the packet to a free
buffer space.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• Ignore: There is no buffer space available.
• Frame errors: Problems in transmission created CRC errors, giant or runt frames. This is usually related to EMI or
failing interface hardware.
Minimizing loss can be achieved with QoS mechanisms like LLQ and compression or by increasing link speed. Some
additional and complementary strategies known as Link Efficiency mechanisms will help to prevent congestion:
• Traffic shaping: Delays packets and sends them at a configured maximum rate. For example, if an FTP server is
generating a 512 kbps stream, shaping could limit the output to 256 kbps, delaying the transmission of the excess
traffic. This will add significant delay and might cause packets to be dropped, so it is not desirable to shape VoIP
traffic, but shaping data traffic is an effective tool to complement voice QoS settings.
• Traffic policing: Drops packets in excess of a configured threshold. These packets may be retransmitted if the traffic
is using TCP, but because VoIP does not, policing should not be applied to VoIP traffic. Again, policing is an effective
complement to QoS configurations.
QoS Requirements for VoIP
There are some accepted targets for delay, loss, and jitter for VoIP traffic. These are the targets that QoS and Link
Efficiency mechanisms help us reach:
• Delay should be less than 150 ms one way.
• Jitter (the variation in the delay between packets) should be less than 30 ms one way.
• Packet loss should be less than 1 percent.
• Each VoIP call requires between 17 kbps and 106 kbps of priority bandwidth, depending on the codec, compression,
and Layer 2 in use; it also requires another 150 bps per call for signaling traffic.
QoS Requirements for Data Traffic
Although data requirements are not as strict as those of VoIP, it is appropriate to classify the enterprise data traffic into
four or five classes and assign each a certain amount of bandwidth in its particular queue. The Cisco QoS classification
tools include Network-Based Application Recognition (NBAR), which makes it simple to classify traffic that would
otherwise be difficult or impossible.
The classifications you create will compose the QoS policy for the organization. The policy will reflect the actual needs
of both voice and data traffic on the network and will be a living document that will adapt to changes in the organization
and the applications it uses for business. A QoS policy is developed using the following process:
1. Perform a network audit to determine the current state of traffic on the network. Determine whether congestion problems
already exist, and list all applications discovered in current use.
2. Perform a business audit to determine where the applications in use fit into the business model. Some apps will be
characterized as critical to the business, some as routine, and some as trivial or perhaps even undesirable. It is not
uncommon to discover that the business executive had no idea some apps were in use, and a decision needs to be
made about how to treat all applications discovered, legitimate or otherwise.
3. Determine the level of service required for each app. This will range from Priority for voice and video, through
Mission Critical, Urgent, Routine and Scavenger, and even Disallowed. The names are not important; the ones used
here serve only to identify the relative importance of the apps as they are classified. Every business audit will generate
a slightly different picture of what is vital to the business and what is to be disallowed.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
• The requirements for video are similar; bandwidth consumption is calculated as [video codec output] + 20 percent.
For example: a typical 384 kbps video stream should be allocated 460 kbps of priority bandwidth.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
4. Build the classification scheme to match the audit findings. Use the business audit and the executive's decisions to
create a classification scheme that lines up with the business needs.
5. Define the QoS settings for each traffic class. This may include a minimum and maximum bandwidth allocation, a
priority for each class, queuing strategies, and link efficiency methods, as appropriate.
AutoQoS
QoS configuration is one of the more advanced skills in the IOS CLI environment. Although it is essentially simple in
architecture, the many commands needed are intimidating and time consuming. AutoQoS is a feature available on voiceenabled
IOS platforms to greatly simplify and automate QoS configurations. AutoQoS generates traffic classes and
service policies using predefined templates, making an in-depth understanding of the commands unnecessary. In any environment
where there is a lack of skill or time, AutoQoS is a benefit. The autogenerated configuration adapts to changes
(such as the relocation of an IP Phone) and is manually customizable to meet specific requirements after the automated
config is completed. Auto QoS is available on all voice-enabled routers and switches with the correct IOS feature set.
Router AutoQoS is limited to the following interfaces:
• Serial PPP or HDLC links
• Frame Relay point-to-point links only
• ATM PVCs, both low- and high-speed
QoS Trust Boundary
One of the important concepts in QoS is the trust boundary—the point at which the QoS marking of a packet or frame is
believed by the switch or router. If it is trusted, the packet is treated according to the QoS marking and corresponding
policy. If it is not trusted, it may be re-marked and treated differently.
Ideally, we want to place the trust boundary as close to the source (the devices generating the traffic) as possible. This
means that the trust boundary should actually be between the IP Phone and the attached PC, because generally we do not
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
trust the PC, but we do trust the phone. If there is no phone, the trust boundary is between the switch and the PC. The
switch must be able to recognize and configure the trust boundary; if it cannot, we must move the boundary up to the
gateway router.
AutoQoS can automatically detect and configure the trust boundary by sensing a connected Cisco IP Phone and applying
the necessary QoS commands.
Configuring AutoQoS
The single command auto qos voip [trust] [fr-atm] enables AutoQoS at the interface. The keyword trust causes the
DSCP markings of packets to be trusted for classification purposes. If trust is not configured, traffic is classified using
NBAR, and the packets are DSCP marked as appropriate. The fr-atm keyword is used on Frame Relay and ATM pointto-
point links. The AutoQoS configurations are based on the configured bandwidth of the interface when AutoQoS is first
run; lowering the bandwidth after AutoQoS is run will not change the AutoQoS configurations, so AutoQoS must be
removed and reapplied if the bandwidth statement is changed.
On a switch interface, the keyword [ciscophone] enables the trusted boundary feature when the switch detects a Cisco
phone through its CDP messages. When a phone is detected, the QoS marking of packets is trusted; when no phone is
detected, the markings are not trusted.
Using the [trust] keyword on a switch interface causes the inbound QoS marking of packets to be trusted regardless of
whether a phone is detected.
Network Time Protocol Best CIsco CCNP Course Treaining Institute in Delhi Gurgaon India
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Clock synchronization is important in VoIP systems for accurate Call Detail Records (used for billing), easier troubleshooting
and debugging, and for good voice performance. Network Time Protocol (NTP) is used on all Cisco devices
to sync the system clock to a master clock. IP Phones get their time from the call agent (CM, CM Business Edition, CM
Express, or SBCS). The call agent(s) are configured to get their time from a master clock, usually a highly accurate
atomic or radio clock external to the network.
R o u t e r ( c o n f i g ) # c l o c k timezone pst -8
! S p e c i f i e s the l o c a l timezone as PST (8 hours behind GMT)
R o u t e r ( c o n f i g ) # c l o c k summer-time zone r e c u r r i n g f i r s t Sunday a p r i l 02:00 l a s t Sunday October 02:00
! A c t i v a t e s Summer Time change in the s p e c i f i e d date range
!
R o u t e r ( c o n f i g ) # n t p server 10.1.2.3
! I d e n t i f i e s the NTP master clock address
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Cisco IP Phone Firmware and XML Configuration Files
Cisco IP Phones need the following three separate files to function:
• The firmware file: This file is loaded into nonvolatile memory and is persistent across reboots. To make the
firmware files available to the phones, use the router command tftp-server flash:firmware-file-name. The command
load phone-type firmware-file is also required to associate the model of IP phone with the appropriate firmware file.
• SEPAAAABBBBCCCC.cnf.xml: This is the device-specific XML configuration file (AAAABBBBCCCC is the
MAC address of the phone), which specifies the IP address, port, firmware, locale, directory URL, and many other
pieces of information. This file is created when the IP Phone has been added to the configuration.
• XMLDefault.cnf.xml: This is the XML configuration file that devices use if their specific SEP<MAC> file is not
available (typically if they have not registered before or if they have been factory reset).
These files are downloaded by the phone during its boot process.
Power over Ethernet
Power over Ethernet (PoE) is a desirable option because it eliminates the cost and clutter of power bricks for the IP
Phones. There are two methods of PoE delivery:
• Cisco prestandard (inline power)
• 802.3af standard
Extra care should be taken to ensure the following:
• RJ-45 cabling is tested and meets the required standard.
• The IP Phone and the switch have a common PoE delivery method.
• The PoE switch has a suitable UPS backup to provide power continuance in the event of a power failure.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Alternatively, each IP Phone may be powered by its own cable and transformer, or a variety of power injectors are available.
The Cisco prestandard PoE method works as follows:
1. The switch sends a special tone, called a Fast Link Pulse (FLP), out of the port. The FLP goes to the powered
device, in this case an IP phone.
2. When unpowered, the PoE device has a physical link between the pin on which the FLP arrives and a pin that goes
back to the switch. This creates a circuit, resulting in the FLP arriving back at the switch. Non-PoE devices will not
have this link; the switch will therefore never receive the FLP from a device that does not require PoE.
3. When the switch receives the returning FLP, it applies power to the line.
4. The link comes up within 5 seconds.
5. The powered device (IP phone) boots.
6. Using CDP, the IP Phone tells the switch exactly how much power it needs. (Power requirements vary from device
to device.)
The 802.3af PoE standard works slightly differently. The standard requires that all eight pins in the RJ-45 cable be
present and punched down. The following describes the 802.3af PoE negotiation steps:
1. The switch applies constant DC power to all ports that may require PoE.
2. An 802.3af-compliant device will apply 25 ohms resistance across the DC circuit.
3. The switch detects the resistance and applies low-power PoE to the link.
4. The powered device (the phone) boots.
5. The phone uses CDP to specify its power needs.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Clock synchronization is important in VoIP systems for accurate Call Detail Records (used for billing), easier troubleshooting
and debugging, and for good voice performance. Network Time Protocol (NTP) is used on all Cisco devices
to sync the system clock to a master clock. IP Phones get their time from the call agent (CM, CM Business Edition, CM
Express, or SBCS). The call agent(s) are configured to get their time from a master clock, usually a highly accurate
atomic or radio clock external to the network.
R o u t e r ( c o n f i g ) # c l o c k timezone pst -8
! S p e c i f i e s the l o c a l timezone as PST (8 hours behind GMT)
R o u t e r ( c o n f i g ) # c l o c k summer-time zone r e c u r r i n g f i r s t Sunday a p r i l 02:00 l a s t Sunday October 02:00
! A c t i v a t e s Summer Time change in the s p e c i f i e d date range
!
R o u t e r ( c o n f i g ) # n t p server 10.1.2.3
! I d e n t i f i e s the NTP master clock address
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Cisco IP Phone Firmware and XML Configuration Files
Cisco IP Phones need the following three separate files to function:
• The firmware file: This file is loaded into nonvolatile memory and is persistent across reboots. To make the
firmware files available to the phones, use the router command tftp-server flash:firmware-file-name. The command
load phone-type firmware-file is also required to associate the model of IP phone with the appropriate firmware file.
• SEPAAAABBBBCCCC.cnf.xml: This is the device-specific XML configuration file (AAAABBBBCCCC is the
MAC address of the phone), which specifies the IP address, port, firmware, locale, directory URL, and many other
pieces of information. This file is created when the IP Phone has been added to the configuration.
• XMLDefault.cnf.xml: This is the XML configuration file that devices use if their specific SEP<MAC> file is not
available (typically if they have not registered before or if they have been factory reset).
These files are downloaded by the phone during its boot process.
Power over Ethernet
Power over Ethernet (PoE) is a desirable option because it eliminates the cost and clutter of power bricks for the IP
Phones. There are two methods of PoE delivery:
• Cisco prestandard (inline power)
• 802.3af standard
Extra care should be taken to ensure the following:
• RJ-45 cabling is tested and meets the required standard.
• The IP Phone and the switch have a common PoE delivery method.
• The PoE switch has a suitable UPS backup to provide power continuance in the event of a power failure.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Alternatively, each IP Phone may be powered by its own cable and transformer, or a variety of power injectors are available.
The Cisco prestandard PoE method works as follows:
1. The switch sends a special tone, called a Fast Link Pulse (FLP), out of the port. The FLP goes to the powered
device, in this case an IP phone.
2. When unpowered, the PoE device has a physical link between the pin on which the FLP arrives and a pin that goes
back to the switch. This creates a circuit, resulting in the FLP arriving back at the switch. Non-PoE devices will not
have this link; the switch will therefore never receive the FLP from a device that does not require PoE.
3. When the switch receives the returning FLP, it applies power to the line.
4. The link comes up within 5 seconds.
5. The powered device (IP phone) boots.
6. Using CDP, the IP Phone tells the switch exactly how much power it needs. (Power requirements vary from device
to device.)
The 802.3af PoE standard works slightly differently. The standard requires that all eight pins in the RJ-45 cable be
present and punched down. The following describes the 802.3af PoE negotiation steps:
1. The switch applies constant DC power to all ports that may require PoE.
2. An 802.3af-compliant device will apply 25 ohms resistance across the DC circuit.
3. The switch detects the resistance and applies low-power PoE to the link.
4. The powered device (the phone) boots.
5. The phone uses CDP to specify its power needs.
Preparing the Infrastructure to Support Unified Communications Best Cisco CCNA Course Training Institute in Delhi India
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
In this section, the best practices components for preparing the network to properly support Unified Communications are
explored. Topics covered include the following:
• Voice VLANs
• DHCP
• NTP
• Power over Ethernet
• IP Phone firmware and configuration files
Voice VLANs
VLANs provide a logical separation of Layer 3 traffic and are created at Layer 2 (the network switch). A voice VLAN
(VVLAN, also called an Auxiliary VLAN) is an additional VLAN for the exclusive use of VoIP and video traffic. The
benefits of using a VVLAN include isolation from the broadcast traffic data VLANs, a measure of additional security, and
simpler deployment because you do not have to renumber the IP address scheme of the whole network to add VoIP
endpoints. (Each VLAN is a new, separate subnet.)
Most Cisco IP Phones are actually 3-port switches. The port that connects to the network switch can act as an 802. lq
trunk, allowing both voice and data traffic to be multiplexed in their respective VLANs on the single cable to the network
switch. The second port connects the desktop PC to the phone (and thus to the network over the trunk on the first port),
and the third port is an internal one for the voice traffic generated and received by the phone.
On many Cisco switches, the port connecting the phone does not need to be a trunk; it can be an access port instead. The
switch is capable of sending the VVLAN ID using CDP messages, and the phone then sends frames from itself tagged
with the learned VVLAN ID and forwards frames from the attached PC untagged. These untagged frames will be tagged
with the access VLAN ID configured on the switch port when they are processed by the switch.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
The phone adds a QoS marking to its own frames, using the 802. lq frame header Class of Service (CoS) field. The phone
marks its frames as CoS 5 by default. This is the recommended setting, but it can be modified.
The following is a typical switchport configuration for an attached IP Phone in VVLAN 100 and the PC in VLAN 50:
S w i t c h ( c o n f i g ) # i n t e r f a c e FastEthernet 0/1
S w i t c h ( c o n f i g - i f ) # s w i t c h p o r t mode access
S w i t c h ( c o n f i g - i f ) # s w i t c h p o r t access vlan 50
S w i t c h ( c o n f i g - i f ) # s w i t c h p o r t voice vlan 100
S w i t c h ( c o n f i g - i f ) # s p a n n i n g - t r e e p o r t f a st
DHCP
It is recommended that you use DHCP for IP Phone addressing. Create a separate subnet for the Voice VLAN and add the
Option 150 parameter to identify the TFTP server IP address. This can be done on an existing DHCP server, or a new one
can be added if necessary; Cisco routers have DHCP server capability. The following configuration is a typical example
of router-based DHCP to support IP Phones:
s e r v i c e dhcp
! enables the DHCP s e r v i ce
I
ip dhcp excluded-address 10.1.1.1 10.1.1.10
! s p e c i f i e s a s t a r t / e n d range of addresses that DHCP w i l l NOT assign
ip dhcp pool name IP_PH0NES
! Creates a pool of addresses ( c a s e - s e n s i t i v e name) and enters DHCP c o n f i g u r a t i o n mode
I
network 10.1.1.0 255.255.255.0
! Defines the subnet of addresses f o r the pool
d e f a u l t - r o u t e r address 10.1.1.1
! Defines the d e f a u l t gateway
dns-server address 192.168.1.10 192.168.1.11
! i d e n t i f i e s the DNS server IP address(es) - up to 8 I P 's
!
o p t i o n 150 ip 192.168.1.2
! i d e n t i f i e s the TFTP server IP
If you choose to use a DHCP server that resides on a different network, you will need to add the ip helper-address
<ip-address> command on the Voice VLAN interface of the router so that it will forward DHCP broadcasts from the
phones to the DHCP server.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
In this section, the best practices components for preparing the network to properly support Unified Communications are
explored. Topics covered include the following:
• Voice VLANs
• DHCP
• NTP
• Power over Ethernet
• IP Phone firmware and configuration files
Voice VLANs
VLANs provide a logical separation of Layer 3 traffic and are created at Layer 2 (the network switch). A voice VLAN
(VVLAN, also called an Auxiliary VLAN) is an additional VLAN for the exclusive use of VoIP and video traffic. The
benefits of using a VVLAN include isolation from the broadcast traffic data VLANs, a measure of additional security, and
simpler deployment because you do not have to renumber the IP address scheme of the whole network to add VoIP
endpoints. (Each VLAN is a new, separate subnet.)
Most Cisco IP Phones are actually 3-port switches. The port that connects to the network switch can act as an 802. lq
trunk, allowing both voice and data traffic to be multiplexed in their respective VLANs on the single cable to the network
switch. The second port connects the desktop PC to the phone (and thus to the network over the trunk on the first port),
and the third port is an internal one for the voice traffic generated and received by the phone.
On many Cisco switches, the port connecting the phone does not need to be a trunk; it can be an access port instead. The
switch is capable of sending the VVLAN ID using CDP messages, and the phone then sends frames from itself tagged
with the learned VVLAN ID and forwards frames from the attached PC untagged. These untagged frames will be tagged
with the access VLAN ID configured on the switch port when they are processed by the switch.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
The phone adds a QoS marking to its own frames, using the 802. lq frame header Class of Service (CoS) field. The phone
marks its frames as CoS 5 by default. This is the recommended setting, but it can be modified.
The following is a typical switchport configuration for an attached IP Phone in VVLAN 100 and the PC in VLAN 50:
S w i t c h ( c o n f i g ) # i n t e r f a c e FastEthernet 0/1
S w i t c h ( c o n f i g - i f ) # s w i t c h p o r t mode access
S w i t c h ( c o n f i g - i f ) # s w i t c h p o r t access vlan 50
S w i t c h ( c o n f i g - i f ) # s w i t c h p o r t voice vlan 100
S w i t c h ( c o n f i g - i f ) # s p a n n i n g - t r e e p o r t f a st
DHCP
It is recommended that you use DHCP for IP Phone addressing. Create a separate subnet for the Voice VLAN and add the
Option 150 parameter to identify the TFTP server IP address. This can be done on an existing DHCP server, or a new one
can be added if necessary; Cisco routers have DHCP server capability. The following configuration is a typical example
of router-based DHCP to support IP Phones:
s e r v i c e dhcp
! enables the DHCP s e r v i ce
I
ip dhcp excluded-address 10.1.1.1 10.1.1.10
! s p e c i f i e s a s t a r t / e n d range of addresses that DHCP w i l l NOT assign
ip dhcp pool name IP_PH0NES
! Creates a pool of addresses ( c a s e - s e n s i t i v e name) and enters DHCP c o n f i g u r a t i o n mode
I
network 10.1.1.0 255.255.255.0
! Defines the subnet of addresses f o r the pool
d e f a u l t - r o u t e r address 10.1.1.1
! Defines the d e f a u l t gateway
dns-server address 192.168.1.10 192.168.1.11
! i d e n t i f i e s the DNS server IP address(es) - up to 8 I P 's
!
o p t i o n 150 ip 192.168.1.2
! i d e n t i f i e s the TFTP server IP
If you choose to use a DHCP server that resides on a different network, you will need to add the ip helper-address
<ip-address> command on the Voice VLAN interface of the router so that it will forward DHCP broadcasts from the
phones to the DHCP server.
Private Line Automatic Ringdown (PLAR) ccie course training in new delhi
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
PLAR creates a permanent association between a voice port and a destination number (or voice port). When PLAR is
configured, going off-hook on that voice port automatically dials the pattern specified by the connection plar <number>
command. The caller does not hear a dial tone and does not have to dial a number. Think of PLAR as a hotline; pick up
the Batline and you get Batman without having to dial.
The following shows a simple PLAR configuration that will call 867-5309 when the phone goes off-hook:
voice port 1/0/0
connection plar 8675309
Troubleshooting Dial Plans and Dial Peers
The following sections discuss some of the commands available to troubleshoot your configuration.
show dial-peer voice
To display information for voice dial peers, use the show dial-peer voice command in user EXEC or privileged EXEC
mode.
show d i a l - p e e r voice [number | summary]
Syntax Description
number (Optional) A specific voice dial peer. Output displays detailed information about that dial peer.
summary (Optional) Output displays a short summary of each voice dial peer.
If both the name argument and summary keyword are omitted, output displays detailed information about all voice dial
peers.
The following is sample output from this command for a VoIP dial peer:
Router# show d i a l - p e e r voice 101
VoiceOverIpPeer101
peer type = voice, i n f o r m a t i o n type = v o i c e,
d e s c r i p t i o n = ' ' ,
tag = 6001, d e s t i n a t i o n - p a t t e r n = " 6 0 0 1 ',
answer-address = ' ' , preference=0,
CLID R e s t r i c t i o n = None
CLID Network Number = "1
CLID Second Number sent
CLID Override RDNIS = d i s a b l e d,
source c a r r i e r - i d = target c a r r i e r - i d =
source t r u n k - g r o u p - l a b e l = ' ' , target t r u n k - g r o u p - l a b e l = ' ' ,
numbering Type = "unknown'
group = 6001, Admin s t a t e is up, Operation s t a t e is up,
incoming c a l l e d - number = connections/maximum = 0 / u n l i m i t e d,
DTMF Relay = d i s a b l e d,
<output omitted>
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
d i a l - p e e r hunt 0
PASS
TAG TYPE ADMIN OPER PREFIX DEST-PATTERN PREF THRU SESS TARGET
100 pots up up 0
101 voip up up 5550112 0 syst i p v4 10.10.1 1
102 voip up up 5550134 0 syst i p v4 10.10.1 1
99 voip up down 0 syst
33 pots up down 0
debug voip dialpeer inout
To display information about the voice dial peers, use the debug voip dialpeer command in privileged EXEC mode.
Router# debug voip dialpeer inout
v o i p dialpeer inout debugging is on
*May 1 19:32:11.731: //-1/6372E2598012/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) a f t e r DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=100
*May 1 19:32:11.731: //-1/6372E2598012/DPM/dpAssociateIncomingPeerCore:
C a l l i n g Number=4085550111, Called Number=3600, V o i c e - l n t e r f a c e = 0 x 0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer I n f o Type=DIALPEER_INFO_SPEECH
*May 1 19:32:11.731: //-1/6372E2598012/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) a f t e r DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=100
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersCore:
C a l l i n g Number=, Called Number=3600, Peer I n f o Type=DIALPEER_INFO_SPEECH
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
The following is sample output from this command with the summary keyword:
Router# show d i a l - p e e r voice summary
Troubleshooting Signaling for POTS Call Legs
show controllers t1
The show controllers tl command displays Tl (or E l ) controller status and function. The following is sample output
from this command:
Router# show c o n t r o l l e r s t1
T1 4/1 i s up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
Framing is ESF, Line Code is AMI, Clock Source is l i ne
Data in current i n t e r v a l (10 seconds elapsed):
0 Line Code V i o l a t i o n s , 0 Path Code V i o l a t i o n s 0 S l i p Sees, 0 Fr Loss Sees,
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=3600
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersCore:
Result=Success(0) a f t e r DP_MATCH_DEST
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
The following event shows the matched dial peers in the order of priority:
List of Matched Outgoing Dial Peer(s):
1: Dial PeerTag=3600
2: Dial Peer Tag=36
Connecting a VoIP System to a Service Provider Network
0 Line Err Sees, 0 Degraded Mins 0 Errored Sees, 0 Bursty Err Sees,
0 Severely Err Sees, 0 Unavail Sees
In this output, no alarms were detected. Possible alarms are as follows:
• Transmitter is sending remote alarm.
• Transmitter is sending AIS.
• Receiver has loss of signal.
• Receiver is getting AIS.
• Receiver has loss of frame.
• Receiver has remote alarm.
• Receiver has no alarms.
show voice port
Use the show voice port command to display configuration and voice-interface-card-specific information about a specific
port.
The following is sample output for an E&M analog voice port:
Router# show voice port 1/0/0
E&M Slot is 1, Sub-unit is 0, Port is 0
Type of VoicePort is E&M
Operation State is DORMANT
A d m i n i s t r a t i v e State is UP
I n i t i a l Time Out is set to 0 s
I n t e r d i g i t Time Out is set to 0 s
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Analog Info Follows:
Region Tone is set f o r northamerica
Voice card s p e c i f i c I n f o Follows:
Signal Type is w i n k - s t a rt
Operation Type is 2-wire
E&M Type is 1
D i a l Type is dtmf
I n Seizure is i n a c t i ve
Out Seizure is i n a c t i ve
show dialplan number
To display which outgoing dial peer is reached when a particular telephone number is dialed, use the show dialplan
number command in privileged EXEC mode.
Router# show d i a l p l a n number 1001
Macro Exp.: 1001
VoiceEncapPeer1003
i n f o r m a t i o n type = voice,
t ag = 1003, d e s t i n a t i o n - p a t t e r n = 1001',
answer-address = ' ' , preference=0,
numbering Type = 1 unknown'
group = 1003, Admin s t a t e is up, Operation s t a t e is up,
incoming called-number = ' ' , connections/maximum = 0 / u n l i m i t e d,
DTMF Relay = d i s a b l e d,
huntstop = enabled,
type = pots, p r e f i x = ' ' ,
f o r w a r d - d i g i t s default
s e s s i o n - t a r g e t = 1 ' , voice-port = '1/1'
debug voip ccapi inout
The debug voip ccapi inout command traces the execution path through the call control API, which serves as the interface
between the call session application and the underlying network-specific software. You can use the output from this
command to understand how calls are being handled by the router. This command shows how a call flows through the
system. Using this debug level, you can see the call setup and teardown operations performed on both the telephony and
network call legs.
Router# debug voip ccapi inout
v o i p ccapi inout debugging is on
NOTE
This debug generates a
very long output, which
is impractical to fully
duplicate here. I suggest
you familiarize yourself
with sample outputs from
the Cisco IOS Debug
Command Guide or
better yet from your own
lab experimentation.
The following lines show information about the calling and called numbers. The network presentation indicator (NPI)
shows the type of transmission. The Incoming Dial-Peer field shows that the incoming dial peer has been matched.
*Apr 18 20:42:19.347: //-1/9C5A9CA88009/CCAPI/cc_api_call_setup_ind_common:
Interface=0x64F26F10, Call I n f o(
Calling Number=4085550111(TON=National, NPI=ISDN, Screening=User, Passed,
Presentation=Allowed),
Called Number=83103(TON=Unknown, NPI=Unknown),
C a l l i n g Translated=FALSE, Subsriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
Incoming Dial-peer=1, Progress Indication=NULL(0), C a l l i n g IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call
Id=-1
*Apr 18 20:42:19.347: //-1/9C5A9CA88009/CCAPI/ccCheckClipClir:
I n : C a l l i n g Number=4085550111(TON=National, NPI=ISDN, Screening=User, Passed,
Presentation=Allowed)
*Apr 18 20:42:19.347: //-1/9C5A9CA88009/CCAPI/ccCheckClipClir:
Out: C a l l i n g Number=4085550111(TON=National, NPI=ISDN, Screening=User, Passed,
Presentation=Allowed)
© 2008
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
PLAR creates a permanent association between a voice port and a destination number (or voice port). When PLAR is
configured, going off-hook on that voice port automatically dials the pattern specified by the connection plar <number>
command. The caller does not hear a dial tone and does not have to dial a number. Think of PLAR as a hotline; pick up
the Batline and you get Batman without having to dial.
The following shows a simple PLAR configuration that will call 867-5309 when the phone goes off-hook:
voice port 1/0/0
connection plar 8675309
Troubleshooting Dial Plans and Dial Peers
The following sections discuss some of the commands available to troubleshoot your configuration.
show dial-peer voice
To display information for voice dial peers, use the show dial-peer voice command in user EXEC or privileged EXEC
mode.
show d i a l - p e e r voice [number | summary]
Syntax Description
number (Optional) A specific voice dial peer. Output displays detailed information about that dial peer.
summary (Optional) Output displays a short summary of each voice dial peer.
If both the name argument and summary keyword are omitted, output displays detailed information about all voice dial
peers.
The following is sample output from this command for a VoIP dial peer:
Router# show d i a l - p e e r voice 101
VoiceOverIpPeer101
peer type = voice, i n f o r m a t i o n type = v o i c e,
d e s c r i p t i o n = ' ' ,
tag = 6001, d e s t i n a t i o n - p a t t e r n = " 6 0 0 1 ',
answer-address = ' ' , preference=0,
CLID R e s t r i c t i o n = None
CLID Network Number = "1
CLID Second Number sent
CLID Override RDNIS = d i s a b l e d,
source c a r r i e r - i d = target c a r r i e r - i d =
source t r u n k - g r o u p - l a b e l = ' ' , target t r u n k - g r o u p - l a b e l = ' ' ,
numbering Type = "unknown'
group = 6001, Admin s t a t e is up, Operation s t a t e is up,
incoming c a l l e d - number = connections/maximum = 0 / u n l i m i t e d,
DTMF Relay = d i s a b l e d,
<output omitted>
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
d i a l - p e e r hunt 0
PASS
TAG TYPE ADMIN OPER PREFIX DEST-PATTERN PREF THRU SESS TARGET
100 pots up up 0
101 voip up up 5550112 0 syst i p v4 10.10.1 1
102 voip up up 5550134 0 syst i p v4 10.10.1 1
99 voip up down 0 syst
33 pots up down 0
debug voip dialpeer inout
To display information about the voice dial peers, use the debug voip dialpeer command in privileged EXEC mode.
Router# debug voip dialpeer inout
v o i p dialpeer inout debugging is on
*May 1 19:32:11.731: //-1/6372E2598012/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) a f t e r DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=100
*May 1 19:32:11.731: //-1/6372E2598012/DPM/dpAssociateIncomingPeerCore:
C a l l i n g Number=4085550111, Called Number=3600, V o i c e - l n t e r f a c e = 0 x 0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer I n f o Type=DIALPEER_INFO_SPEECH
*May 1 19:32:11.731: //-1/6372E2598012/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) a f t e r DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=100
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersCore:
C a l l i n g Number=, Called Number=3600, Peer I n f o Type=DIALPEER_INFO_SPEECH
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
The following is sample output from this command with the summary keyword:
Router# show d i a l - p e e r voice summary
Troubleshooting Signaling for POTS Call Legs
show controllers t1
The show controllers tl command displays Tl (or E l ) controller status and function. The following is sample output
from this command:
Router# show c o n t r o l l e r s t1
T1 4/1 i s up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
Framing is ESF, Line Code is AMI, Clock Source is l i ne
Data in current i n t e r v a l (10 seconds elapsed):
0 Line Code V i o l a t i o n s , 0 Path Code V i o l a t i o n s 0 S l i p Sees, 0 Fr Loss Sees,
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=3600
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersCore:
Result=Success(0) a f t e r DP_MATCH_DEST
*May 1 19:32:11.735: //-1/6372E2598012/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
The following event shows the matched dial peers in the order of priority:
List of Matched Outgoing Dial Peer(s):
1: Dial PeerTag=3600
2: Dial Peer Tag=36
Connecting a VoIP System to a Service Provider Network
0 Line Err Sees, 0 Degraded Mins 0 Errored Sees, 0 Bursty Err Sees,
0 Severely Err Sees, 0 Unavail Sees
In this output, no alarms were detected. Possible alarms are as follows:
• Transmitter is sending remote alarm.
• Transmitter is sending AIS.
• Receiver has loss of signal.
• Receiver is getting AIS.
• Receiver has loss of frame.
• Receiver has remote alarm.
• Receiver has no alarms.
show voice port
Use the show voice port command to display configuration and voice-interface-card-specific information about a specific
port.
The following is sample output for an E&M analog voice port:
Router# show voice port 1/0/0
E&M Slot is 1, Sub-unit is 0, Port is 0
Type of VoicePort is E&M
Operation State is DORMANT
A d m i n i s t r a t i v e State is UP
I n i t i a l Time Out is set to 0 s
I n t e r d i g i t Time Out is set to 0 s
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Analog Info Follows:
Region Tone is set f o r northamerica
Voice card s p e c i f i c I n f o Follows:
Signal Type is w i n k - s t a rt
Operation Type is 2-wire
E&M Type is 1
D i a l Type is dtmf
I n Seizure is i n a c t i ve
Out Seizure is i n a c t i ve
show dialplan number
To display which outgoing dial peer is reached when a particular telephone number is dialed, use the show dialplan
number command in privileged EXEC mode.
Router# show d i a l p l a n number 1001
Macro Exp.: 1001
VoiceEncapPeer1003
i n f o r m a t i o n type = voice,
t ag = 1003, d e s t i n a t i o n - p a t t e r n = 1001',
answer-address = ' ' , preference=0,
numbering Type = 1 unknown'
group = 1003, Admin s t a t e is up, Operation s t a t e is up,
incoming called-number = ' ' , connections/maximum = 0 / u n l i m i t e d,
DTMF Relay = d i s a b l e d,
huntstop = enabled,
type = pots, p r e f i x = ' ' ,
f o r w a r d - d i g i t s default
s e s s i o n - t a r g e t = 1 ' , voice-port = '1/1'
debug voip ccapi inout
The debug voip ccapi inout command traces the execution path through the call control API, which serves as the interface
between the call session application and the underlying network-specific software. You can use the output from this
command to understand how calls are being handled by the router. This command shows how a call flows through the
system. Using this debug level, you can see the call setup and teardown operations performed on both the telephony and
network call legs.
Router# debug voip ccapi inout
v o i p ccapi inout debugging is on
NOTE
This debug generates a
very long output, which
is impractical to fully
duplicate here. I suggest
you familiarize yourself
with sample outputs from
the Cisco IOS Debug
Command Guide or
better yet from your own
lab experimentation.
The following lines show information about the calling and called numbers. The network presentation indicator (NPI)
shows the type of transmission. The Incoming Dial-Peer field shows that the incoming dial peer has been matched.
*Apr 18 20:42:19.347: //-1/9C5A9CA88009/CCAPI/cc_api_call_setup_ind_common:
Interface=0x64F26F10, Call I n f o(
Calling Number=4085550111(TON=National, NPI=ISDN, Screening=User, Passed,
Presentation=Allowed),
Called Number=83103(TON=Unknown, NPI=Unknown),
C a l l i n g Translated=FALSE, Subsriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
Incoming Dial-peer=1, Progress Indication=NULL(0), C a l l i n g IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call
Id=-1
*Apr 18 20:42:19.347: //-1/9C5A9CA88009/CCAPI/ccCheckClipClir:
I n : C a l l i n g Number=4085550111(TON=National, NPI=ISDN, Screening=User, Passed,
Presentation=Allowed)
*Apr 18 20:42:19.347: //-1/9C5A9CA88009/CCAPI/ccCheckClipClir:
Out: C a l l i n g Number=4085550111(TON=National, NPI=ISDN, Screening=User, Passed,
Presentation=Allowed)
© 2008
Internet Telephony Service Providers ccsp course training in new delhi
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
As VoIP technology matured and stabilized, telephone service providers began extending VoIP connectivity to their
customers, allowing for simple, flexible connection alternatives to traditional TDM links. Internet Telephony Service
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Consider the following configuration:
d i a l - p e e r voice 10 voip
d e s t i n a t i o n - p a t t e r n .T
session target ipv4:10.10.10.1
i
d i a l peer voice 20 voip
d e s t i n a t i o n - p a t t e r n 8 6 7 [ 2 - 3 ] . ..
session target ipv4:10.10.20.1
!
d i a l - p e e r voice 30 voip
d e s t i n a t i o n - p a t t e r n 8674...
session t a r g e t ipv4: 10.10.30.1
i
d i a l - p e e r voice 40 voip
d e s t i n a t i o n - p a t t e r n 8675309
session t a r g e t i p v 4 : 1 0 . 1 0 . 4 0 .1
Given this configuration, the following example dialed numbers illustrate how the patterns match dialed digits:
• The dialed number 867-5309 will match dial peer 40 (exact 7-digit match)
• The dialed number 867-4309 will match dial peer 30 (first four digits match)
• The dialed number 867-3309 will match dial peer 20 (first four digits match)
• The dialed number 876-5309 will match dial peer 10 (no other exact match, so the ".T" pattern matches)
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Providers (ITSP) connections are typically much less expensive, available in smaller bandwidth increments than Tl or
PRI links, and can route nonvoice data traffic concurrently. QoS configuration is supported (and in fact is required for
proper VoIP operation). Most ITSP links use SIP, but H.323 is an option. The gateway configuration is relatively simple,
with the creation of a VoIP dial peer pointing at the provider with the parameters they supply. PSTN calls are routed to
the provider, who then routes calls to their PSTN connection, usually with a toll-minimizing route that dramatically
reduces long-distance costs to the customer.
Understanding Call Setup and Digit Manipulation
Successfully completing a phone call requires that the correct digits are sent to the terminating device, whether on the
VoIP network or the PSTN. PSTN calls are typically more complex because of the varying local and international
requirements for the number of digits required to route the call. Over and above this basic requirement are the additional
complexities imposed by requirements of the business: we may want to change our ANI number, add or strip access
codes, compensate for undesirable default behavior, or build specialized functionality for our particular purposes. This
section deals with digit manipulation and troubleshooting.
Digit Consumption and Forwarding
Some strange things happen when an IOS gateway matches a dial peer for an outbound call leg and forwards the dialed
digits to the terminating device.
For POTS dial peers, the gateway consumes (meaning strips away) the left-justified digits that exactly match the dial-peer
destination pattern and forwards only the wildcard-matched digits to the terminating device. Clearly, this could cause
problems if the PSTN were to receive only 4 digits, as in this example:
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 8 6 7 . . ..
port 1/0:1
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
With this configuration, if the dialed number was 867-5309, the gateway would forward only 5309 (the wildcard
matches), and the PSTN would be unable to route the call. Adding the command no digit-strip in the dial-peer configuration
will change this behavior and cause the gateway to forward all dialed digits.
For VoIP dial peers, the default behavior is to forward all collected digits.
Digit Collection
The router will collect digits one at a time and attempt to match a destination pattern. As soon as it has an exact match,
the call is immediately placed, and no more digits are collected. If there are destination patterns that have overlapping
digits, this can cause calls to be misrouted, as in the following example:
D i a l - p e e r voice 1 voip
D e s t i n a t i o n p a t t e r n 555
Session target i p v 4 : 1 0 . 1 . 1 .1
!
D i a l - p e e r voice 2 voip
D e s t i n a t i o n - p a t t e r n 5552112
Session t a r g e t i p v 4 : 1 0 . 2 . 2 .2
If the user dials 555-2112, dial peer 1 will exactly match at the third digit, the call will be immediately routed using dial
peer 1, and only the collected digits of 555 will be forwarded. We solve the problem by changing the configuration as
shown next:
D i a l - p e e r voice 1 voip
D e s t i n a t i o n p a t t e r n 5 5 5 . . ..
Session target i p v 4 : 1 0 . 1 . 1 .1
!
D i a l - p e e r voice 2 voip
D e s t i n a t i o n - p a t t e r n 5552112
Session t a r g e t i p v 4 : 1 0 . 2 . 2 .2
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Now, when the third digit is entered, the router cannot make an exact match because both dial peers are possible matches;
when the last digit is dialed, the router determines that dial peer 2 is an exact match and immediately places the call. Dial
peer 1 is also a match, but because of the wildcards, the destination pattern matches 10,000 possible numbers (0000
through 9999); it is not as close a match as dial peer 2.
Digit Manipulation
Sometimes we need to add, change, or remove digits before the call is placed. We do this to avoid inconveniencing users
or to match the dialed digit requirements of a gateway or the PSTN. We have several methods of modifying the digit
string, as described in the following sections.
prefix
The prefix dial-peer command adds digits to the beginning of the string after the outbound dial peer is matched but
before passing digits to the destination. An example of its use is a POTS dial peer with 2 . . . as the destination pattern. If
the user dials 2112, the default behavior is for the POTS dial peer to forward only 112. Adding the command prefix
6045552 forces the router to prepend the additional digits required to route the call over the PSTN:
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 2 . ..
p r e f i x 6045552
port 1/0/0
forward-digits
forward-digits: This dial-peer command forces the specified number of digits to be forwarded, whether the digits were
exact match or wildcard matches, overriding the default behavior of stripping the exact matches. You can specify a
number of digits to forward (as shown in the example that follows) or use forward-digits all to force all dialed digits to
be forwarded.
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 5552...
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
forward-digits 7
port 1/0/0
Number Expansion
num-exp: The number expansion table is a global command that either expands an extension (perhaps a 4-digit extension
into a full 10-digit PSTN number) or completely replaces one number with another. This command is applied before the
outbound dial peer is matched, so there must be a configured dial peer that matches the expanded number for the call to
be forwarded.
num-exp 2 . . . 5552...
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 5552...
port 1/0/0
Translation Rules
voice translation-rule: This global command configures number translation profiles to allow us to alter the ANI, DNIS,
or redirect number for a call. Using the command is a three-step process:
1. Define the translation rule globally:
voice t r a n s l a t i o n - r u l e 1
r u l e 1 /555/ /867/
The rule command defines a pattern to match (in this case 555) and a pattern to change the matched digits to (in this
case 867). The match and replace patterns are identified and separated by the "/" characters that begin and end the
patterns.
Cisco Regular Expression Characters for Voice Translation Rules
Character Description
Matches any single character.
\ (match) In the match phrase: Escape the special meaning of the next character.
\(replace) In the replace phrase: Reference a set number from the match phrase.
A Match the expression at the beginning of the digit string.
$ Match the expression at the end of the digit string.
/ Identifies the start and end of both the match and replace phrases.
[0-9] Match a single character in a list.
[A0-9] Do not match a single character specified in the list.
continues
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
2. Create the voice translation profile containing the translate instruction (the options are [calledlcallingl
redirect-calledlredirect-target], and reference the rule we just defined by number. In this example we are translating
the called number:
voice t r a n s l a t i o n - p r o f i l e JENNY
t r a n s l a t e c a l l e d 1
3. Apply the profile to one or more dial peers, either inbound or outbound:
d i a l - p e e r voice 20 pots
d e s c r i p t i o n t r a n s l a t e d to Jenny
t r a n s l a t i o n - p r o f i l e outgoing JENNY
d e s t i n a t i o n - p a t t e r n 5552...
port 1/0/0
Translation rules use regular expression syntax, which can be quite complex. The following table defines the characters
used, and examples follow.
* Repeat the previous expression 0 or more times.
+ Repeat the previous expression 1 or more times.
? Repeat the previous expression 0 or 1 time.
() Identifies a set in the match expression.
Example 1:
r u l e 1 /123/ /456/
The first set of forward slashes defines the match phrase; the second set defines the replace phrase. This expression means
"match 123 and replace it with 456." Thus:
• 123 is replaced with 456
• 6123 is replaced with 6456
• 1234 is replaced with 4564
• 1234123 is replaced with 4564123 (only the first instance of the match is replaced)
Example 2:
voice t r a n s l a t i o n ? r u l e 1
r u l e 1 / A 4 0 . . . / /66660B0/
This example replaces any five-digit number that begins with "40" with the number "6666000".
Example 3:
voice t r a n s l a t i o n ? r u l e 1
/ A \ ( 8 6 7 \ ) \ ( . . . . \ ) / /555\2/
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Cisco Regular Expression Characters for Voice Translation Rules continued
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
This example means: "If the number starts with 867 and is followed by any four other digits, change the 867 to 555 and
replace the other four digits with the digits in Set 2 of the match." Remember that the forward slashes define the match
and replace phrases; the backslashes mean "the next character is not part of what to match"; the round brackets indicate
which sets of characters in the matched number to keep in the replaced number. The sets are numbered starting with 1, so
the first set of round brackets is 1, and the second is 2 (as in this example).
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
As VoIP technology matured and stabilized, telephone service providers began extending VoIP connectivity to their
customers, allowing for simple, flexible connection alternatives to traditional TDM links. Internet Telephony Service
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Consider the following configuration:
d i a l - p e e r voice 10 voip
d e s t i n a t i o n - p a t t e r n .T
session target ipv4:10.10.10.1
i
d i a l peer voice 20 voip
d e s t i n a t i o n - p a t t e r n 8 6 7 [ 2 - 3 ] . ..
session target ipv4:10.10.20.1
!
d i a l - p e e r voice 30 voip
d e s t i n a t i o n - p a t t e r n 8674...
session t a r g e t ipv4: 10.10.30.1
i
d i a l - p e e r voice 40 voip
d e s t i n a t i o n - p a t t e r n 8675309
session t a r g e t i p v 4 : 1 0 . 1 0 . 4 0 .1
Given this configuration, the following example dialed numbers illustrate how the patterns match dialed digits:
• The dialed number 867-5309 will match dial peer 40 (exact 7-digit match)
• The dialed number 867-4309 will match dial peer 30 (first four digits match)
• The dialed number 867-3309 will match dial peer 20 (first four digits match)
• The dialed number 876-5309 will match dial peer 10 (no other exact match, so the ".T" pattern matches)
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Providers (ITSP) connections are typically much less expensive, available in smaller bandwidth increments than Tl or
PRI links, and can route nonvoice data traffic concurrently. QoS configuration is supported (and in fact is required for
proper VoIP operation). Most ITSP links use SIP, but H.323 is an option. The gateway configuration is relatively simple,
with the creation of a VoIP dial peer pointing at the provider with the parameters they supply. PSTN calls are routed to
the provider, who then routes calls to their PSTN connection, usually with a toll-minimizing route that dramatically
reduces long-distance costs to the customer.
Understanding Call Setup and Digit Manipulation
Successfully completing a phone call requires that the correct digits are sent to the terminating device, whether on the
VoIP network or the PSTN. PSTN calls are typically more complex because of the varying local and international
requirements for the number of digits required to route the call. Over and above this basic requirement are the additional
complexities imposed by requirements of the business: we may want to change our ANI number, add or strip access
codes, compensate for undesirable default behavior, or build specialized functionality for our particular purposes. This
section deals with digit manipulation and troubleshooting.
Digit Consumption and Forwarding
Some strange things happen when an IOS gateway matches a dial peer for an outbound call leg and forwards the dialed
digits to the terminating device.
For POTS dial peers, the gateway consumes (meaning strips away) the left-justified digits that exactly match the dial-peer
destination pattern and forwards only the wildcard-matched digits to the terminating device. Clearly, this could cause
problems if the PSTN were to receive only 4 digits, as in this example:
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 8 6 7 . . ..
port 1/0:1
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
With this configuration, if the dialed number was 867-5309, the gateway would forward only 5309 (the wildcard
matches), and the PSTN would be unable to route the call. Adding the command no digit-strip in the dial-peer configuration
will change this behavior and cause the gateway to forward all dialed digits.
For VoIP dial peers, the default behavior is to forward all collected digits.
Digit Collection
The router will collect digits one at a time and attempt to match a destination pattern. As soon as it has an exact match,
the call is immediately placed, and no more digits are collected. If there are destination patterns that have overlapping
digits, this can cause calls to be misrouted, as in the following example:
D i a l - p e e r voice 1 voip
D e s t i n a t i o n p a t t e r n 555
Session target i p v 4 : 1 0 . 1 . 1 .1
!
D i a l - p e e r voice 2 voip
D e s t i n a t i o n - p a t t e r n 5552112
Session t a r g e t i p v 4 : 1 0 . 2 . 2 .2
If the user dials 555-2112, dial peer 1 will exactly match at the third digit, the call will be immediately routed using dial
peer 1, and only the collected digits of 555 will be forwarded. We solve the problem by changing the configuration as
shown next:
D i a l - p e e r voice 1 voip
D e s t i n a t i o n p a t t e r n 5 5 5 . . ..
Session target i p v 4 : 1 0 . 1 . 1 .1
!
D i a l - p e e r voice 2 voip
D e s t i n a t i o n - p a t t e r n 5552112
Session t a r g e t i p v 4 : 1 0 . 2 . 2 .2
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Now, when the third digit is entered, the router cannot make an exact match because both dial peers are possible matches;
when the last digit is dialed, the router determines that dial peer 2 is an exact match and immediately places the call. Dial
peer 1 is also a match, but because of the wildcards, the destination pattern matches 10,000 possible numbers (0000
through 9999); it is not as close a match as dial peer 2.
Digit Manipulation
Sometimes we need to add, change, or remove digits before the call is placed. We do this to avoid inconveniencing users
or to match the dialed digit requirements of a gateway or the PSTN. We have several methods of modifying the digit
string, as described in the following sections.
prefix
The prefix dial-peer command adds digits to the beginning of the string after the outbound dial peer is matched but
before passing digits to the destination. An example of its use is a POTS dial peer with 2 . . . as the destination pattern. If
the user dials 2112, the default behavior is for the POTS dial peer to forward only 112. Adding the command prefix
6045552 forces the router to prepend the additional digits required to route the call over the PSTN:
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 2 . ..
p r e f i x 6045552
port 1/0/0
forward-digits
forward-digits: This dial-peer command forces the specified number of digits to be forwarded, whether the digits were
exact match or wildcard matches, overriding the default behavior of stripping the exact matches. You can specify a
number of digits to forward (as shown in the example that follows) or use forward-digits all to force all dialed digits to
be forwarded.
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 5552...
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
forward-digits 7
port 1/0/0
Number Expansion
num-exp: The number expansion table is a global command that either expands an extension (perhaps a 4-digit extension
into a full 10-digit PSTN number) or completely replaces one number with another. This command is applied before the
outbound dial peer is matched, so there must be a configured dial peer that matches the expanded number for the call to
be forwarded.
num-exp 2 . . . 5552...
d i a l - p e e r voice 20 pots
d e s t i n a t i o n - p a t t e r n 5552...
port 1/0/0
Translation Rules
voice translation-rule: This global command configures number translation profiles to allow us to alter the ANI, DNIS,
or redirect number for a call. Using the command is a three-step process:
1. Define the translation rule globally:
voice t r a n s l a t i o n - r u l e 1
r u l e 1 /555/ /867/
The rule command defines a pattern to match (in this case 555) and a pattern to change the matched digits to (in this
case 867). The match and replace patterns are identified and separated by the "/" characters that begin and end the
patterns.
Cisco Regular Expression Characters for Voice Translation Rules
Character Description
Matches any single character.
\ (match) In the match phrase: Escape the special meaning of the next character.
\(replace) In the replace phrase: Reference a set number from the match phrase.
A Match the expression at the beginning of the digit string.
$ Match the expression at the end of the digit string.
/ Identifies the start and end of both the match and replace phrases.
[0-9] Match a single character in a list.
[A0-9] Do not match a single character specified in the list.
continues
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
2. Create the voice translation profile containing the translate instruction (the options are [calledlcallingl
redirect-calledlredirect-target], and reference the rule we just defined by number. In this example we are translating
the called number:
voice t r a n s l a t i o n - p r o f i l e JENNY
t r a n s l a t e c a l l e d 1
3. Apply the profile to one or more dial peers, either inbound or outbound:
d i a l - p e e r voice 20 pots
d e s c r i p t i o n t r a n s l a t e d to Jenny
t r a n s l a t i o n - p r o f i l e outgoing JENNY
d e s t i n a t i o n - p a t t e r n 5552...
port 1/0/0
Translation rules use regular expression syntax, which can be quite complex. The following table defines the characters
used, and examples follow.
* Repeat the previous expression 0 or more times.
+ Repeat the previous expression 1 or more times.
? Repeat the previous expression 0 or 1 time.
() Identifies a set in the match expression.
Example 1:
r u l e 1 /123/ /456/
The first set of forward slashes defines the match phrase; the second set defines the replace phrase. This expression means
"match 123 and replace it with 456." Thus:
• 123 is replaced with 456
• 6123 is replaced with 6456
• 1234 is replaced with 4564
• 1234123 is replaced with 4564123 (only the first instance of the match is replaced)
Example 2:
voice t r a n s l a t i o n ? r u l e 1
r u l e 1 / A 4 0 . . . / /66660B0/
This example replaces any five-digit number that begins with "40" with the number "6666000".
Example 3:
voice t r a n s l a t i o n ? r u l e 1
/ A \ ( 8 6 7 \ ) \ ( . . . . \ ) / /555\2/
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Cisco Regular Expression Characters for Voice Translation Rules continued
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
This example means: "If the number starts with 867 and is followed by any four other digits, change the 867 to 555 and
replace the other four digits with the digits in Set 2 of the match." Remember that the forward slashes define the match
and replace phrases; the backslashes mean "the next character is not part of what to match"; the round brackets indicate
which sets of characters in the matched number to keep in the replaced number. The sets are numbered starting with 1, so
the first set of round brackets is 1, and the second is 2 (as in this example).
Connecting a VoIP System to a Service Provider Network ccnp course training in new delhi
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A VoIP system that can place calls only to other devices on the IP network is only marginally useful; we still need to
place calls out to the PSTN, and to do so we need to connect to a phone service provider, whether via traditional TDM
links or ITSP connections. The device that acts as the interface to the PSTN is the voice gateway; it provides the physical
connection and logical translation between two or more different network technologies.
Understanding Gateways, Voice Ports, and Dial Peers
The following sections establish some terms of reference.
Gateways
In the Cisco Unified Communications architecture, a gateway is typically a voice-enabled router with an appropriate
voice port installed and configured. Gateways can have both analog and digital voice port connections, including analog
FXO, FXS, and E&M or digital T l / E l or PRI interfaces.
Call Legs
A call leg is the inbound or outbound call path as it passes through the gateway. As the call comes into the gateway, it is
associated with an inbound port. (This is the inbound call leg.) As the call is sent out another gateway port, this creates
the outbound call leg. There will be inbound and outbound call legs at each gateway router.
Dial Peers
A dial peer is a pointer to an endpoint, identified by an address (a pattern of digits). Cisco gateways support two types of
dial peers: POTS and VoIP. POTS dial peers are addressed with PSTN phone numbers, and VoIP dial peers are addressed
by IP addresses. Dial peers identify the source and destination endpoints of call legs; an inbound call leg is matched to a
dial peer, and the outbound call leg is routed to a destination dial peer. Depending on the direction of the call, the dial peers
may be POTS inbound and VoIP outbound, vice versa, or possibly both VoIP. It is unlikely but not impossible that the
+ The preceding digit is repeated one or more times.
* and # NOT wildcards; these are valid DTMF digits.
, (comma) Inserts a one-second pause.
. (dot) Specifies any one wildcard digit (0 - 9, *, #). The pattern "20." would match all strings from 200 through 209, plus
20*and20#.
[ ] Square brackets define a range, within which any one digit may be matched; for example, "20[4-6]" defines 204, 205,
and 206.
T Indicates a variable length string; this is useful in cases where local, long-distance, and international PSTN numbers
may be called; the destination pattern could men be ".T". This pattern would match any string of up to 32 digits.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
inbound and outbound dial peers would both be POTS. Each dial peer also defines attributes such as the codec to use, QoS
settings, and other feature settings. Dial peers are configured in the gateway IOS, using either the CLI or GUI interface.
The partial output that follows shows a simple POTS dial peer configuration:
Gateway(config)#dial-peer voice 10 pots
G a t e w a y ( c o n f i g - d i a l p e e r ) # d e s t i n a t i o n - p a t t e r n 8675309
G a t e w a y ( c o n f i g - d i a l p e e r ) # p o r t 1/0/1
The number assigned to dial peers is arbitrary, although dial peer 0 exists by default and cannot be deleted. The keyword
pots creates a POTS dial peer; the keyword voip would create a VoIP dial peer. The destination-pattern command identifies
that the attached device (phone or PBX) terminates calls to the specified number (or a range of numbers if connecting
to a PBX). The port command identifies the physical hardware connection the dial peer will use to reach the
destination pattern.
The destination-pattern command associates a phone number with a dial peer. The specified pattern can be a specific
phone number (as above, 8675309) or an expression that defines a range of numbers. The router uses the patterns to
decide which dial peer (and associated physical port) it should route a call to. The following table briefly explains
destination-pattern syntax.
Character Meaning
Connecting a VoIP System to a Service Provider Network
Configuring VoIP dial peers is equally simple. Examine the following configuration:
Gateway(config)#dial-peer voice 20 voip
Gateway(config-dialpeer)# d e s t i n a t i o n - p a t t e r n 4 . . . .
Gateway(config-dialpeer)# session target i p v 4 : 1 0 . 1 . 1 .2
In this example, the destination pattern is any four-digit number starting with "4." A new command, session-target, is
used to identify the IP (version 4 in this case) address of the gateway or call agent that will terminate the call. If the IP
address is on a router, it should be a loopback IP so that the address is always available even if a physical interface fails.
The preceding configuration creates an H.323 dial peer (in contrast to a SIP dial-peer).
NOTE
The default dial peer 0
cannot be deleted or
modified. It does not
negotiate services such
as VAD, DTMF Relay, or
TCL applications. The
dial peer 0 configuration
for inbound VoIP calls
contains the following:
• Any codec
• VAD enabled
• No RSVP Support
• Fax-rate voice
Routers attempt to match dial peers for the inbound call leg according to the following rules:
1. Look for the incoming called-number command in a dial peer that matches the called number or DNIS string of the
inbound leg.
2. Look for the answer-address command in a dial peer that matches the calling number or ANI string of the inbound
call leg.
3. Look for the destination-pattern command in a dial peer that matches the calling number or ANI string of the
inbound call leg.
4. Look for the POTS dial peer port command that matches the voice port of the incoming call (POTS dial peers only).
5. If all of the above fail to match, match against Default Dial Peer 0 as a last resort.
The default dial peer 0 config for inbound POTS calls includes the following:
• no ivr application
When a router is matching the dialed digits against the patterns in the configured dial peers, it attempts to find the longest
match. This occurs on a digit-by-digit basis. Each successive digit may validate some patterns while eliminating others
until a single pattern represents the longest match between the dialed digits and the destination pattern, at which point the
call is routed to the outbound dial peer configured with that matching pattern.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Internet Telephony Service Providers
As VoIP technology matured and stabilized, telephone service providers began extending VoIP connectivity to their
customers, allowing for simple, flexible connection alternatives to traditional TDM links. Internet Telephony Service
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Consider the following configuration:
d i a l - p e e r voice 10 voip
d e s t i n a t i o n - p a t t e r n .T
session target ipv4:10.10.10.1
i
d i a l peer voice 20 voip
d e s t i n a t i o n - p a t t e r n 8 6 7 [ 2 - 3 ] . ..
session target ipv4:10.10.20.1
!
d i a l - p e e r voice 30 voip
d e s t i n a t i o n - p a t t e r n 8674...
session t a r g e t ipv4: 10.10.30.1
i
d i a l - p e e r voice 40 voip
d e s t i n a t i o n - p a t t e r n 8675309
session t a r g e t i p v 4 : 1 0 . 1 0 . 4 0 .1
Given this configuration, the following example dialed numbers illustrate how the patterns match dialed digits:
• The dialed number 867-5309 will match dial peer 40 (exact 7-digit match)
• The dialed number 867-4309 will match dial peer 30 (first four digits match)
• The dialed number 867-3309 will match dial peer 20 (first four digits match)
• The dialed number 876-5309 will match dial peer 10 (no other exact match, so the ".T" pattern matches)
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A VoIP system that can place calls only to other devices on the IP network is only marginally useful; we still need to
place calls out to the PSTN, and to do so we need to connect to a phone service provider, whether via traditional TDM
links or ITSP connections. The device that acts as the interface to the PSTN is the voice gateway; it provides the physical
connection and logical translation between two or more different network technologies.
Understanding Gateways, Voice Ports, and Dial Peers
The following sections establish some terms of reference.
Gateways
In the Cisco Unified Communications architecture, a gateway is typically a voice-enabled router with an appropriate
voice port installed and configured. Gateways can have both analog and digital voice port connections, including analog
FXO, FXS, and E&M or digital T l / E l or PRI interfaces.
Call Legs
A call leg is the inbound or outbound call path as it passes through the gateway. As the call comes into the gateway, it is
associated with an inbound port. (This is the inbound call leg.) As the call is sent out another gateway port, this creates
the outbound call leg. There will be inbound and outbound call legs at each gateway router.
Dial Peers
A dial peer is a pointer to an endpoint, identified by an address (a pattern of digits). Cisco gateways support two types of
dial peers: POTS and VoIP. POTS dial peers are addressed with PSTN phone numbers, and VoIP dial peers are addressed
by IP addresses. Dial peers identify the source and destination endpoints of call legs; an inbound call leg is matched to a
dial peer, and the outbound call leg is routed to a destination dial peer. Depending on the direction of the call, the dial peers
may be POTS inbound and VoIP outbound, vice versa, or possibly both VoIP. It is unlikely but not impossible that the
+ The preceding digit is repeated one or more times.
* and # NOT wildcards; these are valid DTMF digits.
, (comma) Inserts a one-second pause.
. (dot) Specifies any one wildcard digit (0 - 9, *, #). The pattern "20." would match all strings from 200 through 209, plus
20*and20#.
[ ] Square brackets define a range, within which any one digit may be matched; for example, "20[4-6]" defines 204, 205,
and 206.
T Indicates a variable length string; this is useful in cases where local, long-distance, and international PSTN numbers
may be called; the destination pattern could men be ".T". This pattern would match any string of up to 32 digits.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
inbound and outbound dial peers would both be POTS. Each dial peer also defines attributes such as the codec to use, QoS
settings, and other feature settings. Dial peers are configured in the gateway IOS, using either the CLI or GUI interface.
The partial output that follows shows a simple POTS dial peer configuration:
Gateway(config)#dial-peer voice 10 pots
G a t e w a y ( c o n f i g - d i a l p e e r ) # d e s t i n a t i o n - p a t t e r n 8675309
G a t e w a y ( c o n f i g - d i a l p e e r ) # p o r t 1/0/1
The number assigned to dial peers is arbitrary, although dial peer 0 exists by default and cannot be deleted. The keyword
pots creates a POTS dial peer; the keyword voip would create a VoIP dial peer. The destination-pattern command identifies
that the attached device (phone or PBX) terminates calls to the specified number (or a range of numbers if connecting
to a PBX). The port command identifies the physical hardware connection the dial peer will use to reach the
destination pattern.
The destination-pattern command associates a phone number with a dial peer. The specified pattern can be a specific
phone number (as above, 8675309) or an expression that defines a range of numbers. The router uses the patterns to
decide which dial peer (and associated physical port) it should route a call to. The following table briefly explains
destination-pattern syntax.
Character Meaning
Connecting a VoIP System to a Service Provider Network
Configuring VoIP dial peers is equally simple. Examine the following configuration:
Gateway(config)#dial-peer voice 20 voip
Gateway(config-dialpeer)# d e s t i n a t i o n - p a t t e r n 4 . . . .
Gateway(config-dialpeer)# session target i p v 4 : 1 0 . 1 . 1 .2
In this example, the destination pattern is any four-digit number starting with "4." A new command, session-target, is
used to identify the IP (version 4 in this case) address of the gateway or call agent that will terminate the call. If the IP
address is on a router, it should be a loopback IP so that the address is always available even if a physical interface fails.
The preceding configuration creates an H.323 dial peer (in contrast to a SIP dial-peer).
NOTE
The default dial peer 0
cannot be deleted or
modified. It does not
negotiate services such
as VAD, DTMF Relay, or
TCL applications. The
dial peer 0 configuration
for inbound VoIP calls
contains the following:
• Any codec
• VAD enabled
• No RSVP Support
• Fax-rate voice
Routers attempt to match dial peers for the inbound call leg according to the following rules:
1. Look for the incoming called-number command in a dial peer that matches the called number or DNIS string of the
inbound leg.
2. Look for the answer-address command in a dial peer that matches the calling number or ANI string of the inbound
call leg.
3. Look for the destination-pattern command in a dial peer that matches the calling number or ANI string of the
inbound call leg.
4. Look for the POTS dial peer port command that matches the voice port of the incoming call (POTS dial peers only).
5. If all of the above fail to match, match against Default Dial Peer 0 as a last resort.
The default dial peer 0 config for inbound POTS calls includes the following:
• no ivr application
When a router is matching the dialed digits against the patterns in the configured dial peers, it attempts to find the longest
match. This occurs on a digit-by-digit basis. Each successive digit may validate some patterns while eliminating others
until a single pattern represents the longest match between the dialed digits and the destination pattern, at which point the
call is routed to the outbound dial peer configured with that matching pattern.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Internet Telephony Service Providers
As VoIP technology matured and stabilized, telephone service providers began extending VoIP connectivity to their
customers, allowing for simple, flexible connection alternatives to traditional TDM links. Internet Telephony Service
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Consider the following configuration:
d i a l - p e e r voice 10 voip
d e s t i n a t i o n - p a t t e r n .T
session target ipv4:10.10.10.1
i
d i a l peer voice 20 voip
d e s t i n a t i o n - p a t t e r n 8 6 7 [ 2 - 3 ] . ..
session target ipv4:10.10.20.1
!
d i a l - p e e r voice 30 voip
d e s t i n a t i o n - p a t t e r n 8674...
session t a r g e t ipv4: 10.10.30.1
i
d i a l - p e e r voice 40 voip
d e s t i n a t i o n - p a t t e r n 8675309
session t a r g e t i p v 4 : 1 0 . 1 0 . 4 0 .1
Given this configuration, the following example dialed numbers illustrate how the patterns match dialed digits:
• The dialed number 867-5309 will match dial peer 40 (exact 7-digit match)
• The dialed number 867-4309 will match dial peer 30 (first four digits match)
• The dialed number 867-3309 will match dial peer 20 (first four digits match)
• The dialed number 876-5309 will match dial peer 10 (no other exact match, so the ".T" pattern matches)
Introducing VoIP Signaling Protocols ccna course training in new delhi
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
VoIP signaling protocols are responsible for call setup, maintenance, and teardown. A number of different protocols are in
use—some standards-based, others proprietary, and each with advantages and disadvantages. The following sections
introduce the signaling protocols you should know about, including SCCP, H.323, MGCP, and SIP.
VoIP Signaling Protocols
VoIP signaling protocols handle the call setup, maintenance, and teardown functions of VoIP calls. It is important to keep
in mind that the signaling functions are an entirely separate packet stream from the actual voice bearer path (RTP). The
signaling protocol in use must pass the supervisory, informational, and address information expected in any telephony
system.
VoIP signaling protocols are either peer-to-peer or client-server; in the case of peer-to-peer protocols, the endpoints have
the intelligence to perform the call-control signaling themselves, Client-server protocols send event notifications to the
call agent (the Unified CM server) and receive instructions on what actions to perform in response. The following table
summarizes the characteristics of the four signaling protocols dealt with here.
Inter-Vendor Implemented Implemented
Protocol Standard? Compatibility on Gateways on Cisco IP Phones Operating Mode
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
environments, it is a long-established and stable protocol very suitable for intervendor compatibility. H.323 is supported
by all Cisco voice gateways and CM platforms as well as some third-party video endpoints.
MGCP
Media Gateway Control Protocol is a lightweight client/server protocol for PSTN gateways and some clients. It is simple
to configure and allows the call agent to control the MGCP gateway, eliminating the need for expensive gateways with
intelligence and complex configurations. The gateway reports events such as a trunk going off-hook, and the call agent
instructs the gateway on what to do; the gateway has no local dial plan because all call routing decisions are made at the
call agent and relayed to the MGCP gateway. MGCP is not as widely implemented as SIP or H.323. MGCP is not
supported by Unified CM Express or the Smart Business Communication System.
SIP
Session Initiation Protocol is an IETF standard that uses peer-to-peer signaling. It is very similar in structure and syntax
to HTTP, and because it is text-based, it is relatively simple to debug and troubleshoot. SIP can use multiple transport
layer protocols and can support security and proxy functions. SIP is an evolving standard that currently provides basic
telephony functionality; further developments and extensions to the standard will soon make it feature-comparable with
SCCP. One of its most important capabilities is creating SIP trunks to IP Telephony service providers, replacing or
enhancing traditional TDM PSTN connections.
SCCP
Skinny Client Control Protocol is a Cisco-proprietary signaling protocol used in a client-server manner between Unified
CM and Cisco IP Phones (and some Cisco gateways). SCCP uses TCP connections to the Unified CM to set up, maintain,
and tear down voice and video calls. It is referred to as a stimulus protocol, meaning that it sends messages in response to
events such as a phone going off-hook or a digit being dialed. SCCP is the default signaling protocol for all Cisco IP
phones, although many also support SIP; SIP does not yet support the full feature set available to SCCP phones. All
Cisco Unified Communications call agents (CM, CM Express, and the 500 Series) and some gateways support SCCP.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
VoIP signaling protocols are responsible for call setup, maintenance, and teardown. A number of different protocols are in
use—some standards-based, others proprietary, and each with advantages and disadvantages. The following sections
introduce the signaling protocols you should know about, including SCCP, H.323, MGCP, and SIP.
VoIP Signaling Protocols
VoIP signaling protocols handle the call setup, maintenance, and teardown functions of VoIP calls. It is important to keep
in mind that the signaling functions are an entirely separate packet stream from the actual voice bearer path (RTP). The
signaling protocol in use must pass the supervisory, informational, and address information expected in any telephony
system.
VoIP signaling protocols are either peer-to-peer or client-server; in the case of peer-to-peer protocols, the endpoints have
the intelligence to perform the call-control signaling themselves, Client-server protocols send event notifications to the
call agent (the Unified CM server) and receive instructions on what actions to perform in response. The following table
summarizes the characteristics of the four signaling protocols dealt with here.
Inter-Vendor Implemented Implemented
Protocol Standard? Compatibility on Gateways on Cisco IP Phones Operating Mode
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
environments, it is a long-established and stable protocol very suitable for intervendor compatibility. H.323 is supported
by all Cisco voice gateways and CM platforms as well as some third-party video endpoints.
MGCP
Media Gateway Control Protocol is a lightweight client/server protocol for PSTN gateways and some clients. It is simple
to configure and allows the call agent to control the MGCP gateway, eliminating the need for expensive gateways with
intelligence and complex configurations. The gateway reports events such as a trunk going off-hook, and the call agent
instructs the gateway on what to do; the gateway has no local dial plan because all call routing decisions are made at the
call agent and relayed to the MGCP gateway. MGCP is not as widely implemented as SIP or H.323. MGCP is not
supported by Unified CM Express or the Smart Business Communication System.
SIP
Session Initiation Protocol is an IETF standard that uses peer-to-peer signaling. It is very similar in structure and syntax
to HTTP, and because it is text-based, it is relatively simple to debug and troubleshoot. SIP can use multiple transport
layer protocols and can support security and proxy functions. SIP is an evolving standard that currently provides basic
telephony functionality; further developments and extensions to the standard will soon make it feature-comparable with
SCCP. One of its most important capabilities is creating SIP trunks to IP Telephony service providers, replacing or
enhancing traditional TDM PSTN connections.
SCCP
Skinny Client Control Protocol is a Cisco-proprietary signaling protocol used in a client-server manner between Unified
CM and Cisco IP Phones (and some Cisco gateways). SCCP uses TCP connections to the Unified CM to set up, maintain,
and tear down voice and video calls. It is referred to as a stimulus protocol, meaning that it sends messages in response to
events such as a phone going off-hook or a digit being dialed. SCCP is the default signaling protocol for all Cisco IP
phones, although many also support SIP; SIP does not yet support the full feature set available to SCCP phones. All
Cisco Unified Communications call agents (CM, CM Express, and the 500 Series) and some gateways support SCCP.
Time Division Multiplexing (TDM) ccie certication training institute in gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
TDM is the primary technology used in traditional digital voice; it is also extensively used in data circuits. The basic
premise is to take pieces of multiple streams of digital data and interleave them on a single transmission medium.
T1 Circuits
On a Tl circuit, there are up to 24 channels available for voice. 64k from conversation 1 is loaded into the first Tl
channel, then 64k from the conversation 2 is loaded into the second channel, and so on. If not enough conversations exist
to fill the available channels, they are padded with null values. The 24 channels are grouped together as a frame.
Depending on the implementation, either 12 frames are grouped together as a larger frame (called SuperFrame or SF), or
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
24 frames are grouped together (called Extended SuperFrame or ESF). T l s are typically full duplex, with two wires
sending and the other two wires receiving.
E1 Circuits
An El is very similar to a T l . There are 32 channels, of which 30 can be used for voice. (The other two are used for
framing and signaling, respectively.) The 32 channels are grouped together as a frame, and 16 frames are grouped
together as a multiframe. El circuits are common in Europe and Mexico, with some El services becoming available in
the United States.
Channel Associated Signaling (CAS)—T1
Although the 64 k channels of a Tl are intended to carry digitized voice, we must also be able to transmit signaling information,
such as on-hook and off-hook, addressing, and so forth. In CAS circuits, the least significant bit of each channel
in every sixth frame is "stolen" to generate signaling bit strings. SF implementation takes 12 frames and creates a
SuperFrame. Using one bit per channel in every sixth frame gives two 12-bit signaling strings (known as A and B) per
SuperFrame. The A and B strings are used to signal basic status, addressing, and supervisory messages. In ESF, 24 channels
are in an Extended SuperFrame, which gives A, B, C, and D signaling strings. These can be used to signal more
advanced supervisory functions.
Because CAS takes one bit from each channel in every sixth frame, it is known as Robbed Bit Signaling (RBS). Using
RBS means that a slight degradation occurs in voice quality because every sixth frame has only 7 instead of 8 bits to
represent the sample; however, this is not generally a perceptible degradation.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Channel Associated Signaling (CAS)—T1
El signaling is slightly different. In an El CAS circuit, the first channel (channel 0 or timeslot 1) is reserved for framing
information. The 17th channel (channel 16 or timeslot 17) contains signaling information—no bits are robbed from the
individual channels. Timeslots 2-16 and 18-32 carry the voice data. Each channel has specific bits in timeslot 17 for
signaling. This means that although El CAS does not use RBS, it is still considered CAS; however, the signaling is outof-
band in its own timeslot.
Common Channel Signaling (CCS)
CCS provides for a completely out-of-band signaling channel. This is the function of the D channel in an ISDN PRI or
BRI implementation. The full 64 k of bandwidth per channel is available for voice; instead of generating ABCD bits, a
protocol known as Q.931 is used out-of-band in a separate channel for signaling. An ISDN PRI Tl provides 23 voice
channels of 64 k each (called Bearer or B channels) and one 64 k D (for Data) channel (timeslot 24) for signaling. An
ISDN PRI El provides 30 B channels and 1 D channel (timeslot 17); an ISDN BRI circuit provides two 64 k B channels
and one D channel of 16 k.
Understanding Packetization
IP networks move data around in small pieces known as packets. Because we know how to digitize our voice, it now
becomes just another binary payload to move around in a packet. VoIP uses Digital Signal Processors (DSP) for the codec
functions. The digitized voice is then packaged in an appropriate protocol structure to move it through the IP infrastructure.
DSPs
DSPs are specialized chips that perform high-speed codec functions. DSPs are found in the IP phones to encode the
analog speech of the user and to decode the digitized contents of the packets arriving from the other end of the call. DSPs
are also used on IOS gateways at the interface to PSTN circuits, to change from a digital circuit to packetized voice, or
from an analog circuit to packetized voice. DSPs also change from one codec to another, allow conferencing and call
park, and other telephony features. DSPs are a vital component of a VoIP system. Different chip types have varying
capacities, but the general rule is that you want as many DSP resources available to you as possible. The DSP calculator
on cisco.com will help you calculate what you must have.
Real-Time Transport Protocol (RTP)
RTP was developed to better serve real-time traffic such as voice and video. Voice payloads are encapsulated by RTP, then
by UDP, then by IP. A Layer 2 header of the correct format is applied; the type obviously depends on the link technology
in use by each router interface. A single voice call generates two one-way RTP/UDP/IP packet streams. UDP provides
multiplexing and checksum capability; RTP provides payload identification, timestamps, and sequence numbering.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Understanding VoIP
The elements of traditional telephony—status, address and supervisory signaling, digitization, and so on—must have
functional parallels in the VoIP world for systems to function as people expect them to, and more importantly, for VoIP to
interact with the PSTN properly.
This section examines packetizing digital voice, signaling, and transport protocols, the components of a VoIP network,
and the factors that can cause problems in VoIP networks and how they can be mitigated.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Payload identification allows us to treat voice traffic differently from video, for example, simply by looking for the RTP
header label, simplifying our configuration tasks. Timestamping and sequence numbering allows VoIP devices to reorder
RTP packets that arrived out of sequence and play them back with the same timing in which they were recorded, eliminating
delays or jerkiness. There is no provision for retransmission of a lost RTP packet.
Each RTP stream is accompanied by a Real-Time Transport Control Protocol (RTCP) stream. RTCP monitors the quality
of the RTP stream, allowing devices to record events such as packet count, delay, loss, and jitter (delay variation).
A single voice packet by default contains a payload of 20 msec of voice (either uncompressed or compressed). Because
sampling is occurring at 8000 times per second, 20 msec gives us 160 samples. If we divide 8000 by 160, we see that we
are generating 50 packets with 160 bytes of payload, per second, for a one-way voice stream.
If we use compression, we can squeeze the 160-byte payload down to 20 bytes using the G.729 codec. We still have 160
samples, still 20 msec of audio, but reduced payload size.
Codecs
The codecs supported by Cisco include the following:
• G.711 (64kbps)—Toll-quality voice, uncompressed.
• G.729 (8kbps)
• Annex A variant: less processor-intensive, allows more voice channels encoded per DSP chip; lower audio
quality than G.729
• Annex B variant: Allows the use of Voice Activity Detection and Comfort Noise Generation; can be applied to
G.729 or G.729-A
The values for bandwidth shown do not include the Layer 3 and Layer 2 overhead; the actual bandwidth used by a single
(one-way) voice stream can be significantly larger. The following tables summarize the additional overhead added by
packetization and Layer 2 encapsulation (assume 50 packets per second (pps):
Bandwidth Calculation, Without Layer 2
Codec G.711 G.729
Voice Payload 160 Bytes 20 Bytes
RTP Header 12 Bytes 12 Bytes
UDP Header 8 Bytes 8 Bytes
IP Header 20 Bytes 20 Bytes
Total Before Layer 2 200 Bytes 60 Bytes
Total Bitrate @ 50 pps 80,000 bps (80 kbps) 24,000 bps (24 kbps)
Bandwidth Calculation, With Layer 2
Layer 2 Type G.711 = 200 Bytes/packet G.729 = 60 Bytes/packet
Ethernet 18 Bytes 18 Bytes
Multilink PPP 6 Bytes 6 Bytes
Frame Relay FRF. 12 6 Bytes 6 Bytes
Total incl. Layer 2 218 Bytes 206 Bytes 206 Bytes 78 Bytes 66 Bytes 66 Bytes
Total Bitrate incl. Layer 2
(@ 50 pps)
87.200 82,400 82,400
(87.2 kbps) (82.4 kbps) (82.4 kbps)
31,200 26,400 26,400
(31.2 kbps) (26.4 kbps) (26.4 kbps)
When using G.729, the RTP/UDP/IP header of 40 bytes is twice the size of the 20B voice payload. This consumes significant
bandwidth just for header transmission on a slow link. The recommended solution is to use Compressed RTP
(cRTP) on slow WAN links. cRTP reduces the RTP/UDP/IP header to 2 bytes without checksums or 4 bytes with checksums.
The effect of using cRTP is illustrated in the following table. (Note: Ethernet is not included because it is not classified
as a slow link.)
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Bandwidth Calculation, Using cRTP
Codec G.711 G.729
Voice Payload 160 Bytes 20 Bytes
cRTP header w/ chksum 4 Bytes 4 Bytes
cRTP header no chksum 2 Bytes 2 Bytes
Total before Layer 2: 164 Bytes 162 Bytes 24 Bytes 22 Bytes
Multilink PPP or
Frame Relay FRF. 12 6 Bytes 6 Bytes
Total WAN bandwidth @50 pps incl. Layer 2: 68000 bps 67,200 bps
(68 kbps) (67.2 kbps)
12,000 bps 11,200
(12 kbps) (11.2 kbps)
Voice Activity Detection (VAD)
Phone conversations on average include about 35% silence. In Cisco Unified Communications, by default silence is packetized
and transmitted, consuming the same bandwidth as speech. In situations where bandwidth is very scarce, the VAD
feature can be enabled, causing the voice stream to be stopped during periods of silence. The theory here is that the bandwidth
otherwise used for silence can be reclaimed for voice or data transmission. VAD also adds Comfort Noise
Generation (CNG), which fills in the dead silence created by the stopped voice flow with white noise. VAD should not be
taken into account during the network design bandwidth allocation process because its effectiveness varies with background
noise and speech patterns. VAD is also made ineffective by Music on Hold and fax features. In reality, VAD typically
causes more problems than it solves, and it is usually wiser to add the necessary bandwidth.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Additional DSP Functions
In addition to digitizing voice, DSP resources are used for the following:
• Conferencing: DSPs mix the audio streams from the conference participants and transmit the mix (minus their own)
to each participant.
• Transcoding and Media Termination Points (MTP): A transcoder changes a packetized audio stream from one
codec to another, perhaps for transit across a slow WAN link. MTPs provide a point for the stream to be terminated
while other services are set up.
• Echo Cancellation: DSPs provide the calculation power needed to analyze the audio stream and filter out the repetitive
patterns that indicate echo. Echo is a chief cause of perceived poor voice quality; echo cancellation is an important
function.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
TDM is the primary technology used in traditional digital voice; it is also extensively used in data circuits. The basic
premise is to take pieces of multiple streams of digital data and interleave them on a single transmission medium.
T1 Circuits
On a Tl circuit, there are up to 24 channels available for voice. 64k from conversation 1 is loaded into the first Tl
channel, then 64k from the conversation 2 is loaded into the second channel, and so on. If not enough conversations exist
to fill the available channels, they are padded with null values. The 24 channels are grouped together as a frame.
Depending on the implementation, either 12 frames are grouped together as a larger frame (called SuperFrame or SF), or
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
24 frames are grouped together (called Extended SuperFrame or ESF). T l s are typically full duplex, with two wires
sending and the other two wires receiving.
E1 Circuits
An El is very similar to a T l . There are 32 channels, of which 30 can be used for voice. (The other two are used for
framing and signaling, respectively.) The 32 channels are grouped together as a frame, and 16 frames are grouped
together as a multiframe. El circuits are common in Europe and Mexico, with some El services becoming available in
the United States.
Channel Associated Signaling (CAS)—T1
Although the 64 k channels of a Tl are intended to carry digitized voice, we must also be able to transmit signaling information,
such as on-hook and off-hook, addressing, and so forth. In CAS circuits, the least significant bit of each channel
in every sixth frame is "stolen" to generate signaling bit strings. SF implementation takes 12 frames and creates a
SuperFrame. Using one bit per channel in every sixth frame gives two 12-bit signaling strings (known as A and B) per
SuperFrame. The A and B strings are used to signal basic status, addressing, and supervisory messages. In ESF, 24 channels
are in an Extended SuperFrame, which gives A, B, C, and D signaling strings. These can be used to signal more
advanced supervisory functions.
Because CAS takes one bit from each channel in every sixth frame, it is known as Robbed Bit Signaling (RBS). Using
RBS means that a slight degradation occurs in voice quality because every sixth frame has only 7 instead of 8 bits to
represent the sample; however, this is not generally a perceptible degradation.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Channel Associated Signaling (CAS)—T1
El signaling is slightly different. In an El CAS circuit, the first channel (channel 0 or timeslot 1) is reserved for framing
information. The 17th channel (channel 16 or timeslot 17) contains signaling information—no bits are robbed from the
individual channels. Timeslots 2-16 and 18-32 carry the voice data. Each channel has specific bits in timeslot 17 for
signaling. This means that although El CAS does not use RBS, it is still considered CAS; however, the signaling is outof-
band in its own timeslot.
Common Channel Signaling (CCS)
CCS provides for a completely out-of-band signaling channel. This is the function of the D channel in an ISDN PRI or
BRI implementation. The full 64 k of bandwidth per channel is available for voice; instead of generating ABCD bits, a
protocol known as Q.931 is used out-of-band in a separate channel for signaling. An ISDN PRI Tl provides 23 voice
channels of 64 k each (called Bearer or B channels) and one 64 k D (for Data) channel (timeslot 24) for signaling. An
ISDN PRI El provides 30 B channels and 1 D channel (timeslot 17); an ISDN BRI circuit provides two 64 k B channels
and one D channel of 16 k.
Understanding Packetization
IP networks move data around in small pieces known as packets. Because we know how to digitize our voice, it now
becomes just another binary payload to move around in a packet. VoIP uses Digital Signal Processors (DSP) for the codec
functions. The digitized voice is then packaged in an appropriate protocol structure to move it through the IP infrastructure.
DSPs
DSPs are specialized chips that perform high-speed codec functions. DSPs are found in the IP phones to encode the
analog speech of the user and to decode the digitized contents of the packets arriving from the other end of the call. DSPs
are also used on IOS gateways at the interface to PSTN circuits, to change from a digital circuit to packetized voice, or
from an analog circuit to packetized voice. DSPs also change from one codec to another, allow conferencing and call
park, and other telephony features. DSPs are a vital component of a VoIP system. Different chip types have varying
capacities, but the general rule is that you want as many DSP resources available to you as possible. The DSP calculator
on cisco.com will help you calculate what you must have.
Real-Time Transport Protocol (RTP)
RTP was developed to better serve real-time traffic such as voice and video. Voice payloads are encapsulated by RTP, then
by UDP, then by IP. A Layer 2 header of the correct format is applied; the type obviously depends on the link technology
in use by each router interface. A single voice call generates two one-way RTP/UDP/IP packet streams. UDP provides
multiplexing and checksum capability; RTP provides payload identification, timestamps, and sequence numbering.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Understanding VoIP
The elements of traditional telephony—status, address and supervisory signaling, digitization, and so on—must have
functional parallels in the VoIP world for systems to function as people expect them to, and more importantly, for VoIP to
interact with the PSTN properly.
This section examines packetizing digital voice, signaling, and transport protocols, the components of a VoIP network,
and the factors that can cause problems in VoIP networks and how they can be mitigated.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Payload identification allows us to treat voice traffic differently from video, for example, simply by looking for the RTP
header label, simplifying our configuration tasks. Timestamping and sequence numbering allows VoIP devices to reorder
RTP packets that arrived out of sequence and play them back with the same timing in which they were recorded, eliminating
delays or jerkiness. There is no provision for retransmission of a lost RTP packet.
Each RTP stream is accompanied by a Real-Time Transport Control Protocol (RTCP) stream. RTCP monitors the quality
of the RTP stream, allowing devices to record events such as packet count, delay, loss, and jitter (delay variation).
A single voice packet by default contains a payload of 20 msec of voice (either uncompressed or compressed). Because
sampling is occurring at 8000 times per second, 20 msec gives us 160 samples. If we divide 8000 by 160, we see that we
are generating 50 packets with 160 bytes of payload, per second, for a one-way voice stream.
If we use compression, we can squeeze the 160-byte payload down to 20 bytes using the G.729 codec. We still have 160
samples, still 20 msec of audio, but reduced payload size.
Codecs
The codecs supported by Cisco include the following:
• G.711 (64kbps)—Toll-quality voice, uncompressed.
• G.729 (8kbps)
• Annex A variant: less processor-intensive, allows more voice channels encoded per DSP chip; lower audio
quality than G.729
• Annex B variant: Allows the use of Voice Activity Detection and Comfort Noise Generation; can be applied to
G.729 or G.729-A
The values for bandwidth shown do not include the Layer 3 and Layer 2 overhead; the actual bandwidth used by a single
(one-way) voice stream can be significantly larger. The following tables summarize the additional overhead added by
packetization and Layer 2 encapsulation (assume 50 packets per second (pps):
Bandwidth Calculation, Without Layer 2
Codec G.711 G.729
Voice Payload 160 Bytes 20 Bytes
RTP Header 12 Bytes 12 Bytes
UDP Header 8 Bytes 8 Bytes
IP Header 20 Bytes 20 Bytes
Total Before Layer 2 200 Bytes 60 Bytes
Total Bitrate @ 50 pps 80,000 bps (80 kbps) 24,000 bps (24 kbps)
Bandwidth Calculation, With Layer 2
Layer 2 Type G.711 = 200 Bytes/packet G.729 = 60 Bytes/packet
Ethernet 18 Bytes 18 Bytes
Multilink PPP 6 Bytes 6 Bytes
Frame Relay FRF. 12 6 Bytes 6 Bytes
Total incl. Layer 2 218 Bytes 206 Bytes 206 Bytes 78 Bytes 66 Bytes 66 Bytes
Total Bitrate incl. Layer 2
(@ 50 pps)
87.200 82,400 82,400
(87.2 kbps) (82.4 kbps) (82.4 kbps)
31,200 26,400 26,400
(31.2 kbps) (26.4 kbps) (26.4 kbps)
When using G.729, the RTP/UDP/IP header of 40 bytes is twice the size of the 20B voice payload. This consumes significant
bandwidth just for header transmission on a slow link. The recommended solution is to use Compressed RTP
(cRTP) on slow WAN links. cRTP reduces the RTP/UDP/IP header to 2 bytes without checksums or 4 bytes with checksums.
The effect of using cRTP is illustrated in the following table. (Note: Ethernet is not included because it is not classified
as a slow link.)
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Bandwidth Calculation, Using cRTP
Codec G.711 G.729
Voice Payload 160 Bytes 20 Bytes
cRTP header w/ chksum 4 Bytes 4 Bytes
cRTP header no chksum 2 Bytes 2 Bytes
Total before Layer 2: 164 Bytes 162 Bytes 24 Bytes 22 Bytes
Multilink PPP or
Frame Relay FRF. 12 6 Bytes 6 Bytes
Total WAN bandwidth @50 pps incl. Layer 2: 68000 bps 67,200 bps
(68 kbps) (67.2 kbps)
12,000 bps 11,200
(12 kbps) (11.2 kbps)
Voice Activity Detection (VAD)
Phone conversations on average include about 35% silence. In Cisco Unified Communications, by default silence is packetized
and transmitted, consuming the same bandwidth as speech. In situations where bandwidth is very scarce, the VAD
feature can be enabled, causing the voice stream to be stopped during periods of silence. The theory here is that the bandwidth
otherwise used for silence can be reclaimed for voice or data transmission. VAD also adds Comfort Noise
Generation (CNG), which fills in the dead silence created by the stopped voice flow with white noise. VAD should not be
taken into account during the network design bandwidth allocation process because its effectiveness varies with background
noise and speech patterns. VAD is also made ineffective by Music on Hold and fax features. In reality, VAD typically
causes more problems than it solves, and it is usually wiser to add the necessary bandwidth.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
Additional DSP Functions
In addition to digitizing voice, DSP resources are used for the following:
• Conferencing: DSPs mix the audio streams from the conference participants and transmit the mix (minus their own)
to each participant.
• Transcoding and Media Termination Points (MTP): A transcoder changes a packetized audio stream from one
codec to another, perhaps for transit across a slow WAN link. MTPs provide a point for the stream to be terminated
while other services are set up.
• Echo Cancellation: DSPs provide the calculation power needed to analyze the audio stream and filter out the repetitive
patterns that indicate echo. Echo is a chief cause of perceived poor voice quality; echo cancellation is an important
function.
Introduction to Digital Circuits ccsp certification training institute in gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
analog circuit can handle only one call at a time, whereas a digital circuit can handle many.
There are two main types of digital circuits: Common Channel Signaling (CCS) and Channel Associated Signaling
(CAS). CAS circuits are available in two speeds: Tl at 1.544Mbs supports 24 calls, and El at 2.048Mbs supports 30
calls. (For these values, we are assuming the calls are not compressed; more on this later). CCS circuits are designated as
PRI T l , PRI E l , and BRI. A PRI Tl can support 23 calls, a PRI El 30, and a BRI only 2.
The use of a digital circuit by definition implies that the voice signal must be digitized; the conversion from analog to
digital is performed by a codec. The following sections discuss the conversion of analog to digital.
Digitizing Analog Signals
There are four steps in the process of digitizing analog sound:
1. Sample the analog sound at regular intervals
2. Quantize the sample
3. Encode the value into a binary expression
4. Optionally compress the sample
Sampling could be done any number of times per second; the more samples taken per second, the higher the audio
quality, but the amount of digital data produced is much larger. Nyquist's theorem states that the sampling interval should
be 2x the highest frequency of the sample to produce acceptable audio quality during playback. Because the highest
frequency in human speech that we want to reproduce in telephony is around 4000 Hz, the sampling rate for standard tollquality
digital voice is 8000 intervals per second. By contrast, CD music audio, which must encode both much higher and
much lower frequencies, samples at about 192,000 times per second.
Quantizing refers to making a digital approximation of an analog waveform. Imagine drawing an arc on a chessboard; if
you had to define the arc using only the square it was in for each row (segment) and column (interval), you would end up
with a stepped pattern that was sort of close to the original arc but not exact. This is exactly the process that happens with
quantization: the codec chooses a segment value that is as close as possible to the analog value at the interval it was
sampled, but it cannot be exact. To make the quantization more accurate, each sample is divided into 16 intervals that are
adjusted to more closely match the sampled wave. Furthermore, the segments are actually more fine-grained at the origin
than at the high and low ranges. This is because most of the human speech we are trying to capture accurately is in this
center range of the scale; there are fewer sounds at the very highest and lowest values.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
FIGURE 11
Quantizing the Digital
Sample
Encoding the signal is a simple process. We have a single 8-bit code word to identify whether the analog signal was a
positive or negative voltage, what value the signal was quantized to (which segment), and finally, which interval is represented
by the code word. The first bit identifies either positive voltage (1) or negative (0). The next three bits represent
the segment. There are eight segments in the positive range and eight segments on the negative range, so three bits
provide the necessary encoding for the quantization. The last four bits identify the interval. A code word example is
shown next:
In this case, the first 1 indicates a positive voltage; the next digits of 001 indicate this is the first segment (on the positive
side), and 1100 indicates the twelfth interval.
The code word is 8 bits; we generate a code word 8000 times per second (the sample rate). This gives us a bitrate output
of 8 x 8000 = 64,000 bps (64 kbps). The process we just described is known as Pulse Code Modulation (PCM) and is the
standard for uncompressed digital voice in telephony. One voice stream thus requires 64k of bandwidth for transport.
1 0 0 1 1 1 0 0
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
NOTE
The determination of
voice quality is based on
the Mean Opinion Score
(MOS). This is a subjective
measurement,
created by gathering the
opinion of live human
listeners. A sample
recording is played, and
the listeners give it a
score out of 5, where 5 is
best. The same sample is
played using different
compression or processing
methods and scored
again. Because MOS is
so subjective, other
quality measurements
exist that are more
empirical and more accurate.
For reference, standard
PCM encoding
(G.711) scores 4.1, and
G.729 scores 3.92.
Compression is not a required step, but it is often done to save bandwidth in VoIP environments. The two main types of
compression we are concerned with are the following:
• Adaptive Differential PCM (ADPCM): This method does not send entire code words, but instead sends a smaller
code that represents the difference between this word and the last one sent. This is not commonly used today,
because it produces lower voice quality and compresses down only to about 16 kbps.
• Conjugate Structure Algebraic Code Excited Linear Prediction (CS_ACELP): As the name suggests, this is
more complex compression. Based on a dictionary or codebook of known sounds made by a standardized American
male voice, the digital sample is analyzed and compared to the dictionary. The dictionary code that is the closest to
the sample is sent. The codebook is constantly learning. The output of this compression is typically 8 kbps—with
very little degradation of voice quality. This compression is widely used in VoIP.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
analog circuit can handle only one call at a time, whereas a digital circuit can handle many.
There are two main types of digital circuits: Common Channel Signaling (CCS) and Channel Associated Signaling
(CAS). CAS circuits are available in two speeds: Tl at 1.544Mbs supports 24 calls, and El at 2.048Mbs supports 30
calls. (For these values, we are assuming the calls are not compressed; more on this later). CCS circuits are designated as
PRI T l , PRI E l , and BRI. A PRI Tl can support 23 calls, a PRI El 30, and a BRI only 2.
The use of a digital circuit by definition implies that the voice signal must be digitized; the conversion from analog to
digital is performed by a codec. The following sections discuss the conversion of analog to digital.
Digitizing Analog Signals
There are four steps in the process of digitizing analog sound:
1. Sample the analog sound at regular intervals
2. Quantize the sample
3. Encode the value into a binary expression
4. Optionally compress the sample
Sampling could be done any number of times per second; the more samples taken per second, the higher the audio
quality, but the amount of digital data produced is much larger. Nyquist's theorem states that the sampling interval should
be 2x the highest frequency of the sample to produce acceptable audio quality during playback. Because the highest
frequency in human speech that we want to reproduce in telephony is around 4000 Hz, the sampling rate for standard tollquality
digital voice is 8000 intervals per second. By contrast, CD music audio, which must encode both much higher and
much lower frequencies, samples at about 192,000 times per second.
Quantizing refers to making a digital approximation of an analog waveform. Imagine drawing an arc on a chessboard; if
you had to define the arc using only the square it was in for each row (segment) and column (interval), you would end up
with a stepped pattern that was sort of close to the original arc but not exact. This is exactly the process that happens with
quantization: the codec chooses a segment value that is as close as possible to the analog value at the interval it was
sampled, but it cannot be exact. To make the quantization more accurate, each sample is divided into 16 intervals that are
adjusted to more closely match the sampled wave. Furthermore, the segments are actually more fine-grained at the origin
than at the high and low ranges. This is because most of the human speech we are trying to capture accurately is in this
center range of the scale; there are fewer sounds at the very highest and lowest values.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
FIGURE 11
Quantizing the Digital
Sample
Encoding the signal is a simple process. We have a single 8-bit code word to identify whether the analog signal was a
positive or negative voltage, what value the signal was quantized to (which segment), and finally, which interval is represented
by the code word. The first bit identifies either positive voltage (1) or negative (0). The next three bits represent
the segment. There are eight segments in the positive range and eight segments on the negative range, so three bits
provide the necessary encoding for the quantization. The last four bits identify the interval. A code word example is
shown next:
In this case, the first 1 indicates a positive voltage; the next digits of 001 indicate this is the first segment (on the positive
side), and 1100 indicates the twelfth interval.
The code word is 8 bits; we generate a code word 8000 times per second (the sample rate). This gives us a bitrate output
of 8 x 8000 = 64,000 bps (64 kbps). The process we just described is known as Pulse Code Modulation (PCM) and is the
standard for uncompressed digital voice in telephony. One voice stream thus requires 64k of bandwidth for transport.
1 0 0 1 1 1 0 0
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 147 for more details.
NOTE
The determination of
voice quality is based on
the Mean Opinion Score
(MOS). This is a subjective
measurement,
created by gathering the
opinion of live human
listeners. A sample
recording is played, and
the listeners give it a
score out of 5, where 5 is
best. The same sample is
played using different
compression or processing
methods and scored
again. Because MOS is
so subjective, other
quality measurements
exist that are more
empirical and more accurate.
For reference, standard
PCM encoding
(G.711) scores 4.1, and
G.729 scores 3.92.
Compression is not a required step, but it is often done to save bandwidth in VoIP environments. The two main types of
compression we are concerned with are the following:
• Adaptive Differential PCM (ADPCM): This method does not send entire code words, but instead sends a smaller
code that represents the difference between this word and the last one sent. This is not commonly used today,
because it produces lower voice quality and compresses down only to about 16 kbps.
• Conjugate Structure Algebraic Code Excited Linear Prediction (CS_ACELP): As the name suggests, this is
more complex compression. Based on a dictionary or codebook of known sounds made by a standardized American
male voice, the digital sample is analyzed and compared to the dictionary. The dictionary code that is the closest to
the sample is sent. The codebook is constantly learning. The output of this compression is typically 8 kbps—with
very little degradation of voice quality. This compression is widely used in VoIP.
Subscribe to:
Comments (Atom)