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
Bandwidth on the IP WAN can be conserved using the following methods:
• Using low-bandwidth codecs: If you use low-bandwidth (compression) codecs,
such as G.729, the required bandwidth for digitized voice is 8 kbps, or approximately
26 kbps in RTP, compared to the 64 kbps, or approximately 87 kbps in RTP, that is
required by G.711. These bandwidth calculations are based on using a PPP or Frame
Relay header of 6 bytes. The numbers would change if a different Layer 2 header
were used.
Solutions to Bandwidth Limitations
• Deploying local Music On Hold (MOH) servers (requires a local CUCM server)
or using multicast MOH from branch router flash: Deploying local MOH servers
means that CUCM servers have to be present at each site. In centralized call-processing
models in which CUCM servers are not present at remote sites, it is recommended that
you use multicast MOH from branch router flash. This eliminates the need to stream
MOH over the IP WAN. If this is not an option, you should use multicast MOH instead
of unicast MOH to reduce the number of MOH streams that have to traverse the IP WAN.
Multicast MOH requires multicast routing to be enabled in the routed IP network.
• Limiting the number of voice calls using CAC: Use CAC with CUCM or a gatekeeper
to avoid oversubscription of WAN bandwidth from too many voice calls.
• Using RTP-header compression: When you use RTP-header compression (compressed
RTP [cRTP]), the IP, User Datagram Protocol (UDP), and RTP header can be
compressed to 2 or 4 bytes, compared to the 40 bytes that is required by these headers
if cRTP is not used. cRTP is enabled per link on both ends of a point-to-point WAN
link. It should be selectively used on a slow WAN link, typically less than 768 kbps. It
does not need to be enabled end-to-end across all faster WAN links.
• Deploying local annunciators or disabling remote annunciators: If spoken
announcements are not required, the use of annunciators can be disabled for Cisco
IP Phones that do not have a local annunciator. Otherwise, local annunciators could be
deployed. CUCM supports annunciators running only on CUCM servers for media
provided by the IP Voice Streaming Application service. Therefore, local annunciators
can be implemented only if a local CUCM cluster is deployed or if clustering over the
IP WAN is being used.
• Deploying local conference bridges: If local conference bridges are deployed, the
IP WAN is not used if all conference members are at the same site as the conference bridge.
• Deploying local Media Termination Points (MTP): If MTPs are required, they can
be locally deployed at each site to avoid the need to cross the IP WAN when using MTP
services.
• Deploying transcoders or mixed conference bridges: If low-bandwidth codecs are not
supported by all endpoints, transcoders can be used so that low-bandwidth codecs can be
used across the IP WAN. Then have the voice stream transcoded from G.729 to G.711.
For conferences with local members using G.711 and remote members using lowbandwidth
codecs, mixed conference bridges with digital system processor (DSP)
hardware in a gateway can be deployed that support conference members with different
codecs.
NOTE CUCM can perform conference calls with a software conference bridge only
with the G.711 codec.
Chapter 2: Identifying Multisite Deployment Solutions
Low-Bandwidth Codecs and RTP-Header Compression
In Figure 2-3, a voice packet for a call with the G.711 codec and a 20-ms packetization
period is being passed along a Frame Relay WAN link. The RTP frame has a total size of
206 bytes, composed of 6 bytes of Frame Relay header, 20 bytes of IP header, 8 of bytes
UDP header, 12 bytes of RTP header, and a 160-byte payload of digitized voice. The
packet rate is 50 packets per second (pps), resulting in a bandwidth need of 82.4 kbps.
Note that when compressed RTP (cRTP) is used, the bandwidth is considerably reduced
to 11.2 or 12 kbps.
Figure 2-3 Low-Bandwidth Codecs and RTP-Header Compression
NOTE The default codec with CUCM is G.711, with a 160-byte sample size and a 20-
ms packet interval.
When you use cRTP and change the codec to G.729 with CUCM regions, the required
bandwidth changes as follows: The frame now has a total size of 28 or 30 bytes per frame,
composed of 6 bytes of Frame Relay header, 2 or 4 bytes of cRTP header (depending on
whether the UDP checksum is preserved), and a 20-byte payload of digitized, compressed
voice. The packet rate is still 50 pps (because the packetization period was not changed),
resulting in bandwidth needs of 11.2 or 12 kbps.
Seven G.729 calls with cRTP enabled require less bandwidth than one G.711 call without
cRTP (assuming that cRTP is used without preserving the UDP checksum).
Solutions to Bandwidth Limitations 29
Codec Configuration in CUCM
The codec that is used for a call is determined by the region configuration in CUCM. Each
region in CUCM is configured with the codec that has the highest permitted bandwidth
requirements:
• Within the configured region
• Toward a specific other region (manually configured)
• Toward all other regions (not manually configured)
Regions are assigned to device pools (one region per device pool), and a device pool is
assigned to each device, such as a Cisco IP Phone. The codec actually used depends on the
capabilities of the two devices that are involved in the call. The assigned codec is the one
that is supported by both devices; it does not exceed the bandwidth requirements of the
codec permitted in region configuration. If devices cannot agree on a codec, a transcoder is
invoked. But if a transcoder is unavailable, audio would fail.
Disabled Annunciator
Figure 2-4 shows how bandwidth can be conserved on the IP WAN by simply disabling
annunciator RTP streams to remote phones.
Figure 2-4 Disabled Annunciator
Chapter 2: Identifying Multisite Deployment Solutions
NOTE Because not every call requires annunciator messages, and because the messages
usually are rather short, the bandwidth that may be preserved by disabling the
annunciator is minimal.
Local Versus Remote Conference Bridges
As shown in Figure 2-5, if a local conference bridge is deployed at the remote site with the
remote site gateway DSPs, it keeps voice streams off the IP WAN for conferences in which
all members are physically located at the remote site. The same solution can be implemented
for MTPs. MRGLs specify which conference bridge (or MTP) should be used and by which
IP Phone.
Figure 2-5 Local Versus Remote Conference Bridges
Mixed Conference Bridge
As illustrated in Figure 2-6, a hardware conference bridge is deployed at the main site
gateway. The hardware conference bridge is configured to support mixed conferences, in
which members use different codecs. Headquarters IP Phones that join the conference can
use G.711, whereas remote IP Phones can join the conference using a low-bandwidth
codec. The end result is a minimum WAN utilization with relatively high voice quality.
The annunciator is a CUCM feature that sends one-way audio of prerecorded messages
over RTP to IP Phones. An example is the replacement to the fast busy reorder tone with
the recorded message "Your call cannot be completed as dialed; please .. " If announcements
should not be sent over a saturated IP WAN link, Media Resource Group Lists
(MRGL) can be used so that remote phones do not have access to the annunciator media
resource, as shown in Figure 2-4.
Solutions to Bandwidth Limitations
Figure 2-6 Mixed Conference Bridge
Transcoders
As shown in Figure 2-7, a voice-mail system that supports only G.711 is deployed at the
main site. For example, Cisco Unity Express (CUE) is a branch office voice-mail system
that supports only G.711. One CUCM server is providing a software conference bridge that
also supports G.711 only. If remote Cisco IP Phones are configured to use G.729 over the
IP WAN with CUCM Regions to conserve WAN bandwidth, they would not be able to join
conferences or access the voice-mail system. To allow these IP Phones to use G.729 and to
access the G.711-only services, a hardware transcoder is deployed at the main site in the
gateway using DSP resources.
Remote Cisco IP Phones now send G.729 voice streams to the transcoder over the IP WAN,
which saves bandwidth. The transcoder changes the stream to G.711 and passes it on to the
conference bridge or voice-mail system, allowing the audio connection to work.
Guidelines for Transcoder Configuration
When implementing transcoders to allow G.711-only devices to communicate with remote
IP Phones using G.729, consider the following guidelines.
The first step is to implement the transcoding media resource. Because CUCM does not
support software transcoding resources, the only option is to use a hardware transcoding
resource by first configuring the transcoder at the Cisco IOS router and then adding the
transcoder to CUCM.
Chapter 2: Identifying Multisite Deployment Solutions
Figure 2-7 Transcoders
Software
Conference Bridge,
G.711 Only '
Headquarters
(HQ)
The second step is to implement regions such that only G.729 is permitted on the IP WAN,
and the transcoder can be used, if required. To do so, all IP Phones and G.711-only devices,
such as third-party voice-mail systems or software conference bridges that are located in
the headquarters, are placed in a region (such as headquarters). Remote IP Phones are
placed in another region (such as BR). The transcoding resource is put into a third region
(such as XCODER).
Now the maximum codec for calls within and between regions must be specified:
• Within BR—G.711: This allows local calls between remote IP Phones to use G.711.
• Within HQ—G.711: This allows local calls within headquarters to use G.711. These
calls are not limited to calls between IP Phones. This also includes calls to the G.711-
only third-party voice-mail system or calls that use the G.711-only software
conference bridge.
• Within XCODER—G.711: Because this region includes only the transcoder media
resource, this setting is irrelevant, because there are no calls within this region.
• Between BR and HQ—G.729: This ensures that calls between remote IP Phones and
headquarters devices such as IP Phones, software conference bridges, and voice-mail
systems do not use the G.711 codec for calls that traverse the IP WAN.
Solutions to Bandwidth Limitations
NOTE Calls between IP Phones at headquarters and remote IP Phones do not require a
transcoder. They simply use the best allowed codec that is supported on both ends from
the CUCM region settings—ideally, G.729.
A transcoder is invoked only when the two endpoints of a call cannot find a common
codec that is permitted by region configuration. This is the case in this example. The
remote IP Phones (which support G.711 and G.729) are not allowed to use G.711 over
the IP WAN, and the headquarters voice-mail system and software conference bridge do
not support G.729. CUCM detects this problem based on its region configurations, and
the capability negotiation performed during call setup signaling identifies the need for a
transcoder.
• Between BR and XCODER—G.729: This ensures that the RTP streams between
remote IP Phones and the transcoder, which are sent over the IP WAN, do not use
G.711.
• Between HQ and XCODER—G.711: This is required for the G.711-only devices at
headquarters to be allowed to send G.711 to the transcoder.
Multicast MOH from the Branch Router Flash
Multicast MOH from the branch router flash is a feature for multisite deployments that use
centralized call processing.
The feature works only with multicast MOH and is based on MOH capabilities of Cisco
Unified SRST. The Cisco IOS SRST gateway is configured for multicast MOH and continuously
sends a MOH stream, regardless of its SRST mode (standby or fallback mode).
In fact, neither CUCM nor the remote IP Phones are aware that the SRST gateway is
involved. To them it appears as though a multicast MOH stream has been generated by the
CUCM MOH server and received by the remote IP Phones.
Therefore, the remote Cisco IP Phones are configured to use the centralized CUCM MOH
server as their MOH source. The CUCM MOH server is configured for multicast MOH
(mandatory), and the max-hops value in the MOH server configuration is set to 1 for the
affected audio sources. The max-hops parameter specifies the Time to Live (TTL) value
that is used in the IP header of the RTP packets. The CUCM MOH server and the Cisco IOS
SRST gateway located at the remote site have to use the same multicast address and port
number for their streams. This way, MOH packets generated by the CUCM MOH server at
the central site are dropped by the central-site router because the TTL has been exceeded.
As a consequence, the MOH packets do not cross the IP WAN. The SRST gateway
Chapter 2: Identifying Multisite Deployment Solutions
NOTE Depending on the configuration of MOH in CUCM, a separate MOH stream
for each enabled codec is sent for each multicast MOH audio source. The streams are
incremented either based on IP addresses or based on port numbers (the recommendation
is per IP address). Assuming that one multicast MOH audio source and G.711 a-law,
G.711 mu-law, G.729, and the wideband codec are enabled, there will be four multicast
streams. Make sure that all of them are included in the ACL to prevent MOH packets
from being sent to the IP WAN.
When using multicast MOH from branch router flash, G.711 has to be enabled between the
CUCM MOH server and the remote Cisco IP Phones. This is necessary because the branch
SRST MOH feature supports only G.711. Therefore, the stream that is set up by CUCM in
the signaling messages also has to be G.711. Because the packets are not sent across the
WAN, configuring the high-bandwidth G.711 codec is no problem as long as it is enabled
only for MOH. All other audio streams (such as calls between phones) that are sent over the
WAN should use the low-bandwidth G.729 codec.
An Example of Multicast MOH from the Branch Router Flash
As illustrated in Figure 2-8, the CUCM MOH server is configured for multicast MOH with
a destination Class D multicast group address of 239.1.1, a destination port 16384, and a
max-hops TTL value of 1. Cisco recommends using an IP address in the range reserved for
administratively controlled applications on private networks of 239.0.0.0 to 239.255.255.255.
permanently generates a multicast MOH stream with an identical multicast IP address and
port number so that the Cisco IP Phones simply listen to this stream as it appears to be
coming from the CUCM MOH server.
Instead of setting the max-hops parameter for MOH packets to 1, you can use one of the
following methods:
• Configure an access control list (ACL) on the WAN interface at the central site:
This prevents packets that are destined for the multicast group address or addresses
from being sent out the interface.
• Disable multicast routing on the WAN interface: Do not configure multicast routing
on the WAN interface to ensure that multicast streams are not forwarded into the WAN.
Solutions to Bandwidth Limitations
Figure 2-8 Multicast MOH from Branch Router Flash
The SRST gateway located at the remote site is configured with the same destination IP
address and port number as the CUCM MOH server.
When a remote phone is put on hold, the following happens:
1. According to the MRGL of the remote phone, the CUCM MOH server is used as the
media resource for MOH.
2. CUCM signals the IP Phone to receive MOH on IP address 239.1.1.1, port 16384.
3. The CUCM MOH server sends multicast MOH packets to IP address 239.1.1.1, port
16384, with a TTL value of 1.
4. The router located at the central site drops the multicast MOH packet sent by the
CUCM MOH server because TTL has been exceeded.
5. The router at the remote site is configured as an SRST gateway. In its Cisco Unified
SRST configuration, multicast MOH is enabled with destination address 239.1.1.1
and port 16384. The SRST gateway streams MOH all the time, even if it's not in
fallback mode.
Chapter 2: Identifying Multisite Deployment Solutions
6. The IP Phones listen to the multicast MOH stream that was sent from the SRST
gateway to IP address 239.1.1.1, port 16384, and play the received MOH stream.
7. Whether or not the remote gateway is in SRST mode, MOH packets never cross the
IP WAN.
NOTE If an MOH file is used in router flash, only a single MOH file can be configured
to play at a time. This is unlike CUCM, where many different MOH files can be
configured.
An Example of Multicast MOH f r om the Branch Router Flash Cisco IOS Configuration
As shown in Figure 2-9, the name of the audio file on the branch router flash is moh-file.au,
and the configured multicast address and port number are 239.1.1.1 and 16384, respectively.
The optional route command can be used to specify a source interface address for
the multicast stream. If no route option is specified, the multicast stream is sourced from
the configured Cisco Unified SRST default address. This is specified by the ip sourceaddress
command under the Cisco Unified SRST configuration (10.2.2.2 in this example).
Note that you can stream only a single audio file from flash and that you can use only a
single multicast address and port number per router.
Figure 2-9 Multicast MOH from the Branch Router Flash Cisco IOS Configuration
moh moh-file.au
multicast moh 239.1.1.1 port 16384
A Cisco Unified SRST license is required regardless of whether the SRST functionality will
actually be used. The license is required because the configuration for streaming multicast
MOH from branch router flash is done in SRST configuration mode. Also, even if SRST
functionality will not be used, at least one max-ephones for every Cisco IP Phone supported
and at least one max-dn for every directory number (dn) on all phones must be configured.
Availability 37
Alternatives to Multicast MOH f r om Branch Router Flash
Sometimes multicast MOH from branch router flash cannot be used. For instance, perhaps
the branch router does not support the feature or does not have a Cisco Unified SRST
feature license. In that case, you can consider the following alternatives:
• Using multicast MOH: When you use multicast MOH over the IP WAN, the number
of required MOH streams can be significantly reduced. Thus, less bandwidth is
required compared to multiple unicast MOH streams. The IP network, however, has to
support multicast routing for the path from the MOH server to the remote IP Phones.
• Using G.729 for MOH to remote sites: If multicast MOH is not an option (for
instance, because multicast routing cannot be enabled in the network), you may still
be able to reduce the bandwidth consumed by MOH. If you change the codec that is
used for the MOH streams to G.729 and potentially enable cRTP on the IP WAN, each
individual MOH stream requires less bandwidth and hence reduces the load on the
WAN link. The bandwidth savings are identical to those that are achieved when using
G.729 and cRTP for standard audio streams, which was discussed earlier. To use G.729
for MOH streams, the MOH server and the remote IP Phones have to be put into
different regions, and the audio codec between these two regions must be limited
to G.729.
Availability
You can address availability issues in multisite deployments in several ways:
• PSTN backup: Use the PSTN as a backup for on-net intersite calls.
• MGCP fallback: Configure an MGCP gateway to fall back, and use the locally configured
plain old telephone service (POTS), H.323, or session initiation protocol (SIP)
dial peers when the connection to its call agent is lost. This effectively makes the gateway
use a locally configured dial plan, which is ignored when the gateway is in MGCP
mode. If H.323 is deployed, the dial peers have the same functionality in or out of
SRST mode.
• Fallback for IP Phones with SRST: Cisco IP Phones using either SIP or SCCP must
register to a call-processing device for the phones to work. IP Phones that register over
the IP WAN can have a local Cisco IOS SRST gateway configured as a backup to a
CUCM server in their CUCM group configuration. When the connection to the primary
CUCM server is lost, they can reregister with the local SRST gateway. Alternatively,
CUCM Express can be used in SRST mode, which provides more features than standard
Cisco Unified SRST.
Chapter 2: Identifying Multisite Deployment Solutions
• Automated Alternate Routing (AAR) and Call Forward on No Bandwidth
(CFNB): AAR allows calls to be rerouted over the PSTN when calls over the IP WAN
are not admitted by CAC. CFNB is a call-forwarding configuration of IP Phones,
which becomes effective when AAR is used.
NOTE AAR is configured for calls to and from IP Phones within the same cluster. Calls
to a different cluster over a SIP or H.323 trunk do not use AAR. They are configured to
fail over to the PSTN with CAC by configuring route groups and route lists with path
selection within the route pattern.
• Mobility solutions: When users or devices roam between sites, they can lose features
or have suboptimal configuration because of a change in their actual physical location.
CUCM Extension Mobility and the Device Mobility feature of CUCM can solve such
issues. In addition, Cisco Unified Mobility allows integration of cell phones and home
office phones by enabling reachability on any device via a single (office) number.
PSTN Backup
As shown in Figure 2-10, calls to the remote site within the same cluster are configured with
AAR to use the IP WAN first, and then they use the PSTN as a backup option. The end result
is reduced operating cost with toll bypass over the WAN, and successful delivery of the
same calls over the PSTN but potentially at a higher operating cost if the WAN fails.
Figure 2-10 PSTN Backup
• Call Forward Unregistered (CFUR): This is a call-forwarding configuration of IP
Phones that becomes effective when the IP Phone is not registered.
NOTE CFUR was introduced in CallManager version 4.2, and it appeared again in
CUCM version 6.
Availability 39
MGCP Fallback
MGCP gateway fallback is a feature that improves the availability of remote MGCP
gateways.
A WAN link connects the MGCP gateway at a remote site to the CUCM at a central site,
which is the MGCP call agent. If the WAN link fails, the fallback feature keeps the gateway
working as an H.323 or SIP gateway and rehomes to the MGCP call agent when the WAN
link becomes active again.
Figure 2-11 shows how MGCP fallback improves availability in a multisite environment.
Figure 2-11 MGCP Fallback: Normal Operation
Main Site MGCP Remote Site
The figure illustrates normal operation of MGCP fallback while the connectivity to the call
agent (CUCM) is functional:
• The MGCP gateway is registered with CUCM over the IP WAN.
• CUCM is the call agent of the MGCP gateway that is controlling its interfaces. The
gateway does not have (or does not use) a local dial plan because all call-routing
intelligence is at the call agent. MGCP functions in a client/server model, with CUCM
as the server and the gateway as the client.
When the MGCP gateway loses the connection to its call agent, as shown in Figure 2-12,
it falls back to its default call-control application (POTS, H.323, or SIP). The gateway
now uses a local dial plan configuration, such as dial peers, voice translation profiles,
and so on. Hence, it can operate independently of its MGCP call agent. Without MGCP
fallback, the MGCP gateway would be unable to process calls when the connection to its
call agent is lost.
Chapter 2: Identifying Multisite Deployment Solutions
Figure 2-12 MGCP Fallback: Fallback Mode
Fallback for IP Phones
Fallback for IP Phones is provided by the SRST Cisco IOS feature and improves the availability
of remote IP Phones.
A WAN link connects IP Phones at a remote site to the Cisco Communications Manager
at a central site, which is the call-processing device. If the WAN link fails, Cisco Unified
SRST enables the gateway to provide call-processing services for IP Phones. IP Phones
register with the gateway (which is listed as a backup CUCM server in the server's group
configuration of the IP Phones). The Cisco Unified SRST obtains the configuration of the
IP Phones from the phones themselves and can route calls between the IP Phones or out to
the PSTN.
NOTE When a Cisco IP Phone is in SRST mode, the configuration on the phone should
never be erased, because the phone will not function until the connection to CUCM is
restored.
Figure 2-13 shows how fallback for IP Phones improves availability in a multisite
deployment with centralized call processing.
This figure illustrates normal operation of Cisco Unified SRST while the connectivity
between IP Phones and their primary server (CUCM) is functional:
• Remote IP Phones are registered with CUCM over the IP WAN.
• CUCM handles call processing for IP Phones.
Availability 41
Figure 2-13 Fallback for IP Phones: Normal Operation
Main Site Remote Site
When Cisco IP Phones lose contact with CUCM, as shown in Figure 2-14, they register
with the local Cisco Unified SRST router to sustain the call-processing capability necessary
to place and receive calls.
Figure 2-14 Fallback for IP Phones: Fallback Mode
Main Site Remote Site
The Cisco Unified SRST gateway automatically detects a failure, queries IP Phones for
configuration, and autoconfigures itself. The Cisco Unified SRST gateway uses Simple
Network-Enabled Auto-Provision (SNAP) technology to autoconfigure the branch office
router to provide call processing for Cisco IP Phones that are registered with the router.
CUCM Express in SRST mode can be used instead of standard Cisco Unified SRST
functionality. In this case, IP Phones register with CUCM Express when they lose connection
to their primary CUCM server. CUCM Express in SRST mode provides more features than
standard Cisco Unified SRST.
No comments:
Post a Comment