draft-ietf-avt-rtp-and-rtcp-mux-02.txt | draft-ietf-avt-rtp-and-rtcp-mux-03.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: May 20, 2007 November 16, 2006 | Expires: June 4, 2007 December 1, 2006 | |||
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-02.txt | draft-ietf-avt-rtp-and-rtcp-mux-03.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 May 20, 2007. | This Internet-Draft will expire on June 4, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
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 9, line 18 ¶ | skipping to change at page 9, line 18 ¶ | |||
packets from the source to receivers via the multicast channel, but | packets from the source to receivers via the multicast channel, but | |||
use a separate unicast feedback mechanism [6] to send RTCP from the | use a separate unicast feedback mechanism [6] to send RTCP from the | |||
receivers back to the source, with the source either reflecting the | receivers back to the source, with the source either reflecting the | |||
RTCP packets to the group, or sending aggregate summary reports. | RTCP packets to the group, or sending aggregate summary reports. | |||
Following the terminology of [6], we identify three RTP/RTCP flows in | Following the terminology of [6], we identify three RTP/RTCP flows in | |||
an SSM session: | an SSM session: | |||
1. RTP and RTCP flows between media sender and distribution source. | 1. RTP and RTCP flows between media sender and distribution source. | |||
In many scenarios, the media sender and distribution source are | In many scenarios, the media sender and distribution source are | |||
collocated, so multiplexing is not a concern. If the media | co-located, so multiplexing is not a concern. If the media | |||
sender and distribution source are connected by a unicast | sender and distribution source are connected by a unicast | |||
connection, the rules in Section 5.1 of this memo apply to that | connection, the rules in Section 5.1 of this memo apply to that | |||
connection. If the media sender and distribution source are | connection. If the media sender and distribution source are | |||
connected by an Any Source Multicast connection, the rules in | connected by an Any Source Multicast connection, the rules in | |||
Section 5.2 apply to that connection. If the media sender and | Section 5.2 apply to that connection. If the media sender and | |||
distribution source are connected by a Source Specific Multicast | distribution source are connected by a Source Specific Multicast | |||
connection, the RTP and RTCP packets MAY be multiplexed on a | connection, the RTP and RTCP packets MAY be multiplexed on a | |||
single port, provided this is signalled (using "a=rtcp-mux" if | single port, provided this is signalled (using "a=rtcp-mux" if | |||
using SDP). | using SDP). | |||
skipping to change at page 11, line 21 ¶ | skipping to change at page 11, line 21 ¶ | |||
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, and Ingemar Johansson | Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson and | |||
for their comments on this memo. This work is supported in part by | Dave Singer for their comments on this memo. This work is supported | |||
the UK Engineering and Physical Sciences Research Council. | 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 | |||
End of changes. 5 change blocks. | ||||
7 lines changed or deleted | 7 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/ |