Skip to main content

Tunneling Multiplexed Compressed RTP (TCRTP)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4170.
Authors Dan Wing , Thima Koren , Bruce Thompson
Last updated 2013-03-02 (Latest revision 2004-09-13)
Replaces draft-wing-avt-tcrtp
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Best Current Practice
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4170 (Best Current Practice)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Allison J. Mankin
Send notices to <>, <>
Internet Engineering Task Force                      Bruce Thompson 
   Audio/Video Transport Working Group                     Tmima Koren 
   INTERNET-DRAFT                                             Dan Wing 
   EXPIRES: February 2005                                Cisco Systems 
                                                       September, 2004 
               Tunneling Multiplexed Compressed RTP ("TCRTP")  
Status of this memo 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 5 of RFC3667. 
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or cite them other than as "work in progress". 
   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   and any of which I become aware will be disclosed, in accordance 
   with RFC 3668. 
   The list of current Internet-Drafts can be accessed at 
   The list of Internet-Draft Shadow Directories can be accessed at 
Copyright Notice 
   Copyright (C) The Internet Society (2004).  All Rights Reserved. 
   This document describes a method to improve the bandwidth 
   utilization of RTP streams over network paths that carry multiple 
   Real-time Transport Protocol (RTP) streams in parallel between two 
   endpoints, as in voice trunking. The method combines standard 
   protocols that provide compression, multiplexing, and tunneling over 
   a network path to reduce the bandwidth used when multiple RTP 
   streams are carried over that path. 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
Table of Contents 
1.   Introduction....................................................3 
1.1.  Is Bandwidth Costly?..........................................3 
1.2.  Overview of Protocols.........................................3 
1.3.  Document Focus................................................3 
1.4.  Choice of Enhanced CRTP.......................................4 
1.5.  Reducing TCRTP Overhead.......................................4 
2.   Protocol Operation and Recommended Extensions...................4 
2.1.  Header Compression: ECRTP.....................................5 
2.1.1.  Synchronizing ECRTP States...................................5 
2.1.2.  Out-of-Order Packets.........................................6 
2.2.  Multiplexing: PPP Multiplexing................................6 
2.2.1.  PPP Multiplex Transmitter Modifications for Tunneling........6 
2.2.2.  Tunneling Inefficiencies.....................................8 
2.3.  Tunneling: L2TP...............................................8 
2.3.1.  Tunneling and DiffServ.......................................8 
2.4.  Encapsulation Formats.........................................8 
3.   Bandwidth Efficiency............................................9 
3.1.  Multiplexing gains............................................9 
3.2.  Packet loss rate.............................................10 
3.3.  Bandwidth calculation for Voice and Video Applications.......10 
3.3.1.  Voice Bandwidth Calculation Example.........................12 
3.3.2.  Voice Bandwidth Comparison Table............................12 
3.3.3.  Video Bandwidth Calculation Example.........................13 
3.3.4.  TCRTP over ATM..............................................13 
3.3.5.  TCRTP over non-ATM networks.................................14 
4.   Example implementation of TCRTP................................14 
4.1.  Suggested PPP and L2TP negotiation for TCRTP.................16 
4.2.  PPP negotiation TCRTP........................................16 
4.2.1.  LCP negotiation.............................................16 
4.2.2.  IPCP negotiation............................................16 
4.3.  L2TP negotiation.............................................17 
4.3.1.  Tunnel Establishment........................................17 
4.3.2.  Session Establishment.......................................17 
4.3.3.  Tunnel Tear Down............................................18 
5.   IANA Considerations............................................18 
6.   Security Considerations........................................18 
7.   Acknowledgements...............................................19 
8.   References.....................................................19 
9.   Authors' Addresses.............................................20 
10.  Copyright Notice...............................................21 
11.  Disclaimers....................................................21 
Koren, Thompson, Wing                                         [Page 2] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
1.   Introduction  
  This document describes a way to combine existing protocols for 
  compression, multiplexing, and tunneling to save bandwidth for some 
  RTP applications.  
1.1.  Is Bandwidth Costly?  
  On certain links, such as customer access links, the cost of 
  bandwidth is widely acknowledged to be a significant concern.  
  Protocols such as CRTP (Compressed RTP, [CRTP]) are well suited to 
  help bandwidth inefficiencies of protocols such as VoIP over these 
   Unacknowledged by many, however, is the cost of long-distance WAN 
   links.  While some voice-over-packet technologies such as Voice over 
   ATM (VoAAL2, [I.363.2]) and Voice over MPLS provide bandwidth 
   efficiencies because both technologies lack IP, UDP, and RTP 
   headers, neither VoATM nor VoMPLS provide direct access to voice-
   over-packet services available to Voice over IP.  Thus, goals of WAN 
   link cost reduction are met at the expense of lost interconnection 
   opportunities to other networks.  
   TCRTP solves the VoIP bandwidth discrepancy, especially for large 
   voice trunking applications.  
1.2.  Overview of Protocols  
   Header compression is accomplished using Enhanced CRTP (ECRTP, 
   [ECRTP]). ECRTP is an enhancement to classical CRTP [CRTP] that 
   works better over long delay links, such as the end-to-end tunneling 
   links described in this document.  This header compression reduces 
   the IP, UDP, and RTP headers.  
   Multiplexing is accomplished using PPP Multiplexing [PPP-MUX].  
   Tunneling PPP is accomplished by using L2TP [L2TPv3].  
   CRTP operates link-by-link; that is, to achieve compression over 
   multiple router hops, CRTP must be employed twice on each router -- 
   once on ingress, again on egress.  In contrast, TCRTP described in 
   this document does not require any additional per-router processing 
   to achieve header compression -- instead, headers are compressed 
   end-to-end, saving bandwidth on all intermediate links.  
1.3.  Document Focus 
Koren, Thompson, Wing                                         [Page 3] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   This document is primarily concerned with bandwidth savings for 
   Voice over IP (VoIP) applications over high-delay networks.  
   However, the combinations of protocols described in this document 
   can be used to provide similar bandwidth savings for other RTP 
   applications such as video, and bandwidth savings are included for a 
   sample video application.  
1.4.  Choice of Enhanced CRTP 
  CRTP [CRTP] describes the use of RTP header compression on an 
  unspecified link layer transport, but typically PPP is used.  For 
  CRTP to compress headers, it must be implemented on each PPP link.  A 
  lot of context is required to successfully run CRTP, and memory and 
  processing requirements are high, especially if multiple hops must 
  implement CRTP to save bandwidth on each of the hops.  At higher line 
  rates, CRTP's processor consumption becomes prohibitively expensive.  
   To avoid the per-hop expense of CRTP, a simplistic solution is to 
   use CRTP with L2TP to achieve end-to-end CRTP.  However, as 
   described in [ECRTP], CRTP is only suitable for links with low delay 
   and low loss.  However, once multiple router hops are involved, 
   CRTP's expectation of low delay and low loss can no longer be met.  
   Further, packets can arrive out of order. 
   Therefore, this document describes the use of Enhanced CRTP [ECRTP], 
   which supports high delay, both packet loss, and misordering between 
   the compressor and decompressor. 
1.5.  Reducing TCRTP Overhead  
   If only one stream is tunneled (L2TP) and compressed (ECRTP) there 
   is little bandwidth savings.  Multiplexing is helpful to amortize 
   the overhead of the tunnel header over many RTP payloads.  The 
   multiplexing format that is proposed by this document is PPP   
   multiplexing [PPP-MUX].  See section 2.3 for details.    
2.   Protocol Operation and Recommended Extensions  
   This section describes how to combine three protocols: Enhanced 
   CRTP, PPP Multiplexing, and L2TP Tunneling, to save bandwidth for 
   RTP applications such as Voice over IP.  
2.1.  Models  
   TCRTP can typically be implemented in two ways.  The most 
   straightforward is to implement TCRTP in the gateways terminating 
   the RTP streams:  
       [voice gateway]---[voice gateway]  
Koren, Thompson, Wing                                         [Page 4] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
                 TCRTP over IP  
   Another way TCRTP can be implemented is with an external 
   concentration device.  This device could be placed at strategic 
   places in the network and could dynamically create and destroy TCRTP 
   sessions without the participation of RTP-generating endpoints.  
       [voice GW]\                                   /[voice GW]  
       [voice GW]---[concentrator]---[concentrator]---[voice GW]  
       [voice GW]/                                   \[voice GW]  
                  ^                ^                ^  
                  |                |                |  
             RTP over IP     TCRTP over IP     RTP over IP  
   Such a design also allows classical CRTP [CRTP] to be used on links 
   with only a few active flows per link (where TCRTP isn't efficient;  
   see section 3):  
       [voice GW]\                                   /[voice GW]  
       [voice GW]---[concentrator]---[concentrator]---[voice GW]  
       [voice GW]/                                   \[voice GW]  
                  ^                ^                ^  
                  |                |                |  
           CRTP over IP     TCRTP over IP     RTP over IP  
2.2.  Header Compression: ECRTP  
   As described in [ECRTP], classical CRTP [CRTP] is not suitable over 
   long-delay WAN links commonly used when tunneling as proposed by 
   this document.  Thus, ECRTP should be used instead of CRTP.  
2.2.1.    Synchronizing ECRTP States  
   When the compressor receives an RTP packet which has an unpredicted 
   change in the RTP header, the compressor should send a 
   COMPRESSED_UDP packet (described in [ECRTP]) to synchronize the 
   ECRTP decompressor state.  The COMPRESSED_UDP packet updates the RTP 
   context in the decompressor.  
   To ensure delivery of updates of context variables, COMPRESSED_UDP 
   packets should be delivered using the robust operation described in 
   As the "twice" algorithm described in [ECRTP] relies on UDP 
   checksums, the IP stack on the RTP transmitter should transmit UDP 
Koren, Thompson, Wing                                         [Page 5] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   checksums. If UDP checksums are not used, the ECRTP compressor 
   should use the CRTP Headers checksum described in [ECRTP].  
2.2.2.    Out-of-Order Packets  
   Tunneled transport does not guarantee in order delivery of packets.  
   Therefore, the ECRTP decompressor must operate correctly in the 
   presence of out of order packets.  
   The order of packets for RTP is determined by the RTP sequence 
   number.  ECRTP sends short deltas from the RTP seqno, and sends a 
   full value every N packets, where N is an engineered constant tuned 
   to the kind of pipe ECRTP is used for. 
   By contrast, [ROHC] compresses out the sequence number and another 
   layer is necessary for [ROHC] to handle out-of-order delivery of 
   packets over a tunnel [REORDER]. 
2.3.  Multiplexing: PPP Multiplexing  
   Both CRTP and ECRTP require a layer two protocol which allows 
   identifying different protocols.  [PPP] is suited for this. 
   When CRTP is used inside of a tunnel, the header compression 
   associated with CRTP will reduce the size of the IP, UDP, and IP 
   headers of the IP packet carried in the tunnel. However, the tunnel 
   itself has overhead due to its IP header and the tunnel header (the 
   information necessary to identify the tunneled payload). One way to 
   reduce the overhead of the IP header and tunnel header is to 
   multiplex multiple RTP payloads in a single tunneled packet. 
   [PPP-MUX] describes an encapsulation that combines multiple PPP 
   payloads into one multiplexed payload.  PPP multiplexing allows any 
   supported PPP payload type to be multiplexed.  This multiplexed 
   frame is then carried as a single PPPMUX payload in the IP tunnel.  
   This allows multiple RTP payloads to be carried in a single IP 
   tunnel packet and allows the overhead of the uncompressed IP and 
   tunnel headers to be amortized over multiple RTP payloads. 
   During PPP establishment of the TCRTP tunnel, only LCP and IPCP (for 
   header compression) are required -- IP addresses do not need to be 
   negotiated, nor is authentication necessary.  See section 4.1 for 
2.3.1.    PPP Multiplex Transmitter Modifications for Tunneling    
   Section 1.2 of [PPP-MUX] describes an example transmitter procedure 
   that can be used to implement a PPP Multiplex transmitter. The 
   transmission procedure described in this section includes a 
Koren, Thompson, Wing                                         [Page 6] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   parameter MAX-SF-LEN that is used to limit the maximum size of a PPP 
   Multiplex frame. 
   There are two reasons for limiting the size of a PPP Multiplex 
   frame.  First, a PPPMUX frame should never exceed the MRU of a 
   physical link.  Second, when a PPP session and its associated flow 
   control are bound to a physical link, the MAX-SF-LEN parameter forms 
   an upper limit on the amount of time a multiplex packet can be held 
   before being transmitted.  When flow control for the PPP Multiplex 
   transmitter is bound to a physical link, the clock rate of the 
   physical link can be used to pull frames from the PPP Multiplex 
   This type of flow control limits the maximum amount of time a PPP 
   multiplex frame can be held before being transmitted to MAX-SF-LEN / 
   Link Speed. 
   Tunnel interfaces are typically not bound to physical interfaces.  
   Because of this, a tunnel interface has no well-known transmission 
   rate associated with it. This means that flow control in the PPPMUX 
   transmitter cannot rely on the clock of a physical link to pull 
   frames from the multiplex transmitter. Instead, a timer must be used 
   to limit the amount of time a PPPMUX frame can be held before being 
   transmitted.  The timer along with the MAX-SF-LEN parameter should 
   be used to limit the amount of time a PPPMUX frame is held before 
   being transmitted. 
   The following extensions to the PPPMUX transmitter logic should be 
   made for use with tunnels. The flow control logic of the PPP 
   transmitter should be modified to collect incoming payloads until 
   one of two events has occurred:  
          (1)  a specific number of octets, MAX-SF-LEN, has arrived at 
          the multiplexer, or; 
          (2)  a timer, called T, has expired. 
   When either condition is satisfied, the multiplexed PPP payload is 
   The purpose of MAX-SF-LEN is to ensure that a PPPMUX payload does 
   not exceed the MTU size of any of the possible physical links that 
   the tunnel can be associated with. The value of MAX-SF-LEN should be 
   less than or equal to the minimum of MRU-2(maximum size of length 
   field) and 16,383 (14 bits) for all possible physical interfaces 
   that the tunnel may be associated with. 
   The timer T provides an upper delay bound for tunnel interfaces. 
   Timer T is reset whenever a multiplexed payload is sent to the next 
Koren, Thompson, Wing                                         [Page 7] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   encapsulation layer.  The behavior of this timer is similar to 
   AAL2's Timer_CU described in [I.363.2].  Each PPPMUX transmitter 
   should have its own Timer T. 
   The optimal values for  T will vary depending upon the rate at which 
   payloads are expected to arrive at the multiplexer and the delay 
   budget for the multiplexing function.  For voice applications, the 
   value of T would typically be 5-10 milliseconds. 
2.3.2.    Tunneling Inefficiencies  
   To get reasonable bandwidth efficiency using multiplexing within an 
   L2TP tunnel, multiple RTP streams should be active between the 
   source and destination of an L2TP tunnel.  
   If the source and destination of the L2TP tunnel are the same as the 
   source and destination of the ECRTP sessions, then the source and 
   destination must have multiple active RTP streams to get any benefit 
   from multiplexing. 
   Because of this limitation, TCRTP is mostly useful for applications 
   where many RTP sessions run between a pair of RTP endpoints.  The 
   number of simultaneous RTP sessions required to reduce the header 
   overhead to the desired level depends on the size of the L2TP 
   header.  A smaller L2TP header will result in fewer simultaneous RTP 
   sessions being required to produce bandwidth efficiencies similar to 
2.4.  Tunneling: L2TP  
   L2TP tunnels should be used to tunnel the ECRTP payloads end to end.  
   L2TP includes methods for tunneling messages used in PPP session 
   establishment such as NCP.  This allows [IPCP-HC] to negotiate ECRTP 
   compression/decompression parameters.  
2.4.1.    Tunneling and DiffServ  
   RTP streams may be marked with Expedited Forwarding (EF) bits, as 
   described in [EF-PHB].  When such a packet is tunneled, the tunnel 
   header must also be marked for the same EF bits, as required by [EF-
   PHB].  It is important to not mix EF and non-EF traffic in the same 
   EF-marked multiplexed tunnel.  
2.5.  Encapsulation Formats  
   The packet format for an RTP packet compressed with RTP header 
   compression as defined in ECRTP is:  
Koren, Thompson, Wing                                         [Page 8] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
        |         |   MSTI  |             |                       |  
        | Context |         |     UDP     |                       |  
        |   ID    |   Link  |   Checksum  |       RTP Data        |  
        |         | Sequence|             |                       |  
        |  (1-2)  |   (1)   |     (0-2)   |                       |  
   The packet format of a multiplexed PPP packet as defined by [PPP-
   MUX] is:  
        +-------+---+------+-------+-----+   +---+------+-------+-----+  
        | Mux   |P L|      |       |     |   |P L|      |       |     |  
        | PPP   |F X|Len1  |  PPP  |     |   |F X|LenN  |  PPP  |     |  
        | Prot. |F T|      | Prot. |Info1| ~ |F T|      | Prot. |InfoN|  
        | Field |          | Field1|     |   |          |FieldN |     |  
        | (1)   |1-2 octets| (0-2) |     |   |1-2 octets| (0-2) |     |  
        +-------+----------+-------+-----+   +----------+-------+-----+  
   The combined format used for TCRTP with a single payload is all of 
   the above packets concatenated.  Here is an example with one 
        | IP   | Mux   |P L|      |       |       | MSTI|       |    |  
        |header| PPP   |F X|Len1  |  PPP  |Context|     | UDP   |RTP |  
        | (20) | Proto |F T|      | Proto |  ID   | Link| Cksum |Data|  
        |      | Field |          | Field1|       | Seq |       |    |  
        |      | (1)   |1-2 octets| (0-2) | (1-2) | (1) | (0-2) |    |  
               |<------------- IP payload ------------------------->|  
                       |<----- PPPmux payload --------------------->|  
   If the tunnel contains multiplexed traffic, multiple "PPPMux 
   payload"s are transmitted in one IP packet.  
3.   Bandwidth Efficiency  
   The expected bandwidth efficiency attainable with TCRTP depends upon 
   a number of factors.  These factors include multiplexing gain, 
   expected packet loss rate across the network, and rates of change of 
   specific fields within the IP and RTP headers.  This section also 
   describes how TCRTP significantly enhances bandwidth efficiency for 
   voice over IP over ATM.  
3.1.  Multiplexing gains  
Koren, Thompson, Wing                                         [Page 9] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   Multiplexing reduces the overhead associated with the layer 2 and 
   tunnel headers.  Increasing the number of CRTP payloads combined 
   into one multiplexed PPP payload increases multiplexing gain.  As 
   traffic increases within a tunnel, more payloads are combined in one 
   multiplexed payload.  This will increase multiplexing gain.  
3.2.  Packet loss rate  
   Loss of a multiplexed packet causes packet loss for all of the flows 
   within the multiplexed packet.  
   When the expected loss rate in a tunnel is relatively low (less than 
   perhaps 5%), the robust operation (described in [ECRTP]) should be 
   sufficient to ensure delivery of state changes.  This robust 
   operation is characterized by a parameter N which means that the 
   probability of more than N adjacent packets getting lost on the 
   tunnel is small. 
   A value of N=1 will protect against the loss of a single packet 
   within a compressed session at the expense of bandwidth.  A value of 
   N=2 will protect against the loss of two packets in a row within a 
   compressed session and so on.  Higher values of N have higher 
   bandwidth penalties. 
   The optimal value of N will depend on the loss rate in the tunnel.  
   If the loss rate is high (above perhaps 5%) more advanced techniques 
   must be employed.  Those techniques are beyond the scope of this 
3.3.  Bandwidth calculation for Voice and Video Applications  
   The following formula uses the factors described above to model per- 
   flow bandwidth usage for both voice and video applications.  These 
   variables are defined:  
   SOV-TCRTP, unit: octet.  Per-payload overhead of ECRTP and the 
          multiplexed PPP header.  This value does not include 
          additional overhead for updating IP ID or the RTP Time Stamp 
          fields (see [ECRTP] for details on IP ID).  The value assumes 
          the use of the COMPRESSED_RTP payload type.  It consists of 1 
          octet for the ECRTP context ID, 1 octet for COMPRESSED_RTP 
          flags, 2 octets for the UDP checksum, 1 octet for PPP 
          protocol ID, and 1 octet for the multiplexed PPP length 
          field.  The total is 6 octets. 
   POV-TCRTP, unit: octet.  Per-packet overhead of tunneled ECRTP.  
          This is the overhead for the tunnel header and the 
          multiplexed PPP payload type.  This value is 20 octets for 
Koren, Thompson, Wing                                        [Page 10] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
          the IP header, 4 octets for the L2TPv3 header and 1 octet for 
          the multiplexed PPP protocol ID.  The total is 25 octets.    
   TRANSMIT-LENGTH, unit: milliseconds.  The average duration of a 
          transmission (such as a talk spurt for voice streams).  
   SOV-TSTAMP, unit: octet.  Additional per-payload overhead of the 
          COMPRESSED_UDP header that includes the absolute time stamp 
          field.  This value includes 1 octet for the extra flags field 
          in the COMPRESSED_UDP header and 4 octets for the absolute 
          time stamp for a total of 5 octets. 
   SOV-IPID, unit: octet.  Additional per-payload overhead of the 
          COMPRESSED_UDP header that includes the absolute IPID field.  
          This value includes 2 octets for the absolute IPID.  This 
          value also includes 1 octet for the extra flags field in the 
          COMPRESSED_UDP header.  The total is 3 octets.  
   IPID-RATIO, unit: integer values 0 or 1.  Indicates the frequency at 
          which IPID will be updated by the compressor. If IPID is 
          changing randomly and thus always needs to be updated, then 
          the value is 1. If IPID is changing by a fixed constant 
          amount between payloads of a flow, then IPID-RATIO will be 0.  
          The value of this variable does not consider the IPID value 
          at the beginning of a voice or video transmission, as that is 
          considered by the variable TRANSMIT-LENGTH.  The 
          implementation of the sending IP stack and RTP application 
          controls this behavior.  See section 1.1. 
   NREP, unit: integer (usually a number between 1 and 3).  This is the 
          number of times an update field will be repeated in ECRTP 
          headers to increase the delivery rate between the compressor 
          and decompressor.  For this example, we will assume NREP=2. 
   PAYLOAD-SIZE, unit: octets. The size of the RTP payload in octets. 
   MUX-SIZE, unit: count.  The number of PPP payloads multiplexed into 
          one multiplexed PPP payload.  
   SAMPLE-PERIOD, unit: milliseconds.  The average delay between 
          transmissions of voice or video payloads for each flow in the 
          multiplex.  For example, in voice applications the value of 
          this variable would be 10ms if all calls have a 10ms sample 
   The formula is:  
Koren, Thompson, Wing                                        [Page 11] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
               8) / SAMPLE-PERIOD)  
   The results are:  
   BANDWIDTH, unit: kilobits per second.  The average amount of 
             bandwidth used per voice or video flow.  
   SOV-TOTAL = The total amount of per-payload overhead associated with 
             tunneled ECRTP.  It includes the per-payload overhead of 
             ECRTP and PPP, timestamp update overhead, and IPID update 
3.3.1.    Voice Bandwidth Calculation Example  
   To create an example for a voice application using the above 
   formulas, we will assume the following usage scenario.  Compressed 
   voice streams using G.729 compression with a 20 millisecond 
   packetization period.  In this scenario, VAD is enabled and the 
   average talk spurt length is 1500 milliseconds.  The IPID field is 
   changing randomly between payloads of streams.  There is enough 
   traffic in the tunnel to allow 3 multiplexed payloads.  The 
   following values apply:  
        SAMPLE-PERIOD      = 20 milliseconds  
        TRANSMIT-LENGTH    = 1500 milliseconds  
        IPID-RATIO         = 1  
        PAYLOAD-SIZE       = 20 octets  
        MUX-SIZE           = 3  
   For this example, per call bandwidth is 16.4 kbits/sec.  Classical 
   CRTP over a single HDLC link using the same factors as above yields   
   12.4 kbits/sec.  
   The effect of IPID can have a large effect on per call bandwidth.  
   If the above example is recalculated using an IPID-RATIO of 0, then 
   the per call bandwidth is reduced to 13.8 kbits/sec.  Classical CRTP 
   over a single HDLC link using these same factors yields 11.2 
3.3.2.    Voice Bandwidth Comparison Table  
   Using 5 simultaneous calls, no voice activity detection (VAD), G.729 
   with 20ms packetization interval, not considering RTCP overhead:  
       Normal VoIP over PPP:            124kbps  
       with classical CRTP on a link:    50kbps (savings: 59%)  
       with TCRTP over PPP:              62kbps (savings: 50%)  
Koren, Thompson, Wing                                        [Page 12] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
       with TCRTP over AAL5:             85kbps (savings: 31%)  
3.3.3.    Video Bandwidth Calculation Example 
   Since TCRTP can be used to save bandwidth on any type of RTP 
   encapsulated flow, it can be used to save bandwidth for video 
   applications.  This section documents an example of TCRTP based 
   bandwidth savings for MPEG-2 encoded video. 
   To create an example for a video application using the above 
   formulas, we will assume the following usage scenario.  RTP 
   encapsulation of MPEG System and Transport Streams is performed as 
   described in RFC 2250.  Frames for MPEG-2 encoded video are sent 
   continuously, so the TRANSMIT-LENGTH variable in the bandwidth 
   formula is essentially infinite.  The IPID field is changing 
   randomly between payloads of streams.  There is enough traffic in 
   the tunnel to allow 3 multiplexed payloads.  The following values 
        SAMPLE-PERIOD      = 2.8 milliseconds  
        TRANSMIT-LENGTH    = infinite  
        IPID-RATIO         = 1  
        PAYLOAD-SIZE       = 1316 octets  
        MUX-SIZE           = 3  
   For this example, per flow bandwidth is 3.8 Mbits/sec.  MPEG video 
   with no header compression using the same factors as above yields   
   3.9 Mbits/sec.  While TCRTP does provide some bandwidth savings for 
   video, the ratio of transmission headers to payload is so small that 
   the bandwidth savings are insignificant. 
3.3.4.    TCRTP over ATM  
   IP transport over AAL5 causes a quantizing effect to bandwidth 
   utilization due to the packets always being multiples of ATM cells. 
   For example, the payload size for G.729 using 10 millisecond 
   packetization interval is 10 octets.  This is much smaller than the 
   payload size of an ATM cell (48 octets).  When classical CRTP [CRTP] 
   is used on a link-by-link basis, the IP overhead to payload ratio is 
   quite good.  However, AAL5 encapsulation and its cell padding always 
   force the minimum payload size to be one ATM cell, which results in 
   poor bandwidth utilization.  
   Instead of wasting this padding, the multiplexing of TCRTP allows 
   this previously wasted space in the ATM cell to contain useful data.  
   This is one of the main reasons why multiplexing has such a large 
   effect on bandwidth utilization with Voice over IP over ATM.  
Koren, Thompson, Wing                                        [Page 13] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   This multiplexing efficiency of TCRTP is similar to AAL2 sub-cell 
   multiplexing described in [I.363.1].  Unlike AAL2 sub-cell 
   multiplexing, however, TCRTP's multiplexing efficiency isn't limited  
   to only ATM networks.  
3.3.5.    TCRTP over non-ATM networks  
   When TCRTP is used with other layer 2 encapsulations that do not 
   have a minimum PDU size, the benefit of multiplexing is not as 
   Depending upon the exact overhead of the layer 2 encapsulation, the 
   benefit of multiplexing might be slightly better or worse than link-
   by-link CRTP header compression.  The per-payload overhead of CRTP 
   tunneling is either 4 or 6 octets.  If classical CRTP plus layer 2 
   overhead is greater than this amount, TCRTP multiplexing will 
   consume less bandwidth than classical CRTP when the outer IP header 
   is amortized over a large number of payloads.  
   The payload breakeven point can be determined by the following 
          * MUX-SIZE  
     POV-L2, unit: octet.  Layer 2 packet overhead: 5 octets for HDLC 
     POV-TUNNEL, unit: octet.  Packet overhead due to tunneling: 24 
          octets IP header and L2TPv3 header 
     POV-PPPMUX, unit: octet.  Packet overhead for the multiplexed PPP 
          protocol ID: 1 octet  
     SOV-PPPMUX, unit: octet.  Per-payload overhead of PPPMUX, which is 
          comprised of the payload length field and the ECRTP protocol 
          ID.  The value of SOV-PPPMUX is typically 1, 2, or 3.  
   If using HDLC as the layer 2 protocol, the breakeven point using the 
   above formula is when MUX-SIZE = 7.  Thus 7 voice or video flows 
   need to be multiplexed to make TCRTP as bandwidth-efficient as lijnk 
   by link CRTP ocmpression.  
4.   Example implementation of TCRTP  
Koren, Thompson, Wing                                        [Page 14] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   This section describes an example implementation of TCRTP.  
   Implementations of TCRTP may be done in many ways as long as the 
   requirements of the associated RFCs are met.  
   Here is the path an RTP packet takes in this implementation:  
         +-------------------------------+             ^  
         |          Application          |             |  
         +-------------------------------+             |  
         |              RTP              |             |  
         +-------------------------------+        Application and   
         |              UDP              |            IP stack  
         +-------------------------------+             |  
         |              IP               |             |  
         +-------------------------------+             V  
                         |  IP forwarding  
         +-------------------------------+             ^  
         |             ECRTP             |             |  
         +-------------------------------+             |  
         |            PPPMUX             |             |  
         +-------------------------------+          Tunnel  
         |             PPP               |         Interface  
         +-------------------------------+             |  
         |             L2TP              |             |  
         +-------------------------------+             |  
         |              IP               |             |  
         +-------------------------------+             V  
                         |  IP forwarding  
         +-------------------------------+             ^  
         |            Layer 2            |             |  
         +-------------------------------+          Physical  
         |            Physical           |          Interface  
         +-------------------------------+             V  
   A protocol stack is configured to create an L2TP tunnel interface to 
   a destination host.  The tunnel is configured to negotiate the PPP 
   connection (using NCP IPCP) with ECRTP header compression and 
   PPPMUX.  IP forwarding is configured to route RTP packets to this 
   tunnel.  The destination UDP port number could distinguish RTP 
   packets from non- RTP packets.  
   The transmitting application gathers the RTP data from one source, 
   and formats an RTP packet. Lower level application layers add UDP 
   and IP headers to form a complete IP packet.  
Koren, Thompson, Wing                                        [Page 15] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   The RTP packets are routed to the tunnel interface where headers are 
   compressed, payloads multiplexed, and then tunneled to the 
   destination host. 
   The operation of the receiving node is the same as the transmitting 
   node in reverse.  
4.1.  Suggested PPP and L2TP negotiation for TCRTP  
   This section describes the necessary PPP and LT2P negotiations 
   necessary for establishing a PPP connection and L2TP tunnel with 
   L2TP header compression.  The negotiation is between two peers: 
   Peer1 and Peer2.  
4.2.  PPP negotiation TCRTP  
   The Point-to-Point Protocol is described in [PPP].  
4.2.1.    LCP negotiation  
   Link Control Processing (LCP) is described in [PPP].    Link Establishment  
              Peer1                       Peer2  
              -----                       -----  
     Configure-Request (no options) ->  
                                     <- Configure-Ack  
                                     <- Configure-Request (no options)  
     Configure-Ack                  ->    Link Tear Down  
     Terminate-Request              ->  
                                     <- Terminate-Ack  
4.2.2.    IPCP negotiation  
   The protocol exchange here is described in [IPHCOMP], [PPP], and  
              Peer1                       Peer2  
              -----                       -----  
     Configure-Request              ->         
         Use protocol 0x61   
         and sub-parameters  
         as described in   
Koren, Thompson, Wing                                        [Page 16] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
         [IPCP-HC] and [ECRTP]  
                                     <- Configure-Ack  
                                     <- Configure-Request  
                                            Use protocol 0x61 
                                            and sub-parameters  
                                            as described in   
                                            [IPCP-HC] and [ECRTP]  
     Configure-Ack                  ->  
4.3.  L2TP negotiation  
   L2TP is described in [L2TPv3].  
4.3.1.    Tunnel Establishment  
              Peer1                       Peer2  
              -----                       -----  
     SCCRQ                          ->  
       Mandatory AVP's:  
       Message Type  
       Protocol Version  
       Host Name  
       Framing Capabilities  
       Assigned Tunnel ID  
                                     <- SCCRP  
                                          Mandatory AVP's:  
                                          Message Type  
                                          Protocol Version  
                                          Host Name  
                                          Framing Capabilities  
                                          Assigned Tunnel ID  
     SCCCN                          ->  
     Mandatory AVP's:  
       Message Type  
                                     <- ZLB  
4.3.2.    Session Establishment  
              Peer1                       Peer2  
              -----                       -----  
     ICRQ                           ->  
       Mandatory AVP's:  
       Message Type  
       Assigned Session ID  
       Call Serial Number  
                                         <- ICRP  
                                          Mandatory AVP's:  
Koren, Thompson, Wing                                        [Page 17] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
                                          Message Type  
                                          Assigned Session ID  
     ICCN                           ->  
       Mandatory AVP's:  
       Message Type  
       Tx (Connect Speed)  
       Framing Type  
                                     <- ZLB  
4.3.3.    Tunnel Tear Down  
              Peer1                       Peer2  
              -----                       -----  
     StopCCN                        ->  
       Mandatory AVP's:  
       Message Type  
       Assigned Tunnel ID  
       Result Code  
                                     <- ZLB  
5.   IANA Considerations 
   This document does not require any assignments from IANA. 
6.   Security Considerations  
   This document describes a method for combining several existing 
   protocols implementing compression, multiplexing, and tunneling of 
   RTP streams.  Attacks on the component technologies of TCRTP include 
   attacks on RTP/RTCP headers and payloads carried within a TCRTP 
   session, attacks on the compressed headers, attacks on the 
   multiplexing layer, or attacks on the tunneling negotiation or 
   transport.  The security issues associated individually with each of 
   those component technologies are addressed in their respective 
   specifications, [ECRTP], [PPP-MUX], [L2TPv3], along with the 
   security considerations for RTP itself [RTP]. 
   However, there may be additional security considerations arising 
   from the use of these component technologies together.  For example, 
   there may be an increased risk of unintended misdelivery of packets 
   from one stream in the multiplex to another due to a protocol 
   malfunction or data error because the addressing information is more 
   condensed.  This is particularly true if the tunnel is transmitted 
   over a link-layer protocol that allows delivery of packets 
   containing bit errors in combination with a tunnel transport layer 
   option that does not checksum all of the payload. 
Koren, Thompson, Wing                                        [Page 18] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   The opportunity for malicious misdirection may be increased relative 
   to that for a single RTP stream transported by itself because 
   addressing information must be unencrypted for the header 
   compression and multiplexing layers to function. 
   The primary defense against misdelivery is to make the data unusable 
   to unintended recipients through cryptographic techniques.  The 
   basic method for encryption provided in the RTP specification [RTP] 
   is not suitable because it encrypts the RTP and RTCP headers along 
   with the payload.  However, the RTP specification also allows 
   alternative approaches to be defined in separate profile or payload 
   format specifications wherein only the payload portion of the packet 
   would be encrypted so header compression may be applied to the 
   encrypted packets.  One such profile [SRTP] provides more 
   sophisticated and complete methods for encryption and message 
   authentication than the basic approach in [RTP].  Additional methods 
   may be developed in the future.  Appropriate cryptographic 
   protection should be incorporated into all TCRTP applications. 
7.   Acknowledgements  
   The authors would like to thank the authors of RFC2508, Stephen 
   Casner and Van Jacobson, and the authors of RFC2507, Mikael 
   Degermark, Bjorn Nordgren, and Stephen Pink.  
   The authors would also like to thank Dana Blair, Alex Tweedley, 
   Paddy Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, 
   Hussein Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, 
   Andrew  Valencia, Herb Wildfeuer, J. Martin Borden, John 
   Geevarghese, and Shoou Yiu.  
8.   References 
   Normative References 
     [PPP-MUX] R. Pazhyannur, I. Ali, C. Fox, "PPP Multiplexing", 
          RFC3153, August 2001.   
     [ECRTP] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. 
          Ruddy, " Enhanced Compressed RTP (CRTP) for Links with High 
          Delay, Packet Loss and Reordering",RFC3545, July 2003.  
     [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 
          Low-Speed Serial Links", RFC2508, February 1999.  
     [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, "IP Header 
          Compression", RFC2507, February 1999.  
Koren, Thompson, Wing                                        [Page 19] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
     [IPCP-HC] M. Engan, S. Casner, C. Bormann, "IP Header Compression 
          over PPP", RFC2509, February 1999.  
     [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: 
          A Transport Protocol for Real-Time Applications", RFC1889, 
          January 1996.  
     [L2TP] M. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. 
          Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661, 
          August 1999.  
     [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 
          Protocol (Version 3)", draft-ietf-l2tpext-l2tp-base-14.txt, 
          June 2004.  
     [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 
          2 AAL", I.363.2, September 1997.  
     [EF-PHB] V. Jacobson, K. Nichols, K. Poduri, "An Expedited 
          Forwarding PHB", RFC2598, June 1999. 
     [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC1661, 
          July 1994. 
   Informative References 
     [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 
          "The Secure Real-time Transport Protocol (SRTP)",RFC3711, 
          March 2004. 
     [REORDER] G. Pelletier, L. Jonsson, K. Sandlund, "RObust Header 
          Compression (ROHC): ROHC over Channels that can Reorder 
          Packets", Work in Progress, <draft-pelletier-rohc-over-
          reordering-00.txt>, June 2004. 
     [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 
          Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 
          Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, 
          T., Yoshimura, T. and H. Zheng, "RObust Header Compression 
          (ROHC): Framework and four profiles: RTP, UDP, ESP, and 
          uncompressed", RFC 3095, July 2001. 
9.   Authors' Addresses  
   Bruce Thompson  
   170 West Tasman Drive  
   San Jose, CA  95134-1706  
   United States of America  
Koren, Thompson, Wing                                        [Page 20] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   Phone: +1 408 527 0446  
   Tmima Koren  
   170 West Tasman Drive  
   San Jose, CA  95134-1706  
   United States of America  
   Phone: +1 408 527 6169  
   Dan Wing  
   170 West Tasman Drive  
   San Jose, CA  95134-1706  
   United States of America  
10.  Copyright Notice  
   Copyright (C) The Internet Society (2004).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
11.  Disclaimers 
   This document and the information contained herein are provided 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79. 
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
Koren, Thompson, Wing                                        [Page 21] 

INTERNET-DRAFT    Tunneled Multiplexed Compressed RTP    August, 2004 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf- 
Koren, Thompson, Wing                                        [Page 22]