draft-ietf-mmusic-sdp-bundle-negotiation-11.txt   draft-ietf-mmusic-sdp-bundle-negotiation-12.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: March 26, 2015 C. Jennings Expires: April 12, 2015 C. Jennings
Cisco Cisco
September 22, 2014 October 9, 2014
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-11.txt draft-ietf-mmusic-sdp-bundle-negotiation-12.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework extension, This specification defines a new SDP Grouping Framework extension,
'BUNDLE'. The extension can be used with the Session Description 'BUNDLE'. The extension can be used with the Session Description
Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a
single 5-tuple for sending and receiving media associated with single 5-tuple for sending and receiving media associated with
multiple SDP media descriptions ("m="). This is referred to as multiple SDP media descriptions ("m="). This is referred to as
bundled media. This specification also defines a new SDP attribute, bundled media.
'bundle-only', which can be used to request that specific media is
only used if bundled.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC Both endpoints can negotiate the use of bundle and to support that
3264. The update allows an answerer to assign a non-zero port value negotiations, this specification defines a new SDP attribute,
to an "m=" line in an SDP answer, even if the "m=" line in the 'bundle-only', which can be used to request that specific media is
associated SDP offer contained a zero port value. only used if bundled. This specification also updates sections 5.1,
8.1 and 8.2 of RFC 3264 to allows an answerer to assign a non-zero
port value to an "m=" line in an SDP answer, even if the "m=" line in
the associated SDP offer contained a zero port value.
This specification also defines a new RTP SDES item, and a new RTP There are multiple ways to correlate the bundled RTP packets with the
header extension, that can be used to carry a value that associates appropriate media descriptions. This specification defines a new RTP
RTP/RTCP packets with a specific media description. SDES item and a new RTP header extension that provides an additional
way to do this correlation by using them to carry a value that
associates the RTP/RTCP packets with a specific media description.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 26, 2015.
This Internet-Draft will expire on April 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 15 skipping to change at page 3, line 18
8.5.2. Request a new offerer BUNDLE address . . . . . . . . 15 8.5.2. Request a new offerer BUNDLE address . . . . . . . . 15
8.5.3. Adding a media description to a BUNDLE group . . . . 15 8.5.3. Adding a media description to a BUNDLE group . . . . 15
8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16 8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16
8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18
10.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . 19
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 22 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 22
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 22 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23
12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 23 12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 23
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23
12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 23 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 23
12.3. New text replacing section 5.1 (2nd paragraph) of RFC 12.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 24 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 24
12.5. New text replacing section 8.2 (2nd paragraph) of RFC 12.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 24 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 24
12.7. New text replacing section 8.4 (6th paragraph) of RFC 12.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. RTP/RTCP extensions for mid value transport . . . . . . . . . 25 13. RTP/RTCP extensions for mid value transport . . . . . . . . . 25
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25
13.2. RTP MID SDES Item . . . . . . . . . . . . . . . . . . . 26 13.2. RTP MID SDES Item . . . . . . . . . . . . . . . . . . . 26
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 26 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 26
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 26 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 26
14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 27 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 27
14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 27 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 27
15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27
16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 28
16.1. Example: Bundle Address Selection . . . . . . . . . . . 27 16.1. Example: Bundle Address Selection . . . . . . . . . . . 28
16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 29 16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 29
16.3. Example: Offerer Adds A Media Description To A BUNDLE 16.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 30 Group . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.4. Example: Offerer Moves A Media Description Out Of A 16.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 32 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 32
16.5. Example: Offerer Disables A Media Description Within A 16.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 34 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
20.1. Normative References . . . . . . . . . . . . . . . . . . 39 20.1. Normative References . . . . . . . . . . . . . . . . . . 40
20.2. Informative References . . . . . . . . . . . . . . . . . 40 20.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Design Considerations . . . . . . . . . . . . . . . 40 Appendix A. Design Considerations . . . . . . . . . . . . . . . 42
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 41 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 42
A.3. Usage of port number value zero . . . . . . . . . . . . . 43 A.3. Usage of port number value zero . . . . . . . . . . . . . 44
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 43 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 44
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 44 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 45
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 44 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 45
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 44 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and This specification defines a way to use a single 5-tuple for sending
receiving media associated with multiple SDP media descriptions ("m=" and receiving media associated with multiple SDP media descriptions
lines) has been identified. This would e.g. allow the usage of a ("m=" lines) . This allows the usage of a single set of Interactive
single set of Interactive Connectivity Establishment (ICE) [RFC5245] Connectivity Establishment (ICE) [RFC5245] candidates for multiple
candidates for multiple media descriptions. media descriptions.
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension , 'BUNDLE'. The extension can be used with the Session extension called 'BUNDLE'. The extension can be used with the
Description Protocol (SDP) Offer/Answer mechanism [RFC3264] to Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
negotiate the usage of a single 5-tuple for sending and receiving to negotiate the usage of a single 5-tuple for sending and receiving
media associated with multiple SDP media descriptions ("m="). This media associated with multiple SDP media descriptions ("m="). This
is referred to as bundled media. This specification also defines a is referred to as bundled media.
new SDP attribute, 'bundle-only', which can be used to request that
specific media is only used if bundled.
The offerer and answerer [RFC3264] use the BUNDLE extension to The offerer and answerer [RFC3264] use the BUNDLE extension to
negotiate the 5-tuples (BUNDLE addresses), one for the offerer negotiate the 5-tuples (BUNDLE addresses), one for the offerer
(offerer BUNDLE address) and one for the answerer (answerer BUNDLE (offerer BUNDLE address) and one for the answerer (answerer BUNDLE
address) to be used for the bundled media associated with a BUNDLE address) to be used for the bundled media associated with a BUNDLE
group. group. Once the offerer and the answerer have negotiated a BUNDLE
group, they assign their respective BUNDLE address to each "m=" line
in the BUNDLE group. The BUNDLE address is used to send and receive
all media associated with the BUNDLE group.
Once the offerer and the answerer have negotiated a BUNDLE group, This specification also defines a new SDP attribute, 'bundle-only',
they assign their respective BUNDLE address to each "m=" line in the which can be used to request that specific media is only used if
BUNDLE group. The BUNDLE address is used to send and receive all bundled.
media associated with the BUNDLE group.
NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning As defined in RFC 4566 [RFC4566], the semantics of assigning the same
the same port value to multiple "m=" lines are undefined, and there port value to multiple "m=" lines are undefined, and there is no
is no grouping defined by such means. Instead, an explicit grouping grouping defined by such means. Instead, an explicit grouping
mechanism needs to be used to express the intended semantics. This mechanism needs to be used to express the intended semantics. This
specification provides such an extension. specification provides such an extension.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
[RFC3264]. The update allows an answerer to assign a non-zero port [RFC3264]. The update allows an answerer to assign a non-zero port
value to an "m=" line in an SDP answer, even if the "m=" line in the value to an "m=" line in an SDP answer, even if the "m=" line in the
associated SDP offer contained a zero port value. associated SDP offer contained a zero port value.
This specification also defines a new RTP SDES item, and a new RTP This specification also defines a new RTP SDES item and a new RTP
header extension, that can be used to carry a value that associates header extension that can be used to carry a value that associates
RTP/RTCP packets with a specific media description. RTP/RTCP packets with a specific media description. This can be used
to correlate a RTP packet with the correct media.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE SDP bodies can contain multiple BUNDLE groups. A given BUNDLE
address MUST only be associated with a single BUNDLE group. address MUST only be associated with a single BUNDLE group. The
procedures in this specification apply independently to a given
The procedures in this specification apply independently to a given BUNDLE group. All Real-time Transport Protocol (RTP) [RFC3550] based
BUNDLE group. media flows associated with a single BUNDLE group belong to a single
RTP session [RFC3550].
All Real-time Transport Protocol (RTP) [RFC3550] based media flows
associated with a single BUNDLE group belong to a single RTP session
[RFC3550].
The BUNDLE extension is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the extension are expected to generate offers and answers support the extension are expected to generate offers and answers
without an SDP 'group:BUNDLE' attribute, and are expected to assign a without an SDP 'group:BUNDLE' attribute, and are expected to assign a
unique address to each "m=" line within an offer and answer, unique address to each "m=" line within an offer and answer,
according to the procedures in [RFC4566] and [RFC3264] according to the procedures in [RFC4566] and [RFC3264]
2. Terminology 2. Terminology
5-tuple: A collection of the following values: source address, source 5-tuple: A collection of the following values: source address, source
port, destination address, destination port and protocol. port, destination address, destination port, and protocol.
Unique address: An IP address and IP port combination that is Unique address: An IP address and IP port combination that is
assigned to only one "m=" line in an offer or answer. assigned to only one "m=" line in an offer or answer.
Shared address: An IP address and IP port combination that is Shared address: An IP address and IP port combination that is
assigned to multiple "m=" lines within an offer or answer. assigned to multiple "m=" lines within an offer or answer.
Offerer suggested BUNDLE mid: The first mid value in a given SDP Offerer suggested BUNDLE mid: The first mid value in a given SDP
'group:BUNDLE' attribute mid list in an offer. 'group:BUNDLE' attribute mid list in an offer.
skipping to change at page 7, line 41 skipping to change at page 7, line 41
6. SDP 'bundle-only' Attribute 6. SDP 'bundle-only' Attribute
6.1. General 6.1. General
This section defines a new SDP media-level attribute [RFC4566], This section defines a new SDP media-level attribute [RFC4566],
'bundle-only'. 'bundle-only'.
The 'bundle-only' attribute can be associated with a bundled "m=" The 'bundle-only' attribute can be associated with a bundled "m="
line in an offer, to request that the answerer only accepts the "m=" line in an offer, to request that the answerer only accepts the "m="
line if the answerer keeps the "m=" line within the associated BUNDLE line if the answerer keeps the "m=" line within the associated BUNDLE
group. group. In order to ensure that an answerer that does not supports
the BUNDLE extension always rejects a 'bundle-only' "m=" line, the
In order to ensure that an answerer that does not supports the BUNDLE offerer can assign a zero port value to the "m=" line. According to
extension always rejects a 'bundle-only' "m=" line, the offerer can [RFC4566] an answerer will reject such "m=" line. The usage of the
assign a zero port value to the "m=" line. According to [RFC4566] an 'bundle-only' attribute is only defined for a bundled "m=" line
answerer will reject such "m=" line. within an offer. Other usage is unspecified.
The usage of the 'bundle-only' attribute is only defined for a
bundled "m=" line within an offer. Other usage is unspecified.
[Section 8] defines the detailed SDP Offer/Answer procedures for the [Section 8] defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute. 'bundle-only' attribute.
6.2. Syntax 6.2. Syntax
This section defines the Augmented Backus-Naur Form (ABNF) [RFC5234] This section defines the Augmented Backus-Naur Form (ABNF) [RFC5234]
for the SDP 'bundle-only' attribute, based on the SDP [RFC4566] for the SDP 'bundle-only' attribute, based on the SDP [RFC4566]
grammar. grammar.
skipping to change at page 11, line 37 skipping to change at page 11, line 37
o Reject the "m=" line [Section 8.3.5]; o Reject the "m=" line [Section 8.3.5];
If the answerer keeps a bundle-only "m=" line within the BUNDLE If the answerer keeps a bundle-only "m=" line within the BUNDLE
group, it follows the procedures (assigns the answerer BUNDLE address group, it follows the procedures (assigns the answerer BUNDLE address
to the "m=" line etc) for any other "m=" line kept within the BUNDLE to the "m=" line etc) for any other "m=" line kept within the BUNDLE
group. group.
If the answerer does not want to keep a bundle-only "m=" line within If the answerer does not want to keep a bundle-only "m=" line within
the BUNDLE group, it MUST reject the "m=" line [Section 8.3.5]. the BUNDLE group, it MUST reject the "m=" line [Section 8.3.5].
The answerer MUST NOT include a 'bundle-only' attribute in an The answerer MUST NOT include a 'bundle-only' attribute in an answer.
answer."
NOTE: If a bundled "m=" line in an offer contains a port zero value, NOTE: If a bundled "m=" line in an offer contains a port zero value,
but the "m=" line does not contain an SDP 'bundle-only' attribute, it but the "m=" line does not contain an SDP 'bundle-only' attribute, it
is an indication that the offerer wants to disable the "m=" line is an indication that the offerer wants to disable the "m=" line
[Section 8.5.5]. [Section 8.5.5].
8.3.2. Answerer Selection of Offerer Bundle Address 8.3.2. Answerer Selection of Offerer Bundle Address
In an offer, the address (unique or shared) assigned to the bundled In an offer, the address (unique or shared) assigned to the bundled
"m=" line associated with the offerer suggested BUNDLE mid indicates "m=" line associated with the offerer suggested BUNDLE mid indicates
skipping to change at page 17, line 20 skipping to change at page 17, line 20
line. line.
[Section 16.5] shows an example of an offer for disabling an "m=" [Section 16.5] shows an example of an offer for disabling an "m="
line within a BUNDLE group. line within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
9.1. General 9.1. General
If bundled "m=" lines represent different transport protocols, there If bundled "m=" lines represent different transport protocols, there
MUST exist a publically available specification which describes a MUST exist a publicly available specification which describes a
mechanism, for this specific transport protocol combination, how to mechanism for this specific transport protocol combination that
associate a received packet with the correct transport protocol. describes how to associate a received packet with the correct
transport protocol.
In addition, if a received packet can be associated with more than In addition, if a received packet can be associated with more than
one bundled "m=" line, there MUST exist a publically available one bundled "m=" line, there MUST exist a publically available
specification which describes a mechanism how to associate the specification which describes a mechanism for associating the
received packet with the correct "m=" line. received packet with the correct "m=" line.
9.2. STUN, DTLS, SRTP 9.2. STUN, DTLS, SRTP
Section 5.1.2 of [RFC5764] describes a mechanism how to identify the Section 5.1.2 of [RFC5764] describes a mechanism to identify the
protocol among the STUN, DTLS and SRTP protocols (in any protocol among the STUN, DTLS and SRTP protocols (in any
combination). If an offer or answerer in offers or answers include combination). If an offer or answerer in offers or answers include
bundled "m=" lines that represent these protocols, the offerer or bundled "m=" lines that represent these protocols, the offerer or
answerer MUST support the mechanism described in [RFC5764], and no answerer MUST support the mechanism described in [RFC5764], and no
explicit negotiation is required in order to indicate support and explicit negotiation is required in order to indicate support and
usage of the mechanism. usage of the mechanism.
[RFC5764] does not describe how to identify different protocols [RFC5764] does not describe how to identify different protocols
transported on DTLS, only how to identify the DTLS protocol itself. transported on DTLS, only how to identify the DTLS protocol itself.
If multiple protocols are transported on DTLS, there MUST exist a If multiple protocols are transported on DTLS, there MUST exist a
specification describing a mechanism how to identify each individual specification describing a mechanism for identify each individual
protocol. In addition, if a received DTLS packet can be associated protocol. In addition, if a received DTLS packet can be associated
with more than one "m=" line, there MUST exist a specification which with more than one "m=" line, there MUST exist a specification which
describes a mechanism how to associate the received DTLS packet with describes a mechanism for associating the received DTLS packet with
the correct "m=" line. the correct "m=" line.
[Section 10.2] describes how to associate a received (S)RTP packet [Section 10.2] describes how to associate a received (S)RTP packet
with the correct "m=" line. with the correct "m=" line.
10. RTP Considerations 10. RTP Considerations
10.1. Single RTP Session 10.1. Single RTP Session
10.1.1. General 10.1.1. General
skipping to change at page 18, line 34 skipping to change at page 18, line 34
o The "proto" value in each bundled "m=" line MUST be identical o The "proto" value in each bundled "m=" line MUST be identical
(e.g. RTP/AVPF). (e.g. RTP/AVPF).
o A given SSRC SHOULD NOT transmit RTP packets using payload types o A given SSRC SHOULD NOT transmit RTP packets using payload types
that originate from different bundled "m=" lines. that originate from different bundled "m=" lines.
NOTE: The last bullet above is to avoid sending multiple media types NOTE: The last bullet above is to avoid sending multiple media types
from the same SSRC. If transmission of multiple media types are done from the same SSRC. If transmission of multiple media types are done
with time overlap, RTP and RTCP fail to function. Even if done in with time overlap, RTP and RTCP fail to function. Even if done in
proper sequence this causes RTP Timestamp rate switching issues [ref proper sequence this causes RTP Timestamp rate switching issues
to draft-ietf-avtext-multiple-clock-rates]. [RFC7160].
10.1.2. Payload Type (PT) Value Re-usage 10.1.2. Payload Type (PT) Value Reuse
Multiple bundled "m=" lines might represent RTP based media. As all Multiple bundled "m=" lines might represent RTP based media. As all
RTP based media associated with a BUNDLE group belong to the same RTP RTP based media associated with a BUNDLE group belong to the same RTP
session, in order for a given payload type value to used inside more session, in order for a given payload type value to used inside more
than one bundled "m=" line, all codecs associated with the payload than one bundled "m=" line, all codecs associated with the payload
type numbers MUST share an identical codec configuration. This means type numbers MUST share an identical codec configuration. This means
that the codecs MUST share the same media type, encoding name, clock that the codecs MUST share the same media type, encoding name, clock
rate and any parameter that can affect the codec configuration and rate and any parameter that can affect the codec configuration and
packetization. [I-D.mmusic-sdp-mux-attributes] lists SDP attributes, packetization. [I-D.mmusic-sdp-mux-attributes] lists SDP attributes,
whose attribute values must be identical for all codecs that use the whose attribute values must be identical for all codecs that use the
skipping to change at page 19, line 40 skipping to change at page 19, line 40
RTP/RTCP packets, the offerer and answerer can then use that RTP/RTCP packets, the offerer and answerer can then use that
information to associate received RTP packets with the correct "m=" information to associate received RTP packets with the correct "m="
line. However, an offerer will not know which SSRC values the line. However, an offerer will not know which SSRC values the
answerer will use until it has received the answer providing that answerer will use until it has received the answer providing that
information. Due to this, before the offerer has received the information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate received RTP/RTCP answer, the offerer will not be able to associate received RTP/RTCP
packets with the correct "m=" line using the SSRC values. packets with the correct "m=" line using the SSRC values.
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
received RTP and RTCP packets with the correct "m=" line, an offerer received RTP and RTCP packets with the correct "m=" line, an offerer
and answerer using the BUNDLE extension MUST use the mechanism and answerer using the BUNDLE extension MUST support the mechanism
defined in [Section 13], where the remote endpoint inserts the SDP defined in [Section 13], where the remote endpoint inserts the SDP
'mid' attribute value of an "m=" line in RTP and RTCP packets 'mid' attribute value of an "m=" line in RTP and RTCP packets
associated with that "m=" line. associated with that "m=" line.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
10.3.1. General 10.3.1. General
When a BUNDLE group, which contains RTP based media, is created, the When a BUNDLE group, which contains RTP based media, is created, the
offerer and answerer MUST negotiate whether to enable RTP/RTCP offerer and answerer MUST negotiate whether to enable RTP/RTCP
skipping to change at page 20, line 42 skipping to change at page 20, line 42
10.3.2.3. Generating the SDP Answer 10.3.2.3. Generating the SDP Answer
When an answerer generates an answer, if the offerer indicated When an answerer generates an answer, if the offerer indicated
support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in
the associated offer, the answerer MUST either accept or reject the the associated offer, the answerer MUST either accept or reject the
usage of RTP/RTCP multiplexing in the answer. usage of RTP/RTCP multiplexing in the answer.
If the answerer accepts usage of RTP/RTCP multiplexing within the If the answerer accepts usage of RTP/RTCP multiplexing within the
BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each
bundled "m=" line in the answer. The answerer MUST NOT assign an SDP bundled "m=" line in the answer. The answerer MUST NOT assign an SDP
'rtcp' attribute to any bundled "m=" line in the answer. 'rtcp' attribute to any bundled "m=" line in the answer. The
answerer will use the port number of the selected offerer BUNDLE
address for sending RTP and RTCP packets associated with each bundled
"m=" line towards the offerer.
If the answerer rejects usage of RTP/RTCP multiplexing within the If the answerer rejects usage of RTP/RTCP multiplexing within the
BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp' BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'
attribute to any bundled "m=" line in the answer. attribute to any bundled "m=" line in the answer. The answerer will,
based on the port number of the selected offerer BUNDLE address, use
the next higher (odd) destination port number [RFC3550] for sending
RTCP packets associated with each bundled "m=" line towards the
offerer.
If the usage of RTP/RTCP multiplexing has been negotiated in a If the usage of RTP/RTCP multiplexing has been negotiated in a
previous offer/answer transaction, and the offerer indicates that it previous offer/answer transaction, and the offerer indicates that it
wants to continue using RTP/RTCP multiplexing in a subsequent offer, wants to continue using RTP/RTCP multiplexing in a subsequent offer,
the answerer MUST assign an SDP 'rtcp-mux' attribute to each bundled the answerer MUST assign an SDP 'rtcp-mux' attribute to each bundled
"m=" line in the answer. I.e. the answerer MUST NOT disable the "m=" line in the answer. I.e. the answerer MUST NOT disable the
usage of RTP/RTCP multiplexing. usage of RTP/RTCP multiplexing.
10.3.2.4. Offerer Processing of the SDP Answer 10.3.2.4. Offerer Processing of the SDP Answer
When the offerer receives an answer, if the answerer accepts the When the offerer receives an answer, if the answerer accepts the
usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux' usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux'
attribute to each bundled "m=" line in the answer [Section 10.3.2.3], attribute to each bundled "m=" line in the answer [Section 10.3.2.3],
the answerer follows the procedures for RTP/RTCP multiplexing defined the answerer follows the procedures for RTP/RTCP multiplexing defined
in [RFC5761]. in [RFC5761]. The offerer will use the port number of the answerer
BUNDLE address for sending RTP and RTCP packets associated with each
bundled "m=" line towards the answerer.
If the answerer does not accept the usage of RTP/RTCP multiplexing If the answerer does not accept the usage of RTP/RTCP multiplexing
[Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP
and RTCP. and RTCP. The offerer will, based on the port number of the answerer
BUNDLE address, use the next higher (odd) destination port number
[RFC3550] for sending RTCP packets associated with a bundled "m="
line towards the answerer.
10.3.2.5. Modifying the Session 10.3.2.5. Modifying the Session
When an offerer generates a subsequent offer, if it wants to When an offerer generates a subsequent offer, if it wants to
negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if
it wants to continue usage of RTP/RTCP multiplexing (negotiated in a it wants to continue usage of RTP/RTCP multiplexing (negotiated in a
previous offer/answer transaction), it MUST assign SDP 'rtcp-mux' and previous offer/answer transaction), it MUST assign SDP 'rtcp-mux' and
'rtcp' attributes to each bundled "m=" line (including bundle-only 'rtcp' attributes to each bundled "m=" line (including bundle-only
"m=" lines, and a bundled "m=" line that the offerer wants to add to "m=" lines, and a bundled "m=" line that the offerer wants to add to
the BUNDLE group), unless the offerer wants to disable or remove the the BUNDLE group), unless the offerer wants to disable or remove the
skipping to change at page 27, line 34 skipping to change at page 27, line 41
Purpose: Request a media description to be accepted Purpose: Request a media description to be accepted
in the answer only if kept within a BUNDLE group in the answer only if kept within a BUNDLE group
by the answerer by the answerer
Appropriate values: N/A Appropriate values: N/A
Contact name: Christer Holmberg Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com Contact e-mail: christer.holmberg@ericsson.com
15. Security Considerations 15. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. to the BUNDLE extension. Bundle does not change which information
flows over the network but only changes which ports that information
if flowing on and thus has very little impact on the security of the
RTP sessions.
When the BUNDLE extension is used a single set of security When the BUNDLE extension is used, a single set of security
credentials might be used for all media streams associated with a credentials might be used for all media streams associated with a
BUNDLE group. If the security credentials are compromised, an BUNDLE group.
attacker will have access to all media content.
When the BUNDLE extension is used, the number of SSRC values within a
single RTP session increases, which increases the risk of SSRC
collision. [RFC4568] describes how SSRC collision may weaken SRTP
and SRTCP encryption in certain situations.
16. Examples 16. Examples
16.1. Example: Bundle Address Selection 16.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o 1. An offer, in which the offerer assigns a unique address to o 1. An offer, in which the offerer assigns a unique address to
each bundled "m=" line within the BUNDLE group. each bundled "m=" line within the BUNDLE group.
skipping to change at page 36, line 30 skipping to change at page 37, line 30
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thomson and Flemming Andreasen for Thanks to Paul Kyzivat, Martin Thomson and Flemming Andreasen for
taking the time to read the text along the way, and providing useful taking the time to read the text along the way, and providing useful
feedback. feedback.
19. Change Log 19. 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-11
o Editorial corrections based on comments from Harald Alvestrand.
o Editorial corrections based on comments from Cullen Jennings.
o Reference update (RFC 7160).
o Clarification about RTCP packet sending when RTP/RTCP multiplexing
is not used (http://www.ietf.org/mail-archive/web/mmusic/current/
msg13765.html).
o Additional text added to the Security Considerations.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10
o SDP bundle-only attribute added to IANA Considerations. o SDP bundle-only attribute added to IANA Considerations.
o SDES item and RTP header extension added to Abstract and o SDES item and RTP header extension added to Abstract and
Introduction. Introduction.
o Modification to text updating section 8.2 of RFC 3264. o Modification to text updating section 8.2 of RFC 3264.
o Reference corrections. o Reference corrections.
skipping to change at page 40, line 20 skipping to change at page 41, line 35
20.2. Informative References 20.2. Informative References
[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, July 2003. Applications", STD 64, RFC 3550, July 2003.
[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, October in Session Description Protocol (SDP)", RFC 3605, October
2003. 2003.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[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, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[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, June 2009. (SDP)", RFC 5576, June 2009.
[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, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014.
[I-D.ietf-mmusic-trickle-ice] [I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf- Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-01 (work in progress), February 2014. mmusic-trickle-ice-01 (work in progress), February 2014.
Appendix A. Design Considerations Appendix A. Design Considerations
A.1. General A.1. General
 End of changes. 43 change blocks. 
99 lines changed or deleted 138 lines changed or added

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