| MMUSIC | R. Ejzak |
| Internet-Draft | Alcatel-Lucent |
| Intended status: Informational | 2013 |
| Expires: December 25, 2016 |
Alternatives to BUNDLE
draft-ejzak-mmusic-bundle-alternatives-00
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.
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 December 25, 2016.
Copyright (c) 2013 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.
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. In addition, the grouped m lines are all signaled with the same port number. In the event that BUNDLE negotiation fails, it is still possible to construct separate 5-tuples for each m line by signaling separate port numbers for these m lines in the SDP answer.
Unfortunately, there are some legacy middle boxes that identify an SDP offer with the same port number on multiple m lines as an error, thus failing the call attempt. While it is possible to identify this situation and retry the call without BUNDLE, this is wasteful of system resources and induces undesirable delay in the call setup.
The One-RTP proposal [I-D.alvestrand-one-rtp]is very similar to BUNDLE except that each m line in the SDP offer is signaled with a different port number. It is understood that the endpoints are to use only the port number from the first m line for the multiplexed group. This approach solves the previous legacy case, but causes a problem with other middle boxes that reserve resources based on the multiple port numbers and may later time out due to inactivity, causing the call to drop.
This paper proposes several alternatives to these proposals for consideration. All of these proposals assume the signaling of different port numbers for each m line in the SDP offer to avoid call failure and retry.
Note that in this case if the SDP answerer chooses to not bundle the media then there is no problem. The remainder of the paper will focus primarily on the case where the terminating side selects to bundle media but a middle box might allocate unneeded resources and potentially fail the call due to their inactivity.
Note also that the paper only considers manipulation of the connection and port information in the subsequent m lines of the SDP offer and/or answer. Zero port is not considered due to its very specific meaning on an SDP m line. 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.
Assuming that the middle box allocates resources for each m line in the SDP offer, it will still need to modify those resources upon receipt of the SDP answer. If the SDP answerer signals the same port number for all the bundled m lines, then is there any possibility that the problem can be avoided?
The legacy middle box will have signaled separate port numbers in the forwarded SDP offer so there is still a separate 5-tuple for each m line regardless of the port numbers signaled in the SDP answer. So the middle box will have no choice but to retain the reserved resources after receiving the SDP answer.
In addition, it is possible that the middle box will recognize the use of the same port for the bundle m lines in the SDP answer as an error condition and use the next opportunity to fail the call.
This approach appears to have no value. It seems to always be preferable to include valid but different port numbers in all the subsequent m lines in the SDP answer, even when choosing to bundle.
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 any resources.
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.
It is possible that the middle box will not accept the SDP offer with an unspecified address, although RFC 3264 mandates support for this.
Another problem with this approach is that 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.
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 in the SDP offer, 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.
There is some small risk that the middle box will not recognize the unspecified address (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.
Upon receiving the SDP answer (with separate ports for the subsequent m lines) and recognizing that bundling is selected there is the opportunity to send another SDP offer that might cause the middle box to release extraneous resources.
Signaling the same port for all bundled m lines in the second SDP offer has the same problem as the original BUNDLE proposal if the middle box recognizes this as an error.
Of the alternatives under consideration, the only one that makes sense in the second SDP offer is to modify the connection information for subsequent m lines to indicate the unspecified address. This approach should be effective as long as the middle box supports the unspecified address in SDP, but as long as this is the case it seems preferable to just use the unspecified address for subsequent m lines in the first SDP answer.
Of the approaches presented above, the author is of the opinion that the "unspecified address for subsequent m lines in the SDP answer" is the best choice and the "unspecified address for subsequent m lines in the SDP offer" is a reasonable second choice.
As long as middle boxes support the unspecified address (as RFC 3264 requires them to do), the author's preferred choice successfully completes negotiation of either the bundled or unbundled media case in a single SDP offer/answer transaction. Unfortunately, ICE candidates and middle box resources need to be allocated at least until receipt of the SDP answer.
The second choice avoids any unnecessary ICE candidate or middle box resource allocation and successfully completes negotiation of the preferred bundled media case in a single SDP offer/answer transaction. Unfortunately, the unbundled case (of lower priority) requires Trickle ICE or a second SDP transaction for successful completion.
To be completed.
To be completed.