draft-ietf-mmusic-sdp-bundle-negotiation-18.txt   draft-ietf-mmusic-sdp-bundle-negotiation-19.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: September 10, 2015 C. Jennings Expires: September 27, 2015 C. Jennings
Cisco Cisco
March 9, 2015 March 26, 2015
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-18.txt draft-ietf-mmusic-sdp-bundle-negotiation-19.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 September 10, 2015. This Internet-Draft will expire on September 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 4 skipping to change at page 3, line 4
8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11 8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11
8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12
8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13
8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13 8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13
8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13 8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14
8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 14
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 15 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14
8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 15 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.5.2. Suggesting a new offerer BUNDLE address . . . . . . . 15 8.5.2. Suggesting a new offerer BUNDLE address . . . . . . . 14
8.5.3. Adding a media description to a BUNDLE group . . . . 16 8.5.3. Adding a media description to a BUNDLE group . . . . 15
8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 17 8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16
8.5.5. Disabling A Media Description In A BUNDLE Group . . . 17 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 18 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . 18
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 19
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 24 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 24 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23
12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 23
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23
12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. RTP/RTCP extensions for identification-tag transport . . . . 26 13. RTP/RTCP extensions for identification-tag transport . . . . 25
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25
13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27 13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 26
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 27
14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28
14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28
15. Security Considerations . . . . . . . . . . . . . . . . . . . 29 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28
16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Example: Bundle Address Selection . . . . . . . . . . . 30 16.1. Example: Bundle Address Selection . . . . . . . . . . . 29
16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 32 16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31
16.3. Example: Offerer Adds A Media Description To A BUNDLE 16.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 33 Group . . . . . . . . . . . . . . . . . . . . . . . . . 32
16.4. Example: Offerer Moves A Media Description Out Of A 16.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 34
16.5. Example: Offerer Disables A Media Description Within A 16.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
19.1. Normative References . . . . . . . . . . . . . . . . . . 44 19.1. Normative References . . . . . . . . . . . . . . . . . . 42
19.2. Informative References . . . . . . . . . . . . . . . . . 44 19.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Design Considerations . . . . . . . . . . . . . . . 45 Appendix A. Design Considerations . . . . . . . . . . . . . . . 44
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 46 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 44
A.3. Usage of port number value zero . . . . . . . . . . . . . 47 A.3. Usage of port number value zero . . . . . . . . . . . . . 46
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 47 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 48 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 48 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 49 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
combination (BUNDLE address) for receiving media associated with combination (BUNDLE address) for receiving media associated with
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
skipping to change at page 9, line 20 skipping to change at page 9, line 20
The "c=" line addrtype value [RFC4566] associated with a bundled "m=" The "c=" line addrtype value [RFC4566] associated with a bundled "m="
line MUST be 'IP4' or 'IP6'. The same value MUST be associated with line MUST be 'IP4' or 'IP6'. The same value MUST be associated with
each "m=" line. each "m=" line.
NOTE: Extensions to this specification can specify usage of the NOTE: Extensions to this specification can specify usage of the
BUNDLE mechanism for other nettype and addrtype values than the ones BUNDLE mechanism for other nettype and addrtype values than the ones
listed above. listed above.
7.3. Bandwidth (b=) 7.3. Bandwidth (b=)
The proposed bandwidth for a bundled "m=" line SHOULD be calculated An offerer and answerer MUST use the rules and restrictions defined
in the same way as for a non-bundled "m=" line. in [I-D.mmusic-sdp-mux-attributes] for when associating the SDP
bandwidth (b=) line with bundled "m=" lines.
The total proposed bandwidth for a BUNDLE group is the sum of the
proposed bandwidth for each bundled "m=" line.
The total proposed bandwidth for an offer or answer is the sum of the
proposed bandwidth for each "m=" line (bundled and non-bundled)
within the offer or answer.
7.4. Attributes (a=) 7.4. Attributes (a=)
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer MUST use the rules and restrictions defined
in [I-D.mmusic-sdp-mux-attributes] for when associating SDP in [I-D.mmusic-sdp-mux-attributes] for when associating SDP
attributes with bundled "m=" lines. attributes with bundled "m=" lines.
8. SDP Offer/Answer Procedures 8. SDP Offer/Answer Procedures
8.1. General 8.1. General
skipping to change at page 14, line 27 skipping to change at page 14, line 23
selected by the answerer [Section 8.3.2], as the address for each selected by the answerer [Section 8.3.2], as the address for each
bundled "m=" line. bundled "m=" line.
NOTE: As the answerer might reject one or more bundled "m=" lines, or NOTE: As the answerer might reject one or more bundled "m=" lines, or
move a bundled "m=" line out of a BUNDLE group, each bundled "m=" move a bundled "m=" line out of a BUNDLE group, each bundled "m="
line in the offer might not be indicated as bundled in the answer. line in the offer might not be indicated as bundled in the answer.
If the answer does not contain a BUNDLE group, the offerer MUST If the answer does not contain a BUNDLE group, the offerer MUST
process the answer as a normal answer. process the answer as a normal answer.
8.4.2. Bundle Address Synchronization (BAS)
When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check whether the offerer BUNDLE address,
selected by the answerer [Section 8.3.2], matches what was assigned
to each bundled "m=" line (excluding any bundled "m=" line that was
rejected, or moved out of the BUNDLE group, by the answerer) in the
associated offer. If there is a mismatch, the offerer SHOULD as soon
as possible generate a subsequent offer, in which it assigns the
offerer BUNDLE address to each bundled "m=" line. Such offer is
referred to as a Bundle Address Synchronization (BAS) offer.
A BAS offer is typically sent in the following scenarios:
o The offerer receives an answer to an initial offer, as the bundled
"m=" lines in the initial offer always contain unique addresses
[Section 8.2]; or
o The offerer receives an answer to an offer, in which a new bundled
"m=" line has been added to the BUNDLE group [Section 8.5.3], and
the offerer assigned a unique address to the bundled "m=" line in
the offer.
The offerer is allowed to modify any SDP parameter in the BAS offer.
NOTE: It is important that the BAS offer gets accepted by the
answerer. For that reason the offerer needs to consider the
necessity to modify SDP parameters in the BAS offer, in such a way
that could trigger 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 low risk of being rejected.
NOTE: The main purpose of the BAS offer is to ensure that
intermediaries, that might not support the BUNDLE extension, have
correct information regarding the address that is going to be used to
transport the bundled media.
[Section 16.1] shows an example of a BAS offer.
8.5. Modifying the Session 8.5. Modifying the Session
8.5.1. General 8.5.1. General
When an offerer generates a subsequent offer, it MUST assign the When an offerer generates a subsequent offer, it MUST assign the
previously selected offerer BUNDLE address [Section 8.3.2], to each previously selected offerer BUNDLE address [Section 8.3.2], to each
bundled "m=" line (including any bundle-only "m=" line), except if: bundled "m=" line (including any bundle-only "m=" line), except if:
o The offerer suggests a new offerer BUNDLE address [Section 8.5.2]; o The offerer suggests a new offerer BUNDLE address [Section 8.5.2];
skipping to change at page 16, line 5 skipping to change at page 15, line 10
8.5.2. Suggesting a new offerer BUNDLE address 8.5.2. Suggesting a new offerer BUNDLE address
When an offerer generates an offer, in which it suggests a new When an offerer generates an offer, in which it suggests a new
offerer BUNDLE address [Section 8.2.2], the offerer MUST: offerer BUNDLE address [Section 8.2.2], the offerer MUST:
o Assign the address (shared address) to each "m=" line within the o Assign the address (shared address) to each "m=" line within the
BUNDLE group; or BUNDLE group; or
o Assign the address (unique address) to one bundled "m=" line. o Assign the address (unique address) to one bundled "m=" line.
NOTE: If the offerer assigns a unique address, there might be a need
to send a subsequent BAS offer [Section 8.4.2] once the offerer has
received the associated answer.
In addition, the offerer MUST indicate that the address is the new In addition, the offerer MUST indicate that the address is the new
suggested offerer BUNDLE address [Section 8.2.2]. suggested offerer BUNDLE address [Section 8.2.2].
NOTE: Unless the offerer assigns the new suggested offerer BUNDLE NOTE: Unless the offerer assigns the new suggested offerer BUNDLE
address to each bundled "m=" line, it can assign unique addresses to address to each bundled "m=" line, it can assign unique addresses to
any number of bundled "m=" lines (and the previously selected offerer any number of bundled "m=" lines (and the previously selected offerer
BUNDLE address to any remaining bundled "m=" line) if it wants to BUNDLE address to any remaining bundled "m=" line) if it wants to
suggest multiple alternatives for the new offerer BUNDLE address. suggest multiple alternatives for the new offerer BUNDLE address.
8.5.3. Adding a media description to a BUNDLE group 8.5.3. Adding a media description to a BUNDLE group
skipping to change at page 30, line 30 skipping to change at page 30, line 5
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.
o 2. An answer, in which the answerer selects the offerer BUNDLE o 2. An answer, in which the answerer selects the offerer BUNDLE
address, and in which selects its own BUNDLE address (the answerer address, and in which selects its own BUNDLE address (the answerer
BUNDLE address) and assigns it each bundled "m=" line within the BUNDLE address) and assigns it each bundled "m=" line within the
BUNDLE group. BUNDLE group.
o 3. A subsequent offer (BAS offer), which is used to perform a
Bundle Address Synchronization (BAS).
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
skipping to change at page 31, line 27 skipping to change at page 31, line 5
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Offer (3)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
16.2. Example: BUNDLE Extension Rejected 16.2. Example: BUNDLE Extension Rejected
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.
o 2. An answer, in which the answerer rejects the offered BUNDLE o 2. An answer, in which the answerer rejects the offered BUNDLE
group, and assigns a unique addresses to each "m=" line (following group, and assigns a unique addresses to each "m=" line (following
normal RFC 3264 procedures). normal RFC 3264 procedures).
skipping to change at page 34, line 11 skipping to change at page 33, line 11
a new "m=" line, represented by the "zen" identification-tag, to a a new "m=" line, represented by the "zen" identification-tag, to a
previously negotiated BUNDLE group, assigns a unique address to previously negotiated BUNDLE group, assigns a unique address to
the added "m=" line, and assigns the previously selected offerer the added "m=" line, and assigns the previously selected offerer
BUNDLE address to each of the other bundled "m=" lines within the BUNDLE address to each of the other bundled "m=" lines within the
BUNDLE group. BUNDLE group.
o 2. An answer, in which the answerer assigns the answerer BUNDLE o 2. An answer, in which the answerer assigns the answerer BUNDLE
address to each bundled "m=" line (including the newly added "m=" address to each bundled "m=" line (including the newly added "m="
line) within the BUNDLE group. line) within the BUNDLE group.
o 3. A subsequent offer (BAS offer), which is used to perform a
Bundle Address Synchronization (BAS).
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
skipping to change at page 35, line 19 skipping to change at page 34, line 16
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Offer (3)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 66
b=AS:1000
a=mid:zen
a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
16.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 16.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o 1. A subsequent offer (the BUNDLE group has been created as part o 1. A subsequent offer (the BUNDLE group has been created as part
of a previous offer/answer transaction), in which the offerer of a previous offer/answer transaction), in which the offerer
moves a bundled "m=" line out of a BUNDLE group, assigns a unique moves a bundled "m=" line out of a BUNDLE group, assigns a unique
address to the moved "m=" line, and assigns the offerer BUNDLE address to the moved "m=" line, and assigns the offerer BUNDLE
address to each other bundled "m=" line within the BUNDLE group. address to each other bundled "m=" line within the BUNDLE group.
skipping to change at page 39, line 16 skipping to change at page 37, line 28
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach and Ari Keraenen for taking the time to read the text along the Stach and Ari Keraenen for taking the time to read the text along the
way, and providing useful feedback. way, and providing useful feedback.
18. Change Log 18. 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-18
o - Changes based on agreements at IETF#92
o -- BAS Offer removed, based on agreement at IETF#92.
o -- Procedures regarding usage of SDP "b=" line is replaced with a
reference to to draft-ietf-mmusic-sdp-mux-attributes.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17
o - Editorial changes based on comments from Magnus Westerlund. o - Editorial changes based on comments from Magnus Westerlund.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16
o - Modification of RTP/RTCP multiplexing section, based on comments o - Modification of RTP/RTCP multiplexing section, based on comments
from Magnus Westerlund. from Magnus Westerlund.
o - Reference updates. o - Reference updates.
 End of changes. 20 change blocks. 
174 lines changed or deleted 79 lines changed or added

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