draft-ietf-mmusic-sdp-bundle-negotiation-07.txt   draft-ietf-mmusic-sdp-bundle-negotiation-08.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 25, 2014 C. Jennings Expires: February 23, 2015 C. Jennings
Cisco Cisco
April 23, 2014 August 22, 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-07.txt draft-ietf-mmusic-sdp-bundle-negotiation-08.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework extension, This specification defines a new SDP Grouping Framework extension,
"BUNDLE", that can be used with the Session Description Protocol "BUNDLE", that can be used with the Session Description Protocol
(SDP) Offer/Answer mechanism to negotiate the usage of bundled media, (SDP) Offer/Answer mechanism to negotiate the usage of bundled media,
which refers to the usage of a single 5-tuple for sending and which refers to the usage of a single 5-tuple for sending and
receiving media associated with multiple SDP media descriptions ("m=" receiving media associated with multiple SDP media descriptions ("m="
lines). lines).
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 25, 2014. This Internet-Draft will expire on February 23, 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 2, line 49 skipping to change at page 2, line 49
6.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 13 6.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 13
6.2.3. Offerer Processing of the SDP Answer . . . . . . . . 14 6.2.3. Offerer Processing of the SDP Answer . . . . . . . . 14
6.2.4. Modifying the Session . . . . . . . . . . . . . . . . 14 6.2.4. Modifying the Session . . . . . . . . . . . . . . . . 14
7. Protocol Identification . . . . . . . . . . . . . . . . . . . 15 7. Protocol Identification . . . . . . . . . . . . . . . . . . . 15
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 15 7.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 15
8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 15 8.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 15
8.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 16 8.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 16
8.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 16 8.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 16
8.2. Associating RTP Packets With Correct SDP Media 8.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . . 16 Description . . . . . . . . . . . . . . . . . . . . . . . 16
8.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 17 8.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 17
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 17 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 17
8.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . 18 8.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . 18
9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 20 9.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 20
9.2.1. Generating the Initial SDP Offer . . . . . . . . . . 20 9.2.1. Generating the Initial SDP Offer . . . . . . . . . . 20
9.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 20 9.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 20
9.2.3. Offerer Processing of the SDP Answer . . . . . . . . 20 9.2.3. Offerer Processing of the SDP Answer . . . . . . . . 20
9.2.4. Modifying the Session . . . . . . . . . . . . . . . . 20 9.2.4. Modifying the Session . . . . . . . . . . . . . . . . 20
9.2.5. Keep-alives . . . . . . . . . . . . . . . . . . . . . 20 9.2.5. Keep-alives . . . . . . . . . . . . . . . . . . . . . 20
10. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 21 10. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 20
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 20
10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 21 10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 21
10.3. New text replacing section 5.1 (2nd paragraph) of RFC 10.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 22 10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 21
10.5. New text replacing section 8.2 (2nd paragraph) of RFC 10.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 22 10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 22
10.7. New text replacing section 8.4 (6th paragraph) of RFC 10.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. RTP/RTCP extensions for mid value transport . . . . . . . . . 22
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Example: Bundle Address Selection . . . . . . . . . . . 23 11.2. RTP MID SDES Item . . . . . . . . . . . . . . . . . . . 23
12.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 24 11.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 24
12.3. Example: Offerer Adds A Media Description To A BUNDLE 11.4. IANA Considerations . . . . . . . . . . . . . . . . . . 24
Group . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12.4. Example: Offerer Moves A Media Description Out Of A 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Example: Bundle Address Selection . . . . . . . . . . . 25
12.5. Example: Offerer Disables A Media Description Within A 13.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 26
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 30 13.3. Example: Offerer Adds A Media Description To A BUNDLE
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 Group . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 13.4. Example: Offerer Moves A Media Description Out Of A
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.5. Example: Offerer Disables A Media Description Within A
16.1. Normative References . . . . . . . . . . . . . . . . . . 34 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . 34 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Design Considerations . . . . . . . . . . . . . . . 35 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35 16. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 36 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.3. Usage of port number value zero . . . . . . . . . . . . . 37 17.1. Normative References . . . . . . . . . . . . . . . . . . 35
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 37 17.2. Informative References . . . . . . . . . . . . . . . . . 36
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 38 Appendix A. Design Considerations . . . . . . . . . . . . . . . 36
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 38 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 39 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 A.3. Usage of port number value zero . . . . . . . . . . . . . 39
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 39
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 40
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 40
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and 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=" receiving media associated with multiple SDP media descriptions ("m="
lines) has been identified. This would e.g. allow the usage of a lines) has been identified. This would e.g. allow the usage of a
single set of Interactive Connectivity Establishment (ICE) [RFC5245] single set of Interactive Connectivity Establishment (ICE) [RFC5245]
candidates for multiple media descriptions. Normally different media candidates for multiple media descriptions. Normally different media
types (audio, video etc) will be described using different media types (audio, video etc) will be described using different media
descriptions. descriptions.
skipping to change at page 8, line 20 skipping to change at page 8, line 20
BUNDLE group, the offerer MUST in the SDP offer assign a unique BUNDLE group, the offerer MUST in the SDP offer assign a unique
address to each "m=" line with a non-zero port value, following the address to each "m=" line with a non-zero port value, following the
procedures in [RFC3264]. procedures in [RFC3264].
The offerer MUST in the SDP offer insert an SDP session level The offerer MUST in the SDP offer insert an SDP session level
'group:BUNDLE' attribute, associated with the BUNDLE group, and 'group:BUNDLE' attribute, associated with the BUNDLE group, and
assign an SDP 'mid' attribute [RFC5888] to each "m=" line that the assign an SDP 'mid' attribute [RFC5888] to each "m=" line that the
offerer wants to be within the BUNDLE group, and place the 'mid' offerer wants to be within the BUNDLE group, and place the 'mid'
attribute value in the 'group:BUNDLE' attribute mid list. attribute value in the 'group:BUNDLE' attribute mid list.
[Section 12.1] shows an example of an initial SDP offer. [Section 13.1] shows an example of an initial SDP offer.
5.2.3.2. Request offerer BUNDLE address selection 5.2.3.2. Request offerer BUNDLE address selection
When an offerer generates an initial SDP offer, in order to create a When an offerer generates an initial SDP offer, in order to create a
BUNDLE group, the offerer MUST in the SDP offer indicate which unique BUNDLE group, the offerer MUST in the SDP offer indicate which unique
address, associated with one of the "m=" lines that the offerer wants address, associated with one of the "m=" lines that the offerer wants
to be within the BUNDLE group, that the offerer wants the answerer to to be within the BUNDLE group, that the offerer wants the answerer to
select as the offerer BUNDLE address [Section 5.2.4.2]. In the SDP select as the offerer BUNDLE address [Section 5.2.4.2]. In the SDP
offer, the offerer BUNDLE mid value represents that address. offer, the offerer BUNDLE mid value represents that address.
skipping to change at page 9, line 35 skipping to change at page 9, line 35
address. address.
If all of the criteria is not fulfilled, the answerer MUST select the If all of the criteria is not fulfilled, the answerer MUST select the
next mid value in the mid list, and perform the same criteria check next mid value in the mid list, and perform the same criteria check
for the "m=" line associated with the mid value. for the "m=" line associated with the mid value.
In the SDP answer, the answerer selected BUNDLE mid value represents In the SDP answer, the answerer selected BUNDLE mid value represents
the "m=" line which address (in the associated SDP offer) the the "m=" line which address (in the associated SDP offer) the
answerer has selected as the offerer BUNDLE address. answerer has selected as the offerer BUNDLE address.
[Section 12.1] shows an example of an offerer BUNDLE address [Section 13.1] shows an example of an offerer BUNDLE address
selection. selection.
5.2.4.3. Answerer Selection of Answerer BUNDLE Address 5.2.4.3. Answerer Selection of Answerer BUNDLE Address
When an answerer generates an SDP answer, the answerer MUST select a When an answerer generates an SDP answer, the answerer MUST select a
BUNDLE address for itself, referred to as the answerer BUNDLE BUNDLE address for itself, referred to as the answerer BUNDLE
address, and in the SDP answer assign the answerer BUNDLE address to address, and in the SDP answer assign the answerer BUNDLE address to
each "m=" line within the created BUNDLE group. each "m=" line within the created BUNDLE group.
The answerer MUST NOT in the SDP answer assign the answerer BUNDLE The answerer MUST NOT in the SDP answer assign the answerer BUNDLE
address to an "m=" line that is not associated with the BUNDLE group, address to an "m=" line that is not associated with the BUNDLE group,
or to an "m=" line that is associated with another BUNDLE group. or to an "m=" line that is associated with another BUNDLE group.
The answerer is allowed to select a new answerer BUNDLE address in The answerer is allowed to select a new answerer BUNDLE address in
every SDP answer that the answerer generates. every SDP answer that the answerer generates.
[Section 12.1] shows an example of an answerer BUNDLE address [Section 13.1] shows an example of an answerer BUNDLE address
selection. selection.
5.2.4.4. Moving A Media Description Out Of A BUNDLE Group 5.2.4.4. Moving A Media Description Out Of A BUNDLE Group
When an answerer generates an SDP answer, in which the answerer moves When an answerer generates an SDP answer, in which the answerer moves
a bundled "m=" line out a BUNDLE group, the answerer assigns an a bundled "m=" line out a BUNDLE group, the answerer assigns an
address to the moved "m=" line based on the type of address that the address to the moved "m=" line based on the type of address that the
offerer in the associated SDP offer assigned to the "m=" line. offerer in the associated SDP offer assigned to the "m=" line.
o If the offerer in the SDP offer has assigned a shared address o If the offerer in the SDP offer has assigned a shared address
skipping to change at page 11, line 37 skipping to change at page 11, line 37
necessity to in the BAS offer modify SDP parameters that could get necessity to in the BAS offer modify SDP parameters that could get
the answerer to reject the BAS offer. Disabling "m=" lines, or the answerer to reject the BAS offer. Disabling "m=" lines, or
reducing the number of codecs, in a BAS offer is considered to have a reducing the number of codecs, in a BAS offer is considered to have a
low risk of being rejected. low risk of being rejected.
NOTE: The main purpose of the BAS offer is to ensure that NOTE: The main purpose of the BAS offer is to ensure that
intermediaries, that might not support the BUNDLE mechanism, have intermediaries, that might not support the BUNDLE mechanism, have
correct information regarding the address is going to be used to correct information regarding the address is going to be used to
transport the bundled media. transport the bundled media.
[Section 12.1] shows an example where an offerer sends a BAS offer. [Section 13.1] shows an example where an offerer sends a BAS offer.
5.2.6. Modifying the Session 5.2.6. Modifying the Session
5.2.6.1. General 5.2.6.1. General
When an offerer generates a subsequent SDP offer, the offerer MUST in When an offerer generates a subsequent SDP offer, the offerer MUST in
the SDP offer assign the previously selected offerer BUNDLE address the SDP offer assign the previously selected offerer BUNDLE address
[Section 5.2.4.2] to each bundled "m=" line (including any bundle- [Section 5.2.4.2] to each bundled "m=" line (including any bundle-
only "m=" line), unless the offerer in the SDP offer moves the "m=" only "m=" line), unless the offerer in the SDP offer moves the "m="
line out of the BUNDLE group [Section 5.2.6.3], or disables the "m=" line out of the BUNDLE group [Section 5.2.6.3], or disables the "m="
skipping to change at page 12, line 30 skipping to change at page 12, line 30
offer an address (unique or previously selected offerer BUNDLE offer an address (unique or previously selected offerer BUNDLE
address) to the "m=" line, assigns an SDP 'mid' attribute to the "m=" address) to the "m=" line, assigns an SDP 'mid' attribute to the "m="
line, and places the mid value in the SDP 'group:BUNDLE' attribute line, and places the mid value in the SDP 'group:BUNDLE' attribute
mid list associated with the BUNDLE group [Section 5.2.3.2]. mid list associated with the BUNDLE group [Section 5.2.3.2].
NOTE: If the offerer wants the answerer to select the address NOTE: If the offerer wants the answerer to select the address
associated with the added "m=" as the offerer BUNDLE address, the associated with the added "m=" as the offerer BUNDLE address, the
offerer suggested BUNDLE mid MUST represent the added "m=" line offerer suggested BUNDLE mid MUST represent the added "m=" line
[Section 5.2.3.2]. [Section 5.2.3.2].
[Section 12.3] shows an example where an offerer sends an SDP offer [Section 13.3] shows an example where an offerer sends an SDP offer
in order to add an "m=" line to a BUNDLE group. in order to add an "m=" line to a BUNDLE group.
5.2.6.3. Moving A Media Description Out Of A BUNDLE Group 5.2.6.3. Moving A Media Description Out Of A BUNDLE Group
When an offerer generates an SDP offer, in which the offerer wants to When an offerer generates an SDP offer, in which the offerer wants to
move a bundled "m=" line out of a BUNDLE group, the offerer MUST move a bundled "m=" line out of a BUNDLE group, the offerer MUST
assign a unique address to the "m=" line. In addition, the offerer assign a unique address to the "m=" line. In addition, the offerer
MUST NOT place a mid value associated with the "m=" line in the SDP MUST NOT place a mid value associated with the "m=" line in the SDP
'group:BUNDLE' attribute mid list associated with the BUNDLE group. 'group:BUNDLE' attribute mid list associated with the BUNDLE group.
NOTE: The offerer MAY keep a previously assigned SDP 'mid' attribute NOTE: The offerer MAY keep a previously assigned SDP 'mid' attribute
in an "m=" line that it wants to move out of a BUNDLE group, e.g. if in an "m=" line that it wants to move out of a BUNDLE group, e.g. if
the mid value is used for some other SDP grouping extension than the mid value is used for some other SDP grouping extension than
BUNDLE. BUNDLE.
[Section 12.4] shows an example where an offerer sends an SDP offer [Section 13.4] shows an example where an offerer sends an SDP offer
in order to move an "m=" line out of a BUNDLE group. in order to move an "m=" line out of a BUNDLE group.
5.2.6.4. Disabling A Media Description In A BUNDLE Group 5.2.6.4. Disabling A Media Description In A BUNDLE Group
When an offerer generates an SDP offer, in which the offerer wants to When an offerer generates an SDP offer, in which the offerer wants to
disable a bundled "m=" line, the offerer MUST assign an address with disable a bundled "m=" line, the offerer MUST assign an address with
a zero port alue to the "m=" line, following the procedures in a zero port alue to the "m=" line, following the procedures in
[RFC4566]. In addition, the offerer MUST NOT place a mid value [RFC4566]. In addition, the offerer MUST NOT place a mid value
associated with the "m=" line in the SDP 'group:BUNDLE' attribute mid associated with the "m=" line in the SDP 'group:BUNDLE' attribute mid
list associated with the BUNDLE group. list associated with the BUNDLE group.
NOTE: The offerer MAY assign an SDP 'mid' attribute to an "m=" line NOTE: The offerer MAY assign an SDP 'mid' attribute to an "m=" line
that it wants to disable, e.g. if the mid value is used for some that it wants to disable, e.g. if the mid value is used for some
other SDP grouping extension than BUNDLE. other SDP grouping extension than BUNDLE.
[Section 12.5] shows an example where an offerer sends an SDP offer [Section 13.5] shows an example where an offerer sends an SDP offer
in order to disable an "m=" line within a BUNDLE group. in order to disable an "m=" line within a BUNDLE group.
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'. An offerer can in an SDP offer assign a 'bundle-only' 'bundle-only'. An offerer can in an SDP offer assign a 'bundle-only'
"m=" line to a bundled "m=" line (including an "m=" line that the "m=" line to a bundled "m=" line (including an "m=" line that the
offerer wants to add to the BUNDLE group [Section 5.2.6.2]), in order offerer wants to add to the BUNDLE group [Section 5.2.6.2]), in order
skipping to change at page 16, line 21 skipping to change at page 16, line 21
lines representing RTP-based media in a bundle group will share a lines representing RTP-based media in a bundle group will share a
single SSRC numbering space [RFC3550]. single SSRC numbering space [RFC3550].
The following rules and restrictions apply for a single RTP session: The following rules and restrictions apply for a single RTP session:
o A specific payload type value can be used in multiple bundled "m=" o A specific payload type value can be used in multiple bundled "m="
lines if each codec associated with the payload type number shares lines if each codec associated with the payload type number shares
an identical codec configuration [Section 8.1.2]. an identical codec configuration [Section 8.1.2].
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 originates from different bundled "m=" lines. that originates 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 fails to function. Even if done in with time overlap RTP and RTCP fails 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 [ref
to draft-ietf-avtext-multiple-clock-rates]. to draft-ietf-avtext-multiple-clock-rates].
skipping to change at page 16, line 45 skipping to change at page 16, line 45
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.nandakumar-mmusic-sdp-mux-attributes] lists SDP packetization. [I-D.nandakumar-mmusic-sdp-mux-attributes] lists SDP
attributes, which attribute values must be identical for all codecs attributes, which attribute values must be identical for all codecs
that use the same payload type value. that use the same payload type value.
8.2. Associating RTP Packets With Correct SDP Media Description 8.2. Associating RTP/RTCP Packets With Correct SDP Media Description
In general, there are multiple mechanisms that can be used by an In general, there are multiple mechanisms that can be used by an
endpoint in order to associate received RTP packets with the bundled endpoint in order to associate received RTP/RTCP packets with the
"m=" line representing the RTP packets. Such mechanisms include bundled "m=" line representing the RTP packets. Such mechanisms
using the local address:port combination on which the RTP packets are include using the local address:port combination on which the RTP
received, the payload type value carried inside the RTP packets, the packets are received, the payload type value carried inside the RTP
SSRC values carried inside the RTP packets, and other "m=" line packets, the SSRC values carried inside the RTP packets, and other
specific information carried inside the RTP packets. "m=" line specific information carried inside the RTP packets.
As all RTP packets associated with a BUNDLE group are sent and As all RTP/RTCP packets associated with a BUNDLE group are sent and
received using the same 5-tuple, the local address:port combination received using the same 5-tuple, the local address:port combination
cannot be used to associate received RTP packets with the correct cannot be used to associate received RTP packets with the correct
"m=" line. "m=" line.
As described in [Section 8.1.2], the same payload type value might be As described in [Section 8.1.2], the same payload type value might be
used inside RTP packets described by multiple "m=" lines. In such used inside RTP packets described by multiple "m=" lines. In such
cases, the payload type value cannot be used to associate received cases, the payload type value cannot be used to associate received
RTP packets with the correct "m=" line. RTP packets with the correct "m=" line.
An offerer and answerer can in an SDP offer and answer inform each An offerer and answerer can in an SDP offer and answer inform each
other which SSRC values they will use inside sent RTP packets by, by other which SSRC values they will use inside sent RTP/RTCP packets
assigning an SDP 'ssrc' attribute [RFC5576] to each bundled "m=" line by, by assigning an SDP 'ssrc' attribute [RFC5576] to each bundled
which contains a payload type value that is also used inside another "m=" line which contains a payload type value that is also used
bundled "m=" line. As the SSRC values will be carried inside the RTP inside another bundled "m=" line. As the SSRC values will be carried
packets, the offerer and answerer can then use that information to inside the RTP/RTCP packets, the offerer and answerer can then use
associate received RTP packets with the correct "m=" line. However, that information to associate received RTP packets with the correct
an offerer will not know which SSRC values the answerer will use "m=" line. However, an offerer will not know which SSRC values the
until it has received the SDP answer providing that information. Due answerer will use until it has received the SDP answer providing that
to this, before the offerer has received the SDP answer, the offerer information. Due to this, before the offerer has received the SDP
will not be able to associate received RTP packets with the correct answer, the offerer will not be able to associate received RTP/RTCP
"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 packets with the correct "m=" line, the offerer and received RTP and RTCP packets with the correct "m=" line, an offerer
answerer MUST in an SDP offer and answer assign an SDP "receiver-id" and answerer using the BUNDLE mechanism MUST use the mechanism
attribute [receiver-id-reference-to-be-added] to each bundled "m=" defined in Section 11, where the remote endpoint inserts the SDP
line which contains a payload type value that is also used inside 'mid' attribute value of an "m=" line in RTP and RTCP packets
another bundled "m=" line. If an answerer accepts such "m=" line, associated with that "m=" line.
and keeps it within the BNDLE group, the answerer MUST insert the
'receiver-id' attribute value in RTP packets, associated with the
"m=" line, sent towards the offerer.
OPEN ISSUE: We need a mechanism that implements the 'receiver-id'
mechanism and the associated SDP attribute.
8.3. RTP/RTCP Multiplexing 8.3. RTP/RTCP Multiplexing
8.3.1. General 8.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
multiplexing for the RTP based media associated with the BUNDLE group multiplexing for the RTP based media associated with the BUNDLE group
[RFC5761]. [RFC5761].
skipping to change at page 18, line 48 skipping to change at page 18, line 45
multiplexing [RFC5761] within a BUNDLE group, the answerer MUST in multiplexing [RFC5761] within a BUNDLE group, the answerer MUST in
the SDP answer either accept or reject usage of RTP/RTCP the SDP answer either accept or reject usage of RTP/RTCP
multiplexing. multiplexing.
If the answerer accepts usage of RTP/RTCP multiplexing within the If the answerer accepts usage of RTP/RTCP multiplexing within the
BUNDLE group, the answerer MUST in the SDP answer assign an SDP BUNDLE group, the answerer MUST in the SDP answer assign an SDP
'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST 'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST
NOT in the SDP answer assign an SDP 'rtcp' attribute to any bundled NOT in the SDP answer assign an SDP 'rtcp' attribute to any bundled
"m=" line. "m=" line.
OPEN ISSUE: Do we want to include the SDP 'rtcp' attribute also in
the SDP answer, eventhough it is not needed?
If the answerer rejects usage of RTP/RTCP multiplexing within the If the answerer rejects usage of RTP/RTCP multiplexing within the
BUNDLE group, the answerer MUST NOT in the SDP answer assign an SDP BUNDLE group, the answerer MUST NOT in the SDP answer assign an SDP
'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=" line. 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=" line.
8.3.2.3.2. Generating the SDP Answer to a Subsequent SDP Offer 8.3.2.3.2. Generating the SDP Answer to a Subsequent SDP Offer
When the answerer generates an SDP answer to a subsequent SDP offer, When the answerer generates an SDP answer to a subsequent SDP offer,
if the offerer in the associated SDP offer indicated support of RTP/ if the offerer in the associated SDP offer indicated support of RTP/
RTCP multiplexing [RFC5761] within a BUNDLE group, the answerer MUST RTCP multiplexing [RFC5761] within a BUNDLE group, the answerer MUST
in the SDP answer assign an SDP 'rtcp-mux' attribute and SDP 'rtcp' in the SDP answer assign an SDP 'rtcp-mux' attribute and SDP 'rtcp'
skipping to change at page 23, line 5 skipping to change at page 22, line 43
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, if it would specify that the stream has been number MUST NOT be zero, if it would specify that the stream has been
disabled. However, an extension mechanism might specify different disabled. However, an extension mechanism might specify different
semantics of the zero port number usage. An agent MUST be capable of semantics of the zero port number usage. An agent MUST be capable of
receiving SDP with a connection address of 0.0.0.0, in which case it receiving SDP with a connection address of 0.0.0.0, in which case it
means that neither RTP nor RTCP should be sent to the peer. means that neither RTP nor RTCP should be sent to the peer.
11. Security Considerations 11. RTP/RTCP extensions for mid value transport
11.1. General
SDP Offerers and Answerers [RFC3264] can assign values, mid values,
to SDP Media Descriptions (m= lines) within SDP Offers and Answers,
using the procedures in [RFC5888]. Each mid value uniquely
references an m= line.
This section defines a new RTP SDES item [RFC3550], 'MID', which is
used to carry mid values within RTCP SDES packets. This section also
defines a new RTP header extension [RFC5285], which can be used to
carry the mid value in RTP packets.
The SDES item and RTP header extension makes is possible for a
receiver to associate received RTCP- and RTP packets with a specific
m= line, to which the receiver has assigned a mid value, even if
those m= lines are part of the same RTP session. The endpoint
informs the remote endpoint about the mid values using the procedures
in [RFC5888], and the remote endpoint then inserts the mid values in
RTCP- and RTP packets sent towards the other endpoint.
NOTE: This text above defines how the mid value is carried in SDP
Offers and Answers. The usage of other signalling protocols for
carrying the mid value is not prevented, but the usage of such
protocols is outside the scope of this document.
The RTP MID SDES item SHOULD be sent in the first few RTCP packets
sent on joining the session, and SHOULD be sent regularly thereafter.
The exact number of RTCP packets in which this SDES item is sent is
intentionally not specified here, as it will depend on the expected
packet loss rate, the RTCP reporting interval, and the allowable
overhead.
The RTP MID header extension SHOULD be included in some RTP packets
at the start of the session and whenever the SSRC changes. It might
also be useful to include the header extension in RTP packets that
comprise random access points in the media (e.g., with video
I-frames). The exact number of RTP packets in which this header
extension is sent is intentionally not specified here, as it will
depend on expected packet loss rate and loss patterns, the overhead
the application can tolerate, and the importance of immediate receipt
of the mid value.
For robustness purpose, endpoints need to be prepared for situations
where the mid value is delayed, and SHOULD NOT terminate sessions in
such cases, as the mid value is likely to arrive soon.
11.2. RTP MID SDES Item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | mid value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The mid value payload is UTF-8 encoded, as in SDP.
11.3. RTP MID Header Extension
The payload, containing the mid value, of the RTP MID header
extension element can be encoded using either the one-byte or two-
byte header [RFC5285]. The mid value payload is UTF-8 encoded, as in
SDP.
11.4. IANA Considerations
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.]
This document adds the MID SDES item to the IANA "RTP SDES item
types" registry as follows:
Value: TBD
Abbrev.: MID
Name: Media Identification
Reference: RFCXXXX
This document defines a new extension URI in the RTP Compact Header
Extensions subregistry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification
Contact: christer.holmberg@ericsson.com
Reference: RFCXXXX
12. Security Considerations
This specification does not significantly change the security This specification does not significantly change the security
considerations of SDP which can be found in Section X of TBD. considerations of SDP which can be found in Section X of TBD.
TODO: Think carefully about security analysis of reuse of same SDES 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 key on multiple "m=" lines when the far end does not use BUNDLE and
warn developers of any risks. warn developers of any risks.
12. Examples 13. Examples
12.1. Example: Bundle Address Selection 13.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer assigns a unique address to o 1. An SDP 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.
o 2. An SDP answer, in which the answerer selects the offerer o 2. An SDP answer, in which the answerer selects the offerer
BUNDLE address, and in which selects its own BUNDLE address (the BUNDLE address, and in which selects its own BUNDLE address (the
answerer BUNDLE address) and assigns it each bundled "m=" line answerer BUNDLE address) and assigns it each bundled "m=" line
within the BUNDLE group. within the BUNDLE group.
skipping to change at page 24, line 42 skipping to change at page 26, line 32
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
12.2. Example: Bundle Mechanism Rejected 13.2. Example: Bundle Mechanism Rejected
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer assigns a unique address to o 1. An SDP 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.
o 2. An SDP answer, in which the answerer rejects the offered o 2. An SDP answer, in which the answerer rejects the offered
BUNDLE group, and assigns a unique addresses to each "m=" line BUNDLE group, and assigns a unique addresses to each "m=" line
(following normal RFC 3264 procedures). (following normal RFC 3264 procedures).
skipping to change at page 25, line 43 skipping to change at page 27, line 39
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
12.3. Example: Offerer Adds A Media Description To A BUNDLE Group 13.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer adds a new "m=" line, o 1. An SDP offer, in which the offerer adds a new "m=" line,
represented by the "zen" mid value, to a previously negotiated represented by the "zen" mid value, to a previously negotiated
BUNDLE group, assigns a unique address to the added "m=" line, and BUNDLE group, assigns a unique address to the added "m=" line, and
assigns the previously selected offerer BUNDLE address to each of assigns the previously selected offerer BUNDLE address to each of
the other bundled "m=" lines within the BUNDLE group. the other bundled "m=" lines within the BUNDLE group.
o 2. An SDP answer, in which the answerer assigns the answerer o 2. An SDP answer, in which the answerer assigns the answerer
skipping to change at page 27, line 38 skipping to change at page 29, line 34
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 10000 RTP/AVP 66 m=video 10000 RTP/AVP 66
a=mid:zen a=mid:zen
b=AS:1000 b=AS:1000
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
12.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 13.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer moves a bundled "m=" line o 1. An SDP offer, in which the offerer moves a bundled "m=" line
out of a BUNDLE group, assigns a unique address to the moved "m=" out of a BUNDLE group, assigns a unique address to the moved "m="
line, and assigns the offerer BUNDLE address to each other bundled line, and assigns the offerer BUNDLE address to each other bundled
"m=" line within the BUNDLE group. "m=" line within the BUNDLE group.
o 2. An SDP answer, in which the answerer moves the "m=" line out o 2. An SDP answer, in which the answerer moves the "m=" line out
of the BUNDLE group, assigns unique address to the moved "m=" of the BUNDLE group, assigns unique address to the moved "m="
skipping to change at page 30, line 5 skipping to change at page 31, line 5
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
12.5. Example: Offerer Disables A Media Description Within A BUNDLE 13.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer disables a bundled "m=" o 1. An SDP offer, in which the offerer disables a bundled "m="
line within BUNDLE group, assigns a zero port number the disabled line within BUNDLE group, assigns a zero port number the disabled
"m=" line, and assigns the offerer BUNDLE address to each of the "m=" line, and assigns the offerer BUNDLE address to each of the
other bundled "m=" lines within the BUNDLE group. other bundled "m=" lines within the BUNDLE group.
o 2. An SDP answer, in which the answerer moves the disabled "m=" o 2. An SDP answer, in which the answerer moves the disabled "m="
skipping to change at page 32, line 5 skipping to change at page 33, line 5
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
13. IANA Considerations 14. IANA Considerations
This document requests IANA to register the new SDP Grouping semantic This document requests IANA to register the new SDP Grouping semantic
extension called BUNDLE. extension called BUNDLE.
14. Acknowledgements 15. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on a similar alternatives proposed by Harald Alvestrand and is based on a similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE mechanism described in this document is Cullen Jennings. The BUNDLE mechanism described in this document is
based on the different alternative proposals, and text (e.g. SDP based on the different alternative proposals, and text (e.g. SDP
examples) have been borrowed (and, in some cases, modified) from examples) have been borrowed (and, in some cases, modified) from
those alternative proposals. those alternative proposals.
The SDP examples are also modified versions from the ones in the The SDP examples are also modified versions from the ones in the
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat and Martin Thompson for taking the the time to Thanks to Paul Kyzivat and Martin Thompson for taking the the time to
read the text along the way, and providing useful feedback. read the text along the way, and providing useful feedback.
15. Change Log 16. 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-07
o OPEN ISSUE regarding Receiver-ID closed.
o - RTP MID SDES Item.
o - RTP MID Header Extension.
o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in SDP
answers closed.
o - Indicating that, when rtcp-mux is used, the answerer MUST NOT
include an 'rtcp' attribute in the answer, based on the procedures
in section 5.1.3 of RFC 5761.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06
o Draft title changed. o Draft title changed.
o Added "SDP" to section names containing "Offer" or "Answer". o Added "SDP" to section names containing "Offer" or "Answer".
o Editorial fixes based on comments from Paul Kyzivat (http:// o Editorial fixes based on comments from Paul Kyzivat
www.ietf.org/mail-archive/web/mmusic/current/msg13314.html). (http://www.ietf.org/mail-archive/web/mmusic/current/
msg13314.html).
o Editorial fixed based on comments from Colin Perkins (http:// o Editorial fixed based on comments from Colin Perkins
www.ietf.org/mail-archive/web/mmusic/current/msg13318.html). (http://www.ietf.org/mail-archive/web/mmusic/current/
msg13318.html).
o - Removed text about extending BUNDLE to allow multiple RTP o - Removed text about extending BUNDLE to allow multiple RTP
sessions within a BUNDLE group. sessions within a BUNDLE group.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05
o Major re-structure of SDP Offer/Answer sections, to align with RFC o Major re-structure of SDP Offer/Answer sections, to align with RFC
3264 structure. 3264 structure.
o Additional definitions added. o Additional definitions added.
skipping to change at page 33, line 33 skipping to change at page 34, line 49
o Connection data nettype/addrtype restrictions added. o Connection data nettype/addrtype restrictions added.
o RFC 3264 update section added. o RFC 3264 update section added.
o Indicating that a specific payload type value can be used in o Indicating that a specific payload type value can be used in
multiple "m=" lines, if the value represents the same codec multiple "m=" lines, if the value represents the same codec
configuration in each "m=" line. configuration in each "m=" line.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04
o Updated Offerer procedures (http://www.ietf.org/mail-archive/web/ o Updated Offerer procedures (http://www.ietf.org/mail-
mmusic/current/msg12293.html). archive/web/mmusic/current/msg12293.html).
o Updated Answerer procedures (http://www.ietf.org/mail-archive/web/ o Updated Answerer procedures (http://www.ietf.org/mail-
mmusic/current/msg12333.html). archive/web/mmusic/current/msg12333.html).
o Usage of SDP 'bundle-only' attribute added. o Usage of SDP 'bundle-only' attribute added.
o Reference to Trickle ICE document added. o Reference to Trickle ICE document added.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02
o Mechanism modified, to be based on usage of SDP Offers with both o Mechanism modified, to be based on usage of SDP Offers with both
different and identical port number values, depending on whether different and identical port number values, depending on whether
it is known if the remote endpoint supports the extension. it is known if the remote endpoint supports the extension.
skipping to change at page 34, line 22 skipping to change at page 35, line 40
o Draft name changed. o Draft name changed.
o Harald Alvestrand added as co-author. o Harald Alvestrand added as co-author.
o "Multiplex" terminology changed to "bundle". o "Multiplex" terminology changed to "bundle".
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.
16. References 17. References
16.1. Normative References 17.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[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, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[I-D.nandakumar-mmusic-sdp-mux-attributes] [I-D.nandakumar-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-01 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-01
(work in progress), February 2014. (work in progress), February 2014.
16.2. Informative References 17.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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
skipping to change at page 38, line 29 skipping to change at page 40, line 9
would tear down the call. Similarly, an SBC that did not understand 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 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 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 that generated an Offer with capabilities it does not understand is
not compliant with the specifications. not compliant with the specifications.
A.4.1. Traffic Policing A.4.1. Traffic Policing
Sometimes intermediaries do not act as B2BUA, in the sense that they Sometimes intermediaries do not act as B2BUA, in the sense that they
don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 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 however, they may use SDP information (e.g. IP address and port) in
order to control traffic gating functions, and to set traffic order to control traffic gating functions, and to set traffic
policing rules. There might be rules which will trigger a session to 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 be terminated in case media is not sent or received on the ports
retrieved from the SDP. This typically occurs once the session is retrieved from the SDP. This typically occurs once the session is
already established and ongoing. already established and ongoing.
A.4.2. Bandwidth Allocation A.4.2. Bandwidth Allocation
Sometimes intermediaries do not act as B2BUA, in the sense that they Sometimes intermediaries do not act as B2BUA, in the sense that they
don't modify SDP bodies, nor do they terminate SIP dialogs. Still, don't modify SDP bodies, nor do they terminate SIP dialogs. Still,
 End of changes. 44 change blocks. 
98 lines changed or deleted 206 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/