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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |