One document matched: draft-ejzak-mmusic-bundle-alternatives-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY BUNDLE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-00.xml">
<!ENTITY SHIM SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-transport-multiplexing-02.xml">
<!ENTITY muxarchitecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-multiplex-architecture-01.xml">
<!ENTITY maxssrc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-max-ssrc-01.xml">
<!ENTITY rtpmux SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-rosenberg-rtcweb-rtpmux-00.xml">
<!ENTITY rtpusage SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtcweb-rtp-usage-02.xml">
<!ENTITY ssrcdemux SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.peterson-rosenberg-avt-rtp-ssrc-demux.xml">
<!ENTITY msid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.alvestrand-mmusic-msid.xml">
<!ENTITY OneRTP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.alvestrand-one-rtp.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC5761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5761.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ejzak-mmusic-bundle-alternatives-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
        or pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="BUNDLE alternatives">Alternatives to BUNDLE</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Richard Ejzak" initials="R." 
            surname="Ejzak">
      <organization>Alcatel-Lucent</organization>

      <address>
        <postal>
          <street>1960 Lucent Lane</street>

          <!-- Reorder these if your country does things differently -->

          <city>Naperville</city>

          <region>Illinois</region>

          <code>60563-1594</code>

          <country>US</country>
        </postal>

        <email>richard.ejzak@alcatel-lucent.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2013" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>RAI</area>

    <workgroup>MMUSIC</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

   

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This paper discusses some potential modifications to the BUNDLE proposal for multiplexing of multiple media types within a single 5-tuple to address limitations of the current proposal and alternatives already considered by MMUSIC.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>BUNDLE <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> provides for the multiplexing of the media associated with multiple SDP <xref target="RFC4566"></xref> m lines into a single 5-tuple and RTP <xref target="RFC3550"></xref> session, thus providing many potential advantages in reducing the messages needed for ICE <xref target="RFC5245"></xref> candidate gathering (particularly for server reflexive candidates) and reducing the messaging for DTLS <xref target="RFC6347"></xref> key exchange. BUNDLE is signaled in an SDP offer by using the grouping framework to identify those m lines that are to share a single 5-tuple. The grouped m lines are all signaled with different port numbers in the first SDP offer/answer exchange to allow for successful negotiation without BUNDLE. This is a change from the previous version of BUNDLE, which signaled the same port for each bundled m line. The change was needed to work with legacy intermediaries that would fail the call on receipt an SDP offer with the same port on multiple m lines. In the event that BUNDLE negotiation succeeds, each subsequent SDP offer is sent with the same port number for each valid m line in the bundle. This is done to clearly signal to intermediaries the 5-tuple in use for each m line.</t>
    </section>

    <section title="Issues with BUNDLE">
      <t>BUNDLE always requires at least two SDP offer/answer exchanges to negotiate the (preferred) use of bundled media, but only one offer/answer exchange to reject bundled media. BUNDLE is intended to minimize signaling rather than to increase it - and particularly the more expensive out-of-band signaling.</t>

      <t>Since the answerer can reject individual m lines (including the first one), it's not clear which 5-tuple will be in use for the bundle until the second offer/answer exchange completes, delaying call setup time in this case.</t>

      <t>In the event that a subsequent SDP offer/answer exchange is needed later during the session, BUNDLE requires the signaling of the same port for each bundled m line. If there is an intermediary in the session performing 3pcc procedures as a B2BUA, then the intermediary may send an empty (SDP-less) re-INVITE request to a WebRTC endpoint to trigger sending of an SDP offer, which is a common 3pcc scenario. If the purpose of the empty re-INVITE is to establish a connection to a different media endpoint and the SDP offer is forwarded to the new endpoint via a legacy intermediary that requires unique ports on m lines, then the 3pcc procedure will fail and there is no simple work-around. While it is possible to provide an API option to request a new offer with different port numbers, there is no reliable way to anticipate when such a 3pcc scenario might occur so there is still the risk of 3pcc scenario failure.</t>
    </section>

    <section title="Potential solutions">
      <t>This paper proposes two modifications to BUNDLE for consideration. As with the current version of BUNDLE, these proposals assume the signaling of different port numbers for each m line in the SDP offer to avoid call failure and retry. Since the proposals address different scenarios and are compatible with one another, both could be adopted, as also discussed below as a "hybrid" option.</t>
      
      <t>Note that the paper only considers manipulation of the connection and port information in the subsequent m lines of the SDP offer and/or answer (in particular the use of the unspecified address). Zero port is not considered due to its very specific meaning on an SDP m line. There are also some restrictions on the handling of DTLS crypto information since this is shared among the bundled m lines. Changes to bandwidth, directionality, or other attributes are not considered since they are all needed to signal characteristics of the media associated with the m line.</t>
      
      <t>This paper does not discuss the syntax of the unspecified address for IPv6 as this has been covered elsewhere.</t>
      
      <section title="Unspecified address for subsequent m lines in SDP offer">
        <t>This approach borrows a mechanism from Trickle ICE to avoid the signaling of any candidates for the subsequent m lines in the SDP offer. The middle box will not allocate resources for these m lines when forwarding the SDP offer, and the SDP answerer will usually respond with the unspecified address for these m lines. Even if the SDP answer includes valid connection information for these m lines, the middle box will still not allocate separate transport flows for them.</t>

        <t>If the SDP answerer chooses to reject the first m line(s) in the bundle group in the SDP offer (by setting port in the m line to zero), it places the intended port, connection, candidate and DTLS crypto information for the bundle in the first valid m line of the SDP answer and includes the unspecified address for all other m lines in the bundle group. Because of this, it is understood by both endpoints that the 5-tuple connection, port and DTLS crypto information is to be based on the first valid m line in the SDP offer and the first valid m line in the SDP answer. It is possible for this information to be included in different m lines in the answer compared to the offer, but with this rule there is no ambiguity as to the parameters of the transport connection, and the intermediary only sees this SDP exchange if it has previously forwarded an indication of support for BUNDLE.</t>

       <t>In this relatively rare case where the answerer rejects the first (usually highest priority) m line, the offerer should send an updated offer acknowledging rejection of the initial m line(s) (with zero port), and with the transport information already in use for the bundle moved to the new first valid m line. Simple intermediaries that only look at transport information in the SDP, e.g., to open pinholes, would be confused without a second SDP offer.</t>

        <t>For subsequent offers, the offerer will put the port, connection, candidate and DTLS crypto information in use for the bundle in the first valid m line of the new SDP offer to start the process again.</t>

        <t>If the SDP answerer chooses to not bundle media, then the SDP offerer will either need to perform Trickle ICE, if supported, or to send another SDP offer with valid connection, candidate and port information for each m line.</t>

        <t>The primary advantage of this approach is that it is unnecessary to allocate either any ICE candidates for the subsequent m lines or any middle box resources for these m lines.</t>

        <t>Another advantage of this approach is that media setup completes in one SDP offer/answer exchange for the most common scenarios with BUNDLE where the first bundled m line is acccepted by the answerer. The need of a second SDP offer/answer to support the less-preferred non-bundle scenario or to support the unlikely answerer's rejection of the first m line should be of less concern.</t>

        <t>This approach also eliminates redundant (and potentially conflicting) transport information from multiple m lines in both SDP offers and answers, thus improving readability and slightly decreasing the size of the SDP messages.</t>
        
        <t>It is possible that the middle box will not accept the SDP offer with an unspecified address, although RFC 3264 mandates support for this.</t>

        <t>RFC 3264 indicates that the use of unspecified address for an m line signals that "neither RTP nor RTCP should be sent to the peer". It is understood with the BUNDLE extension defined here that this text is modified to mean that no RTP or RTCP is sent using the transport parameters defined for the media line.</t>
        
      </section>
            
      <section title="Unspecified address for subsequent m lines in SDP answer">
        <t>To further reduce the potential for unsupported signaling at middle boxes and to avoid problems with the unbundled case, the solution might still signal valid connection and port information for all m lines in the bundle group of the first SDP offer (as in the current BUNDLE draft), thus potentially causing the middle box to unnecessarily allocate resources. But if the SDP answerer decides to bundle media, then it can signal the unspecified address for the subsequent m lines in the bundle.</t>

        <t>With this approach, the middle box recognizing the unspecified address in subsequent m lines will release extraneous resources and avoid failure due to inactivity.</t>

        <t>If the SDP answerer chooses to reject the first m line(s) in the bundle group in the SDP offer (by setting port in the m line to zero), it places the intended port, connection, candidate and DTLS crypto information for the bundle in the first valid m line of the SDP answer and includes the unspecified address for all other m lines in the bundle group. Because of this, it is understood by both endpoints that the 5-tuple connection, port and DTLS crypto information is to be based on the first valid m line in the SDP offer and the first valid m line in the SDP answer. It is possible for this information to be included in different m lines in the answer compared to the offer, but with this rule there is no ambiguity as to the parameters of the transport connection, and the intermediary only sees this SDP exchange if it has previously forwarded an indication of support for BUNDLE.</t>

       <t>In this relatively rare case where the answerer rejects the first (usually highest priority) m line, the offerer should send an updated offer acknowledging rejection of the initial m line(s) (with zero port), and with the transport information already in use for the bundle moved to the new first valid m line. Note in this case that the new SDP offer still includes valid port and connection information for all other valid m lines in the bundle group to be prepared for any 3pcc scenario. Simple intermediaries that only look at transport information in the SDP, e.g., to open pinholes, would be confused without a second SDP offer.</t>

        <t>For subsequent offers, the offerer will put the port, connection, candidate and DTLS crypto information in use for the bundle in the first valid m line of the new SDP offer to start the process again. The new SDP offer still includes valid port and connection information for all other valid m lines in the bundle group.</t>

        <t>This approach is robust in the presence of 3pcc scenarios that forward SDP to different endpoints. This approach avoids sending the unspecified address to intermediaries that have not already indicated support for BUNDLE.</t>

        <t>This approach also eliminates redundant (and potentially conflicting) transport information from multiple m lines in the SDP answer, thus improving readability and slightly decreasing the size of the SDP messages.</t>
        
        <t>There is some small risk that the middle box will not recognize the unspecified address in the SDP answer (even though its support is mandated), but this risk is limited to the bundled case since the SDP for the unbundled case is not impacted.</t>

        <t>This approach has the disadvantage that the offerer must allocate connection and candidate information for all m lines in the bundle even when only one set of transportation information is used in the bundle case.</t>
      </section>

      <section title="Hybrid approach">
        <t>The two approaches "unspecified address for subsequent m lines in SDP offer" (option O) and "unspecified address for subsequent m lines in SDP answer" (option A) can be combined into a hybrid approach as follows.</t>

        <t>Option A is the default option for the initial SDP offer/answer exchange for a new session with an unknown endpoint. This minimizes potential problems with intermediaries and allows for completion of media setup with one SDP offer/answer exchange for most bundled cases and all non-bundled cases.</t>

        <t>Option O can also be used for the initial SDP offer/answer exchange when it is known that bundle is likely to succeed and there is no concern with compatibility at intermediaries.</t>

        <t>Option O is the default option for subsequent SDP offer/answer exchanges during a session once it is established that both endpoints and intermediaries support BUNDLE.</t>

        <t>Option A is used for subsequent SDP offer/answer exchanges during a session if BUNDLE is not negotiated during the initial exchange or if there is any potential for a 3pcc scenario sending signaling through a new and potentially incompatible intermediary.</t>

        <t>This hybrid approach combines the best features of both alternatives and provides considerable flexibility in fine tuning the SDP offer/answer exchange for different applications.</t>

      </section>
    </section>
    
    <section title="Discussion">
      <t>Of the approaches presented in the paper, the author prefers the hybrid modification of BUNDLE described above over either individual approach and prefers all of them over the current BUNDLE.</t>

      <t>The hybrid approach allows completion of media and transport negotiation in one SDP offer/exchange in most cases, and most importantly when successfully negotiating the bundling of media.</t>

      <t>The hybrid approach is consistent with 3pcc using either signaling option, thus avoiding potential 3pcc failure scenarios.</t>

      <t>The hybrid approach minimizes redundant transport related information in the bundled m lines thus slightly reducing SDP size and processing requirements.</t>

      <t>The hybrid approach allows for customization of the procedures to simplify common (e.g., WebRTC only) cases and to avoid allocation of transport resources when they are not needed.</t>
      
      <t>There is some risk in including the unspecified address for certain m lines in the SDP. This risk can be limited to exposing the unspecified address only in the SDP answer to intermediaries that have already signaled support for this extended BUNDLE proposal in the forwarded SDP offer. Since support for the unspecified address is mandated by RFC 3264, this seems like a small risk.</t>
     </section>
    
     <section anchor="IANA" title="IANA Considerations">
      <t>To be completed.</t>

      </section>

    <section anchor="Security" title="Security Considerations">
      <t>To be completed.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &BUNDLE;
      
      &RFC3550;
      
      &RFC5245;
      
      &RFC6347;
      
       &RFC4566;

    </references>    
 
  </back>
</rfc>