draft-ietf-avt-rtp-and-rtcp-mux-05.txt   draft-ietf-avt-rtp-and-rtcp-mux-06.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Updates: 3550 (if approved) M. Westerlund Updates: 3550 (if approved) M. Westerlund
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: November 22, 2007 May 21, 2007 Expires: January 24, 2008 July 23, 2007
Multiplexing RTP Data and Control Packets on a Single Port Multiplexing RTP Data and Control Packets on a Single Port
draft-ietf-avt-rtp-and-rtcp-mux-05.txt draft-ietf-avt-rtp-and-rtcp-mux-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 22, 2007. This Internet-Draft will expire on January 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo discusses issues that arise when multiplexing RTP data This memo discusses issues that arise when multiplexing RTP data
packets and RTP control protocol (RTCP) packets on a single UDP port. packets and RTP control protocol (RTCP) packets on a single UDP port.
It updates RFC 3550 to describe when such multiplexing is, and is It updates RFC 3550 to describe when such multiplexing is, and is
not, appropriate, and explains how the Session Description Protocol not, appropriate, and explains how the Session Description Protocol
(SDP) can be used to signal multiplexed sessions. (SDP) can be used to signal multiplexed sessions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4
5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5 5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 6
5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6 5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6 5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7 5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7
5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7 5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7
5.1.4. Interactions with Header Compression . . . . . . . . . 8 5.1.4. Interactions with Header Compression . . . . . . . . . 8
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8 5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9 5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9 6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [1] comprises two components: The Real-time Transport Protocol (RTP) [1] comprises two components:
a data transfer protocol, and an associated control protocol (RTCP). a data transfer protocol, and an associated control protocol (RTCP).
Historically, RTP and RTCP have been run on separate UDP ports. With Historically, RTP and RTCP have been run on separate UDP ports. With
increased use of Network Address Translation (NAT) this has become increased use of Network Address Port Translation (NAPT) [14] this
problematic, since opening multiple NAT pinholes can be costly. This has become problematic, since maintaining multiple NAT bindings can
memo discusses how the RTP and RTCP flows for a single media type can be costly. It also complicates firewall administration, since
be run on a single port, to ease NAT traversal, and considers when multiple ports must be opened to allow RTP traffic. This memo
such multiplexing is appropriate. The multiplexing of several types discusses how the RTP and RTCP flows for a single media type can be
of media (e.g. audio and video) onto a single port is not considered run on a single port, to ease NAT traversal and simplify firewall
here (but see Section 5.2 of [1]). administration, and considers when such multiplexing is appropriate.
The multiplexing of several types of media (e.g. audio and video)
onto a single port is not considered here (but see Section 5.2 of
[1]).
This memo is structured as follows: in Section 2 we discuss the This memo is structured as follows: in Section 2 we discuss the
design choices which led to the use of separate ports, and comment on design choices which led to the use of separate ports, and comment on
the applicability of those choices to current network environments. the applicability of those choices to current network environments.
We discuss terminology in Section 3, how to distinguish multiplexed We discuss terminology in Section 3, how to distinguish multiplexed
packets in Section 4, and then specify when and how RTP and RTCP packets in Section 4, and then specify when and how RTP and RTCP
should be multiplexed, and how to signal multiplexed sessions, in should be multiplexed, and how to signal multiplexed sessions, in
Section 5. Quality of service and bandwidth issues are discussion in Section 5. Quality of service and bandwidth issues are discussion in
Section 6. We conclude with security considerations in Section 7. Section 6. We conclude with security considerations in Section 7.
skipping to change at page 3, line 46 skipping to change at page 3, line 49
to the underlying transport protocol, rather than being provided to the underlying transport protocol, rather than being provided
within RTP, for the following reasons: within RTP, for the following reasons:
1. Simplicity: an RTP implementation is simplified by moving the RTP 1. Simplicity: an RTP implementation is simplified by moving the RTP
and RTCP demultiplexing to the transport layer, since it need not and RTCP demultiplexing to the transport layer, since it need not
concern itself with the separation of data and control packets. concern itself with the separation of data and control packets.
This allows the implementation to be structured in a very natural This allows the implementation to be structured in a very natural
fashion, with a clean separation of data and control planes. fashion, with a clean separation of data and control planes.
2. Efficiency: following the principle of integrated layer 2. Efficiency: following the principle of integrated layer
processing [14] an implementation will be more efficient when processing [15] an implementation will be more efficient when
demultiplexing happens in a single place (e.g. according to UDP demultiplexing happens in a single place (e.g. according to UDP
port) than when split across multiple layers of the stack (e.g. port) than when split across multiple layers of the stack (e.g.
according to UDP port then according to packet type). according to UDP port then according to packet type).
3. To enable third party monitors: while unicast voice-over-IP has 3. To enable third party monitors: while unicast voice-over-IP has
always been considered, RTP was also designed to support loosely always been considered, RTP was also designed to support loosely
coupled multicast conferences [15] and very large-scale multicast coupled multicast conferences [16] and very large-scale multicast
streaming media applications (such as the so-called "triple-play" streaming media applications (such as the so-called "triple-play"
IPTV service). Accordingly, the design of RTP allows the RTCP IPTV service). Accordingly, the design of RTP allows the RTCP
packets to be multicast using a separate IP multicast group and packets to be multicast using a separate IP multicast group and
UDP port to the data packets. This not only allows participants UDP port to the data packets. This not only allows participants
in a session to get reception quality feedback, but also enables in a session to get reception quality feedback, but also enables
deployment of third party monitors which listen to reception deployment of third party monitors which listen to reception
quality without access to the data packets. This was intended to quality without access to the data packets. This was intended to
provide manageability of multicast sessions, without compromising provide manageability of multicast sessions, without compromising
privacy. privacy.
skipping to change at page 4, line 41 skipping to change at page 4, line 43
the RTP implementation, in exchange for simplified NAT traversal. the RTP implementation, in exchange for simplified NAT traversal.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
4. Distinguishable RTP and RTCP Packets 4. Distinguishable RTP and RTCP Packets
When RTP and RTCP packets are multiplexed onto a single port, they When RTP and RTCP packets are multiplexed onto a single port, the
can be distinguished provided: 1) the RTP payload type (PT) values RTCP packet type field occupies the same position in the packet as
the combination of the RTP marker (M) bit and the RTP payload type
(PT). This field can be used to distinguish RTP and RTCP packets
when two restrictions are observed: 1) the RTP payload type values
used are distinct from the RTCP packet types used; and 2) for each used are distinct from the RTCP packet types used; and 2) for each
RTP payload type, PT+128 is distinct from the RTCP packet types used. RTP payload type (PT), PT+128 is distinct from the RTCP packet types
The first constraint precludes a direct conflict between RTP payload used. The first constraint precludes a direct conflict between RTP
type and RTCP packet type, the second constraint precludes a conflict payload type and RTCP packet type, the second constraint precludes a
between an RTP data packet with marker bit set and an RTCP packet. conflict between an RTP data packet with the marker bit set and an
This demultiplexing method works because the RTP payload type and RTCP packet.
RTCP packet type occupy the same position within the packet.
The following conflicts between RTP and RTCP packet types are known: The following conflicts between RTP and RTCP packet types are known:
o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and
NACK packets defined in the original RTP Payload Format for H.261 NACK packets defined in the original RTP Payload Format for H.261
[3]. [3].
o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE
and APP packets defined in the RTP specification [1]. and APP packets defined in the RTP specification [1].
skipping to change at page 5, line 29 skipping to change at page 5, line 32
o RTP payload type 80 conflicts with Receiver Summary Information o RTP payload type 80 conflicts with Receiver Summary Information
(RSI) packets defined in the RTCP Extensions for Single-Source (RSI) packets defined in the RTCP Extensions for Single-Source
Multicast Sessions with Unicast Feedback [6]. Multicast Sessions with Unicast Feedback [6].
New RTCP packet types may be registered in future, and will further New RTCP packet types may be registered in future, and will further
reduce the RTP payload types that are available when multiplexing RTP reduce the RTP payload types that are available when multiplexing RTP
and RTCP onto a single port. To allow this multiplexing, future RTCP and RTCP onto a single port. To allow this multiplexing, future RTCP
packet type assignments SHOULD be made after the current assignments packet type assignments SHOULD be made after the current assignments
in the range 209-223, then in the range 194-199, so that only the RTP in the range 209-223, then in the range 194-199, so that only the RTP
payload types in the range 64-95 are blocked. payload types in the range 64-95 are blocked. RTCP packet types in
the ranges 1-191 and 224-254 SHOULD only be used when other values
have been exhausted.
Given these constraints, it is RECOMMENDED to follow the guidelines Given these constraints, it is RECOMMENDED to follow the guidelines
in the RTP/AVP profile [7] for the choice of RTP payload type values, in the RTP/AVP profile [7] for the choice of RTP payload type values,
with the additional restriction that payload type values in the range with the additional restriction that payload type values in the range
64-95 MUST NOT be used. Specifically, dynamic RTP payload types 64-95 MUST NOT be used. Specifically, dynamic RTP payload types
SHOULD be chosen in the range 96-127 where possible. Values below 64 SHOULD be chosen in the range 96-127 where possible. Values below 64
MAY be used if that is insufficient, in which case it is RECOMMENDED MAY be used if that is insufficient, in which case it is RECOMMENDED
that payload type numbers that are not statically assigned by [7] be that payload type numbers that are not statically assigned by [7] be
used first. used first.
skipping to change at page 7, line 25 skipping to change at page 7, line 29
multiplexing is offered in that INVITE, it is important to be aware multiplexing is offered in that INVITE, it is important to be aware
that some answerers may support multiplexed RTP and RTCP, some not. that some answerers may support multiplexed RTP and RTCP, some not.
This will require the offerer to listen for RTCP on both the RTP port This will require the offerer to listen for RTCP on both the RTP port
and the usual RTCP port, and to send RTCP on both ports, unless and the usual RTCP port, and to send RTCP on both ports, unless
branches of the call that support multiplexing are re-negotiated to branches of the call that support multiplexing are re-negotiated to
use separate RTP and RTCP ports. use separate RTP and RTCP ports.
5.1.3. Interactions with ICE 5.1.3. Interactions with ICE
It is common to use the Interactive Connectivity Establishment (ICE) It is common to use the Interactive Connectivity Establishment (ICE)
[16] methodology to establish RTP sessions in the presence of Network [17] methodology to establish RTP sessions in the presence of Network
Address Translation (NAT) devices or other middleboxes. If RTP and Address Translation (NAT) devices or other middleboxes. If RTP and
RTCP are sent on separate ports, the RTP media stream comprises two RTCP are sent on separate ports, the RTP media stream comprises two
components in ICE (one for RTP and one for RTCP), with connectivity components in ICE (one for RTP and one for RTCP), with connectivity
checks being performed for each component. If RTP and RTCP are to be checks being performed for each component. If RTP and RTCP are to be
multiplexed on the same port some of these connectivity checks can be multiplexed on the same port some of these connectivity checks can be
avoided, reducing the overhead of ICE. avoided, reducing the overhead of ICE.
If it is desired to use both ICE and multiplexed RTP and RTCP, the If it is desired to use both ICE and multiplexed RTP and RTCP, the
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:" RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:"
skipping to change at page 8, line 17 skipping to change at page 8, line 22
session is established. If the "a=rtcp-mux" line is not present, the session is established. If the "a=rtcp-mux" line is not present, the
session proceeds with connectivity checks using both RTP and RTCP session proceeds with connectivity checks using both RTP and RTCP
candidates, eventually leading to a session being established with candidates, eventually leading to a session being established with
RTP and RTCP on separate ports (as signalled by the "a=rtcp:" RTP and RTCP on separate ports (as signalled by the "a=rtcp:"
attribute). attribute).
5.1.4. Interactions with Header Compression 5.1.4. Interactions with Header Compression
Multiplexing RTP and RTCP packets onto a single port may negatively Multiplexing RTP and RTCP packets onto a single port may negatively
impact header compression schemes, for example Compressed RTP (CRTP) impact header compression schemes, for example Compressed RTP (CRTP)
[17] and RObust Header Compression (ROHC) [18]. Header compression [18] and RObust Header Compression (ROHC) [19]. Header compression
exploits patterns of change in the RTP headers of consecutive packets exploits patterns of change in the RTP headers of consecutive packets
to send an indication that the packet changed in the expected way, to send an indication that the packet changed in the expected way,
rather than sending the complete header each time. This can lead to rather than sending the complete header each time. This can lead to
significant bandwidth savings if flows have uniform behaviour. significant bandwidth savings if flows have uniform behaviour.
The presence of RTCP packets multiplexed with RTP data packets can The presence of RTCP packets multiplexed with RTP data packets can
disrupt the patterns of change between headers, and has the potential disrupt the patterns of change between headers, and has the potential
to significantly reduce header compression efficiency. The extent of to significantly reduce header compression efficiency. The extent of
this disruption depends on the header compression algorithm used, and this disruption depends on the header compression algorithm used, and
on the way flows are classified. A well designed classifier should on the way flows are classified. A well designed classifier should
skipping to change at page 11, line 16 skipping to change at page 11, line 24
o Long-form attribute name: RTP and RTCP multiplexed on one port o Long-form attribute name: RTP and RTCP multiplexed on one port
o Type of attribute: media level o Type of attribute: media level
o Subject to charset: no o Subject to charset: no
This attribute is used to signal that RTP and RTCP traffic should be This attribute is used to signal that RTP and RTCP traffic should be
multiplexed on a single port (see Section 5 of this memo). It is a multiplexed on a single port (see Section 5 of this memo). It is a
property attribute, which does not take a value. property attribute, which does not take a value.
The rules for assignment of RTP RTCP Control Packet Types in the RTP
Parameters registry are updated as follows. When assigning RTP RTCP
Control Packet types, IANA is requested to assign unused values from
the range 200-223 where possible. If that range is fully occupied,
values from the range 194-199 may be used, and then values from the
ranges 1-191 and 224-254. This improves header validity checking of
RTCP packets compared to RTP packets or other unrelated packets. The
values 0 and 255 are avoided for improved validity checking relative
to random packets since all-zeros and all-ones are common values.
Note to RFC Editor: please replace "RFC XXXX" above with the RFC Note to RFC Editor: please replace "RFC XXXX" above with the RFC
number of this memo, and remove this note. number of this memo, and remove this note.
9. Acknowledgements 9. Acknowledgements
We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar
Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni,
Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson, Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson,
Dave Singer, and Kevin Johns for their comments on this memo. This Dave Singer, Kevin Johns, and David Black for their comments on this
work was supported in part by the UK Engineering and Physical memo. This work was supported in part by the UK Engineering and
Sciences Research Council. Physical Sciences Research Council.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
skipping to change at page 12, line 33 skipping to change at page 13, line 7
[12] Casner, S., "Session Description Protocol (SDP) Bandwidth [12] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003. July 2003.
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
10.2. Informative References 10.2. Informative References
[14] Clark, D. and D. Tennenhouse, "Architectural Considerations for [14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[15] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols", Proceedings of ACM a New Generation of Protocols", Proceedings of ACM
SIGCOMM 1990, September 1990. SIGCOMM 1990, September 1990.
[15] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM [16] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM
SIGCOMM Computer Communication Review, Volume 22, Number 3, SIGCOMM Computer Communication Review, Volume 22, Number 3,
July 1992. July 1992.
[16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [17] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-15 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-15 (work in
progress), March 2007. progress), March 2007.
[17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for [18] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999. Low-Speed Serial Links", RFC 2508, February 1999.
[18] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [19] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
 End of changes. 24 change blocks. 
38 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/