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 | |||
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[3] Turletti, T., "RTP Payload Format for H.261 Video Streams", | [3] Turletti, T., "RTP Payload Format for H.261 Video Streams", | |||
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. 25 change blocks. | ||||
39 lines changed or deleted | 59 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |