draft-ietf-mmusic-sdp-bundle-negotiation-12.txt   draft-ietf-mmusic-sdp-bundle-negotiation-13.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: April 12, 2015 C. Jennings Expires: June 11, 2015 C. Jennings
Cisco Cisco
October 9, 2014 December 8, 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-12.txt draft-ietf-mmusic-sdp-bundle-negotiation-13.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework extension, This specification defines a new Session Description Protocol (SDP)
'BUNDLE'. The extension can be used with the Session Description Grouping Framework extension, 'BUNDLE'. The extension can be used
Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single 5-tuple for sending and receiving media associated with single address:port combination (BUNDLE address) for receiving media,
multiple SDP media descriptions ("m="). This is referred to as referred to as bundled media, associated with multiple SDP media
bundled media. descriptions ("m=" lines).
Both endpoints can negotiate the use of bundle and to support that To assist endpoints in negotiating the use of bundle this
negotiations, this specification defines a new SDP attribute, specification defines a new SDP attribute, 'bundle-only', which can
'bundle-only', which can be used to request that specific media is be used to request that specific media is only used if bundled. This
only used if bundled. This specification also updates sections 5.1, specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to
8.1 and 8.2 of RFC 3264 to allows an answerer to assign a non-zero allow an answerer to assign a non-zero port value to an "m=" line in
port value to an "m=" line in an SDP answer, even if the "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer
the associated SDP offer contained a zero port value. contained a zero port value.
There are multiple ways to correlate the bundled RTP packets with the There are multiple ways to correlate the bundled RTP packets with the
appropriate media descriptions. This specification defines a new RTP appropriate media descriptions. This specification defines a new
SDES item and a new RTP header extension that provides an additional RTCP source description (SDES) item and a new RTP header extension
way to do this correlation by using them to carry a value that that provides an additional way to do this correlation by using them
associates the RTP/RTCP packets with a specific media description. 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 April 12, 2015. This Internet-Draft will expire on June 11, 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 29 skipping to change at page 2, line 32
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. bundle-only . . . . . . . . . . . . . . . . . . . . . . . 8
7. SDP Information Considerations . . . . . . . . . . . . . . . 8 7. SDP Information Considerations . . . . . . . . . . . . . . . 8
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 8 7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9
7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 8 7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9
7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10
8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
8.2.2. Request offerer BUNDLE address selection . . . . . . 10 8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11
8.3.2. Answerer Selection of Offerer Bundle Address . . . . 11 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12
8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 12 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13
8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 12 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 . . . . . . . . . . 13 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14
8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 13 8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 14
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 15
8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . 16
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 . . . 17
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 Reuse . . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . 20
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 22 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . 24
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
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 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 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 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
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 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. RTP/RTCP extensions for mid value transport . . . . . . . . . 25 13. RTP/RTCP extensions for identification-tag transport . . . . 26
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. RTP MID SDES Item . . . . . . . . . . . . . . . . . . . 26 13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 26 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 26 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 27
14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 27 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28
14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 27 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28
15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28
16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 28 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Example: Bundle Address Selection . . . . . . . . . . . 28 16.1. Example: Bundle Address Selection . . . . . . . . . . . 29
16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . . 32
16.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 16.5. Example: Offerer Disables A Media Description Within A
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
20.1. Normative References . . . . . . . . . . . . . . . . . . 40 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
20.2. Informative References . . . . . . . . . . . . . . . . . 41 19.1. Normative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Design Considerations . . . . . . . . . . . . . . . 42 19.2. Informative References . . . . . . . . . . . . . . . . . 43
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix A. Design Considerations . . . . . . . . . . . . . . . 43
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 42 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.3. Usage of port number value zero . . . . . . . . . . . . . 44 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 44
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 44 A.3. Usage of port number value zero . . . . . . . . . . . . . 46
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 45 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 45 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 45 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This specification defines a way to use a single 5-tuple for sending This specification defines a way to use a single address:port
and receiving media associated with multiple SDP media descriptions combination (BUNDLE address) for receiving media associated with
("m=" lines) . This allows the usage of a single set of Interactive multiple SDP media descriptions ("m=" lines).
Connectivity Establishment (ICE) [RFC5245] candidates for multiple
media descriptions.
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]
to negotiate the usage of a single 5-tuple for sending and receiving to negotiate the usage of a BUNDLE group. Within the BUNDLE group, a
media associated with multiple SDP media descriptions ("m="). This BUNDLE address is used for receiving media associated with multiple
is referred to as bundled media. "m=" lines. This is referred to as bundled media.
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 BUNDLE addresses, one for the offerer (offerer BUNDLE
(offerer BUNDLE address) and one for the answerer (answerer BUNDLE address) and one for the answerer (answerer BUNDLE address), to be
address) to be used for the bundled media associated with a BUNDLE used for receiving the bundled media associated with a BUNDLE group.
group. Once the offerer and the answerer have negotiated a BUNDLE Once the offerer and the answerer have negotiated a BUNDLE group,
group, they assign their respective BUNDLE address to each "m=" line they assign their respective BUNDLE address to each "m=" line in the
in the BUNDLE group. The BUNDLE address is used to send and receive BUNDLE group. The BUNDLE addresses are used to receive all media
all media associated with the BUNDLE group. associated with the BUNDLE group.
The use of a BUNDLE group and a BUNDLE address also allows the usage
of a single set of Interactive Connectivity Establishment (ICE)
[RFC5245] candidates for multiple "m=" lines.
This specification also defines a new SDP attribute, 'bundle-only', This specification also defines a new SDP attribute, 'bundle-only',
which can be used to request that specific media is only used if which can be used to request that specific media is only used if kept
bundled. within a BUNDLE group.
As defined in RFC 4566 [RFC4566], the semantics of assigning the same As defined in RFC 4566 [RFC4566], the semantics of assigning the same
port value to multiple "m=" lines are undefined, and there is no port value to multiple "m=" lines are undefined, and there 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 Real-time Transport Protocol
header extension that can be used to carry a value that associates (RTP) [RFC3550] SDES item and a new RTP header extension that can be
RTP/RTCP packets with a specific media description. This can be used used to carry a value that associates RTP/RTCP packets with a
to correlate a RTP packet with the correct media. 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. The address MUST only be associated with a single BUNDLE group. The
procedures in this specification apply independently to a given procedures in this specification apply independently to a given
BUNDLE group. All Real-time Transport Protocol (RTP) [RFC3550] based BUNDLE group. All RTP based media flows associated with a single
media flows associated with a single BUNDLE group belong to a single BUNDLE group belong to a single RTP session [RFC3550].
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 transport-layer
protocol.
Unique address: An IP address and IP port combination that is Unique address: An IP address and port combination that is assigned
assigned to only one "m=" line in an offer or answer. 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 port combination that is assigned
assigned to multiple "m=" lines within an offer or answer. to multiple "m=" lines within an offer or answer.
Offerer suggested BUNDLE mid: The first mid value in a given SDP Offerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute mid list in an offer. 'group:BUNDLE' attribute identification-tag list in an offer.
Answerer selected BUNDLE mid: The first mid value in a given SDP Answerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute mid list in an answer. 'group:BUNDLE' attribute identification-tag list in an answer.
Offerer BUNDLE address: Within a given BUNDLE group, an IP address Offerer BUNDLE address: Within a given BUNDLE group, an IP address
and IP port combination used by an offerer to receive all media and port combination used by an offerer to receive all media
associated with each "m=" line within the BUNDLE group. associated with each "m=" line within the BUNDLE group.
Answerer BUNDLE address: Within a given BUNDLE group, an IP address Answerer BUNDLE address: Within a given BUNDLE group, an IP address
and IP port combination used by an answerer to receive all media and port combination used by an answerer to receive all media
associated with each "m=" line within the BUNDLE group. associated with each "m=" line within the BUNDLE group.
BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer
exchange, for which each endpoint uses a single 5-tuple to send and exchange, which uses the same BUNDLE address for receiving media.
receive media. Each endpoint uses its BUNDLE address, associated
with the BUNDLE group, to send and receive the media.
Bundled "m=" line: An "m=" line, whose SDP 'mid' attribute value is Bundled "m=" line: An "m=" line, whose identification-tag is placed
placed in a SDP 'group:BUNDLE' attribute mid value list in an offer in an SDP 'group:BUNDLE' attribute identification-tag list in an
or answer. offer or answer.
Bundle-only "m=" line: A bundled "m=" line with an associated SDP Bundle-only "m=" line: A bundled "m=" line with an associated SDP
'bundle-only' attribute. 'bundle-only' attribute.
Bundled media: All media associated with a given BUNDLE group. Bundled media: All media associated with a given BUNDLE group.
Initial offer: The first offer, within an SDP session, in which the Initial offer: The first offer, within an SDP session, in which the
offerer indicates that it wants to create a given BUNDLE group. offerer indicates that it wants to create a given BUNDLE group.
Subsequent offer: An offer which contains a BUNDLE group that has Subsequent offer: An offer which contains a BUNDLE group that has
been created as part of a previous SDP Offer/Answer exchange. been created as part of a previous SDP Offer/Answer exchange.
Identification-tag: A unique token value that is used to identify an
"m=" line. The SDP 'mid' attribute [RFC5888], associated with an
"m=" line, carries an unique identification-tag. The session-level
SDP 'group' attribute [RFC5888] carries a list of identification-
tags, identifying the "m=" lines associated with that particular
'group' attribute.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
4. Applicability Statement 4. Applicability Statement
The mechanism in this specification only applies to the Session The mechanism in this specification only applies to the Session
Description Protocol (SDP) [RFC4566], when used together with the SDP Description Protocol (SDP) [RFC4566], when used together with the SDP
Offer/Answer mechanism [RFC3264]. Offer/Answer mechanism [RFC3264].
5. SDP Grouping Framework BUNDLE Extension 5. SDP Grouping Framework BUNDLE Extension
5.1. General 5.1. General
This section defines a new SDP Grouping Framework extension This section defines a new SDP Grouping Framework extension
[RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP
Session Description Protocol (SDP) Offer/Answer mechanism to Offer/Answer mechanism to negotiate the usage of a single
negotiate the usage of a single 5-tuple for sending and receiving address:port combination (BUNDLE address) for receiving bundled
media, referred to as bundled media, associated with multiple SDP media.
media descriptions ("m=" lines). Within a successfully created
BUNDLE group, media described with "m=" lines associated with the A single address:port combination is also used for sending bundled
BUNDLE group will be sent and received using a single 5-tuple. media. The address:port combination used for sending bundled media
MAY be the same as the BUNDLE address, used to receive bundled media,
depending on whether symmetric RTP is used. A given address:port
combination MUST NOT be used for sending media associated with
multiple BUNDLE groups.
All media associated with a BUNDLE group share a single 5-tuple, i.e.
in addition to using a single address:port combination all bundled
media MUST be transported using the same transport-layer protocol.
The BUNDLE extension is indicated using an SDP 'group' attribute with The BUNDLE extension is indicated using an SDP 'group' attribute with
a "BUNDLE" semantics value [RFC5888]. An SDP "mid" attribute is a "BUNDLE" semantics value [RFC5888]. An identification-tag is
assigned to each bundled "m=" line, and the "mid" attribute value is assigned to each bundled "m=" line, and each identification-tag is
listed in the 'group:BUNDLE' attribute mid value list. Each "m=" listed in the SDP 'group:BUNDLE' attribute identification-tag list.
line, whose mid value is listed in the mid value list, is associated Each "m=" line, whose identification-tag is listed in the
with a given BUNDLE group. identification-tag list, is associated with a given BUNDLE group.
SDP bodies can contain multiple BUNDLE groups. Any given bundled SDP bodies can contain multiple BUNDLE groups. Any given bundled
"m=" line MUST NOT be associated with more than one BUNDLE group. "m=" line MUST NOT be associated with more than one BUNDLE group.
[Section 8] defines the detailed SDP Offer/Answer procedures for the Section 8 defines the detailed SDP Offer/Answer procedures for the
BUNDLE extension. BUNDLE extension.
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=" 6.2. bundle-only
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
group. In order to ensure that an answerer that does not supports
the BUNDLE extension always rejects a 'bundle-only' "m=" line, the
offerer can assign a zero port value to the "m=" line. According to
[RFC4566] an answerer will reject such "m=" line. 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 Name: bundle-only
'bundle-only' attribute.
6.2. Syntax Value:
This section defines the Augmented Backus-Naur Form (ABNF) [RFC5234] Usage Level: media
for the SDP 'bundle-only' attribute, based on the SDP [RFC4566]
grammar.
attribute =/ bundle-only-attribute Charset Dependent: no
bundle-only-attribute = "bundle-only" Example:
a=bundle-only
In order to ensure that an answerer that does not supports the BUNDLE
extension always rejects a bundled "m=" line, the offerer can assign
a zero port value to the "m=" line. According to [RFC4566] an
answerer will reject such "m=" line. By associating an SDP 'bundle-
only' attribute with such "m=" line, the offerer can request that the
answerer accepts the "m=" line if the answerer supports the Bundle
extension, and if the answerer keeps the "m=" line within the
associated BUNDLE group.
NOTE: Once an offerer BUNDLE address has been selected, the offerer
can ensure that an bundled "m=" line is accepted by the answerer only
if the answerer keeps the "m=" line within the associated BUNDLE
group by assigning the offerer BUNDLE address to the "m=" line. If
the answerer does not keep that "m=" line within the BUNDLE group,
the answerer will reject it. Therefore, the SDP 'bundle-only'
attribute is not needed in such cases
The usage of the 'bundle-only' attribute is only defined for a
bundled "m=" line with a zero port value, within an offer. Other
usage is unspecified.
Section 8 defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute.
7. SDP Information Considerations 7. SDP Information Considerations
7.1. General 7.1. General
This section describes restrictions associated with the usage of SDP This section describes restrictions associated with the usage of SDP
parameters within a BUNDLE group. It also describes, when parameter parameters within a BUNDLE group. It also describes, when parameter
and attribute values have been assigned to each bundled "m=" line, and attribute values have been associated with each bundled "m="
how to calculate a value for the whole BUNDLE group. line, how to calculate a value for the whole BUNDLE group.
7.2. Connection Data (c=) 7.2. Connection Data (c=)
The "c=" line nettype value [RFC4566] assigned to a bundled "m=" line The "c=" line nettype value [RFC4566] associated with a bundled "m="
MUST be 'IN'. line MUST be 'IN'.
The "c=" line addrtype value [RFC4566] assigned to 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 assigned to each line MUST be 'IP4' or 'IP6'. The same value MUST be associated with
"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 The proposed bandwidth for a bundled "m=" line SHOULD be calculated
in the same way as for a non-bundled "m=" line. in the same way as for a non-bundled "m=" line.
skipping to change at page 9, line 37 skipping to change at page 10, line 14
The generic rules and procedures defined in [RFC3264] and [RFC5888] The generic rules and procedures defined in [RFC3264] and [RFC5888]
also apply to the BUNDLE extension. For example, if an offer is also apply to the BUNDLE extension. For example, if an offer is
rejected by the answerer, the previously negotiated SDP parameters rejected by the answerer, the previously negotiated SDP parameters
and characteristics (including those associated with a BUNDLE group) and characteristics (including those associated with a BUNDLE group)
apply. Hence, if an offerer generates an offer in which the offerer apply. Hence, if an offerer generates an offer in which the offerer
wants to create a BUNDLE group, and the answerer rejects the offer, wants to create a BUNDLE group, and the answerer rejects the offer,
the BUNDLE group is not created. the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
transport protocol represented by a bundled "m=" line. [Section 10] transport protocol represented by a bundled "m=" line. Section 10
defines additional considerations for RTP based media. [Section 6] defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. [Section 11] defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) mechanism the usage of Interactive Connectivity Establishment (ICE) [RFC5245]
[RFC5245]. mechanism .
The offerer and answerer MUST follow the rules and restrictions The offerer and answerer MUST follow the rules and restrictions
defined in [Section 7] when creating offers and answers. defined in Section 7 when creating offers and answers.
SDP bodies can contain multiple BUNDLE groups. The procedures in SDP bodies can contain multiple BUNDLE groups. The procedures in
this section apply independently to a given BUNDLE group. this section apply independently to a given BUNDLE group.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
8.2.1. General 8.2.1. General
When an offerer generates an initial offer, in order to create a When an offerer generates an initial offer, in order to create a
BUNDLE group, it MUST: BUNDLE group, it MUST:
o Assign a unique address to each "m=" line within the offer, o Assign a unique address to each "m=" line within the offer,
following the procedures in [RFC3264]; following the procedures in [RFC3264];
o Assign an SDP 'group:BUNDLE' attribute to the offer; o Assign a unique address to each "m=" line within the offer,
following the procedures in [RFC3264];
o Place the SDP 'mid' attribute value [RFC5888] of each bundled "m=" o Add an SDP 'group:BUNDLE' attribute to the offer;
line to the SDP 'group:BUNDLE' attribute mid value list; and
o Indicate which unique address the offerer wants the answerer to o Place the identification-tag of each bundled "m=" line in the SDP
select as the offerer BUNDLE address [Section 8.2.2]. 'group:BUNDLE' attribute identification-tag list; and
o Indicate which unique address the offerer suggests as the offerer
BUNDLE address [Section 8.2.2].
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accepts a given
"m=" line only if the answerer keeps the "m=" line within the BUNDLE "m=" line only if the answerer keeps the "m=" line within the BUNDLE
group, the offerer MUST: group, the offerer MUST:
o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the
"m=" line; and "m=" line; and
o Assign a zero port value to the "m=" line. o Assign a zero port value to the "m=" line.
NOTE: If the offerer assigns a zero port value to an "m=" line, but NOTE: If the offerer assigns a zero port value to an "m=" line, but
does not also associate an SDP 'bundle-only' attribute with the "m=" does not also associate an SDP 'bundle-only' attribute with the "m="
line, it is an indication that the offerer wants to disable the "m=" line, it is an indication that the offerer wants to disable the "m="
line [Section 8.5.5]. line [Section 8.5.5].
[Section 16.1] shows an example of an initial offer. [Section 16.1] shows an example of an initial offer.
8.2.2. Request offerer BUNDLE address selection 8.2.2. Suggesting the offerer BUNDLE address
In the offer, the address assigned to the "m=" line associated with In the offer, the address assigned to the "m=" line associated with
the offerer suggested BUNDLE mid indicates the address that the the offerer BUNDLE-tag indicates the address that the offerer
offerer wants the answer to select as the offerer BUNDLE address suggests as the offerer BUNDLE address.
[Section 8.3.2].
8.3. Generating the SDP Answer 8.3. Generating the SDP Answer
8.3.1. General 8.3.1. General
When an answerer generates an answer, which contains a BUNDLE group, When an answerer generates an answer, which contains a BUNDLE group,
the following general SDP grouping framework restrictions, defined in the following general SDP grouping framework restrictions, defined in
[RFC5888], also apply to the BUNDLE group: [RFC5888], also apply to the BUNDLE group:
o The answerer MUST NOT include a BUNDLE group in the answer, unless o The answerer MUST NOT include a BUNDLE group in the answer, unless
skipping to change at page 11, line 37 skipping to change at page 12, line 14
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 answer. The answerer MUST NOT associate an SDP 'bundle-only' attribute with
any "m=" line in an 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 zero port 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 BUNDLE-tag indicates the
the address that the offerer wants the answer to select as the address that the offerer suggests as the offerer BUNDLE address
offerer BUNDLE address [Section 8.2.2]. The answerer MUST check [Section 8.2.2]. The answerer MUST check whether that "m=" line
whether the "m=" line fulfils the following criteria: fulfills the following criteria:
o The answerer will not move the "m=" line out of the BUNDLE group o The answerer will not move the "m=" line out of the BUNDLE group
[Section 8.3.4]; [Section 8.3.4];
o The answerer will not reject the "m=" line [Section 8.3.5]; and o The answerer will not reject the "m=" line [Section 8.3.5]; and
o The "m=" line does not contain a zero port value. o The "m=" line does not contain a zero port value.
If all of the criteria above is fulfilled, the answerer MUST select If all of the criteria above are fulfilled, the answerer MUST select
the address associated with the "m=" line as the offerer BUNDLE the address associated with the "m=" line as the offerer BUNDLE
address. In the answer, the answerer selected BUNDLE mid represents address. In the answer, the answerer BUNDLE-tag represents the "m="
the "m=" line, and the address associated with the "m=" line in the line, and the address associated with the "m=" line in the offer
offer becomes the offerer BUNDLE address. becomes the offerer BUNDLE address.
If all of the criteria is not fulfilled, the answerer MUST select the If one or more of the criteria are not fulfilled, the answerer MUST
next mid value in the mid list, and perform the same criteria check select the next identification-tag in the identification-tag list,
for the "m=" line associated with that mid value. If there are no and perform the same criteria check for the "m=" line associated with
more mid values in the mid list, the answerer MUST NOT create the that identification-tag. If there are no more identification-tags in
BUNDLE group. the identification-tag list, the answerer MUST NOT create the BUNDLE
group.
[Section 16.1] shows an example of an offerer BUNDLE address [Section 16.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.3. Answerer Selection of Answerer BUNDLE Address 8.3.3. Answerer Selection of Answerer BUNDLE Address
When the answerer selects a BUNDLE address for itself, referred to as When the answerer selects a BUNDLE address for itself, referred to as
the answerer BUNDLE address, it MUST assign the address to each the answerer BUNDLE address, it MUST assign that address to each
bundled "m=" line within the created BUNDLE group in the answer. bundled "m=" line within the created BUNDLE group in the answer.
The answerer MUST NOT assign the answerer BUNDLE address to an "m=" The answerer MUST NOT assign the answerer BUNDLE address to an "m="
line that is not within the BUNDLE group, or to an "m=" line that is line that is not within the BUNDLE group, or to an "m=" line that is
within another BUNDLE group. within another BUNDLE group.
[Section 16.1] shows an example of an answerer BUNDLE address [Section 16.1] shows an example of an answerer BUNDLE address
selection. selection.
8.3.4. Moving A Media Description Out Of A BUNDLE Group 8.3.4. Moving A Media Description Out Of A BUNDLE Group
When an answerer moves a "m=" line out of a BUNDLE group, it assigns When an answerer moves a "m=" line out of a BUNDLE group, it assigns
an address to the "m=" line in the answer based on the following an address to the "m=" line in the answer based on the following
rules: rules:
o In the associated offer, if the "m=" line contains a shared o In the associated offer, if the "m=" line contains a shared
address (e.g. a previously selected offerer BUNDLE address), the address (e.g. a previously selected offerer BUNDLE address), the
answerer MUST reject the moved "m=" line [Section 8.3.5]; answerer MUST reject the moved "m=" line [Section 8.3.5];
o In the associated offer, if the "m=" line contains a unique o In the associated offer, if the "m=" line contains a unique
address, the answerer MUST assign a unique address to the "m=" address, the answerer MUST assign a unique address also to the
line in the answer; or "m=" line in the answer; or
o In the associated offer, if the "m=" line contains an SDP 'bundle- o In the associated offer, if an SDP 'bundle-only' attribute is
only' attribute the answerer MUST reject the "m=" line associated with the "m=" line, and if the "m=" line contains a
zero port value, the answerer MUST reject the "m=" line
[Section 8.3.5]. [Section 8.3.5].
In addition, in either case above, the answerer MUST NOT include a In addition, in either case above, the answerer MUST NOT place the
mid value, associated with the moved "m=" line, in the SDP identification-tag, associated with the moved "m=" line, in the SDP
'group:BUNDLE' attribute mid list associated with the BUNDLE group. 'group' attribute identification-tag list associated with the BUNDLE
group.
8.3.5. Rejecting A Media Description In A BUNDLE Group 8.3.5. Rejecting A Media Description In A BUNDLE Group
When an answerer rejects an "m=" line, it MUST assign an address with When an answerer rejects an "m=" line, it MUST assign an address with
a zero port value to the "m=" line in the answer, according to the a zero port value to the "m=" line in the answer, according to the
procedures in [RFC4566]. procedures in [RFC4566].
In addition, the answerer MUST NOT include a mid value, associated In addition, the answerer MUST NOT place the identification-tag,
with the rejected "m=" line, in the SDP 'group:BUNDLE' attribute mid associated with the rejected "m=" line, in the SDP 'group' attribute
list associated with the BUNDLE group. identification-tag list associated with the BUNDLE group.
8.4. Offerer Processing of the SDP Answer 8.4. Offerer Processing of the SDP Answer
8.4.1. General 8.4.1. General
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check that any bundled "m=" line in the group, the offerer MUST check that any bundled "m=" line in the
answer was indicated as bundled in the associated offer. If there is answer was indicated as bundled in the associated offer. If there is
no mismatch, the offerer MUST apply the offerer BUNDLE address, no mismatch, the offerer MUST use the offerer BUNDLE address,
selected by the answerer [Section 8.3.2], to each bundled "m=" line. selected by the answerer [Section 8.3.2], as the address for each
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) 8.4.2. Bundle Address Synchronization (BAS)
skipping to change at page 14, line 25 skipping to change at page 15, line 9
NOTE: It is important that the BAS offer gets accepted by the NOTE: It is important that the BAS offer gets accepted by the
answerer. For that reason the offerer needs to consider the answerer. For that reason the offerer needs to consider the
necessity to modify SDP parameters in the BAS offer, in such a way necessity to modify SDP parameters in the BAS offer, in such a way
that could trigger the answerer to reject the BAS offer. Disabling that could trigger the answerer to reject the BAS offer. Disabling
"m=" lines, or reducing the number of codecs, in a BAS offer is "m=" lines, or reducing the number of codecs, in a BAS offer is
considered to have a low risk of being rejected. considered to have a 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 extension, have intermediaries, that might not support the BUNDLE extension, have
correct information regarding the address is going to be used to correct information regarding the address that is going to be used to
transport the bundled media. transport the bundled media.
[Section 16.1] shows an example of a BAS offer. [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), with the bundled "m=" line (including any bundle-only "m=" line), except if:
following exceptions:
o The offerer wants to request the answerer to select a new offerer o The offerer suggests a new offerer BUNDLE address [Section 8.5.2];
BUNDLE address [Section 8.5.2];
o The offerer wants to add a bundled "m=" line to the BUNDLE group o The offerer wants to add a bundled "m=" line to the BUNDLE group
[Section 8.5.3]; [Section 8.5.3];
o The offerer wants to move a bundled "m=" line out of the BUNDLE o The offerer wants to move a bundled "m=" line out of the BUNDLE
group [Section 8.5.4]; or group [Section 8.5.4]; or
o The offerer wants to disable the bundled "m=" line o The offerer wants to disable the bundled "m=" line
[Section 8.5.5]. [Section 8.5.5].
In addition, the offerer MUST select an offerer suggested BUNDLE mid In addition, the offerer MUST select an offerer BUNDLE-tag
[Section 8.2.2], even if the offerer does not want the answerer to [Section 8.2.2], even if the offerer does not suggest a new offerer
select a new offerer BUNDLE address. BUNDLE address.
If the offerer associates an SDP 'bundle-only' attribute with a
bundled "m=" line in the subsequent offer, if MUST assign the offerer
BUNDLE address to the "m=" line. The offerer MUST NOT assign a
unique address, or a zero port value, to a bundle-only "m=" line in a
subsequent offer.
NOTE: The offerer can associate an SDP 'bundle-only' attribute with a The offerer MUST NOT associate an SDP 'bundle-only' attribute with a
bundled "m=" line in a subsequent offer, even if the offerer did not bundled "m=" line in a subsequent offer, unless the offerer also
associate a 'bundle-only' attribute with the same "m=" line in a assigns a zero port value to the "m=" line.
previous offer.
8.5.2. Request a new offerer BUNDLE address 8.5.2. Request a new offerer BUNDLE address
When an offerer generates an offer, in which it wants the answerer to When an offerer generates an offer, in which it suggests a new
select a new offerer BUNDLE address [Section 8.2.2], the offerer offerer BUNDLE address [Section 8.2.2], the offerer MUST:
MUST:
o Assign a unique address, which the offerer wants the answerer to o Assign a unique address, which the offerer suggests as the new
select as the offerer BUNDLE address, to a bundled "m=" line; and offerer BUNDLE address, to a bundled "m=" line; and
o Indicate that the offerer wants the answerer to select the unique o Indicate that the offerer suggests the unique address as the new
address as the offerer BUNDLE address [Section 8.2.2] offerer BUNDLE address [Section 8.2.2]
NOTE: The offerer can assign a unique address to each bundled "m=" NOTE: The offerer can assign a unique address to each bundled "m="
line in the offer, or it can assign the previously negotiated offerer line in the offer, or it can assign the previously selected offerer
BUNDLE address to each "m=" line (except the "m=" line to which it BUNDLE address to each "m=" line (except to the "m=" line to which it
assigns the unique address that it wants the answerer to select as assigns the unique address that it suggests as the new offerer BUNDLE
the new offerer BUNDLE address). address).
8.5.3. Adding a media description to a BUNDLE group 8.5.3. Adding a media description to a BUNDLE group
When an offerer generates an offer, in which it wants to add a When an offerer generates an offer, in which it wants to add a
bundled "m=" line to BUNDLE group, the offerer MUST: bundled "m=" line to a BUNDLE group, the offerer MUST:
o Assign a unique address (excluding bundle-only "m=" lines), or the
offerer BUNDLE address (selected by the answerer in a previous
offer/answer transaction), to the "m=" line;
o Place the SDP 'mid' attribute value associated with the "m=" line o Assign a unique address, or the previously selected offerer BUNDLE
in the SDP 'group:BUNDLE' attribute mid list associated with the address, to the "m=" line; and
BUNDLE group [Section 8.2.2].
NOTE: Adding a unique address to the "m=" line allows the answerer to o Extend the SDP 'group:BUNDLE' attribute identification-tag list
move the "m=" line out of the BUNDLE group [Section 8.3.4], without with the BUNDLE group [Section 8.2.2] by adding the
having to reject the "m=" line. identification-tag associated with the added "m=" line to the
list.
If the offerer wants the answerer to select the address associated NOTE: Assigning a unique address to the "m=" line allows the answerer
with the added "m=" line as the new offerer BUNDLE address, the to move the "m=" line out of the BUNDLE group [Section 8.3.4],
offerer suggested BUNDLE mid MUST represent the added "m=" line without having to reject the "m=" line.
[Section 8.2.2].
If the offerer associates an SDP 'bundle-only' attribute with the If the offerer suggests the address associated with the added "m="
added "m=" line, the offerer MUST assign the offerer BUNDLE address line as the new offerer BUNDLE address, the offerer BUNDLE-tag MUST
(selected by the answerer in a previous offer/answer transaction) to represent the added "m=" line [Section 8.2.2].
the "m=" line.
[Section 16.3] shows an example where an offerer sends an offer in [Section 16.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" line to a BUNDLE group. order to add a bundled "m=" line to a BUNDLE group.
8.5.4. Moving A Media Description Out Of A BUNDLE Group 8.5.4. Moving A Media Description Out Of A BUNDLE Group
When an offerer generates an offer, in which it wants to move a When an offerer generates an offer, in which it wants to move a
bundled "m=" line out of a BUNDLE group it was added to in a previous bundled "m=" line out of a BUNDLE group it was added to in a previous
offer/answer transaction, the offerer: offer/answer transaction, the offerer:
o MUST assign a unique address to the "m=" line; o MUST assign a unique address to the "m=" line; and
o MUST NOT place a mid value associated with the "m=" line in the
SDP 'group:BUNDLE' attribute mid list associated with that BUNDLE
group; and
o MUST NOT associate an SDP 'bundle-only' attribute with the "m=" o MUST NOT place the identification-tag associated with the "m="
line. line in the SDP 'group:BUNDLE' attribute identification-tag list
associated with the BUNDLE group.
NOTE: If an "m=" line, when being moved out of a BUNDLE group, is NOTE: If an "m=" line, when being moved out of a BUNDLE group, is
added to another BUNDLE group, the offerer applies the procedures in added to another BUNDLE group, the offerer applies the procedures in
[Section 8.5.3] to the "m=" line. [Section 8.5.3] to the "m=" line.
[Section 16.4] shows an example of an offer for moving an "m=" line [Section 16.4] shows an example of an offer for moving an "m=" line
out of a BUNDLE group. out of a BUNDLE group.
8.5.5. Disabling A Media Description In A BUNDLE Group 8.5.5. Disabling A Media Description In A BUNDLE Group
When an offerer generates an offer, in which it wants to disable a When an offerer generates an offer, in which it wants to disable a
bundled "m=" line (added to the BUNDLE group in a previous offer/ bundled "m=" line (added to the BUNDLE group in a previous offer/
answer transaction), the offerer: answer transaction), the offerer:
o MUST assign an address with a zero port value to the "m=" line, o MUST assign an address with a zero port value to the "m=" line,
following the procedures in [RFC4566]; following the procedures in [RFC4566]; and
o MUST NOT place a mid value associated with the "m=" line in the
SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE
group; and
o MUST NOT associate an SDP 'bundle-only' attribute with the "m=" o MUST NOT place the identification-tag associated with the "m="
line. line in the SDP 'group:BUNDLE' attribute identification-tag list
associated with the BUNDLE group.
[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 Each "m=" line within a BUNDLE group MUST use the same transport-
MUST exist a publicly available specification which describes a layer protocol. If bundled "m=" lines use different protocols on top
mechanism for this specific transport protocol combination that of the transport-layer protocol, there MUST exist a publicly
describes how to associate a received packet with the correct available specification which describes a mechanism, for this
transport protocol. particular protocol combination, how to associate a received packet
with the correct 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 for associating 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 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 of a received packet among the STUN, DTLS and SRTP protocols
combination). If an offer or answerer in offers or answers include (in any combination). If an offer or answer includes bundled "m="
bundled "m=" lines that represent these protocols, the offerer or lines that represent these protocols, the offerer or answerer MUST
answerer MUST support the mechanism described in [RFC5764], and no support the mechanism described in [RFC5764], and no explicit
explicit negotiation is required in order to indicate support and negotiation is required in order to indicate support and usage of the
usage of the mechanism. 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 for identify each individual specification describing a mechanism for identifying 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 for associating 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
skipping to change at page 18, line 25 skipping to change at page 18, line 30
Since a single RTP session is used for each bundle group, all "m=" Since a single RTP session is used for each bundle group, all "m="
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 10.1.2]. an identical codec configuration [Section 10.1.2].
o The "proto" value in each bundled "m=" line MUST be identical o The "proto" value in each bundled RTP-based "m=" line MUST be
(e.g. RTP/AVPF). identical (e.g. RTP/AVPF).
o A given SSRC SHOULD NOT transmit RTP packets using payload types o An SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp-
hdrext:sdes:mid' URI value, MUST, in every offer and answer, be
associated with each bundled "m=" line representing RTP-based
media.
o A given SSRC MUST 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 proper sequence this causes RTP Timestamp rate switching issues
[RFC7160]. [RFC7160]. However, once an SSRC has left the RTP session (by
sending an RTCP BYE packet), that SSRC value can later be reused by
another source(possible associated with a different bundled "m="
line.
10.1.2. Payload Type (PT) Value Reuse 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 be used inside
than one bundled "m=" line, all codecs associated with the payload more than one bundled "m=" line, all codecs associated with the
type numbers MUST share an identical codec configuration. This means payload type number MUST share an identical codec configuration.
that the codecs MUST share the same media type, encoding name, clock This means that the codecs MUST share the same media type, encoding
rate and any parameter that can affect the codec configuration and name, clock rate and any parameter that can affect the codec
packetization. [I-D.mmusic-sdp-mux-attributes] lists SDP attributes, configuration and packetization. [I-D.mmusic-sdp-mux-attributes]
whose attribute values must be identical for all codecs that use the lists SDP attributes, whose attribute values must be identical for
same payload type value. all codecs that use the same payload type value.
10.2. Associating RTP/RTCP Packets With Correct SDP Media Description 10.2. Associating RTP/RTCP Packets With Correct SDP Media Description
In general, there are multiple mechanisms that can be used by an There are multiple mechanisms that can be used by an endpoint in
endpoint in order to associate received RTP/RTCP packets with the order to associate received RTP/RTCP packets with a bundled "m="
bundled "m=" line representing the RTP packets. Such mechanisms line. Such mechanisms include using the payload type value carried
include using the local address:port combination on which the RTP inside the RTP packets, the SSRC values carried inside the RTP
packets are received, the payload type value carried inside the RTP packets, and other "m=" line specific information carried inside the
packets, the SSRC values carried inside the RTP packets, and other RTP packets.
"m=" line specific information carried inside the RTP packets.
As all RTP/RTCP packets associated with a BUNDLE group are sent and As all RTP/RTCP packets associated with a BUNDLE group are received
received using the same 5-tuple, the local address:port combination (and sent) using single address:port combinations, the local
cannot be used to associate received RTP packets with the correct address:port combination cannot be used to associate received RTP
"m=" line. packets with the correct "m=" line.
As described in [Section 10.1.2], the same payload type value might As described in [Section 10.1.2], the same payload type value might
be used inside RTP packets described by multiple "m=" lines. In such be 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 offer and answer inform each other An offerer and answerer can in an offer and answer inform each other
which SSRC values they will use inside sent RTP/RTCP packets, by which SSRC values they will use inside sent RTP/RTCP packets, by
assigning an SDP 'ssrc' attribute [RFC5576] to each bundled "m=" line associating an SDP 'ssrc' attribute [RFC5576] with each bundled "m="
which contains a payload type value that is also used inside another line which contains a payload type value that is also used inside
bundled "m=" line. As the SSRC values will be carried inside the another bundled "m=" line. As the SSRC values will be carried inside
RTP/RTCP packets, the offerer and answerer can then use that the 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 support 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
'mid' attribute value of an "m=" line in RTP and RTCP packets identification-tag associated with an "m=" line in RTP and RTCP
associated with that "m=" line. packets 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
multiplexing for the RTP based media associated with the BUNDLE group multiplexing for the RTP based media associated with the BUNDLE group
[RFC5761]. [RFC5761].
If RTP/RTCP multiplexing is not enabled, separate 5-tuples will be If RTP/RTCP multiplexing is not enabled, separate address:port
used for sending and receiving the RTP packets and the RTCP packets. combinations will be used for receiving (and sending) the RTP packets
and the RTCP packets.
10.3.2. SDP Offer/Answer Procedures 10.3.2. SDP Offer/Answer Procedures
10.3.2.1. General 10.3.2.1. General
This section describes how an offerer and answerer can use the SDP This section describes how an offerer and answerer can use the SDP
'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605] 'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605]
to negotiate usage of RTP/RTCP multiplexing for RTP based media to negotiate usage of RTP/RTCP multiplexing for RTP based media
associated with a BUNDLE group. associated with a BUNDLE group.
10.3.2.2. Generating the Initial SDP Offer 10.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, if the offerer wants to When an offerer generates an initial offer, if the offerer wants to
negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, the negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, the
offerer MUST assign an SDP 'rtcp-mux' attribute [RFC5761] to each offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with
bundled "m=" line (including any bundle-only "m=" line) in the offer. each bundled RTP-based "m=" line (including any bundle-only "m="
In addition, the offerer MUST assign an SDP 'rtcp' attribute line) in the offer. In addition, the offerer MUST associate an SDP
[RFC3605] to each bundled "m=" line (including any bundle-only "m=" 'rtcp' attribute [RFC3605] with each bundled RTP-based "m=" line
line), with an attribute value that is identical to the port value (including any bundle-only "m=" line), with an attribute value that
assigned to the "m=" line itself, in the offer. is identical to the port value assigned to the "m=" line itself, in
the offer.
If the offerer does not want to negotiate usage of RTP/RTCP If the offerer does not want to negotiate usage of RTP/RTCP
multiplexing, it MUST NOT assign the SDP attributes above to any multiplexing, it MUST NOT associate the SDP attributes above with any
bundled "m=" line. bundled "m=" line.
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 associate an SDP 'rtcp-mux' attribute with each
bundled "m=" line in the answer. The answerer MUST NOT assign an SDP bundled RTP-based "m=" line in the answer. The answerer MUST NOT
'rtcp' attribute to any bundled "m=" line in the answer. The associate an SDP 'rtcp' attribute with any bundled "m=" line in the
answerer will use the port number of the selected offerer BUNDLE answer. The answerer will use the port number of the selected
address for sending RTP and RTCP packets associated with each bundled offerer BUNDLE address for sending RTP and RTCP packets associated
"m=" line towards the offerer. with each bundled RTP-based "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 associate an SDP 'rtcp-mux' or SDP 'rtcp'
attribute to any bundled "m=" line in the answer. The answerer will, attribute with any bundled "m=" line in the answer. The answerer
based on the port number of the selected offerer BUNDLE address, use MUST, based on the port number of the selected offerer BUNDLE
the next higher (odd) destination port number [RFC3550] for sending address, use the next higher (odd) destination port number [RFC3550]
RTCP packets associated with each bundled "m=" line towards the for sending RTCP packets associated with each bundled RTP-based "m="
offerer. line towards the offerer.
NOTE: When the answerer rejects usage of RTP/RTCP multiplexing, the
reason for mandating usage of the next higher (odd) destination port
number for RTCP is to allign the procedures for the corresponding
offer.
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 associate an SDP 'rtcp-mux' attribute with each
"m=" line in the answer. I.e. the answerer MUST NOT disable the bundled "m=" line in the answer. I.e. the answerer MUST NOT disable
usage of RTP/RTCP multiplexing. the 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]. The offerer will use the port number of the answerer in [RFC5761]. The offerer will use the port number of the answerer
BUNDLE address for sending RTP and RTCP packets associated with each BUNDLE address for sending RTP and RTCP packets associated with each
bundled "m=" line towards the answerer. 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 address:port
and RTCP. The offerer will, based on the port number of the answerer combinations for RTP and RTCP. The offerer will, based on the port
BUNDLE address, use the next higher (odd) destination port number number of the answerer BUNDLE address, use the next higher (odd)
[RFC3550] for sending RTCP packets associated with a bundled "m=" destination port number [RFC3550] for sending RTCP packets associated
line towards the answerer. 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 associate SDP 'rtcp-mux'
'rtcp' attributes to each bundled "m=" line (including bundle-only and 'rtcp' attributes with each bundled "m=" line (including any
"m=" lines, and a bundled "m=" line that the offerer wants to add to bundled "m=" line that the offerer wants to add to the BUNDLE group),
the BUNDLE group), unless the offerer wants to disable or remove the unless the offerer wants to disable or remove the "m=" line from the
"m=" line from the BUNDLE group. BUNDLE group.
If the offerer does not want to negotiate usage of RTP/RTCP If the offerer does not want to negotiate usage of RTP/RTCP
multiplexing within the BUNDLE group, or if it wants to disable usage multiplexing within the BUNDLE group, or if it wants to disable usage
of RTP/RTCP multiplexing (negotiated in a previous offer/answer of RTP/RTCP multiplexing (negotiated in a previous offer/answer
transaction), the offerer MUST NOT assign SDP 'rtcp-mux' and 'rtcp' transaction), the offerer MUST NOT associate SDP 'rtcp-mux' and
attributes to any bundled "m=" line in the subsequent offer. 'rtcp' attributes with any bundled "m=" line in the subsequent offer.
NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has
been negotiated within a BUNDLE group, that the usage is not been negotiated within a BUNDLE group, that the usage is not
disabled. Disabling RTP/RTCP multiplexing means that the offerer and disabled. Disabling RTP/RTCP multiplexing means that the offerer and
answerer need to reserve new IP ports, to be used for sending and answerer need to reserve new ports, to be used for sending and
receiving RTCP packets. receiving RTCP packets.
11. ICE Considerations 11. ICE Considerations
11.1. General 11.1. General
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [RFC5245]. mechanism [RFC5245].
skipping to change at page 22, line 27 skipping to change at page 23, line 4
o When BUNDLE addresses for a BUNDLE group have been selected for o When BUNDLE addresses for a BUNDLE group have been selected for
both endpoints, ICE connectivity checks and keep-alives only need both endpoints, ICE connectivity checks and keep-alives only need
to be performed for the whole BUNDLE group, instead of per bundled to be performed for the whole BUNDLE group, instead of per bundled
"m=" line. "m=" line.
Support and usage of ICE mechanism together with the BUNDLE extension Support and usage of ICE mechanism together with the BUNDLE extension
is OPTIONAL. is OPTIONAL.
11.2. SDP Offer/Answer Procedures 11.2. SDP Offer/Answer Procedures
11.2.1. General 11.2.1. General
When an offerer or answerer assigns a unique address to a bundled When an offerer assigns a unique address to a bundled "m=" line
"m=" line (excluding bundle-only "m=" lines), it MUST also assign (excluding and bundle-only "m=" line), it MUST also associate unique
unique ICE candidates [RFC5245] to the "m=" line. ICE candidates [RFC5245] to the "m=" line.
An offerer MUST NOT assign ICE candidates to a bundle-only "m=" line
with a zero port value.
NOTE: The bundle-only "m=" line, if accepted by the answerer, will
inherit the candidates associated with the selected offerer BUNDLE
address. An answerer that does not support BUNDLE would not accept a
bundle-only "m=" line.
When an offerer or answerer assigns a shared address (i.e. a When an offerer or answerer assigns a shared address (i.e. a
previously selected BUNDLE address) to one or more bundled "m=" line previously selected BUNDLE address) to one or more bundled "m="
(including bundle-only "m=" lines), and when it assigns an address lines, it MUST associate identical ICE candidates (referred to as
with a zero port value to one or more bundle-only "m=" lines, it MUST shared ICE candidates) to each of those "m=" lines.
assign identical ICE candidates (referred to as shared ICE
candidates) to each of those "m=" lines.
11.2.2. Generating the Initial SDP Offer 11.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, it assigns unique or When an offerer generates an initial offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to shared ICE candidates to the bundled "m=" lines, according to
[Section 11.1]. Section 11.1.
11.2.3. Generating the SDP Answer 11.2.3. Generating the SDP Answer
When an answerer generates an answer, which contains a BUNDLE group, When an answerer generates an answer, which contains a BUNDLE group,
the answerer MUST assign shared ICE candidates to each bundled "m=" the answerer MUST assign shared ICE candidates to each bundled "m="
line (including "m=" lines that were indicated as bundle-only in the line (including "m=" lines that were indicated as bundle-only in the
associated offer) in the answer. associated offer) in the answer.
11.2.4. Offerer Processing of the SDP Answer 11.2.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer supports and uses When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST assign the ICE mechanism and the BUNDLE extension, the offerer MUST assign
the ICE candidates, associated with the "m=" line representing the the same ICE candidates, associated with the "m=" line representing
offerer BUNDLE address (selected by the answerer) to each bundled the offerer BUNDLE address (selected by the answerer), to each
"m=" line. bundled "m=" line.
11.2.5. Modifying the Session 11.2.5. Modifying the Session
When an offerer generates a subsequent offer, it assigns unique or When an offerer generates a subsequent offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to shared ICE candidates to the bundled "m=" lines, according to
[Section 11.1]. (Section 11.1).
12. Update to RFC 3264 12. Update to RFC 3264
12.1. General 12.1. General
This section replaces the text of the following sections of RFC 3264: This section replaces the text of the following sections of RFC 3264:
o Section 5.1 (Unicast Streams). o Section 5.1 (Unicast Streams).
o Section 8.2 (Removing a Media Stream). o Section 8.2 (Removing a Media Stream).
skipping to change at page 24, line 35 skipping to change at page 25, line 18
zero in the answer. Like the offer, the answer MAY omit all zero in the answer. Like the offer, the answer MAY omit all
attributes present previously, and MAY list just a single media attributes present previously, and MAY list just a single media
format from amongst those in the offer. format from amongst those in the offer.
12.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264 12.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264
A stream that is offered with a port of zero MUST by default be A stream that is offered with a port of zero MUST by default be
marked with port zero in the answer, unless an extension mechanism, marked with port zero in the answer, unless an extension mechanism,
which specifies semantics for the usage of a non-zero port value, is which specifies semantics for the usage of a non-zero port value, is
used. If the stream is marked with port zero in the answer, the used. If the stream is marked with port zero in the answer, the
answer MAY omit (like the offer) all attributes present previously, answer MAY omit all attributes present previously, and MAY list just
and MAY list just a single media format from amongst those in the a single media format from amongst those in the offer."
offer."
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
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
skipping to change at page 25, line 21 skipping to change at page 26, line 5
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.
13. RTP/RTCP extensions for mid value transport 13. RTP/RTCP extensions for identification-tag transport
13.1. General 13.1. General
SDP Offerers and Answerers [RFC3264] can assign mid values to SDP SDP Offerers and Answerers [RFC3264] can associate identification-
Media Descriptions (m= lines) within SDP Offers and Answers, using tags with "m=" lines within SDP Offers and Answers, using the
the procedures in [RFC5888]. Each mid value uniquely identifies an procedures in [RFC5888]. Each identification-tag uniquely represents
m= line. an "m=" line.
This section defines a new RTP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry mid values within RTCP SDES packets. This section also used to carry identification-tags within RTCP SDES packets. This
defines a new RTP header extension [RFC5285], which can be used to section also defines a new RTP header extension [RFC5285], which is
carry the mid value in RTP packets. used to carry identification-tags in RTP packets.
The SDES item and RTP header extension makes is possible for a The SDES item and RTP header extension make it possible for a
receiver to associate received RTCP- and RTP packets with a specific receiver to associate received RTCP- and RTP packets with a specific
m= line, to which the receiver has assigned a mid value, even if "m=" line, to which the receiver has assigned an identification-tag,
those m= lines are part of the same RTP session. The endpoint even if those "m=" lines are part of the same RTP session. The
informs the remote endpoint about the mid values using the procedures endpoint informs the remote endpoint about the identification-tag
in [RFC5888], and the remote endpoint then inserts the mid values in using the procedures in [RFC5888], and the remote endpoint then
RTCP- and RTP packets sent towards the other endpoint. inserts the identification-tag in RTCP- and RTP packets sent towards
the other endpoint.
NOTE: This text above defines how the mid value is carried in SDP NOTE: This text above defines how identification-tags are carried in
Offers and Answers. The usage of other signalling protocols for SDP Offers and Answers. The usage of other signalling protocols for
carrying the mid value is not prevented, but the usage of such carrying identification-tags is not prevented, but the usage of such
protocols is outside the scope of this document. protocols is outside the scope of this document.
[RFC3550] defines general procedures regarding the RTCP transmission [RFC3550] defines general procedures regarding the RTCP transmission
interval. The RTP MID SDES item SHOULD be sent in the first few RTCP interval. The RTCP MID SDES item SHOULD be sent in the first few
packets sent on joining the session, and SHOULD be sent regularly RTCP packets sent on joining the session, and SHOULD be sent
thereafter. The exact number of RTCP packets in which this SDES item regularly thereafter. The exact number of RTCP packets in which this
is sent is intentionally not specified here, as it will depend on the SDES item is sent is intentionally not specified here, as it will
expected packet loss rate, the RTCP reporting interval, and the depend on the expected packet loss rate, the RTCP reporting interval,
allowable overhead. and the allowable overhead.
The RTP MID header extension SHOULD be included in some RTP packets 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 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 also be useful to include the header extension in RTP packets that
comprise random access points in the media (e.g., with video comprise random access points in the media (e.g., with video
I-frames). The exact number of RTP packets in which this header I-frames). The exact number of RTP packets in which this header
extension is sent is intentionally not specified here, as it will extension is sent is intentionally not specified here, as it will
depend on expected packet loss rate and loss patterns, the overhead depend on expected packet loss rate and loss patterns, the overhead
the application can tolerate, and the importance of immediate receipt the application can tolerate, and the importance of immediate receipt
of the mid value. of the identification-tag.
For robustness purpose, endpoints need to be prepared for situations For robustness purpose, endpoints need to be prepared for situations
where the mid value is delayed, and SHOULD NOT terminate sessions in where the reception of the identification-tag is delayed, and SHOULD
such cases, as the mid value is likely to arrive soon. NOT terminate sessions in such cases, as the identification-tag is
likely to arrive soon.
13.2. RTP MID SDES Item 13.2. RTCP MID SDES Item
0 1 2 3 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 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 ... | MID=TBD | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The mid value payload is UTF-8 encoded, as in SDP. The identification-tag payload is UTF-8 encoded, as in SDP.
The identification-tag is not zero terminated.
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
13.3. RTP MID Header Extension 13.3. RTP MID Header Extension
The payload, containing the mid value, of the RTP MID header The payload, containing the mid value, of the RTP MID header
extension element can be encoded using either the one-byte or two- 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 byte header [RFC5285]. The identification-tag payload is UTF-8
SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, however, that
RTP header extensions that are not a multiple of 32 bits in length
MUST be padded to the next 32-bit boundary using zero bytes; these
padding bytes are not included in the header length field [RFC3550].
14. IANA Considerations 14. IANA Considerations
14.1. New SDES item 14.1. New SDES item
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
This document adds the MID SDES item to the IANA "RTP SDES item
This document adds the MID SDES item to the IANA "RTCP SDES item
types" registry as follows: types" registry as follows:
Value: TBD Value: TBD
Abbrev.: MID Abbrev.: MID
Name: Media Identification Name: Media Identification
Reference: RFCXXXX Reference: RFCXXXX
14.2. New RTP Header Extension URI 14.2. New RTP Header Extension URI
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.]
This document defines a new extension URI in the RTP Compact Header This document defines a new extension URI in the RTP Compact Header
Extensions subregistry of the Real-Time Transport Protocol (RTP) Extensions subregistry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data: Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification Description: Media identification
Contact: christer.holmberg@ericsson.com Contact: christer.holmberg@ericsson.com
Reference: RFCXXXX Reference: RFCXXXX
14.3. New SDP Attribute 14.3. New SDP Attribute
This document defines a new SDP media-level attribute, according to [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
the following data: document.]
Attribute name: bundle-only This document defines a new SDP media-level attribute, 'bundle-only',
Type of attribute: Media-level according to the following data:
Subject to charset: No
Purpose: Request a media description to be accepted Attribute name: bundle-only
in the answer only if kept within a BUNDLE group Type of attribute: media
by the answerer Subject to charset: No
Appropriate values: N/A Purpose: Request a media description to be accepted
Contact name: Christer Holmberg in the answer only if kept within a BUNDLE
Contact e-mail: christer.holmberg@ericsson.com group by the answerer.
Appropriate values: N/A
Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com
Reference: RFCXXXX
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. Bundle does not change which information to the BUNDLE extension. Bundle does not change which information
flows over the network but only changes which ports that 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 is flowing on and thus has very little impact on the security of the
RTP sessions. 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. BUNDLE group.
When the BUNDLE extension is used, the number of SSRC values within a When the BUNDLE extension is used, the number of SSRC values within a
single RTP session increases, which increases the risk of SSRC single RTP session increases, which increases the risk of SSRC
collision. [RFC4568] describes how SSRC collision may weaken SRTP collision. [RFC4568] describes how SSRC collision may weaken SRTP
and SRTCP encryption in certain situations. and SRTCP encryption in certain situations.
skipping to change at page 28, line 40 skipping to change at page 29, line 42
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
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Offer (3) SDP Offer (3)
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
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/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
skipping to change at page 30, line 18 skipping to change at page 32, line 14
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
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
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
16.3. Example: Offerer Adds A Media Description To A BUNDLE Group 16.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows: The example below shows:
o 1. An offer, in which the offerer adds a new "m=" line, o 1. A subsequent offer (the BUNDLE group has been created as part
represented by the "zen" mid value, to a previously negotiated of a previous offer/answer transaction), in which the offerer adds
BUNDLE group, assigns a unique address to the added "m=" line, and a new "m=" line, represented by the "zen" identification-tag, to a
assigns the previously selected offerer BUNDLE address to each of previously negotiated BUNDLE group, assigns a unique address to
the other bundled "m=" lines within the BUNDLE group. the added "m=" line, and assigns the previously selected offerer
BUNDLE address to each of the other bundled "m=" lines within the
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 o 3. A subsequent offer (BAS offer), which is used to perform a
Bundle Address Synchronization (BAS). 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
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
a=mid:zen
b=AS:1000 b=AS:1000
a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
a=mid:zen
b=AS:1000 b=AS:1000
a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Offer (3) SDP Offer (3)
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
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 66 m=video 10000 RTP/AVP 66
a=mid:zen
b=AS:1000 b=AS:1000
a=mid:zen
a=rtpmap:66 H261/90000 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. An offer, in which the offerer moves a bundled "m=" line out o 1. A subsequent offer (the BUNDLE group has been created as part
of a BUNDLE group, assigns a unique address to the moved "m=" of a previous offer/answer transaction), in which the offerer
line, and assigns the offerer BUNDLE address to each other bundled moves a bundled "m=" line out of a BUNDLE group, assigns a unique
"m=" line within the BUNDLE group. address to the moved "m=" line, and assigns the offerer BUNDLE
address to each other bundled "m=" line within the BUNDLE group.
o 2. An answer, in which the answerer moves the "m=" line out of o 2. An answer, in which the answerer moves the "m=" line out of
the BUNDLE group, assigns unique address to the moved "m=" line, the BUNDLE group, assigns unique address to the moved "m=" line,
and assigns the answerer BUNDLE address to each other bundled "m=" and assigns the answerer BUNDLE address to each of the remaining
line within the BUNDLE group. bundled "m=" line within the BUNDLE group.
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
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 50000 RTP/AVP 66 m=video 50000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
16.5. Example: Offerer Disables A Media Description Within A BUNDLE 16.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
The example below shows: The example below shows:
o 1. An offer, in which the offerer disables a bundled "m=" line o 1. A subsequent offer (the BUNDLE group has been created as part
within BUNDLE group, assigns a zero port number the disabled "m=" of a previous offer/answer transaction), in which the offerer
line, and assigns the offerer BUNDLE address to each of the other disables a bundled "m=" line within BUNDLE group, assigns a zero
bundled "m=" lines within the BUNDLE group. port number to the disabled "m=" line, and assigns the offerer
BUNDLE address to each of the other bundled "m=" lines within the
BUNDLE group.
o 2. An answer, in which the answerer moves the disabled "m=" line o 2. An answer, in which the answerer moves the disabled "m=" line
out of the BUNDLE group, assigns a zero port value to the disabled out of the BUNDLE group, assigns a zero port value to the disabled
"m=" line, and assigns the answerer BUNDLE address to each of the "m=" line, and assigns the answerer BUNDLE address to each of the
other bundled "m=" lines within the BUNDLE group. remaining bundled "m=" line within the BUNDLE group.
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
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200 b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000 b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
17. IANA Considerations 17. Acknowledgements
This document requests IANA to register the new SDP Grouping semantic
extension called BUNDLE.
18. 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 extension described in this document is Cullen Jennings. The BUNDLE extension 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, Martin Thomson and Flemming Andreasen for Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
taking the time to read the text along the way, and providing useful Stach and Ari Keraenen for taking the time to read the text along the
feedback. way, and providing useful feedback.
19. 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-12
o Usage of SDP 'extmap' attribute added
o SDP 'bundle-only' attribute scoped with "m=" lines with a zero
port value
o Changes based on WGLC comments from Thomas Stach
o - ICE candidates not assigned to bundle-only m- lines with a zero
port value
o - Editorial changes
o Changes based on WGLC comments from Colin Perkins
o - Editorial changes:
o -- "RTP SDES item" -> "RTCP SDES item"
o -- "RTP MID SDES item" -> "RTCP MID SDES item"
o - Changes in section 10.1.1:
o -- "SHOULD NOT" -> "MUST NOT"
o -- Additional text added to the Note
o - Change to section 13.2:
o -- Clarify that mid value is not zero terminated
o - Change to section 13.3:
o -- Clarify that mid value is not zero terminated
o -- Clarify padding
o Changes based on WGLC comments from Paul Kyzivat
o - Editorial changes:
o Changes based on WGLC comments from Jonathan Lennox
o - Editorial changes:
o - Defintion of SDP bundle-only attribute alligned with structure
in 4566bis draft
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 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 Harald Alvestrand.
o Editorial corrections based on comments from Cullen Jennings. o Editorial corrections based on comments from Cullen Jennings.
o Reference update (RFC 7160). o Reference update (RFC 7160).
o Clarification about RTCP packet sending when RTP/RTCP multiplexing o Clarification about RTCP packet sending when RTP/RTCP multiplexing
is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ is not used (http://www.ietf.org/mail-archive/web/mmusic/current/
skipping to change at page 40, line 42 skipping to change at page 42, line 25
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.
20. References 19. References
20.1. Normative References 19.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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. 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.mmusic-sdp-mux-attributes] [I-D.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-02 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-05
(work in progress), July 2014. (work in progress), November 2014.
20.2. Informative References 19.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 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
skipping to change at page 42, line 19 skipping to change at page 43, line 46
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
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
been whether, in SDP Offers and SDP Answers, the same port number been whether, in SDP Offers and SDP Answers, the same port value
value should be inserted in "m=" lines associated with a BUNDLE should be inserted in "m=" lines associated with a BUNDLE group, as
group, as the purpose of the extension is to negotiate the usage of a the purpose of the extension is to negotiate the usage of a single
single 5-tuple for media associated with the "m=" lines. Issues with address:port combination for media associated with the "m=" lines.
both approaches, discussed in the Appendix have been raised. The Issues with both approaches, discussed in the Appendix have been
outcome was to specify a mechanism which uses SDP Offers with both raised. The outcome was to specify a mechanism which uses SDP Offers
different and identical port number values. with both different and identical port values.
Below are the primary issues that have been considered when defining Below are the primary issues that have been considered when defining
the "BUNDLE" grouping extension: the "BUNDLE" grouping extension:
o 1) Interoperability with existing UAs. o 1) Interoperability with existing UAs.
o 2) Interoperability with intermediary B2BUA- and proxy entities. o 2) Interoperability with intermediary B2BUA- and proxy entities.
o 3) Time to gather, and the number of, ICE candidates. o 3) Time to gather, and the number of, ICE candidates.
skipping to change at page 44, line 29 skipping to change at page 46, line 14
A.3. Usage of port number value zero A.3. Usage of port number value zero
In an SDP Offer or SDP Answer, the media associated with an "m=" line In an SDP Offer or SDP Answer, the media associated with an "m=" line
can be disabled/rejected by setting the port number value to zero. can be disabled/rejected by setting the port number value to zero.
This is different from e.g. using the SDP direction attributes, where This is different from e.g. using the SDP direction attributes, where
RTCP traffic will continue even if the SDP "inactive" attribute is RTCP traffic will continue even if the SDP "inactive" attribute is
indicated for the associated "m=" line. indicated for the associated "m=" line.
If each "m=" line associated with a BUNDLE group would contain If each "m=" line associated with a BUNDLE group would contain
different port number values, and one of those port would be used for different port values, and one of those port values would be used for
the 5-tuple, problems would occur if an endpoint wants to disable/ a BUNDLE address associated with the BUNDLE group, problems would
reject the "m=" line associated with that port, by setting the port occur if an endpoint wants to disable/reject the "m=" line associated
number value to zero. After that, no "m=" line would contain the with that port, by setting the port value to zero. After that, no
port number value which is used for the 5-tuple. In addition, it is "m=" line would contain the port value which is used for the BUNDLE
unclear what would happen to the ICE candidates associated with the address. In addition, it is unclear what would happen to the ICE
"m=" line, as they are also used for the 5-tuple. candidates associated with the "m=" line, as they are also used for
the BUNDLE address.
A.4. B2BUA And Proxy Interoperability A.4. B2BUA And Proxy Interoperability
Some back to back user agents may be configured in a mode where if Some back to back user agents may be configured in a mode where if
the incoming call leg contains an SDP attribute the B2BUA does not the incoming call leg contains an SDP attribute the B2BUA does not
understand, the B2BUS still generates that SDP attribute in the Offer understand, the B2BUS still generates that SDP attribute in the Offer
for the outgoing call leg. Consider an B2BUA that did not understand for the outgoing call leg. Consider an B2BUA that did not understand
the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way.
Further assume that the B2BUA was configured to tear down any call Further assume that the B2BUA was configured to tear down any call
where it did not see any RTCP for 5 minutes. In this cases, if the where it did not see any RTCP for 5 minutes. In this cases, if the
 End of changes. 231 change blocks. 
477 lines changed or deleted 604 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/