MMUSIC Working Group C. Holmberg Internet-Draft Ericsson Intended status: Standards Track H. Alvestrand Expires: December 16, 2013 Google C. Jennings Cisco June 14, 2013 Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers draft-ietf-mmusic-sdp-bundle-negotiation-04.txt Abstract This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=" lines). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 16, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Holmberg, et al. Expires December 16, 2013 [Page 1] Internet-Draft Bundled media June 2013 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 5 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. Bundled SDP Information . . . . . . . . . . . . . . . . . 5 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 6.2.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 6 6.2.3. rtcp-mux Attribute . . . . . . . . . . . . . . . . . 6 6.2.4. rtcp Attribute . . . . . . . . . . . . . . . . . . . 6 6.2.5. DTLS-SRTP fingerprint Attribute . . . . . . . . . . . 6 6.2.6. SDES crypto Attribute . . . . . . . . . . . . . . . . 6 6.2.7. Other Attributes (a=) . . . . . . . . . . . . . . . . 6 6.3. RFC 5888 restrictions . . . . . . . . . . . . . . . . . . 6 6.4. SDP Offerer Procedures . . . . . . . . . . . . . . . . . 6 6.4.1. SDP Offerer Bundle Address Request and Usage . . . . 7 6.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 7 6.4.3. Adding a media description to a BUNDLE group . . . . 8 6.4.4. Moving A Media Description Out Of A BUNDLE Group . . 8 6.4.5. Disabling A Media Description In A BUNDLE Group . . . 9 6.5. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 9 6.5.1. Answerer Bundle Address Selection and Usage . . . . . 9 6.5.2. Moving A Media Description Out Of A BUNDLE Group . . 10 6.5.3. Rejecting A Media Description In A BUNDLE Group . . . 10 7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 11 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . 11 8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Example: Bundle Address Selection . . . . . . . . . . . 12 10.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 14 10.3. Example: Offerer Adds A Media Description To A BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 17 Holmberg, et al. Expires December 16, 2013 [Page 2] Internet-Draft Bundled media June 2013 10.5. Example: Offerer Disables A Media Description In A BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Design Considerations . . . . . . . . . . . . . . . 21 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 22 A.3. Usage of port number value zero . . . . . . . . . . . . . 23 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 24 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 24 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 25 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m=" lines) has been identified. This would e.g. allow the usage of a single set of Interactive Connectivity Establishment (ICE) [RFC5245] candidates for multiple media descriptions. Normally different media types (audio, video etc) will be described using different media descriptions. This specification defines a new SDP Grouping Framework [RFC5888] extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=" lines). The Offerer and Answerer [RFC3264] use the BUNDLE mechanism to negotiate a single BUNDLE address to be used for the bundled media associated with a BUNDLE group. The BUNDLE mechanism allows an SDP Offerer and SDP Answerer to assign identical addresses to multiple "m=" lines, if those "m=" lines are associated with a BUNDLE group. However, until it is known whether both the Offerer and Answerer support the BUNDLE mechanism, unique addresses are assigned to each "m=" line, including those associated with a BUNDLE group. NOTE: As defined in RFC 4566 [RFC4566], the semantics of multiple "m=" lines using the same port number value are undefined, and there Holmberg, et al. Expires December 16, 2013 [Page 3] Internet-Draft Bundled media June 2013 is no grouping defined by such means. Instead, an explicit grouping mechanism needs to be used to express the intended semantics. This specification provides such extension. SDP Offers and SDP Answer can contain multiple BUNDLE groups. For each BUNDLE group, a BUNDLE address is negotiated. Multiple BUNDLE groups cannot share the same bundle address. The default assumption is that all Real-Time Protocol (RTP) [RFC3550] based media flows within a BUNDLE group belongs to the same RTP Session [RFC3550]. Future extensions can change that assumption. The BUNDLE mechanism is backward compatible. Endpoints that do not support the BUNDLE mechanism are expected to generate SDP Offers and SDP Answers without an SDP group:BUNDLE attribute, and are expected to assign unique addresses to each "m=" line, according to the procedures in [RFC4566] and [RFC3264] 2. Terminology 5-tuple: A collection of the following values: source address, source port, destination address, destination port and protocol. Bundled media: Two or more RTP streams using a single 5-tuple. The RTCP streams associated with the RTP streams also use a single 5-tuple, which might be the same, but can also be different, as the one used by the RTP streams. Unique address: This refers to an IP address and IP port combination, that can only be associated with a single "m=" line within an SDP Session. BUNDLE address: This refers to an IP address and IP port combination, that is associated with each "m=" line within a BUNDLE group, within an SDP Session. The zero IP port value BUNDLE address MUST NOT be used in a BUNDLE address. NOTE: "m=" lines that share a BUNDLE address MUST also share other parameters related to the media transport plane, e.g. ICE candidate information. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Holmberg, et al. Expires December 16, 2013 [Page 4] Internet-Draft Bundled media June 2013 4. Applicability Statement The mechanism in this specification only applies to the Session Description Protocol (SDP) [RFC4566], when used together with the SDP Offer/Answer mechanism [RFC3264]. 5. SDP Grouping Framework BUNDLE Extension Semantics This section defines a new SDP Grouping Framework extension, BUNDLE. The BUNDLE extension can be indicated using an SDP session-level 'group' attribute. Each SDP Media Description ("m=" line) that is grouped together, using SDP media-level mid attributes, belongs to a given BUNDLE group. 6. SDP Offer/Answer Procedures 6.1. General This section describes the usage of the SDP Offer/Answer mechanism [RFC3264] to negotiate the usage of the BUNDLE mechanism, to negotiate the BUNDLE address, and to add, remove and reject SDP Media Descriptions ("m=" lines) [RFC4566] associated with a BUNDLE group. The generic rules and procedures defined in [RFC3264] and [RFC5888] apply when the SDP Offer/Answer mechanism is used with the BUNDLE mechanism. For example, if an SDP Offer is rejected, the previously negotiated SDP parameters and characteristics (including those associated with BUNDLE groups) apply. When an endpoint, acting as an Offerer or Answerer [RFC3264], generates an SDP Offer, or an SDP Answer, the endpoint MUST assign an SDP media-level mid value for each "m=" line in a BUNDLE group. In addition, the endpoint MUST assign an SDP session-level group:BUNDLE attribute for each BUNDLE group, and place each mid associated with the SDP group:BUNDLE attribute mid list. 6.2. Bundled SDP Information 6.2.1. General This section describes restrictions associated with the usage of SDP parameters and extensions within a BUNDLE group. It also describes, when parameter and attribute values have been assigned to each "m=" line in the BUNDLE group, how to calculate a value for the whole BUNDLE group. Holmberg, et al. Expires December 16, 2013 [Page 5] Internet-Draft Bundled media June 2013 6.2.2. Bandwidth (b=) The total proposed bandwidth is the sum of the proposed bandwidth for each "m=" line associated with a negotiated BUNDLE group. 6.2.3. rtcp-mux Attribute For each "m=" line in a BUNDLE group, an Offerer and Answerer MUST assign an SDP rtcp-mux attribute [RFC5761]. 6.2.4. rtcp Attribute When used, for each RTP media "m=" line in a BUNDLE group, an Offerer and Answerer MUST assign an SDP rtcp attribute [RFC3605] with an identical attribute value. 6.2.5. DTLS-SRTP fingerprint Attribute When DTLS-SRTP is used, for each RTP media "m=" line in a BUNDLE group, an Offerer and Answerer MUST assign an SDP DTLS-SRTP fingerprint attribute with identical attribute values. 6.2.6. SDES crypto Attribute When SDES is used, for each RTP media "m=" line in a BUNDLE group, an Offerer and Answerer MUST assign an SDP crypto attribute, with unique attribute values. 6.2.7. Other Attributes (a=) There are also special rules for handling many different attributes as defined in [I-D.nandakumar-mmusic-sdp-attributes]. It might not possible to use bundle with some attributes. 6.3. RFC 5888 restrictions Based on the rules and procedures in [RFC5888], the following restrictions also apply to BUNDLE groups in SDP Answers: o 1) A BUNDLE group must not be added to an SDP Answer, unless the same BUNDLE group was included in the associated SDP Offer; and o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP Answer, unless it was in the same BUNDLE group in the associated SDP Offer. 6.4. SDP Offerer Procedures Holmberg, et al. Expires December 16, 2013 [Page 6] Internet-Draft Bundled media June 2013 6.4.1. SDP Offerer Bundle Address Request and Usage An Offerer can assign a BUNDLE address to multiple "m=" lines in a BUNDLE group, once the Answerer has selected the BUNDLE address for the Offerer. An Offerer MUST NOT assign a BUNDLE address to multiple "m=" lines until the Answerer has selected the BUNDLE address. OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to multiple "m=" lines in a BUNDLE group, before the Answerer has selected the BUNDLE address? In order to negotiate (or, to re-negotiate) the BUNDLE address associated with a BUNDLE group, the Offerer, in the SDP Offer, assigns a unique address to each "m=" line in the BUNDLE group. In addition, the Offerer indicates which unique address it wishes the Answerer to select as the Offerer's BUNDLE address. The Offerer places the mid, associated with the unique address requested to be selected as the BUNDLE address, first in the SDP group:BUNDLE attribute mid list. The Answerer will then select the BUNDLE address for the Offerer ([ref-to-be-added]). If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the BUNDLE address associated with a BUNDLE group, it MAY assign the previously negotiated BUNDLE address as a unique address to one of the "m=" lines in the BUNDLE group. If the Offerer assigns the previously selected BUNDLE address to more than one "m=" line in a BUNDLE group, the first mid in the SDP group:BUNDLE attribute mid list MUST represent an "m=" line to which the BUNDLE address is assigned. Hence, in order to re-negotiate the BUNDLE address, the Offerer needs to assign a unique address to each "m=" line in the BUNDLE group, as described above. An Offerer MUST NOT assign a BUNDLE address to an "m=" line that is not associated with a BUNDLE group. An Offerer MUST NOT assign a BUNDLE address, that has been negotiated for a BUNDLE group, to an "m=" line that is associated with another BUNDLE group. Section 10.1 shows an example of a Bundle Address Request. 6.4.2. Bundle Address Synchronization (BAS) When an Offerer has requested the Answerer to select the Offerer's BUNDLE address, and the Offerer did not assign the requested BUNDLE address to each "m=" line in the BUNDLE group of the SDP Offer used to request the BUNDLE address, when the associated SDP Answer is received the Offerer MUST send a subsequent SDP Offer. In the subsequent SDP Offer the Offerer MUST assign the selected BUNDLE Holmberg, et al. Expires December 16, 2013 [Page 7] Internet-Draft Bundled media June 2013 address to each "m=" line in the BUNDLE group. This procedure is referred to as Bundle Address Synchronization (BAS). When the Offerer performs a BAS, the Offerer MAY modify SDP parameters in the same SDP Offer. NOTE: It is important that the SDP Offer used for the BAS gets accepted by the Answerer, so the Offerer needs to consider the necessity to modify SDP parameters that could get the Answerer to reject the SDP Offer. Removing "m=" lines, or reducing the number of codecs, in the SDP Offer used for the BAS is considered to have a low risk of being rejected. NOTE: The main purpose of the BAS is to make sure that intermediaries, that might not support the BUNDLE mechanism, have correct information regarding which IP address and port is going to be used for the bundled media. Section 10.1 shows an example of an SDP Offer used to perform a BAS. 6.4.3. Adding a media description to a BUNDLE group When an Offerer adds an "m=" line to a BUNDLE group, the Offerer MUST assign either a unique address, or the BUNDLE address associated with the BUNDLE group, to the added "m=" line. In addition, the Offerer MUST assign a mid value to the "m=" line, and place the mid in the SDP group:BUNDLE attribute mid list associated with the BUNDLE group, in order to group the "m=" line to the BUNDLE group. NOTE: If the Offerer assigns a unique address to the added "m=" line, it allows the Answerer to move the "m=" line out of the BUNDLE group without having to reject the "m=" line ([ref-to-be-added]). To the previously added "m=" lines in the BUNDLE group, the Offerer assigns either unique addresses or the BUNDLE address associated with the BUNDLE group, according to the procedures in Section 6.4.1. Section 10.3 shows an example of an SDP Offer used to add an "m=" line to a BUNDLE group. 6.4.4. Moving A Media Description Out Of A BUNDLE Group When an Offerer moves an "m=" line out of a BUNDLE group, the Offerer MUST assign a unique address to the moved "m=" line. In addition, the Offerer MUST NOT anymore use a mid value to group the "m=" line with the BUNDLE group. Holmberg, et al. Expires December 16, 2013 [Page 8] Internet-Draft Bundled media June 2013 To the remaining "m=" lines in the BUNDLE group, the Offerer assigns either unique addresses or the BUNDLE address associated with the BUNDLE group, according to the procedures in Section 6.4.1. Section 10.4 shows an example of an SDP Offer used to move an "m=" line out of a BUNDLE group. 6.4.5. Disabling A Media Description In A BUNDLE Group When an Offerer disables an "m=" line in a BUNDLE group, the Offerer MUST assign a zero port value [RFC3264] to the disabled "m=" line. In addition, the Offerer MUST NOT anymore use a mid value to group the "m=" line with the BUNDLE group. To the remaining "m=" lines in the BUNDLE group, the Offerer assigns either unique addresses or the BUNDLE address associated with the BUNDLE group, according to the procedures in Section 6.4.1. Section 10.5 shows an example of an SDP Offer used to move an "m=" line out of a BUNDLE group. 6.5. SDP Answerer Procedures 6.5.1. Answerer Bundle Address Selection and Usage 6.5.1.1. Offerer Bundle Address Selection If the Offerer, in an SDP Offer, assigned a unique address to each "m=" line in a BUNDLE group, it means that the Offerer has requested the Answerer to select a BUNDLE address for the Offerer. The first mid in the SDP group:BUNDLE attribute mid list of the SDP Offer represents the unique address which the Offerer requests the Answer to select as the Offerer's BUNDLE address. The Answerer SHOULD select the unique address associated with the first mid to become the Offerer's BUNDLE address, unless the Answerer in the SDP Answer will move the "m=" line represented by the mid out of the BUNDLE group, or if there is some other reason why the Answerer can not select the unique address associated with the mid. In that case, the Answerer MUST try the next mid in the list. In the SDP Answer, the Answerer MUST place the mid associated with the selected BUNDLE address first in the SDP group:BUNDLE attribute mid list associated with the BUNDLE group. Section 10.1 shows an example of an Offerer's BUNDLE address selection. Holmberg, et al. Expires December 16, 2013 [Page 9] Internet-Draft Bundled media June 2013 6.5.1.2. Anwerer Bundle Address Selection The Answerer MUST select a local BUNDLE address, and in the SDP Answer assign it to each "m=" line associated with the BUNDLE group. The Answerer is allowed to change its BUNDLE address in any SDP Answer. The Answerer MUST NOT assign a BUNDLE address to an "m=" line that is not associated with a BUNDLE group. The Answerer MUST NOT assign a BUNDLE address, associated with a BUNDLE group, to an "m=" line associated with another BUNDLE group. Section 10.1 shows an example of an Answerer's local BUNDLE address selection. 6.5.2. Moving A Media Description Out Of A BUNDLE Group When an Answerer moves an "m=" line out of a BUNDLE group, the Answerer MUST assign a unique address to the moved "m=" line. In addition, the Answerer MUST NOT anymore use a mid value to group the "m=" line with the BUNDLE group. To the remaining "m=" lines in the BUNDLE group, the Answerer assigns the Answerer's BUNDLE address. An Answerer MUST NOT move an "m=" line out of a BUNDLE group, unless: o 1) The Offerer assigned a unique address to the "m=" line in the associated SDP Offer; or o 2) The Answerer also rejects the "m=" line Section 6.5.3. 6.5.3. Rejecting A Media Description In A BUNDLE Group When an Answerer rejects an "m=" line in a BUNDLE group, the Answerer MUST assign a zero port value to the rejected "m=" line. In addition, the Answerer MUST NOT anymore use a mid value to group the "m=" line with the BUNDLE group. To the remaining "m=" lines in the BUNDLE group, the Answerer assigns the Answerer's BUNDLE address. Holmberg, et al. Expires December 16, 2013 [Page 10] Internet-Draft Bundled media June 2013 7. Single vs Multiple RTP Sessions 7.1. General By default, all RTP based media flows within a given BUNDLE group belong to a single RTP session [RFC3550]. Multiple BUNDLE groups will form multiple RTP Sessions. The usage of multiple RTP Sessions within a given BUNDLE group, or the usage of a single RTP Session that spans over multiple BUNDLE groups, is outside the scope of this specification. Other specification needs to extend the BUNDLE mechanism in order to allow such usages. 7.2. Single RTP Session When a single RTP Session is used, media associated with all "m=" lines part of a bundle group share a single SSRC [RFC3550] numbering space. In addition, the following rules and restrictions apply for a single RTP Session: o - The dynamic payload type values used in the "m=" lines MUST NOT overlap. o - The "proto" value in each "m=" line MUST be identical (e.g. RTP/ AVPF). o - A given SSRC SHOULD NOT transmit RTP packets using payload types that originates from different "m=" lines. NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC. If transmission of multiple media types are done with time overlap RTP and RTCP fails to function. Even if done in proper sequence this causes RTP Timestamp rate switching issues [ref to draft-ietf-avtext-multiple-clock-rates]. 8. Usage With ICE 8.1. General This section describes how to use the BUNDLE grouping extension together with the Interactive Connectivity Establishment (ICE) mechanism [RFC5245]. 8.2. Candidates Holmberg, et al. Expires December 16, 2013 [Page 11] Internet-Draft Bundled media June 2013 When an ICE-enabled endpoint generates an SDP Offer, which contains a BUNDLE group, the SDP Offerer MUST include ICE candidates for each "m=" line associated with a "BUNDLE" group, except for any "m=" line with a zero port number value. If the "m=" lines associated with the BUNDLE group contain different port number values, the SDP Offerer MUST also insert different candidate values in each "m=" line associated with the BUNDLE group. If the "m=" lines associated with the BUNDLE group contain an identical port number value, the candidate values MUST also be identical. When an ICE-enabled endpoint generates and SDP Answer, which contains a BUNDLE group, the Answerer MUST include ICE candidates for each "m=" line associated with the "BUNDLE" group, except for any "m=" line where the port number value is set to zero. The Answerer MUST insert identical candidate values in each "m=" line associated with the BUNDLE group. 8.3. Candidates Once it is known that both endpoints support, and accept to use, the BUNDLE grouping extension, ICE connectivity checks and keep-alives only needs to be performed for the whole BUNDLE group, instead of for each individual "m=" line associated with the group. 9. Security Considerations This specification does not significantly change the security considerations of SDP which can be found in Section X of TBD. TODO: Think carefully about security analysis of reuse of same SDES key on multiple "m=" lines when the far end does not use BUNDLE and warn developers of any risks. 10. Examples 10.1. Example: Bundle Address Selection The example below shows: o 1. An SDP Offer, in which the Offerer assigns unique addresses to each "m=" line in the BUNDLE group, and requests the Answerer to select the Offerer's BUNDLE address. o 2. An SDP Answer, in which the Answerer selects the BUNDLE address for the Offerer, and assigns its own local BUNDLE address to each "m=" line in the BUNDLE group. Holmberg, et al. Expires December 16, 2013 [Page 12] Internet-Draft Bundled media June 2013 o 3. A subsequent SDP Offer, which is used to perform a Bundle Address Synchronization (BAS). SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10002 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 m=video 20000 RTP/AVP 32 a=mid:bar b=AS:1000 a=rtpmap:32 MPV/90000 SDP Offer (3) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= Holmberg, et al. Expires December 16, 2013 [Page 13] Internet-Draft Bundled media June 2013 c=IN IP4 host.atlanta.com t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 10.2. Example: Bundle Mechanism Rejected The example below shows: o 1. An SDP Offer, in which the Offerer assigns unique addresses to each "m=" line in the BUNDLE group, and requests the Answerer to select the Offerer's BUNDLE address. o 2. An SDP Answer, in which the Answerer rejects the BUNDLE group, and assigns unique addresses to each "m=" line. SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10002 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 Holmberg, et al. Expires December 16, 2013 [Page 14] Internet-Draft Bundled media June 2013 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 m=audio 20000 RTP/AVP 0 b=AS:200 a=rtpmap:0 PCMU/8000 m=video 30000 RTP/AVP 32 b=AS:1000 a=rtpmap:32 MPV/90000 10.3. Example: Offerer Adds A Media Description To A BUNDLE Group The example below shows: o 1. An SDP Offer, in which the Offerer adds an "m=" line, represented by the "zen" mid value, to a previously negotiated BUNDLE group, assigns a unique address to the added "m=" line, and assigns the previously negotiated BUNDLE address to the previously added "m=" lines in the BUNDLE group. o 2. An SDP Answer, in which the Answerer assigns its own local BUNDLE address to each "m=" line (including the added "m=" line) in the BUNDLE group. o 3. A subsequent SDP Offer, which is used to perform a Bundle Address Synchronization (BAS). SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:BUNDLE foo bar zen m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 Holmberg, et al. Expires December 16, 2013 [Page 15] Internet-Draft Bundled media June 2013 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=video 20000 RTP/AVP 66 a=mid:zen b=AS:1000 a=rtpmap:66 H261/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 a=group:BUNDLE foo bar zen m=audio 20000 RTP/AVP 0 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 m=video 20000 RTP/AVP 32 a=mid:bar b=AS:1000 a=rtpmap:32 MPV/90000 m=video 20000 RTP/AVP 66 a=mid:zen b=AS:1000 a=rtpmap:66 H261/90000 SDP Offer (3) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:BUNDLE foo bar zen m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 Holmberg, et al. Expires December 16, 2013 [Page 16] Internet-Draft Bundled media June 2013 m=video 10000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=video 10000 RTP/AVP 66 a=mid:zen b=AS:1000 a=rtpmap:66 H261/90000 10.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group The example below shows: o 1. An SDP Offer, in which the Offerer moves an "m=" line out of a previously negotiated BUNDLE group, assigns a unique address to the moved "m=" line, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in the BUNDLE group. o 2. An SDP Answer, in which the Answerer moves the corresponding "m=" line out of the BUNDLE group, and assigns unique address to the moved "m=" line, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in the BUNDLE group. SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=video 50000 RTP/AVP 66 Holmberg, et al. Expires December 16, 2013 [Page 17] Internet-Draft Bundled media June 2013 b=AS:1000 a=rtpmap:66 H261/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 m=video 20000 RTP/AVP 32 a=mid:bar b=AS:1000 a=rtpmap:32 MPV/90000 m=video 60000 RTP/AVP 66 b=AS:1000 a=rtpmap:66 H261/90000 10.5. Example: Offerer Disables A Media Description In A BUNDLE Group The example below shows: o 1. An SDP Offer, in which the Offerer moves an "m=" line out of a previously negotiated BUNDLE group, assigns a zero port number the moved "m=" line in order to disable it, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in the BUNDLE group. o 2. An SDP Answer, in which the Answerer moves the corresponding "m=" line out of the BUNDLE group, and assigns a zero port value to the moved "m=" line in order to disable it, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in the BUNDLE group. SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com Holmberg, et al. Expires December 16, 2013 [Page 18] Internet-Draft Bundled media June 2013 s= c=IN IP4 host.atlanta.com t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=video 0 RTP/AVP 66 a=rtpmap:66 H261/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 m=video 20000 RTP/AVP 32 a=mid:bar b=AS:1000 a=rtpmap:32 MPV/90000 m=video 0 RTP/AVP 66 a=rtpmap:66 H261/90000 11. IANA Considerations This document requests IANA to register the new SDP Grouping semantic extension called BUNDLE. 12. Acknowledgements Holmberg, et al. Expires December 16, 2013 [Page 19] Internet-Draft Bundled media June 2013 The usage of the SDP grouping extension for negotiating bundled media is based on a similar alternatives proposed by Harald Alvestrand and Cullen Jennings. The BUNDLE mechanism described in this document is based on the different alternative proposals, and text (e.g. SDP examples) have been borrowed (and, in some cases, modified) from those alternative proposals. The SDP examples are also modified versions from the ones in the Alvestrand proposal. Thanks to Paul Kyzivat and Martin Thompson for taking the the time to read the text along the way, and providing useful feedback. 13. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 o Mechanism modified, to be based on usage of SDP Offers with both different and identical port number values, depending on whether it is known if the remote endpoint supports the extension. o Cullen Jennings added as co-author. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 o No changes. New version due to expiration. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 o No changes. New version due to expiration. Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 o Draft name changed. o Harald Alvestrand added as co-author. o "Multiplex" terminology changed to "bundle". o Added text about single versus multiple RTP Sessions. o Added reference to RFC 3550. 14. References Holmberg, et al. Expires December 16, 2013 [Page 20] Internet-Draft Bundled media June 2013 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [I-D.nandakumar-mmusic-sdp-attributes] Nandakumar, S. and C. Jennings, "A Framework for SDP Attributes when Multiplexing", draft-nandakumar-mmusic- sdp-attributes-00 (work in progress), February 2013. 14.2. Informative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. Appendix A. Design Considerations A.1. General One of the main issues regarding the BUNDLE grouping extensions has been whether, in SDP Offers and SDP Answers, the same port number value 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 5-tuple for media associated with the "m=" lines. Issues with both approaches, discussed in the Appendix have been raised. The Holmberg, et al. Expires December 16, 2013 [Page 21] Internet-Draft Bundled media June 2013 outcome was to specify a mechanism which uses SDP Offers with both different and identical port number values. Below are the primary issues that have been considered when defining the "BUNDLE" grouping extension: o 1) Interoperability with existing UAs. o 2) Interoperability with intermediary B2BUA- and proxy entities. o 3) Time to gather, and the number of, ICE candidates. o 4) Different error scenarios, and when they occur. o 5) SDP Offer/Answer impacts, including usage of port number value zero. NOTE: Before this document is published as an RFC, this Appendix might be removed. A.2. UA Interoperability Consider the following SDP Offer/Answer exchange, where Alice sends an SDP Offer to Bob: SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 m=audio 10000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 10002 RTP/AVP 97 a=rtpmap:97 H261/90000 SDP Answer v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com Holmberg, et al. Expires December 16, 2013 [Page 22] Internet-Draft Bundled media June 2013 t=0 0 m=audio 20000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 20002 RTP/AVP 97 a=rtpmap:97 H261/90000 RFC 4961 specifies a way of doing symmetric RTP but that is an a later invention to RTP and Bob can not assume that Alice supports RFC 4961. This means that Alice may be sending RTP from a different port than 10000 or 10002 - some implementation simply send the RTP from an ephemeral port. When Bob's endpoint receives an RTP packet, the only way that Bob know if it should be passed to the video or audio codec is by looking at the port it was received on. This lead some SDP implementations to use the fact that each "m=" line had a different port number to use that port number as an index to find the correct m line in the SDP. As a result, some implementations that do support symmetric RTP and ICE still use a SDP data structure where SDP with "m=" lines with the same port such as: SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 m=audio 10000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 98 a=rtpmap:98 H261/90000 will result in the second "m=" line being considered an SDP error because it has the same port as the first line. A.3. Usage of port number value zero In an SDP Offer or SDP Answer, the media associated with an "m=" line can be disabled/rejected by setting the port number value to zero. This is different from e.g. using the SDP direction attributes, where RTCP traffic will continue even if the SDP "inactive" attribute is indicated for the associated "m=" line. Holmberg, et al. Expires December 16, 2013 [Page 23] Internet-Draft Bundled media June 2013 If each "m=" line associated with a BUNDLE group would contain different port number values, and one of those port would be used for the 5-tuple, problems would occur if an endpoint wants to disable/ reject the "m=" line associated with that port, by setting the port number value to zero. After that, no "m=" line would contain the port number value which is used for the 5-tuple. In addition, it is unclear what would happen to the ICE candidates associated with the "m=" line, as they are also used for the 5-tuple. A.4. B2BUA And Proxy Interoperability Some back to back user agents may be configured in a mode where if the incoming call leg contains an SDP attribute the B2BUA does not understand, the B2BUS still generates that SDP attribute in the Offer for the outgoing call leg. Consider an B2BUA that did not understand the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. Further assume that the B2BUA was configured to tear down any call where it did not see any RTCP for 5 minutes. In this cases, if the B2BUA received an Offer like: SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtcp:53020 It would be looking for RTCP on port 49172 but would not see any because the RTCP would be on port 53020 and after five minutes, it would tear down the call. Similarly, an SBC that did not understand BUNDLE yet put BUNDLE in it's offer may be looking for media on the wrong port and tear down the call. It is worth noting that a B2BUA that generated an Offer with capabilities it does not understand is not compliant with the specifications. A.4.1. Traffic Policing Sometimes intermediaries do not act as B2BUA, in the sense that they don't modify SDP bodies, nor do they terminate SIP dialogs. Still, however, they may use SDP information (e.g. IP address and port) in order to control traffic gating functions, and to set traffic Holmberg, et al. Expires December 16, 2013 [Page 24] Internet-Draft Bundled media June 2013 policing rules. There might be rules which will trigger a session to be terminated in case media is not sent or received on the ports retrieved from the SDP. This typically occurs once the session is already established and ongoing. A.4.2. Bandwidth Allocation Sometimes intermediaries do not act as B2BUA, in the sense that they don't modify SDP bodies, nor do they terminate SIP dialogs. Still, however, they may use SDP information (e.g. codecs and media types) in order to control bandwidth allocation functions. The bandwidth allocation is done per "m=" line, which means that it might not be enough if media associated with all "m=" lines try to use that bandwidth. That may either simply lead to bad user experience, or to termination of the call. A.5. Candidate Gathering When using ICE, an candidate needs to be gathered for each port. This takes approximately 20 ms extra for each extra "m=" line due to the NAT pacing requirements. All of this gather can be overlapped with other things while the page is loading to minimize the impact. If the client only wants to generate TURN or STUN ICE candidates for one of the "m=" lines and then use trickle ICE [TODO REF] to get the non host ICE candidates for the rest of the "m=" lines, it MAY do that and will not need any additional gathering time. Some people have suggested a TURN extension to get a bunch of TURN allocation at once. This would only provide a single STUN result so 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 sides supported BUNDLE and would fall back to a successful call in the other cases. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg, et al. Expires December 16, 2013 [Page 25] Internet-Draft Bundled media June 2013 Harald Tveit Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada Email: fluffy@iii.ca Holmberg, et al. Expires December 16, 2013 [Page 26]