Guest

Gateway Protocols

Designing and Deploying VoIP over ISDN

Document ID: 25610

Updated: Feb 02, 2006

   Print

Introduction

Voice over IP (VoIP) over Integrated Service Digital Network (ISDN) is sometimes a desirable combination, especially in enterprise networks using IP Telephony. The features required to provide necessary quality of service (QoS) for VoIP, Low Latency Queuing (LLQ), Class Based Weighted Fair Queuing (CBWFQ), and Link Fragmentation and Interleaving (LFI), are supported for ISDN and the combination works. However, there are significant design considerations to take into account. This document discusses the caveats and limitations involved in using these VoIP related QoS features with ISDN, and provides some tested sample configurations.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

  • ISDN

  • Point-to-Point Protocol (PPP)

  • Multilink PPP (MLPPP)

  • LFI

  • LLQ

  • CBWFQ

  • Compressed Real Time Protocol (cRTP)

This document does not provide technology training on these subjects but rather an explanation of how these technologies work together in a VoIP network. See the Related Information

Related Cisco Support Community Discussions section for more information on these subjects.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco IOS® Software Release 12.2

  • Cisco IOS Software Release 12.2(2)T to 12.2(10)T

  • Cisco IOS Software Release 12.2(12)T and later

These design options are presented in this document and have been tested with the noted Cisco IOS software releases:

Testing was performed using the following equipment. These routers were connected directly across ISDN. Pagent was used to simulate RTP traffic and oversubscribe the connection.

  • Cisco 7200 Router with PRI interface

  • Cisco 2600 Router with BRI interface

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Design Issues

There are three issues that require special consideration when you design VoIP over ISDN networks. These are described briefly in this table and then expanded upon.

Issue Description
Variable bandwidth ISDN link bandwidth varies as B-channels are added or dropped.
Packet reordering caused by LFI When RTP packets are interleaved they can arrive out of order when transmitted across multiple B-channels.
Cisco CallManager Call Admission Control (CAC) Limitations Cisco CallManager location-based CAC is not currently topology aware.

Variable Bandwidth

ISDN allows B-channels to be added or dropped in response to the demand for bandwidth. The fact that the bandwidth of a link varies over time presents a special challenge to the CBWFQ and LLQ queuing mechanisms of Cisco IOS. Until Cisco IOS Software Release 12.2(2)T, a policy-map that implemented LLQ or CBWFQ could only be assigned a fixed amount of bandwidth. By default, the bandwidth assigned can only consume 75% of the available bandwidth. On an ISDN interface, CBWFQ and LLQ assumes that only 64 Kbps is available, even though the interface has the potential to provide 1.544 or 2.408 Mbps of bandwidth. Therefore, only 75% of 64 Kbps, or 48 Kbps, can be allocated by a policy-map on any ISDN interface. This restricts the number of VoIP calls that can be carried. If more bandwidth is allocated, then an error message is generated when the policy-map is applied to the ISDN interface.

Consider this policy-map usage as an example:

The policy-map Command
policy-map isdn-qos
  class VoIP-RTP
  priority 64
  class VoIP-Sig
  bandwidth 10

When it is applied to a BRI interface, the policy-map command is rejected because more than 75% of one B-channel (48 Kbps) is reserved:

The service-policy output Command

!--- Note the highlighted error message when the policy 
!--- is applied to the dialer interface
.

router(config)# interface dialer 0
  router(config-if)# service-policy output isdn-qos
  I/f Dialer0 class VoIP-RTP requested bandwidth 64 (kbps) Available only 47 (kbps)

The solution to this problem was introduced in Cisco IOS Software Release 12.2(2)T. As of this release, it is possible to reserve a percentage of bandwidth available instead of an absolute amount of bandwidth. In order to reserve 64 Kbps for RTP and 8 Kbps for signaling on a BRI interface with two B-channels that total 128 Kbps and one D-channel of 8 Kbps, the service-policy is:

The policy-map Command
policy-map isdn-qos
  class VoIP-RTP
  priority percent 50
  class VoIP-SIG
  bandwidth 8

As a result, there are 32 Kbps available for RTP when the first B-channel comes up, and 64 Kbps available when the second channel comes up. In addition, Cisco IOS never removes the service-policy from the interface due to oversubscription, since an oversubscription can never occur.

Packet Reordering Caused by LFI

When you perform VoIP over ISDN, MLPPP is used for LFI. LFI divides large data packets into smaller fragments and transmits them in parallel across all of the B-channels in the bundle. At the same time voice packets are interleaved in between the fragments and their delay is reduced. The interleaved packets are not subject to MLPPP encapsulation, they are encapsulated as regular PPP packets. Therefore, they have no MLPPP sequence numbers and cannot be reordered should they arrive out of order. The possibility for reordering is real. The depth of the various link queues in the bundle can differ, which causes RTP packets to overtake each other as a result of the difference in queuing delay. The various B-channels can also take different paths through the ISDN network and end up with different transmission delays.

Generally, this reordering of packets is not a problem for RTP packets. The de-jitter buffers on the receiving VoIP devices reorder the packets based on the RTP sequence numbers. However, the reordering does become a problem if cRTP is used. The cRTP algorithm assumes that RTP packets are compressed and decompressed in the same order. If they get reordered, then decompression does not occur correctly. It is not currently safe to use cRTP if there is more than one B-channel in the MLPPP bundle. The same restriction applies for MLPPP over ATM or Frame Relay. In this case, cRTP is not possible if there is more than one virtual circuit (VC) in the bundle.

A solution to the reordering problem is offered by multi-class multilink PPP (MCMP). MCMP gives the interleaved packets a small header with a sequence number. This allows the interleaved packets to be reordered by the far end of the bundle, before cRTP decompression takes place. MCMP support is expected in Cisco IOS Software Release 12.2(12)T. Refer to RFC 2686 and Cisco bug ID CSCdv46666 (registered customers only) for further information.

Cisco CallManager CAC Limitations

Enterprise customers with branch networks often use ISDN for data backup. When IP Telephony is deployed, customers like to use the ISDN backup link for voice, as well as data. This configuration is possible but there are some caveats to observe.

IP Telephony in branch networks is typically based on the centralized call-processing model, and uses location-based CAC to limit the number of calls across the WAN. Location-based CAC does not currently have any mechanism to track topology changes in the network. Cisco CallManager is not aware if the primary link to a branch goes down and ISDN backup activates. For this reason, it is critical that the ISDN backup link supports the same number of VoIP calls as the main link. Otherwise, CAC could oversubscribe the backup link.

The actual bandwidth of the primary link and the backup link does not need to be identical. The links just need to be able to carry the same number of VoIP calls. For example, the backup link can use cRTP while the primary link does not. In this case, less bandwidth is required on the backup link to carry the same number of calls as the primary link.

Design Options

There are various broad design options available to the network designer based on the Cisco IOS software release used. These options are:

Discussion on each option follows including the configuration examples listed here.

Voice and Data Coexisting on a Single B-Channel With or Without cRTP

In Cisco IOS Software Release 12.2, bandwidth in a policy-map can only be specified as a fixed amount up to a default maximum of 75% of the link bandwidth. In addition, ISDN is always assumed to provide 64 Kbps of bandwidth irrespective of the number of B-channels used on a BRI or PRI interface. Therefore, 48 Kbps is the default maximum bandwidth that can be reserved in the policy-map for ISDN.

These limitations mean that it only makes sense to use one B-channel for carrying RTP packets. Based on the requirements, you can choose to carry data and voice on the same B-channel. Alternatively, you can use the second B-channel of a BRI for data only. In both of these design options, it is safe to use cRTP as all RTP packets travel down a single B-channel, and cannot arrive out of order.

This design option sends all voice and data traffic down a single B-channel. Since voice and data compete for the same link, you need LFI, LLQ, and CBWFQ. You can also safely use cRTP since there is no opportunity for RTP packets to become reordered.

By default, a service-policy cannot reserve more than 48 Kbps (75% of 64 Kbps) for RTP and VoIP signaling. The minimum amount that you can assign to the VoIP signaling class is 8 Kbps. With the remaining 40 Kbps available for use by RTP, you can produce this table which shows the maximum number of calls that can be carried by a single BRI.

Sample Size (Bytes) PPS cRTP Packet Length (Bytes) Bandwidth (Kbps) Calls per BRI
20 50 No 66 26.4 1
20 50 Yes 28 11.2 3
30 33 No 76 20.1 1
30 33 Yes 38 10.0 3
40 25 No 86 17.2 2
40 25 Yes 48 9.6 4

This output shows a sample configuration for voice and data on the same B-channel.

Configuration for voice and data on a single B-channel with cRTP

!--- This section shows only relevant parts of the configuration.


class-map match-all VoIP-RTP
 match ip dscp ef
 
!--- RTP packets.

class-map match-all VoIP-SIG
 match ip dscp af31
 
!--- VoIP signaling packets.


policy-map voice-and-data
 class VoIP-RTP
  priority 40
 
!--- 40 Kbps available for voice.

 class VoIP-SIG
  bandwidth 8
  
!--- 8 Kbps is the minimum value allowed by Cisco IOS.


interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 bandwidth 64
 
!--- Increase the bandwidth from 56 to 64 Kbps
. 
 dialer pool 1
 dialer remote-name routerB-dialer1
 dialer-group 1
 dialer string 12345678
 service-policy output voice-and-data
 
!--- The service policy.

 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 
!--- THe LFI delay equals 10 msec.

 ppp multilink interleave
 
!--- Enable LFI.

 ip rtp header-compression
 
!--- RTP header compression is OK.

Voice and Data on Separate B-Channels With or Without cRTP

This design is also possible by use of Cisco IOS Software Release 12.2. However, in order to make better use of available ISDN B-channels, voice and data are separated. The example chosen is suitable for a basic rate configuration where RTP packets use one B-channel, and data and voice signaling use the second B-channel. Similar concepts apply for a primary rate configuration where more channels can be used for data.

Because the RTP packets do not compete with any data, LFI and LLQ on the voice channel should not be required. However, it is a good practice to enable it anyway. Cisco Discovery Protocol (CDP) and routing updates can be enabled by mistake, or a denial of service (DoS) attack can be flooding the voice channel. On the data channel, no LFI is required. But CBWFQ is required to protect the VoIP signaling from general data. Routing updates on the voice channel need to be suppressed to avoid traffic that is routed across this interface. In its place, use policy based routing to force RTP packets across the voice channel. You can safely use cRTP since there is no opportunity for RTP packets to become reordered.

By default a service-policy cannot reserve more than 48 Kbps (75% of 64 Kbps) for RTP and VoIP signaling. However, it is safe to increase the percentage to 90% with this design, as there is no other traffic on the voice channel. This increased maximum can be specified with the max-reserved-bandwidth command.

Based on 57 Kbps for RTP, you can produce this table which shows the maximum number of calls that a single BRI can carry.

Sample Size (Bytes) PPS cRTP Packet Length (Bytes) Bandwidth (Kbps) Calls per BRI
20 50 No 66 26.4 2
20 50 Yes 28 11.2 5
30 33 No 76 20.1 2
30 33 Yes 38 10.0 5
40 25 No 86 17.2 3
40 25 Yes 48 9.6 5

This table shows a sample configuration for voice and data on separate B-channels.

Configuration for Voice and Data on Separate B-channels with cRTP

!--- This section shows only relevant parts of the configuration.



Class-map match-all VoIP-RTP
 match ip dscp ef
class-map match-all VoIP-SIG
 match ip dscp af31 

policy-map voice-only
 class VoIP-RTP
  priority 57

policy-map data-and-signaling
 class VoIP-SIG
  bandwidth 8

interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 bandwidth 64
 
!--- Increase the bandwidth from 56 to 64 Kbps.

 dialer pool 1
 dialer remote-name routerB-dialer1
 max-reserved-bandwidth 90
 
!--- Allow 90% of the bandwidth to be reserved.

 dialer-group 1
 dialer string 12345678
 service-policy output voice-only
 
!--- RTP packets only.

 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave 
 ip rtp header-compression

interface Dialer2
 encapsulation ppp
 dialer pool 1
 dialer remote-name routerB-dialer2
 dialer-group 1
 dialer string 12345678
 service-policy output data-and-signaling
 
!--- Data and VoIP signaling.

 ppp authentication chap
 ppp chap hostname routerA-dialer2
 ppp chap password cisco

router eigrp 1
 passive-interface dialer 1
 
!--- Suppress routing on the voice channel.


interface fastethernet 0/1
 ip policy route-map ip-rtp
 
!--- Policy route RTP packets.


route-map ip-rtp permit 10
 match ip address 100
 set interface dialer 1
 
!--- Route RTP packets out dialer 1.


access-list 100 permit udp any range 16384 32768
  any range 16384 32768 dscp ef

Voice and Data Coexisting on Multiple B-Channels Without cRTP

This design takes advantage of the fact that as of Cisco IOS Software Release 12.2(2)T, you can specify bandwidth in the policy-map as a percentage instead of an absolute number. This capability allows you to apply a service policy to a bundle with multiple B-channels. As a result, RTP packets can be carried across multiple B-channels. The trade-off is that implementation of multiple paths means that cRTP is not safe to use due to the potential reordering of RTP packets.

Cisco IOS provides two mechanisms for you to control how additional B-channels are brought in response to demand. The first mechanism is commonly referred to as Dial on Demand Routing (DDR). DDR requires a load threshold to be specified as a fraction of available bandwidth. When traffic flow exceeds this threshold number, an additional channel is added to the bundle. The threshold is calculated as a running average, and there is certain delay in bringing up additional B-channels when the load increases. This delay is not a problem with data. However, with voice, it is not acceptable if a user makes a phone call, and it takes minutes to bring up the required bandwidth to support the QoS for the call.

You can reduce the delay to bring up additional channels to around 30 seconds with the load-interval command on the physical ISDN interface. However, even 30 seconds is too long for a call to go without the required QoS. The solution is to have the dialer load-threshold command set to a value that ensures sufficient bandwidth in reserve to support at least one additional VoIP call with appropriate QoS.

Since the problem still exists if two calls are brought up within the 30-second interval, a second and more robust solution is preferred. The solution is to bring all B-channels up immediately and keep them up as long as the ISDN service is required. You can use the ppp multilink links minimum command to specify this action.

With two B-channels available, the service-policy can now reserve 96 Kbps (75% of 128 Kbps) for RTP and VoIP signaling. You need 8 Kbps for VoIP signaling, so this leaves 88 Kbps for RTP. Based on the use of two B-channels, this table shows the maximum number of calls that can be carried on the BRI.

Sample Size (Bytes) PPS cRTP Packet Length (Bytes) Bandwidth (Kbps) Calls per BRI
20 50 No 66 26.4 3
20 50 Yes 28 11.2
30 33 No 76 20.1 4
30 33 Yes 38 10.0
40 25 No 86 17.2 5
40 25 Yes 48 9.6

This output shows a sample configuration for voice and data that coexists on multiple B-channels without cRTP.

Configuration for Voice and Data Coexisting on Multiple B-channels without cRTP

!--- This section shows only relevant parts of the configuration.



Class-map match-all VoIP-RTP
 match ip dscp ef
class-map match-all VoIP-SIG
 match ip dscp af31 

policy-map voice-and-data
 class VoIP-RTP
  priority percent 65
  
!--- This is 65% of 64/128K for RTP.

 class VoIP-SIG
  bandwidth percent 10
  
!--- This is 10% of 64/128K for VoIP signaling.


interface BRI0/0
 encapsulation ppp
 dialer pool-member 1
 ppp authentication chap

interface Dialer1
 encapsulation ppp
 dialer pool 1
 dialer remote-name routerB-dialer1
 dialer-group 1
 dialer string 12345678
 service-policy output voice-and-data
 ppp authentication chap
 ppp chap hostname routerA-dialer1
 ppp chap password cisco
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave 
 ppp multilink links minimum 2
 
!--- Bring up two B-channels immediately.

 no ip rtp header-compression
 
!--- cRTP is not safe

Voice and Data Coexisting on Multiple B-Channels With cRTP

With the introduction of MCMP in Cisco IOS Software Release 12.2(12)T, the cRTP reordering issue is solved, and it is possible to have voice use multiple B-channels and still do cRTP. The design principles for this are identical to that discussed in the Voice and Data Coexisting on Multiple B-Channels Without cRTP section, with the only difference being that you can now enable cRTP. This table adds the maximum number of calls that can be carried on the BRI, based on the use of cRTP on two B-channels.

Sample Size (Bytes) PPS cRTP Packet Length (Bytes) Bandwidth (Kbps) Calls per BRI
20 50 No 66 26.4 3
20 50 Yes 28 11.2 7
30 33 No 76 20.1 4
30 33 Yes 38 10.0 8
40 25 No 86 17.2 5
40 25 Yes 48 9.6 9

For this scenario the Configuration for Voice and Data Coexisting on Multiple B-Channels Without cRTP applies. The exception is that now MCMP is enabled and cRTP is on when you add this output to the dialer interface.

Sample ppp multilink multi-class Configuration

!--- This command is available with Cisco IOS Software Release 12.2(12)T.
 
interface Dialer1 ppp multilink multiclass
	  
!--- Enable MCMP.

 ip rtp header-compression
    
!--- Support cRTP on the bundle

Related Information

Updated: Feb 02, 2006
Document ID: 25610