draft-ietf-mmusic-sdp-bundle-negotiation-38.txt   draft-ietf-mmusic-sdp-bundle-negotiation-39.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: October 14, 2017 C. Jennings Expires: March 4, 2018 C. Jennings
Cisco Cisco
April 12, 2017 August 31, 2017
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-38.txt draft-ietf-mmusic-sdp-bundle-negotiation-39.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, specified by multiple SDP media referred to as bundled media, specified by multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 14, 2017. This Internet-Draft will expire on March 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 3, line 24
8.5.2. Adding a media description to a BUNDLE group . . . . 17 8.5.2. Adding a media description to a BUNDLE group . . . . 17
8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17
8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20
10.2. Associating RTP/RTCP Streams With Correct SDP Media 10.2. Associating RTP/RTCP Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . 20
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 25 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 26
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 26 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 26
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 29 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 29
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 29 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 30
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 29 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 30
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 30 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 30
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 30 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 30
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 31 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 31
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 31 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 31
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 14.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 32 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 32
14.4. New text replacing section 8.2 (2nd paragraph) of RFC 14.4. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 32 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 32
14.6. New text replacing section 8.4 (6th paragraph) of RFC 14.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15. RTP/RTCP extensions for identification-tag transport . . . . 33 15. RTP/RTCP extensions for identification-tag transport . . . . 33
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 34 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 34
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 34 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 34
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 35 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 35
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 35 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 35
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 36 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 36
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 36 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 36
17. Security Considerations . . . . . . . . . . . . . . . . . . . 37 17. Security Considerations . . . . . . . . . . . . . . . . . . . 37
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
18.1. Example: Bundle Address Selection . . . . . . . . . . . 38 18.1. Example: Bundle Address Selection . . . . . . . . . . . 38
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 40 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 40
18.3. Example: Offerer Adds A Media Description To A BUNDLE 18.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 41 Group . . . . . . . . . . . . . . . . . . . . . . . . . 41
18.4. Example: Offerer Moves A Media Description Out Of A 18.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 43 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 43
18.5. Example: Offerer Disables A Media Description Within A 18.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
21.1. Normative References . . . . . . . . . . . . . . . . . . 55 21.1. Normative References . . . . . . . . . . . . . . . . . . 56
21.2. Informative References . . . . . . . . . . . . . . . . . 57 21.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Design Considerations . . . . . . . . . . . . . . . 58 Appendix A. Design Considerations . . . . . . . . . . . . . . . 59
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 59 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 59
A.2. Usage of port number value zero . . . . . . . . . . . . . 61 A.2. Usage of port number value zero . . . . . . . . . . . . . 61
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 61 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 61
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 62 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 62
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 62 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 62
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 62 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
skipping to change at page 21, line 27 skipping to change at page 21, line 27
that information. Due to this, before the offerer has received the that information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate an RTP stream with answer, the offerer will not be able to associate an RTP stream with
the correct "m=" line using the SSRC value associated with the RTP the correct "m=" line using the SSRC value associated with the RTP
stream. In addition, the offerer and answerer may start using new stream. In addition, the offerer and answerer may start using new
SSRC values mid-session, without informing each other using the SDP SSRC values mid-session, without informing each other using the SDP
'ssrc' attribute. 'ssrc' attribute.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
an RTP stream with the correct "m=" line, the offerer and answerer an RTP stream with the correct "m=" line, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in using the BUNDLE extension MUST support the mechanism defined in
section 14, where the offerer and answerer insert the identification- Section 15, where the offerer and answerer insert the identification-
tag associated with an "m=" line (provided by the remote peer) into tag associated with an "m=" line (provided by the remote peer) into
RTP and RTCP packets associated with a BUNDLE group. RTP and RTCP packets associated with a BUNDLE group.
When using this mechanism, the mapping from an SSRC to an When using this mechanism, the mapping from an SSRC to an
identification-tag is carried in RTP header extensions or RTCP SDES identification-tag is carried in RTP header extensions or RTCP SDES
packets, as specified in section 14. Since a compound RTCP packet packets, as specified in Section 15. Since a compound RTCP packet
can contain multiple RTCP SDES packets, and each RTCP SDES packet can can contain multiple RTCP SDES packets, and each RTCP SDES packet can
contain multiple chunks, a single RTCP packet can contain several contain multiple chunks, a single RTCP packet can contain several
SSRC to identification-tag mappings. The offerer and answerer SSRC to identification-tag mappings. The offerer and answerer
maintain tables used for routing that are updated each time an RTP/ maintain tables used for routing that are updated each time an RTP/
RTCP packet contains new information that affects how packets should RTCP packet contains new information that affects how packets should
be routed. be routed.
However, some implementations of may not include this identification- However, some implementations of may not include this identification-
tag in their RTP and RTCP traffic when using the BUNDLE mechanism, tag in their RTP and RTCP traffic when using the BUNDLE mechanism,
and instead use a payload type based mechanism for demuxing. In this and instead use a payload type based mechanism to associate RTP
situation, each "m=" line MUST use unique payload type values, in streams with SDP m= lines. In this situation, each "m=" line MUST
order for the payload type to be a reliable indicator of the relevant use unique payload type values, in order for the payload type to be a
"m=" line for the RTP stream. Note that when using payload type reliable indicator of the relevant "m=" line for the RTP stream.
based demuxing, an SSRC will be mapped to an "m=" line by the first Note that when using the payload type to associate RTP streams with
packet with that SSRC, and the mapping will not be changed even if m= lines an RTP stream, identified by SSRC, will be mapped to an "m="
the same SSRC is received with a different payload type. In other line when the first packet of that RTP stream is received, and the
words, the SSRC cannot to "move" to a different "m=" line simply by mapping will not be changed even if the payload type used by that RTP
changing the payload type. stream changes. In other words, the SSRC cannot to "move" to a
different "m=" line simply by changing the payload type.
Applications can implement RTP stacks in many different ways. The Applications can implement RTP stacks in many different ways. The
algorithm below details one way that demultiplexing can be algorithm below details one way that RTP streams can be associated
accomplished, but is not meant to be prescriptive about exactly how with m= lines, but is not meant to be prescriptive about exactly how
an RTP stack needs to be implemented. Applications MAY use any an RTP stack needs to be implemented. Applications MAY use any
algorithm that achieves equivalent results to those described in the algorithm that achieves equivalent results to those described in the
algorithm below. algorithm below.
To prepare for demultiplexing RTP/RTCP packets to the correct "m=" To prepare to associate RTP streams with the correct "m=" line, the
line, the following steps MUST be followed for each BUNDLE group. following steps MUST be followed for each BUNDLE group.
Construct a table mapping MID to "m=" line for each "m=" line in Construct a table mapping MID to "m=" line for each "m=" line in
this BUNDLE group. Note that an "m=" line may only have one MID. this BUNDLE group. Note that an "m=" line may only have one MID.
Construct a table mapping incoming SSRC to "m=" line for each "m=" Construct a table mapping SSRCs of incoming RTP streams to "m="
line in this BUNDLE group and for each SSRC configured for line for each "m=" line in this BUNDLE group and for each SSRC
receiving in that "m=" line. configured for receiving in that "m=" line.
Construct a table mapping outgoing SSRC to "m=line" for each "m=" Construct a table mapping the SSRC of each outgoing RTP stream to
line in this BUNDLE group and for each SSRC configured for sending "m=line" for each "m=" line in this BUNDLE group and for each SSRC
in that "m=" line. configured for sending in that "m=" line.
Construct a table mapping payload type to "m=" line for each "m=" Construct a table mapping payload type to "m=" line for each "m="
line in the BUNDLE group and for each payload type configured for line in the BUNDLE group and for each payload type configured for
receiving in that "m=" line. If any payload type is configured receiving in that "m=" line. If any payload type is configured
for receiving in more than one "m=" line in the BUNDLE group, do for receiving in more than one "m=" line in the BUNDLE group, do
not it include it in the table, as it cannot be used to uniquely not it include it in the table, as it cannot be used to uniquely
identify a "m=" line. identify a "m=" line.
Note that for each of these tables, there can only be one mapping Note that for each of these tables, there can only be one mapping
for any given key (MID, SSRC, or PT). In other words, the tables for any given key (MID, SSRC, or PT). In other words, the tables
are not multimaps. are not multimaps.
As "m=" lines are added or removed from the BUNDLE groups, or their As "m=" lines are added or removed from the BUNDLE groups, or their
configurations are changed, the tables above MUST also be updated. configurations are changed, the tables above MUST also be updated.
For each RTP packet received, the following steps MUST be followed to When an RTP packet is received, it MUST be delivered to the RTP
route the packet to the correct "m=" section within a BUNDLE group. stream corresponding to its SSRC. That RTP stream MUST then be
Note that the phrase 'deliver a packet to the "m=" line' means to associated with the correct m= line within a BUNDLE group, for
further process the packet as would normally happen with RTP/RTCP, if additional processing, according to the following steps.
it were received on a transport associated with that "m=" line
outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd),
including dropping an RTP packet if the packet's PT does not match
any PT in the "m=" line.
If the packet has a MID, and that MID is not in the table mapping If the MID associated with the RTP stream is not in the table
MID to "m=" line, drop the packet and stop. mapping MID to a€œm=a€œ line, then the RTP
stream is not decoded and the payload data is discarded.
If the packet has a MID, and the packet's extended sequence number If the packet has a MID, and the packet's extended sequence number
is greater than that of the last MID update, as discussed in is greater than that of the last MID update, as discussed in
[RFC7941], Section 4.2.6, update the incoming SSRC mapping table [RFC7941], Section 4.2.6, update the MID associated with the RTP
to include an entry that maps the packet's SSRC to the "m=" line stream to match the MID carried in the RTP packet, then update the
for that MID. mapping tables to include an entry that maps the SSRC of that RTP
stream to the a€œm=a€œ line for that MID.
If the packet's SSRC is in the incoming SSRC mapping table, check If the SSRC of the RTP stream is in the incoming SSRC mapping
that the packet's PT matches a PT included on the associated "m=" table, check that the payload type used by the RTP stream matches
line. If so, route the packet to that associated "m=" line and a payload type included on the matching
stop; otherwise drop the packet and stop. a€œm=a€œ line. If so, associate the RTP
stream with that a€œm=a€œ line. Otherwise,
the RTP stream is not decoded and the payload data is discarded.
If the packet's payload type is in the payload type table, update If the payload type used by the RTP stream is in the payload type
the the incoming SSRC mapping table to include an entry that maps table, update the incoming SSRC mapping table to include an entry
the packet's SSRC to the "m=" line for that payload type. In that maps the RTP streama€™s SSRC to the
addition, route the packet to the associated "m=" line and stop. a€œm=a€œ line for that payload type.
Associate the RTP stream with the corresponding
a€œm=a€œ line.
Otherwise, drop the packet. Otherwise, mark the RTP stream as not for decoding and discard the
payload.
If the RTP packet contains one of more contributing source (CSRC)
identifiers, then each CSRC is looked up in the incoming SSRC table
and a copy of the RTP packet is associated with the corresponding m=
line for additional processing.
For each RTCP packet received (including each RTCP packet that is For each RTCP packet received (including each RTCP packet that is
part of a compound RTCP packet), the packet MUST be routed to the part of a compound RTCP packet), the packet is processed as usual by
"m=" line for the RTP streams it contains information about. This the RTP layer, then is passed to the a€œm=a€œ
routing is type-dependent, as each kind of RTCP packet has its own lines corresponding to the RTP streams it contains information about
mechanism for associating it with the relevant RTP streams. for additional processing. This routing is type-dependent, as each
kind of RTCP packet has its own mechanism for associating it with the
relevant RTP streams.
Packets for which no appropriate "m=" line can be identified (i.e., RTCP packets for which no appropriate a€œm=a€œ
for unknown RTP streams) are not relevant in the context of this line can be identified MUST be processed as usual by the RTP layer,
algorithm and MAY be dropped. This situation may occur with certain updating the metadata associated with the corresponding RTP streams,
multiparty RTP topologies. but are not passed to any a€œm=a€œ line. This
situation can occur with certain multiparty RTP topologies, or when
RTCP packets are sent containing a subset of the SDES information.
Rules for handling the various types of RTCP packets are explained Rules for additional processing of the various types of RTCP packets
below. are explained below.
If the packet is of type SDES, for each chunk in the packet whose If the RTCP packet is of type SDES, for each chunk in the packet
SSRC is found in the incoming SSRC table, deliver a copy of the whose SSRC is found in the incoming SSRC table, deliver a copy of
packet to the "m=" line associated with that SSRC. In addition, the SDES packet to the "m=" line associated with that SSRC. In
for any SDES MID items contained in these chunks, if the MID is addition, for any SDES MID items contained in these chunks, if the
found in the table mapping MID to "m=" line, update the incoming MID is found in the table mapping MID to "m=" line, update the
SSRC table to include an entry that maps the chunk's SSRC to the incoming SSRC table to include an entry that maps the RTP stream
"m=" line associated with that MID, unless the packet is older associated with chunk's SSRC to the "m=" line associated with that
than the packet that most recently updated the mapping for this MID, unless the packet is older than the packet that most recently
SSRC, as discussed in [RFC7941], Section 4.2.6. updated the mapping for this SSRC, as discussed in [RFC7941],
Section 4.2.6.
Note that if an SDES packet is received as part of a compound RTCP Note that if an SDES packet is received as part of a compound RTCP
packet, the SSRC to "m=" line mapping may not exist until the SDES packet, the SSRC to "m=" line mapping may not exist until the SDES
packet is handled (e.g., in the case where RTCP for a source is packet is handled (e.g., in the case where RTCP for a source is
received before any RTP packets). Therefore, when processing a received before any RTP packets). Therefore, when processing a
compound packet, any contained SDES packet MUST be handled first. compound packet, any contained SDES packet MUST be handled first.
Note that this is a backwards change from [RFC3550] Section 6.1,
which states that "Each individual RTCP packet in the compound
packet may be processed independently with no requirements upon
the order or combination of packets".
If the packet is of type BYE, it indicates that the RTP streams If the RTCP packet is of type BYE, it indicates that the RTP
referenced in the packet are ending. Therefore, for each SSRC streams referenced in the packet are ending. Therefore, for each
indicated in the packet that is found in the incoming SSRC table, SSRC indicated in the packet that is found in the incoming SSRC
first deliver a copy of the packet to the "m=" line associated table, first deliver a copy of the BYE packet to the "m=" line
with that SSRC, but then remove the entry for that SSRC from the associated with that SSRC, but then remove the entry for that SSRC
incoming SSRC table after an appropriate delay to account for from the incoming SSRC table after an appropriate delay to account
"straggler packets", as specified in [RFC3550], Section 6.2.1. for "straggler packets", as specified in [RFC3550], Section 6.2.1.
If the packet is of type SR or RR, for each report block in the If the RTCP packet is of type SR or RR, for each report block in
report whose "SSRC of source" is found in the outgoing SSRC table, the report whose "SSRC of source" is found in the outgoing SSRC
deliver a copy of the RTCP packet to the "m=" line associated with table, deliver a copy of the SR or RR packet to the "m=" line
that SSRC. In addition, if the packet is of type SR, and the associated with that SSRC. In addition, if the packet is of type
sender SSRC for the packet is found in the incoming SSRC table, SR, and the sender SSRC for the packet is found in the incoming
deliver a copy of the packet to the "m=" line associated with that SSRC table, deliver a copy of the SR packet to the "m=" line
SSRC. associated with that SSRC.
If the implementation supports RTCP XR and the packet is of type If the implementation supports RTCP XR and the packet is of type
XR, as defined in [RFC3611], for each report block in the report XR, as defined in [RFC3611], for each report block in the report
whose "SSRC of source" is is found in the outgoing SSRC table, whose "SSRC of source" is is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" line associated with deliver a copy of the XR packet to the "m=" line associated with
that SSRC. In addition, if the sender SSRC for the packet is that SSRC. In addition, if the sender SSRC for the packet is
found in the incoming SSRC table, deliver a copy of the packet to found in the incoming SSRC table, deliver a copy of the XR packet
the "m=" line associated with that SSRC. to the "m=" line associated with that SSRC.
If the packet is a feedback message of type RTPFB or PSFB, as If the RTCP packet is a feedback message of type RTPFB or PSFB, as
defined in [RFC4585], it will contain a media source SSRC, and defined in [RFC4585], it will contain a media source SSRC, and
this SSRC is used for routing certain subtypes of feedback this SSRC is used for routing certain subtypes of feedback
messages. However, several subtypes of PSFB messages include messages. However, several subtypes of PSFB messages include
target SSRC(s) in a section called Feedback Control Information target SSRC(s) in a section called Feedback Control Information
(FCI). For these messages, the target SSRC(s) are used for (FCI). For these messages, the target SSRC(s) are used for
routing. routing.
If the packet is a feedback message that does not include target If the RTCP packet is a feedback packet that does not include
SSRCs in its FCI section, and the media source SSRC is found in target SSRCs in its FCI section, and the media source SSRC is
the outgoing SSRC table, deliver the packet to the "m=" line found in the outgoing SSRC table, deliver the feedback packet to
associated with that SSRC. RTPFB and PSFB types that are handled the "m=" line associated with that SSRC. RTPFB and PSFB types
in this way include: that are handled in this way include:
Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). Generic NACK: [RFC4585] (PT=RTPFB, FMT=1).
Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1).
Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2).
Reference Picture Selection Indication (RPSI): [RFC4585] Reference Picture Selection Indication (RPSI): [RFC4585]
(PT=PSFB, FMT=3). (PT=PSFB, FMT=3).
If the packet is a feedback message that does include target If the RTCP packet is a feedback message that does include target
SSRC(s) in its FCI section, it can either be a request or a SSRC(s) in its FCI section, it can either be a request or a
notification. Requests reference a RTP stream that is being sent notification. Requests reference a RTP stream that is being sent
by the message recipient, whereas notifications are responses to by the message recipient, whereas notifications are responses to
an earlier request, and therefore reference a RTP stream that is an earlier request, and therefore reference a RTP stream that is
being received by the message recipient. being received by the message recipient.
If the packet is a feedback request that includes target SSRC(s), If the RTCP packet is a feedback request that includes target
for each target SSRC that is found in the outgoing SSRC table, SSRC(s), for each target SSRC that is found in the outgoing SSRC
deliver a copy of the RTCP packet to the "m=" line associated with table, deliver a copy of the RTCP packet to the "m=" line
that SSRC. PSFB types that are handled in this way include: associated with that SSRC. PSFB types that are handled in this
way include:
Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4).
Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB,
FMT=5). FMT=5).
H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB,
FMT=7). FMT=7).
Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB,
FMT=TBD). FMT=TBD).
If the packet is a feedback notification that include target If the RTCP packet is a feedback notification that include target
SSRC(s), for each target SSRC that is found in the incoming SSRC SSRC(s), for each target SSRC that is found in the incoming SSRC
table, deliver a copy of the RTCP packet to the "m=" line table, deliver a copy of the RTCP packet to the "m=" line
associated with that SSRC. PSFB types that are handled in this associated with the RTP stream with matching SSRC. PSFB types
way include: that are handled in this way include:
Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] Temporal-Spatial Trade-off Notification (TSTN): [RFC5104]
(PT=PSFB, FMT=6). This message is a notification in response (PT=PSFB, FMT=6). This message is a notification in response
to a prior TSTR. to a prior TSTR.
If the packet is of type APP, the only routing information If the RTCP packet is of type APP, then it is handled in an
included is the source of the packet, and therefore the packet application specific manner. If the application does not
could be related to any existing "m=" line. Accordingly, deliver recognise the APP packet, then it MUST be discarded.
a copy of the packet to each "m=" line.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
multiplexing [RFC5761] for the RTP-based media specified by the multiplexing [RFC5761] for the RTP-based media specified by the
BUNDLE group. BUNDLE group.
When RTP/RTCP multiplexing is enabled, the same address:port When RTP/RTCP multiplexing is enabled, the same address:port
combination will be used for sending all RTP packets and the RTCP combination will be used for sending all RTP packets and the RTCP
packets associated with the BUNDLE group. Each endpoint will send packets associated with the BUNDLE group. Each endpoint will send
skipping to change at page 47, line 9 skipping to change at page 47, line 9
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
20. Change Log 20. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38
o Changes to RTP streaming mapping section based on text from Colin
Perkins.
o The following GitHub pull requests were merged:
o https://github.com/cdh4u/draft-sdp-bundle/pull/34
o - Proposed updates to RTP processing
o https://github.com/cdh4u/draft-sdp-bundle/pull/35
o - fixed reference to receiver-id section
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37
o The following GitHub pull request was merged: o The following GitHub pull request was merged:
o https://github.com/cdh4u/draft-sdp-bundle/pull/33 o https://github.com/cdh4u/draft-sdp-bundle/pull/33
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36
o The following GitHub pull requests were merged: o The following GitHub pull requests were merged:
skipping to change at page 55, line 46 skipping to change at page 56, line 11
o Added text about single versus multiple RTP Sessions. o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550. o Added reference to RFC 3550.
21. References 21. References
21.1. Normative References 21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3605>. editor.org/info/rfc3605>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<http://www.rfc-editor.org/info/rfc4961>. <https://www.rfc-editor.org/info/rfc4961>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5245>. editor.org/info/rfc5245>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <https://www.rfc-editor.org/info/rfc5285>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5761>. editor.org/info/rfc5761>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5764>. editor.org/info/rfc5764>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5888>. editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <http://www.rfc-editor.org/info/rfc7941>. August 2016, <https://www.rfc-editor.org/info/rfc7941>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-08 (work in progress), December 2016. rfc5245bis-10 (work in progress), May 2017.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 2016.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-11 (work in progress), February 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using Petit-Huguenin, M., Keranen, A., and S. Nandakumar,
Interactive Connectivity Establishment (ICE) with Session "Session Description Protocol (SDP) Offer/Answer
Description Protocol (SDP) offer/answer and Session procedures for Interactive Connectivity Establishment
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- (ICE)", draft-ietf-mmusic-ice-sip-sdp-13 (work in
sdp-12 (work in progress), March 2017. progress), June 2017.
21.2. Informative References 21.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4585>. editor.org/info/rfc4585>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014, DOI 10.17487/RFC7160, April 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7160>. editor.org/info/rfc7160>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7656>. editor.org/info/rfc7656>.
[I-D.ietf-mmusic-trickle-ice] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
Incremental Provisioning of Candidates for the Interactive "Trickle ICE: Incremental Provisioning of Candidates for
Connectivity Establishment (ICE) Protocol", draft-ietf- the Interactive Connectivity Establishment (ICE)
mmusic-trickle-ice-02 (work in progress), January 2015. Protocol", draft-ietf-ice-trickle-13 (work in progress),
July 2017.
[I-D.ietf-avtext-lrr] [I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-04 (work in progress), Message", draft-ietf-avtext-lrr-07 (work in progress),
April 2017. July 2017.
Appendix A. Design Considerations Appendix A. Design Considerations
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
been whether, in SDP Offers and SDP Answers, the same port value been whether, in SDP Offers and SDP Answers, the same port value
should be inserted in "m=" lines associated with a BUNDLE group, as should be inserted in "m=" lines associated with a BUNDLE group, as
the purpose of the extension is to negotiate the usage of a single the purpose of the extension is to negotiate the usage of a single
address:port combination for media specified by the "m=" lines. address:port combination for media specified by the "m=" lines.
Issues with both approaches, discussed in the Appendix have been Issues with both approaches, discussed in the Appendix have been
raised. The outcome was to specify a mechanism which uses SDP Offers raised. The outcome was to specify a mechanism which uses SDP Offers
skipping to change at page 62, line 37 skipping to change at page 63, line 6
termination of the call. termination of the call.
A.4. Candidate Gathering A.4. Candidate Gathering
When using ICE, a candidate needs to be gathered for each port. This When using ICE, a candidate needs to be gathered for each port. This
takes approximately 20 ms extra for each extra "m=" line due to the takes approximately 20 ms extra for each extra "m=" line due to the
NAT pacing requirements. All of this gather can be overlapped with NAT pacing requirements. All of this gather can be overlapped with
other things while for exampe a web-page is loading to minimize the other things while for exampe a web-page is loading to minimize the
impact. If the client only wants to generate TURN or STUN ICE impact. If the client only wants to generate TURN or STUN ICE
candidates for one of the "m=" lines and then use trickle ICE candidates for one of the "m=" lines and then use trickle ICE
[I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for [I-D.ietf-ice-trickle] to get the non host ICE candidates for the
the rest of the "m=" lines, it MAY do that and will not need any rest of the "m=" lines, it MAY do that and will not need any
additional gathering time. additional gathering time.
Some people have suggested a TURN extension to get a bunch of TURN Some people have suggested a TURN extension to get a bunch of TURN
allocations at once. This would only provide a single STUN result so allocations at once. This would only provide a single STUN result so
in cases where the other end did not support BUNDLE, may cause more in cases where the other end did not support BUNDLE, may cause more
use of the TURN server but would be quick in the cases where both use of the TURN server but would be quick in the cases where both
sides supported BUNDLE and would fall back to a successful call in sides supported BUNDLE and would fall back to a successful call in
the other cases. the other cases.
Authors' Addresses Authors' Addresses
 End of changes. 67 change blocks. 
159 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/