Internet DRAFT - draft-ejzak-mmusic-bundle-alternatives
draft-ejzak-mmusic-bundle-alternatives
MMUSIC R. Ejzak
Internet-Draft Alcatel-Lucent
Intended status: Informational February 26, 2013
Expires: August 30, 2013
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 August 30, 2013.
Copyright Notice
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.
Ejzak Expires August 30, 2013 [Page 1]
Internet-Draft BUNDLE alternatives February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Issues with BUNDLE . . . . . . . . . . . . . . . . . . . . . . 3
3. Potential solutions . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Unspecified address for subsequent m lines in SDP offer . . 4
3.2. Unspecified address for subsequent m lines in SDP
answer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Hybrid approach . . . . . . . . . . . . . . . . . . . . . . 7
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Ejzak Expires August 30, 2013 [Page 2]
Internet-Draft BUNDLE alternatives February 2013
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
Ejzak Expires August 30, 2013 [Page 3]
Internet-Draft BUNDLE alternatives February 2013
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
Ejzak Expires August 30, 2013 [Page 4]
Internet-Draft BUNDLE alternatives February 2013
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.
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.
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.
Ejzak Expires August 30, 2013 [Page 5]
Internet-Draft BUNDLE alternatives February 2013
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.
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. 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
Ejzak Expires August 30, 2013 [Page 6]
Internet-Draft BUNDLE alternatives February 2013
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.
Ejzak Expires August 30, 2013 [Page 7]
Internet-Draft BUNDLE alternatives February 2013
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
To be completed.
7. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
Using Session Description Protocol (SDP) Port Numbers",
draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in
progress), February 2012.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Ejzak Expires August 30, 2013 [Page 8]
Internet-Draft BUNDLE alternatives February 2013
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
Author's Address
Richard Ejzak
Alcatel-Lucent
1960 Lucent Lane
Naperville, Illinois 60563-1594
US
Email: richard.ejzak@alcatel-lucent.com
Ejzak Expires August 30, 2013 [Page 9]
