draft-ietf-avt-rtp-and-rtcp-mux-04.txt | draft-ietf-avt-rtp-and-rtcp-mux-05.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: September 4, 2007 March 3, 2007 | Expires: November 22, 2007 May 21, 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-04.txt | draft-ietf-avt-rtp-and-rtcp-mux-05.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 September 4, 2007. | This Internet-Draft will expire on November 22, 2007. | |||
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 | |||
skipping to change at page 4, line 18 ¶ | skipping to change at page 4, line 18 ¶ | |||
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. | |||
While these design choices are appropriate for many use of RTP, they | While these design choices are appropriate for many uses of RTP, they | |||
are problematic in some cases. There are many RTP deployments which | are problematic in some cases. There are many RTP deployments which | |||
don't use IP multicast, and with the increased use of Network Address | don't use IP multicast, and with the increased use of Network Address | |||
Translation (NAT) the simplicity of multiplexing at the transport | Translation (NAT) the simplicity of multiplexing at the transport | |||
layer has become a liability, since it requires complex signalling to | layer has become a liability, since it requires complex signalling to | |||
open multiple NAT pinholes. In environments such as these, it is | open multiple NAT pinholes. In environments such as these, it is | |||
desirable to provide an alternative to demultiplexing RTP and RTCP | desirable to provide an alternative to demultiplexing RTP and RTCP | |||
using separate UDP ports, instead using only a single UDP port and | using separate UDP ports, instead using only a single UDP port and | |||
demultiplexing within the application. | demultiplexing within the application. | |||
This memo provides such an alternative by multiplexing RTP and RTCP | This memo provides such an alternative by multiplexing RTP and RTCP | |||
skipping to change at page 5, line 51 ¶ | 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 multicast sessions, the procedures also depend on whether ASM or | For multicast sessions, the procedures also depend on whether Any | |||
SSM multicast is to be used. | Source Multicast (ASM) or Source Specific Multicast (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, and provided that multiplexing is signalled in advance. | in Section 4, and provided that multiplexing is signalled in advance. | |||
The following sections describe how such multiplexed sessions can be | The following sections describe how such multiplexed sessions can be | |||
signalled using the Session Initiation Protocol (SIP) with the offer/ | signalled using the Session Initiation Protocol (SIP) with the offer/ | |||
answer model. | answer model. | |||
skipping to change at page 7, line 15 ¶ | skipping to change at page 7, line 17 ¶ | |||
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 | |||
including the RTCP bandwidth. | including the RTCP bandwidth. | |||
5.1.2. Interactions with SIP forking | 5.1.2. Interactions with SIP forking | |||
When using SIP with a forking proxy, it is possible that an INVITE | 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 | request may result in multiple 200 (OK) responses. If RTP and RTCP | |||
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 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 | [16] 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 | |||
skipping to change at page 12, line 5 ¶ | skipping to change at page 12, line 5 ¶ | |||
[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., Ott, J., and E. Schooler, "RTCP Extensions | [6] Chesterfield, J., Ott, J., and E. Schooler, "RTCP Extensions | |||
for Single-Source Multicast Sessions with Unicast Feedback", | for Single-Source Multicast Sessions with Unicast Feedback", | |||
draft-ietf-avt-rtcpssm-12 (work in progress), October 2006. | draft-ietf-avt-rtcpssm-13 (work in progress), March 2007. | |||
[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 43 ¶ | 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-13 (work in | Offer/Answer Protocols", draft-ietf-mmusic-ice-15 (work in | |||
progress), January 2007. | progress), March 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. | |||
End of changes. 8 change blocks. | ||||
10 lines changed or deleted | 11 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/ |