One document matched: draft-holmberg-mmusic-sdp-multiplex-negotiation-00.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200811" category="std" docName="draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt" obsoletes="" extends="" submissionType="IETF" xml:lang="en">
<front>
    <title abbrev="Multiplexing">
		Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers
	</title>
    <author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
		<organization>Ericsson</organization>
		<address>
			<postal>
				<street>Hirsalantie 11</street>
				<code>02420</code>
				<city>Jorvas</city>
				<country>Finland</country>
			</postal>
        <email>christer.holmberg@ericsson.com</email>
		</address>
    </author>

    <date year="2011" />
    <area>Transport</area>
    <workgroup>MMUSIC Working Group</workgroup>
    <keyword>RTP</keyword>
    <keyword>SDP</keyword>
    <keyword>Multiplexing</keyword>
    <keyword>RTCWEB</keyword>
    <keyword>WEB</keyword>
    <keyword>Browser</keyword>

    <abstract>
		<t>
			This document defines how to use the Session Description Protocol (SDP) in order
			to negotiate the usage of multiplexed media.
		</t>	  
    </abstract>
</front>

<middle>
    <section title="Introduction" toc="default">
		<t>
			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.
		</t>
		<t>
			This document defines a mechanism to negotiate the usage of multiplexing using
			the Session Description Protocol (SDP) <xref format="default" pageno="false" 
			target="RFC4566"/>, by indicating identical "m=" line port number values to every
			media stream that would be part of a multiplex.
		</t>
		<t>
			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 <xref format="default" pageno="false" 
			target="RFC5888"/> extension, MULTIPLEX, which is used to group media that is part
			of a multiplex.
		</t>
		<t>
			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.
		</t>	  
    </section>

    <section title="Conventions" toc="default">
		<t>
			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 <xref
			format="default" pageno="false" target="RFC2119" />.
		</t>
    </section>

    <section title="Applicability Statement" toc="default">
		<t>
			The mechanism in this specification only applies to SDP, when used together with the 
			SDP offer/answer media negotiation mechanism <xref format="default" pageno="false" 
			target="RFC3264"/>.
		</t>		
    </section>

	<section title="SDP Grouping Framework MULTIPLEX Extension Semantics" toc="default">
		<t>
			This section defines a new SDP Grouping Framework extension, MULTIPLEX.
		</t>
		<t>
			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.
		</t>
		<t>
			OPEN ISSUE: We need a reference to the specification defining the actual 
			multiplexing mechanism.
		</t>
    </section>
	
    <section title="SDP Offer/Answer Procedures" toc="default">
		<section title="General" toc="default">
			<t>
				This section defines the SDP offer/answer procedures for
				negotiating the usage of multiplexing.
			</t>
		</section>

		<section anchor="S.offerer" title="SDP Offerer Procedures" toc="default">
			<t>
				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.
			</t>	  
			<t>
				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.
			</t>
			<t>
				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.
			</t>
			<t>
				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.
			</t>
			<t>
				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.
			</t>
			<t>
				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.
			</t>
			<t>
				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.
			</t>
			<t>
				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).
			</t>
		</section>

		<section title="SDP Answer Procedures" toc="default">
			<t>
				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.
			</t>	  
			<t>
				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.
			</t>
			<t>
				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.			
			</t>
		</section>
    </section>

	<section anchor="sec-ice" title="Usage With ICE" toc="default">
		<t>
			When an entity that supports the Interactive Connectivity Establishment (ICE)
			mechanism <xref format="default" pageno="false" target="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.
		</t>
		<t>
			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.
		</t>
		<t>
			The candidate information inserted in an SDP offer or answer MUST be identical for each "m=" line
			associated with a specific MULTIPLEX SDP group.
		</t>
		<t>
			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.
		</t>
    </section>


    <section anchor="sec-security" title="Security Considerations" toc="default">
		<t>
			TBA
		</t>
    </section>

	
    <section anchor="sec-example" title="Example" toc="default">
		<t>
			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.
		</t>
		<figure>
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[
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=
    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		 
    a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host



		 
]]></artwork>
        </figure>
    </section>

	
	
    <section title="IANA Considerations" toc="default">
		<t>
			This document requests IANA to register the new SDP Grouping semantic
			extension called MULTIPLEX.
		</t>
    </section>
		
    <section anchor="sec-acks" title="Acknowledgements" toc="default">
		<t>
			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.
		</t>
    </section>

    <section title="Change Log">
		<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>

		<t>Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-xx
			<list style="symbols">
				<t></t>
			</list>
		</t>
    </section>
</middle>

<back>
    <references title="Normative References">
		<?rfc include="reference.RFC.2119"?>
		<?rfc include="reference.RFC.3261"?>
		<?rfc include="reference.RFC.3264"?>
		<?rfc include="reference.RFC.4566"?>
		<?rfc include="reference.RFC.5888"?>
    </references>

    <references title="Informative References">
		<?rfc include="reference.RFC.5245"?>
    </references>
  </back>
</rfc>