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