draft-ietf-avt-rtp-and-rtcp-mux-03.txt   draft-ietf-avt-rtp-and-rtcp-mux-04.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: June 4, 2007 December 1, 2006 Expires: September 4, 2007 March 3, 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-03.txt draft-ietf-avt-rtp-and-rtcp-mux-04.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 June 4, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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+128 is distinct from the RTCP packet types used.
The first constraint precludes a direct conflict between RTP payload The first constraint precludes a direct conflict between RTP payload
type and RTCP packet type, the second constraint precludes a conflict type and RTCP packet type, the second constraint precludes a conflict
between an RTP data packet with marker bit set and an RTCP packet. between an RTP data packet with marker bit set and an RTCP packet.
This demultiplexing method works because the RTP payload type and This demultiplexing method works because the RTP payload type and
RTCP packet type occupy the same position within the 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 RTCP FIR and NACK o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and
packets defined in the RTP Payload Format for H.261 [3]. NACK packets defined in the original RTP Payload Format for H.261
[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].
o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB
packets defined in the RTP/AVPF profile [4]. packets defined in the RTP/AVPF profile [4].
o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5]
packets. packets.
skipping to change at page 5, line 50 skipping to change at page 5, line 51
beginning with an SR or an RR packet ([1] Section 6.1), one might beginning with an SR or an RR packet ([1] Section 6.1), one might
wonder why RTP payload types other than 72 and 73 are prohibited wonder why RTP payload types other than 72 and 73 are prohibited
when multiplexing RTP and RTCP. This is done to ensure robustness when multiplexing RTP and RTCP. This is done to ensure robustness
against broken nodes which send non-compliant RTCP packets, which against broken nodes which send non-compliant RTCP packets, which
might otherwise be confused with multiplexed RTP packets. might otherwise be confused with multiplexed RTP packets.
5. Multiplexing RTP and RTCP on a Single Port 5. Multiplexing RTP and RTCP on a Single Port
The procedures for multiplexing RTP and RTCP on a single port depend The procedures for multiplexing RTP and RTCP on a single port depend
on whether the session is a unicast session or a multicast session. on whether the session is a unicast session or a multicast session.
For a multicast sessions, also depends whether ASM or SSM multicast For multicast sessions, the procedures also depend on whether ASM or
is to be used. SSM multicast is to be used.
5.1. Unicast Sessions 5.1. Unicast Sessions
It is acceptable to multiplex RTP and RTCP packets on a single UDP It is acceptable to multiplex RTP and RTCP packets on a single UDP
port to ease NAT traversal for unicast sessions, provided the RTP port to ease NAT traversal for unicast sessions, provided the RTP
payload types used in the session are chosen according to the rules payload types used in the session are chosen according to the rules
in Section 4. The following sections describe how such multiplexed in Section 4, and provided that multiplexing is signalled in advance.
sessions can be signalled using the Session Initiation Protocol (SIP) The following sections describe how such multiplexed sessions can be
with the offer/answer model. signalled using the Session Initiation Protocol (SIP) with the offer/
answer model.
5.1.1. SDP Signalling 5.1.1. SDP Signalling
When the Session Description Protocol (SDP) [8] is used to negotiate When the Session Description Protocol (SDP) [8] is used to negotiate
RTP sessions following the offer/answer model [9], the "a=rtcp-mux" RTP sessions following the offer/answer model [9], the "a=rtcp-mux"
attribute (see Section 8) indicates the desire to multiplex RTP and attribute (see Section 8) indicates the desire to multiplex RTP and
RTCP onto a single port. The initial SDP offer MUST include this RTCP onto a single port. The initial SDP offer MUST include this
attribute to request multiplexing of RTP and RTCP on a single port. attribute to request multiplexing of RTP and RTCP on a single port.
For example: For example:
skipping to change at page 6, line 42 skipping to change at page 6, line 44
This offer denotes a unicast voice-over-IP session using the RTP/AVP 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 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. 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 If the answerer wishes to multiplex RTP and RTCP onto a single port
it MUST include an "a=rtcp-mux" attribute in the answer. The RTP it MUST include an "a=rtcp-mux" attribute in the answer. The RTP
payload types used in the answer MUST conform to the rules in payload types used in the answer MUST conform to the rules in
Section 4. Section 4.
If the answer does not contain an "a=rtcp-mux" attribute, the offerer If the answer does not contain an "a=rtcp-mux" attribute, the offerer
SHOULD NOT multiplex RTP and RTCP packets on a single port. Instead, 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 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 usual port selection rules (either the port pair, or a signalled port
if the "a=rtcp:" attribute [10] is also included). This will occur 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" when talking to a peer that does not understand the "a=rtcp-mux"
attribute. attribute.
When SDP is used in a declarative manner, the presence of an "a=rtcp- 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 mux" attribute signals that the sender will multiplex RTP and RTCP on
the same port. The receiver MUST be prepared to receive RTCP packets the same port. The receiver MUST be prepared to receive RTCP packets
on the RTP port, and any resource reservation needs to be made on the RTP port, and any resource reservation needs to be made
skipping to change at page 10, line 44 skipping to change at page 10, line 44
transmission. At the receiver, the cryptographic context is derived transmission. At the receiver, the cryptographic context is derived
from the SSRC, destination network address and destination transport from the SSRC, destination network address and destination transport
port number in the usual manner, augmented using the RTP payload type port number in the usual manner, augmented using the RTP payload type
and RTCP packet type to demultiplex SRTP and SRTCP according to the 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 rules in Section 4 of this memo. After the SRTP and SRTCP packets
have been demultiplexed, cryptographic processing happens in the have been demultiplexed, cryptographic processing happens in the
usual manner. usual manner.
8. IANA Considerations 8. IANA Considerations
The IANA is requested to register one new SDP attribute, following Following the guidelines in [8], the IANA is requested to register
the guidelines in [8]: one new SDP attribute:
o Contact name/email: authors of RFC XXXX o Contact name/email: authors of RFC XXXX
o Attribute name: rtcp-mux o Attribute name: rtcp-mux
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.
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 and Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson,
Dave Singer for their comments on this memo. This work is supported Dave Singer, and Kevin Johns for their comments on this memo. This
in part by the UK Engineering and Physical Sciences Research Council. work was supported in part by the UK Engineering and 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 11, line 46 skipping to change at page 11, line 49
[3] Turletti, T., "RTP Payload Format for H.261 Video Streams", [3] Turletti, T., "RTP Payload Format for H.261 Video Streams",
RFC 2032, October 1996. RFC 2032, October 1996.
[4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control Protocol "Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol [5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003. Extended Reports (RTCP XR)", RFC 3611, November 2003.
[6] Chesterfield, J., "RTCP Extensions for Single-Source Multicast [6] Chesterfield, J., Ott, J., and E. Schooler, "RTCP Extensions
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-11 for Single-Source Multicast Sessions with Unicast Feedback",
(work in progress), March 2006. draft-ietf-avt-rtcpssm-12 (work in progress), October 2006.
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
skipping to change at page 12, line 41 skipping to change at page 12, line 43
[14] Clark, D. and D. Tennenhouse, "Architectural Considerations for [14] 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 [15] 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 [16] 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-10 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in
progress), August 2006. progress), January 2007.
[17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for [17] 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., [18] 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.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Torshamgatan 23 Torshamgatan 23
Stockholm SE-164 80 Stockholm SE-164 80
Sweden Sweden
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 15 change blocks. 
27 lines changed or deleted 32 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/