Internet DRAFT - draft-holmberg-mmusic-sdp-multiplex-negotiation
draft-holmberg-mmusic-sdp-multiplex-negotiation
MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track September 14, 2011
Expires: March 17, 2012
Multiplexing Negotiation Using Session Description Protocol (SDP) Port
Numbers
draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt
Abstract
This document defines how to use the Session Description Protocol
(SDP) in order to negotiate the usage of multiplexed media.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 17, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Holmberg Expires March 17, 2012 [Page 1]
Internet-Draft Multiplexing September 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3
4. SDP Grouping Framework MULTIPLEX Extension Semantics . . . . . 3
5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . . 4
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. SDP Offerer Procedures . . . . . . . . . . . . . . . . . . 4
5.3. SDP Answer Procedures . . . . . . . . . . . . . . . . . . . 5
6. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Holmberg Expires March 17, 2012 [Page 2]
Internet-Draft Multiplexing September 2011
1. Introduction
In the IETF RTCWEB WG, a need for media multiplexing has been
identified. In order to be able to establish media sessions with
entities that do not support multiplexing, there needs to be a
mechanism to negotiate whether multiplexing will be used or not.
This document defines a mechanism to negotiate the usage of
multiplexing using the Session Description Protocol (SDP) [RFC4566],
by indicating identical "m=" line port number values to every media
stream that would be part of a multiplex.
As defined in RFC 4566, the semantics of multiple "m=" lines using
the same transport address are undefined, and there is no grouping
defined by such means. Instead, an explicit grouping mechanism needs
to be used to express the intended semantics. Therefore, this
specification defines an SDP grouping framework [RFC5888] extension,
MULTIPLEX, which is used to group media that is part of a multiplex.
The mechanism is backward compatible. Entities that do not support
the MULTIPLEX grouping extension, or do not want to enable
multiplexing within the session associated with the SDP offer, are
expected to generate a "normal" SDP answer, are expected to generate
a "normal" SDP answer, using different port numbers for each "m="
line, to the SDP offer. The offerer will still use a single port for
each media, but as the answerer will use separate ports there will be
no multiplexing of media between the endpoints.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
3. Applicability Statement
The mechanism in this specification only applies to SDP, when used
together with the SDP offer/answer media negotiation mechanism
[RFC3264].
4. SDP Grouping Framework MULTIPLEX Extension Semantics
This section defines a new SDP Grouping Framework extension,
MULTIPLEX.
Holmberg Expires March 17, 2012 [Page 3]
Internet-Draft Multiplexing September 2011
The MULTIPEX extension can be indicated using an SDP session-level
"a=group" attribute. Every "m=" line that is grouped together, using
an SDP media-level "a=mid" attribute, is part of a specific
multiplex.
OPEN ISSUE: We need a reference to the specification defining the
actual multiplexing mechanism.
5. SDP Offer/Answer Procedures
5.1. General
This section defines the SDP offer/answer procedures for negotiating
the usage of multiplexing.
5.2. SDP Offerer Procedures
When an SDP offerer wants to offer multiplexed media, it inserts the
same port number value for each "m=" line that is part of the offered
multiplex. In addition, the SDP offerer inserts an SDP session-level
"a=group" attribute, with a "MULTIPLEX" value, and assigns an SDP
media-level "a=mid" attribute value for each "m=" line that is part
of the offered multiplex.
NOTE: If the SDP offerer wants to disable a specific stream within a
multiplex, it will use a zero port number value for the "m=" line
associated with the stream.
If the associated SDP answer includes the session-level "a=group"
attribute, with a "MULTIPLEX" value, and associated "m=" lines with
identical port number values, the SDP offerer can enable media
multiplexing between the entities.
If the associated SDP does not include the session-level "a=group"
attribute, with a "MULTIPLEX" value, the SDP offerer MUST NUT enable
media multiplexing between the entities, even if two or more "m="
lines in the SDP answer contain identical port number values.
If the SDP answer indicates that multiplexing will not be enabled,
the offerer will still receive multiple media on the single port that
it included in the SDP offer, and it normally will be able to
separate each individual media. The default mechanism for doing this
is by using a 5-tuple based mapping for each individual media. If
the offerer is aware of the SSRC values that the remote peer will use
in the media it sends, and the values will be unique for each media,
the offerer can also separate media based on the SSRC values.
Holmberg Expires March 17, 2012 [Page 4]
Internet-Draft Multiplexing September 2011
NOTE: Assuming symmetric media is used, the offerer can use the port
information from the SDP answer in order to create the 5-tuple
mapping for each media.
If the offerer is not able to separate multiple media on a single
port, it MUST send a new SDP offer, without using the "MULTIPLEX"
grouping, where each media (m= line) is given a different port number
value.
NOTE: If the SDP offer is rejected, and the SDP offerer has reasons
to believe that the rejection is due to the fact that the SDP offer
contained identical "m=" line port number values, the SDP offerer
might send a new SDP offer, without offered multiplex (and with
separate port number values for each "m=" line).
5.3. SDP Answer Procedures
When an SDP answerer receives an SDP offer, offering multiplexing, if
the SDP answerer accepts the offered multiplexing, it MUST include a
session-level "a=group" attribute, with a "MULTIPLEX" value, in the
SDP answer. In addition, the SDP answerer assigns an SDP media-level
"a=mid" attribute value for each "m=" line that is part of the
multiplex.
If the SDP answerer does not accept the offered multiplex, it MUST
NOT include a session-evel "a=group" attribute, with a "MULTIPLEX"
value, in the SDP answer. In addition, it MUST assign separate port
number values for each "m=" line in the SDP answer.
NOTE: If the SDP answerer wants to disable a specific stream within a
multiplex, it will use a zero port number value for the "m=" line
associated with the stream.
6. Usage With ICE
When an entity that supports the Interactive Connectivity
Establishment (ICE) mechanism [RFC5245] sends an SDP offer, it MUST
include ICE candidates for each "m=" line of the SDP offer, even if
it offers multiplexing and the SDP "m=" line port value numbers are
identical. This is true also for subsequent SDP offers, when the
usage of multiplexing has previously been negotiated.
When an entity that supports ICE and multiplexing receives an SDP
offer, offering multiplexing and ICE, if it accepts the multiplex,
and ICE, it MUST include ICE candidates for each "m=" line of the SDP
answer, even if the SDP "m=" line port value numbers are identical.
Holmberg Expires March 17, 2012 [Page 5]
Internet-Draft Multiplexing September 2011
The candidate information inserted in an SDP offer or answer MUST be
identical for each "m=" line associated with a specific MULTIPLEX SDP
group.
Once the usage of multiplexing has been negotiated, ICE connectivity
checks and keep-alives only needs to be performed for the whole
multiplex, represented by a MULTIPLEX SDP group, instead of for
individual m= lines associated with the multiplex.
7. Security Considerations
TBA
8. Example
The example below shows an SDP offer, where multiplexing is offered.
The example also shows two SDP answer alternatives: one where
multiplexing is accepted, and one where multiplexing is rejected (or,
not even supported) by the SDP answerer.
SDP Offer (Multiplexing offered)
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 host.atlanta.com
t=0 0
a=group:MULTIPLEX foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
SDP Answer (Multiplexing accepted)
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s=
Holmberg Expires March 17, 2012 [Page 6]
Internet-Draft Multiplexing September 2011
c=IN IP4 host.biloxi.com
t=0 0
a=group:MULTIPLEX foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
SDP Answer (Multiplexing not accepted)
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s=
c=IN IP4 host.biloxi.com
t=0 0
m=audio 20000 RTP/AVP 0
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32
b=AS:1000
a=rtpmap:32 MPV/90000
SDP Offer with ICE (Multiplexing offered)
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 host.atlanta.com
t=0 0
a=group:MULTIPLEX foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
Holmberg Expires March 17, 2012 [Page 7]
Internet-Draft Multiplexing September 2011
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
9. IANA Considerations
This document requests IANA to register the new SDP Grouping semantic
extension called MULTIPLEX.
10. Acknowledgements
The usage of the SDP grouping mechanism is based on a similar
alternative proposed by Harald Alvestrand. The SDP examples are also
modified versions from the ones in the Alvestrand proposal.
11. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-xx
o
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Holmberg Expires March 17, 2012 [Page 8]
Internet-Draft Multiplexing September 2011
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
12.2. Informative References
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires March 17, 2012 [Page 9]
