diff options
Diffstat (limited to 'doc/rfc/rfc5761.txt')
| -rw-r--r-- | doc/rfc/rfc5761.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc5761.txt b/doc/rfc/rfc5761.txt new file mode 100644 index 0000000..3ad7216 --- /dev/null +++ b/doc/rfc/rfc5761.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Perkins +Request for Comments: 5761 University of Glasgow +Updates: 3550, 3551 M. Westerlund +Category: Standards Track Ericsson +ISSN: 2070-1721 April 2010 + + + Multiplexing RTP Data and Control Packets on a Single Port + +Abstract + + This memo discusses issues that arise when multiplexing RTP data + packets and RTP Control Protocol (RTCP) packets on a single UDP port. + It updates RFC 3550 and RFC 3551 to describe when such multiplexing + is and is not appropriate, and it explains how the Session + Description Protocol (SDP) can be used to signal multiplexed + sessions. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5761. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Perkins & Westerlund Standards Track [Page 1] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Background ......................................................3 + 3. Terminology .....................................................4 + 4. Distinguishable RTP and RTCP Packets ............................4 + 5. Multiplexing RTP and RTCP on a Single Port ......................6 + 5.1. Unicast Sessions ...........................................6 + 5.1.1. SDP Signalling ......................................6 + 5.1.2. Interactions with SIP Forking .......................7 + 5.1.3. Interactions with ICE ...............................7 + 5.1.4. Interactions with Header Compression ................8 + 5.2. Any Source Multicast Sessions ..............................9 + 5.3. Source-Specific Multicast Sessions .........................9 + 6. Multiplexing, Bandwidth, and Quality of Service ................10 + 7. Security Considerations ........................................10 + 8. IANA Considerations ............................................11 + 9. Acknowledgements ...............................................11 + 10. References ....................................................11 + 10.1. Normative References .....................................11 + 10.2. Informative References ...................................12 + + + + + + + + + + + + + + + + + + +Perkins & Westerlund Standards Track [Page 2] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + +1. Introduction + + The Real-time Transport Protocol (RTP) [1] comprises two components: + a data transfer protocol and an associated control protocol (RTCP). + Historically, RTP and RTCP have been run on separate UDP ports. With + increased use of Network Address Port Translation (NAPT) [14], this + has become problematic, since maintaining multiple NAT bindings can + be costly. It also complicates firewall administration, since + multiple ports must be opened to allow RTP traffic. This memo + discusses how the RTP and RTCP flows for a single media type can be + run on a single port, to ease NAT traversal and simplify firewall + 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 + design choices that led to the use of separate ports and comment on + the applicability of those choices to current network environments. + We discuss terminology in Section 3 and how to distinguish + multiplexed packets in Section 4; we then specify when and how RTP + and RTCP should be multiplexed, and how to signal multiplexed + sessions, in Section 5. Quality of service and bandwidth issues are + discussed in Section 6. We conclude with security considerations in + Section 7 and IANA considerations in Section 8. + + This memo updates Section 11 of [1]. + +2. Background + + An RTP session comprises data packets and periodic control (RTCP) + packets. RTCP packets are assumed to use "the same distribution + mechanism as the data packets", and the "underlying protocol MUST + provide multiplexing of the data and control packets, for example + using separate port numbers with UDP" [1]. Multiplexing was deferred + to the underlying transport protocol, rather than being provided + within RTP, for the following reasons: + + 1. Simplicity: an RTP implementation is simplified by moving the RTP + and RTCP demultiplexing to the transport layer, since it need not + concern itself with the separation of data and control packets. + This allows the implementation to be structured in a very natural + fashion, with a clean separation of data and control planes. + + + + + + + + +Perkins & Westerlund Standards Track [Page 3] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + 2. Efficiency: following the principle of integrated layer + processing [15], an implementation will be more efficient when + demultiplexing happens in a single place (e.g., according to UDP + port) than when split across multiple layers of the stack (e.g., + according to UDP port and then according to packet type). + + 3. To enable third-party monitors: while unicast voice-over-IP has + always been considered, RTP was also designed to support loosely + coupled multicast conferences [16] and very large-scale multicast + streaming media applications (such as the so-called triple-play + IP television (IPTV) service). Accordingly, the design of RTP + allows the RTCP packets to be multicast using a separate IP + multicast group and UDP port to the data packets. This not only + allows participants in a session to get reception-quality + feedback but also enables deployment of third-party monitors, + which listen to reception quality without access to the data + packets. This was intended to provide manageability of multicast + sessions, without compromising privacy. + + While these design choices are appropriate for many uses of RTP, they + are problematic in some cases. There are many RTP deployments that + don't use IP multicast, and with the increased use of Network Address + Translation (NAT) the simplicity of multiplexing at the transport + layer has become a liability, since it requires complex signalling to + open multiple NAT pinholes. In environments such as these, it is + desirable to provide an alternative to demultiplexing RTP and RTCP + using separate UDP ports, instead using only a single UDP port and + demultiplexing within the application. + + This memo provides such an alternative by multiplexing RTP and RTCP + packets on a single UDP port, distinguished by the RTP payload type + and RTCP packet type values. This pushes some additional work onto + the RTP implementation, in exchange for simplified NAT traversal. + +3. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + +4. Distinguishable RTP and RTCP Packets + + When RTP and RTCP packets are multiplexed onto a single port, the + 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 + + + +Perkins & Westerlund Standards Track [Page 4] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + RTP payload type (PT), PT+128 is distinct from the RTCP packet types + used. The first constraint precludes a direct conflict between RTP + payload type and RTCP packet type; the second constraint precludes a + conflict between an RTP data packet with the marker bit set and an + RTCP packet. + + The following conflicts between RTP and RTCP packet types are known: + + 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 + Video Streams" [3] (which was obsoleted by [17]). + + o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE, + and APP packets defined in the RTP specification [1]. + + o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB + packets defined in the RTP/AVPF profile [4]. + + o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] + packets. + + o RTP payload type 80 conflicts with Receiver Summary Information + (RSI) packets defined in "RTCP Extensions for Single-Source + Multicast Sessions with Unicast Feedback" [6]. + + New RTCP packet types may be registered in the future and will + further reduce the RTP payload types that are available when + multiplexing RTP and RTCP onto a single port. To allow this + multiplexing, future RTCP 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 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 + 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 + 64-95 MUST NOT be used. Specifically, dynamic RTP payload types + 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 + that payload type numbers that are not statically assigned by [7] be + used first. + + Note: Since Section 6.1 of [1] specifies that all RTCP packets + MUST be sent as compound packets beginning with a Sender Report + (SR) or a Receiver Report (RR) packet, one might wonder why RTP + + + + + +Perkins & Westerlund Standards Track [Page 5] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + payload types other than 72 and 73 are prohibited when + multiplexing RTP and RTCP. This is done to support [18], which + allows the use of non-compound RTCP packets in some circumstances. + +5. Multiplexing RTP and RTCP on a Single Port + + The procedures for multiplexing RTP and RTCP on a single port depend + on whether the session is a unicast session or a multicast session. + For multicast sessions, the procedures also depend on whether Any + Source Multicast (ASM) or Source-Specific Multicast (SSM) is to be + used. + +5.1. Unicast Sessions + + It is acceptable to multiplex RTP and RTCP packets on a single UDP + port to ease NAT traversal for unicast sessions, provided the RTP + payload types used in the session are chosen according to the rules + in Section 4, and provided that multiplexing is signalled in advance. + The following sections describe how such multiplexed sessions can be + signalled using the Session Initiation Protocol (SIP) with the offer/ + answer model. + +5.1.1. SDP Signalling + + When the Session Description Protocol (SDP) [8] is used to negotiate + RTP sessions following the offer/answer model [9], the "a=rtcp-mux" + attribute (see Section 8) indicates the desire to multiplex RTP and + RTCP onto a single port. The initial SDP offer MUST include this + attribute at the media level to request multiplexing of RTP and RTCP + on a single port. For example: + + v=0 + o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e + s=- + c=IN IP6 2001:DB8::211:24ff:fea3:7a2e + t=1153134164 1153137764 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + a=rtcp-mux + + This offer denotes a unicast voice-over-IP session using the RTP/AVP + profile with iLBC coding. The answerer is requested to send both RTP + and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. + + If the answerer wishes to multiplex RTP and RTCP onto a single port, + it MUST include a media-level "a=rtcp-mux" attribute in the answer. + The RTP payload types used in the answer MUST conform to the rules in + Section 4. + + + +Perkins & Westerlund Standards Track [Page 6] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + If the answer does not contain an "a=rtcp-mux" attribute, the offerer + MUST NOT multiplex RTP and RTCP packets on a single port. Instead, + it should send and receive RTCP on a port allocated according to the + usual port-selection rules (either the port pair, or a signalled port + if the "a=rtcp:" attribute [10] is also included). This will occur + when talking to a peer that does not understand the "a=rtcp-mux" + attribute. + + When SDP is used in a declarative manner, the presence of an "a=rtcp- + mux" attribute signals that the sender will multiplex RTP and RTCP on + the same port. The receiver MUST be prepared to receive RTCP packets + on the RTP port, and any resource reservation needs to be made + including the RTCP bandwidth. + +5.1.2. Interactions with SIP Forking + + When using SIP with a forking proxy, it is possible that an INVITE + request may result in multiple 200 (OK) responses. If RTP and RTCP + multiplexing is offered in that INVITE, it is important to be aware + 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 + and the usual RTCP port, and to send RTCP on both ports, unless + branches of the call that support multiplexing are re-negotiated to + use separate RTP and RTCP ports. + +5.1.3. Interactions with ICE + + It is common to use the Interactive Connectivity Establishment (ICE) + [19] methodology to establish RTP sessions in the presence of Network + Address Translation (NAT) devices or other middleboxes. If RTP and + RTCP are sent on separate ports, the RTP media stream comprises two + 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 + multiplexed on the same port some of these connectivity checks can be + avoided, reducing the overhead of ICE. + + 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 + RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" + lines for both RTP and RTCP along with an "a=rtcp:" line indicating a + fallback port for RTCP in the case that the answerer does not support + RTP and RTCP multiplexing. This MUST be done for each media where + RTP and RTCP multiplexing is desired. + + If the answerer wishes to multiplex RTP and RTCP on a single port, it + MUST generate an answer containing an "a=rtcp-mux" attribute and a + single "a=candidate:" line corresponding to the RTP port (i.e., there + is no candidate for RTCP) for each media where it is desired to use + + + +Perkins & Westerlund Standards Track [Page 7] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + RTP and RTCP multiplexing. The answerer then performs connectivity + checks for that media as if the offer had contained only a single + candidate for RTP. If the answerer does not want to multiplex RTP + and RTCP on a single port, it MUST NOT include the "a=rtcp-mux" + attribute in its answer and MUST perform connectivity checks for all + offered candidates in the usual manner. + + On receipt of the answer, the offerer looks for the presence of the + "a=rtcp-mux" line for each media where multiplexing was offered. If + this is present, then connectivity checks proceed as if only a single + candidate (for RTP) were offered, and multiplexing is used once the + session is established. If the "a=rtcp-mux" line is not present, the + session proceeds with connectivity checks using both RTP and RTCP + candidates, eventually leading to a session being established with + RTP and RTCP on separate ports (as signalled by the "a=rtcp:" + attribute). + +5.1.4. Interactions with Header Compression + + Multiplexing RTP and RTCP packets onto a single port may negatively + impact header compression schemes, for example, Compressed RTP (CRTP) + [20] and RObust Header Compression (ROHC) [21] [22]. Header + compression exploits patterns of change in the RTP headers of + consecutive packets to send an indication that the packet changed in + the expected way, rather than sending the complete header each time. + This can lead to significant bandwidth savings if flows have uniform + behaviour. + + The presence of RTCP packets multiplexed with RTP data packets can + disrupt the patterns of change between headers and has the potential + to significantly reduce header compression efficiency. The extent of + this disruption depends on the header compression algorithm used and + on the way flows are classified. A well-designed classifier should + be able to separate RTP and RTCP multiplexed on the same port into + different compression contexts, using the payload type field, such + that the effect on the compression ratio is small. A classifier that + assigns compression contexts based only on the IP addresses and UDP + ports will not perform well. It is expected that implementations of + header compression will need to be updated to efficiently support RTP + and RTCP multiplexed on the same port. + + This effect of multiplexing RTP and RTCP on header compression may be + especially significant in those environments, such as some wireless + telephony systems, that rely on the efficiency of header compression + to match the media to a limited-capacity channel. The implications + of multiplexing RTP and RTCP should be carefully considered before + use in such environments. + + + + +Perkins & Westerlund Standards Track [Page 8] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + +5.2. Any Source Multicast Sessions + + The problem of NAT traversal is less severe for Any Source Multicast + (ASM) RTP sessions than for unicast RTP sessions, and the benefit of + using separate ports for RTP and RTCP is greater due to the ability + to support third-party RTCP-only monitors. Accordingly, RTP and RTCP + packets SHOULD NOT be multiplexed onto a single port when using ASM + RTP sessions and SHOULD instead use separate ports and multicast + groups. + +5.3. Source-Specific Multicast Sessions + + RTP sessions running over Source-Specific Multicast (SSM) send RTCP + packets from the source to receivers via the multicast channel, but + use a separate unicast feedback mechanism [6] to send RTCP from the + receivers back to the source, with the source either reflecting the + RTCP packets to the group or sending aggregate summary reports. + + Following the terminology of [6], we identify three RTP/RTCP flows in + an SSM session: + + 1. RTP and RTCP flows between media sender and distribution source. + In many scenarios, the media sender and distribution source are + co-located, so multiplexing is not a concern. If the media + sender and distribution source are connected by a unicast + connection, the rules in Section 5.1 of this memo apply to that + connection. If the media sender and distribution source are + connected by an Any Source Multicast connection, the rules in + Section 5.2 apply to that connection. If the media sender and + distribution source are connected by a Source-Specific Multicast + connection, the RTP and RTCP packets MAY be multiplexed on a + single port, provided this is signalled (using "a=rtcp-mux" if + using SDP). + + 2. RTP and RTCP sent from the distribution source to the receivers. + The distribution source MAY multiplex RTP and RTCP onto a single + port to ease NAT traversal issues on the forward SSM path, + although doing so may hinder third-party monitoring devices if + the session uses the simple feedback model. When using SDP, the + multiplexing SHOULD be signalled using the "a=rtcp-mux" + attribute. + + 3. RTCP sent from receivers to distribution source. This is an + RTCP-only path, so multiplexing is not a concern. + + Multiplexing RTP and RTCP packets on a single port in an SSM session + has the potential for interactions with header compression described + in Section 5.1.4. + + + +Perkins & Westerlund Standards Track [Page 9] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + +6. Multiplexing, Bandwidth, and Quality of Service + + Multiplexing RTP and RTCP has implications on the use of the Quality + of Service (QoS) mechanism that handles flow that are determined by a + three or five tuple (protocol, port, and address for source and/or + destination). In these cases, the RTCP flow will be merged with the + RTP flow when multiplexing them together. Thus, the RTCP bandwidth + requirement needs to be considered when doing QoS reservations for + the combined RTP and RTCP flow. However, from an RTCP perspective it + is beneficial to receive the same treatment of RTCP packets as for + RTP as it provides more accurate statistics for the measurements + performed by RTCP. + + The bandwidth required for a multiplexed stream comprises the session + bandwidth of the RTP stream plus the bandwidth used by RTCP. In the + usual case, the RTP session bandwidth is signalled in the SDP "b=AS:" + (or "b=TIAS:" [11]) line, and the RTCP traffic is limited to 5% of + this value. Any QoS reservation SHOULD therefore be made for 105% of + the "b=AS:" value. If a non-standard RTCP bandwidth fraction is + used, signalled by the SDP "b=RR:" and/or "b=RS:" lines [12], then + any QoS reservation SHOULD be made for bandwidth equal to (AS + RS + + RR), taking the RS and RR values from the SDP answer. + +7. Security Considerations + + The usage of multiplexing RTP and RTCP is not believed to introduce + any new security considerations. Known major issues are the + integrity and authentication of the signalling used to set up the + multiplexing as well as the integrity, authentication, and + confidentiality of the actual RTP and RTCP traffic. The security + considerations in the RTP specification [1] and any applicable RTP + profile (e.g., [7]) and payload format(s) apply. + + If the Secure Real-time Transport Protocol (SRTP) [13] is to be used + in conjunction with multiplexed RTP and RTCP, then multiplexing MUST + be done below the SRTP layer. The sender generates SRTP and SRTCP + packets in the usual manner, based on their separate cryptographic + contexts, and multiplexes them onto a single port immediately before + transmission. At the receiver, the cryptographic context is derived + from the synchronization source (SSRC), destination network address, + and destination transport port number in the usual manner, augmented + using the RTP payload type and RTCP packet type to demultiplex SRTP + and SRTCP according to the rules in Section 4 of this memo. After + the SRTP and SRTCP packets have been demultiplexed, cryptographic + processing happens in the usual manner. + + + + + + +Perkins & Westerlund Standards Track [Page 10] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + +8. IANA Considerations + + Following the guidelines in [8], the IANA has registered one new SDP + attribute: + + o Contact name/email: authors of RFC 5761 + + o Attribute name: rtcp-mux + + o Long-form attribute name: RTP and RTCP multiplexed on one port + + o Type of attribute: media level + + o Subject to charset: no + + 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 + 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. + +9. Acknowledgements + + We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar + Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, + Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson, + Dave Singer, Kevin Johns, and David Black for their comments on this + memo. This work was supported in part by the UK Engineering and + Physical Sciences Research Council. + +10. References + +10.1. Normative References + + [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", STD 64, + RFC 3550, July 2003. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + +Perkins & Westerlund Standards Track [Page 11] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + [3] Turletti, T., "RTP Payload Format for H.261 Video Streams", + RFC 2032, October 1996. + + [4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control Protocol + (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. + + [5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol + Extended Reports (RTCP XR)", RFC 3611, November 2003. + + [6] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control + Protocol (RTCP) Extensions for Single-Source Multicast Sessions + with Unicast Feedback", RFC 5760, February 2010. + + [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video + Conferences with Minimal Control", STD 65, RFC 3551, July 2003. + + [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in + Session Description Protocol (SDP)", RFC 3605, October 2003. + + [11] Westerlund, M., "A Transport Independent Bandwidth Modifier for + the Session Description Protocol (SDP)", RFC 3890, + September 2004. + + [12] Casner, S., "Session Description Protocol (SDP) Bandwidth + Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, + July 2003. + + [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, March 2004. + +10.2. Informative References + + [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 + SIGCOMM 1990, September 1990. + + + + + +Perkins & Westerlund Standards Track [Page 12] + +RFC 5761 Multiplexing RTP and RTCP April 2010 + + + [16] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM + SIGCOMM Computer Communication Review, Volume 22, Number 3, + July 1992. + + [17] Even, R., "RTP Payload Format for H.261 Video Streams", + RFC 4587, August 2006. + + [18] Johansson, I. and M. Westerlund, "Support for Reduced-Size + Real-Time Transport Control Protocol (RTCP): Opportunities and + Consequences", RFC 5506, April 2009. + + [19] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A + Protocol for Network Address Translator (NAT) Traversal for + Offer/Answer Protocols", RFC 5245, April 2010. + + [20] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for + Low-Speed Serial Links", RFC 2508, February 1999. + + [21] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L-E., 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. + + [22] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust + Header Compression (ROHC) Framework", RFC 5795, March 2010. + +Authors' Addresses + + Colin Perkins + University of Glasgow + Department of Computing Science + Glasgow G12 8QQ + UK + + EMail: csp@csperkins.org + + + Magnus Westerlund + Ericsson + Farogatan 6 + Stockholm SE-164 80 + Sweden + + EMail: magnus.westerlund@ericsson.com + + + + + +Perkins & Westerlund Standards Track [Page 13] + |