Alternatives to BUNDLE
draft-ejzak-mmusic-bundle-alternatives-01

Abstract

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.

Status of This Memo

This Internet-Draft is submitted 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 October 13, 2013.

Copyright Notice

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.

1. Introduction
2. Issues with BUNDLE
3. Potential solutions
3.1. Unspecified address for subsequent m lines in SDP offer
3.2. Unspecified address for subsequent m lines in SDP answer
3.3. Hybrid approach
4. Discussion
5. IANA Considerations
6. Security Considerations
7. Informative References
Author's Address

1. Introduction

BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] provides for the multiplexing of the media associated with multiple SDP [RFC4566] m lines into a single 5-tuple and RTP [RFC3550] session, thus providing many potential advantages in reducing the messages needed for ICE [RFC5245] candidate gathering (particularly for server reflexive candidates) and reducing the messaging for DTLS [RFC6347] 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.

2. Issues with BUNDLE

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.

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.

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.

3. Potential solutions

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.

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.

This paper does not discuss the syntax of the unspecified address for IPv6 as this has been covered elsewhere.

3.1. Unspecified address for subsequent m lines in SDP offer

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.

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.

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.

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.

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.

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.

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.

It is possible that the middle box will not accept the SDP offer with an unspecified address, although RFC 3264 mandates support for this.

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.

3.2. Unspecified address for subsequent m lines in SDP answer

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.

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

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.

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.

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.

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.

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.

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.

3.3. Hybrid approach

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.

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.

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.

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.

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.

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.

4. Discussion

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.

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.

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

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

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.

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.

5. IANA Considerations

To be completed.

6. Security Considerations