draft-ietf-avt-rtp-and-rtcp-mux-06.txt | draft-ietf-avt-rtp-and-rtcp-mux-07.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: January 24, 2008 July 23, 2007 | Expires: February 2, 2008 August 1, 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-06.txt | draft-ietf-avt-rtp-and-rtcp-mux-07.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 January 24, 2008. | This Internet-Draft will expire on February 2, 2008. | |||
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 2, line 17 ¶ | skipping to change at page 2, line 17 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 | 4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 | |||
5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 6 | 5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 6 | |||
5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6 | 5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6 | 5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7 | 5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7 | |||
5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7 | 5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7 | |||
5.1.4. Interactions with Header Compression . . . . . . . . . 8 | 5.1.4. Interactions with Header Compression . . . . . . . . . 8 | |||
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8 | 5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 9 | |||
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9 | 5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9 | |||
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 10 | 6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 10 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 15 | Intellectual Property and Copyright Statements . . . . . . . . . . 15 | |||
skipping to change at page 5, line 49 ¶ | skipping to change at page 5, line 49 ¶ | |||
64-95 MUST NOT be used. Specifically, dynamic RTP payload types | 64-95 MUST NOT be used. Specifically, dynamic RTP payload types | |||
SHOULD be chosen in the range 96-127 where possible. Values below 64 | SHOULD be chosen in the range 96-127 where possible. Values below 64 | |||
MAY be used if that is insufficient, in which case it is RECOMMENDED | MAY be used if that is insufficient, in which case it is RECOMMENDED | |||
that payload type numbers that are not statically assigned by [7] be | that payload type numbers that are not statically assigned by [7] be | |||
used first. | used first. | |||
Note: since all RTCP packets MUST be sent as compound packets | Note: since all RTCP packets MUST be sent as compound packets | |||
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 nodes which send non-compound RTCP packets, which might | |||
might otherwise be confused with multiplexed RTP packets. | otherwise be confused with multiplexed RTP packets. At the time | |||
of this writing, there is a proposal to allow non-compound RTCP | ||||
packets in some circumstances [17], so this robustness may become | ||||
more important in future. | ||||
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 Any | For multicast sessions, the procedures also depend on whether Any | |||
Source Multicast (ASM) or Source Specific Multicast (SSM) multicast | Source Multicast (ASM) or Source Specific Multicast (SSM) multicast | |||
is to be used. | is to be used. | |||
5.1. Unicast Sessions | 5.1. Unicast Sessions | |||
skipping to change at page 7, line 29 ¶ | skipping to change at page 7, line 33 ¶ | |||
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 to 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) | |||
[17] methodology to establish RTP sessions in the presence of Network | [18] 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 | |||
components in ICE (one for RTP and one for RTCP), with connectivity | components in ICE (one for RTP and one for RTCP), with connectivity | |||
checks being performed for each component. If RTP and RTCP are to be | checks being performed for each component. If RTP and RTCP are to be | |||
multiplexed on the same port some of these connectivity checks can be | multiplexed on the same port some of these connectivity checks can be | |||
avoided, reducing the overhead of ICE. | avoided, reducing the overhead of ICE. | |||
If it is desired to use both ICE and multiplexed RTP and RTCP, the | If it is desired to use both ICE and multiplexed RTP and RTCP, the | |||
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that | initial offer MUST contain an "a=rtcp-mux" attribute to indicate that | |||
RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:" | RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:" | |||
skipping to change at page 8, line 22 ¶ | skipping to change at page 8, line 25 ¶ | |||
session is established. If the "a=rtcp-mux" line is not present, the | session is established. If the "a=rtcp-mux" line is not present, the | |||
session proceeds with connectivity checks using both RTP and RTCP | session proceeds with connectivity checks using both RTP and RTCP | |||
candidates, eventually leading to a session being established with | candidates, eventually leading to a session being established with | |||
RTP and RTCP on separate ports (as signalled by the "a=rtcp:" | RTP and RTCP on separate ports (as signalled by the "a=rtcp:" | |||
attribute). | attribute). | |||
5.1.4. Interactions with Header Compression | 5.1.4. Interactions with Header Compression | |||
Multiplexing RTP and RTCP packets onto a single port may negatively | Multiplexing RTP and RTCP packets onto a single port may negatively | |||
impact header compression schemes, for example Compressed RTP (CRTP) | impact header compression schemes, for example Compressed RTP (CRTP) | |||
[18] and RObust Header Compression (ROHC) [19]. Header compression | [19] and RObust Header Compression (ROHC) [20]. Header compression | |||
exploits patterns of change in the RTP headers of consecutive packets | exploits patterns of change in the RTP headers of consecutive packets | |||
to send an indication that the packet changed in the expected way, | to send an indication that the packet changed in the expected way, | |||
rather than sending the complete header each time. This can lead to | rather than sending the complete header each time. This can lead to | |||
significant bandwidth savings if flows have uniform behaviour. | significant bandwidth savings if flows have uniform behaviour. | |||
The presence of RTCP packets multiplexed with RTP data packets can | The presence of RTCP packets multiplexed with RTP data packets can | |||
disrupt the patterns of change between headers, and has the potential | disrupt the patterns of change between headers, and has the potential | |||
to significantly reduce header compression efficiency. The extent of | to significantly reduce header compression efficiency. The extent of | |||
this disruption depends on the header compression algorithm used, and | this disruption depends on the header compression algorithm used, and | |||
on the way flows are classified. A well designed classifier should | on the way flows are classified. A well designed classifier should | |||
skipping to change at page 13, line 18 ¶ | skipping to change at page 13, line 18 ¶ | |||
Translator (Traditional NAT)", RFC 3022, January 2001. | Translator (Traditional NAT)", RFC 3022, January 2001. | |||
[15] Clark, D. and D. Tennenhouse, "Architectural Considerations for | [15] 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. | |||
[16] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM | [16] 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. | |||
[17] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A | [17] Johansson, I. and M. Westerlund, "Support for non-compund RTCP | |||
in RTCP AVPF profile, opportunities and consequences", | ||||
draft-johansson-avt-rtcp-avpf-non-compound-02 (work in | ||||
progress), July 2007. | ||||
[18] 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-15 (work in | Offer/Answer Protocols", draft-ietf-mmusic-ice-17 (work in | |||
progress), March 2007. | progress), July 2007. | |||
[18] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for | [19] 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. | |||
[19] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., | [20] 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. | |||
Authors' Addresses | Authors' Addresses | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
End of changes. 11 change blocks. | ||||
13 lines changed or deleted | 21 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/ |