| Internet Engineering Task Force | A. Hutton, Ed. |
| Internet-Draft | T. Stach |
| Intended status: Standards Track | Siemens Enterprise Communications |
| Expires: October 13, 2013 | April 11, 2013 |
Multiplexing Negotiation Using ICE Candidate Extension
draft-hutton-mmusic-bundled-ice-candidates-00
This document describes a mechanism for extending ICE candidates with an optional parameter which can be used to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for multiple RTP streams. In a scenario where a party initiating the negotiation supports ICE [RFC5245] this mechanism provides the ability to provide an SDP offer which is both backwards compatible and able to fully specify the use of bundled media. Therefore, this mechanism allows bundled and non-bundled media to be negotiated in a single offer/answer exchange when both parties support ICE and this extension. The mechanism complements the procedures described in [draft-ietf-mmusic-sdp-bundle-negotiation].
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 (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.
This document describes a mechanism for extending ICE candidates with an optional parameter which can be used to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for multiple RTP streams. In a scenario where a party initiating the negotiation supports ICE [RFC5245] this mechanism provides the ability to provide an SDP offer which is both backwards compatible and able to fully specify the use of bundled media. Therefore, this mechanism allows bundled and non-bundled media to be negotiated in a single offer/answer exchange when both parties support ICE and this extension.
The mechanism complements the procedures within [draft-ietf-mmusic-sdp-bundle-negotiation] with explicitly signalled ports (OPEN ISSUE: Possibly also IP Address for the bundle media in each candidate that may form part of a bundle). If the MMUSIC working group agrees this could be considered as an enhancement for incorporation in to [draft-ietf-mmusic-sdp-bundle-negotiation].
A problem with the existing bundling proposals is that it does not appear possible to create a single initial offer that will allow bundle to be negotiated but maintain interworking with bundle unaware implementations and therefore it is necessary to perform an initial offer/answer exchange which does not fully describe or at least only implicitly describes what the offerer really wants to offer. The existing bundle proposals also don't take account of the fact that when both parties support ICE [RFC5245] the port in the m-line of the initial offer may not be used at all, for example due to a dual stack offer endpoint offering IPv4 and IPv6 addresses in parallel.
Also the existing bundle proposals have not considered some of the more complex ICE scenarios involving multiple candidates. For example when an SDP m-line contains multiple ICE host candidates during dual stack negotiation, the candidates cannot be considered equivalent with regard to bundling with candidates on in another m-line and therefore some way of indicating which candidates can be bundled seems to be desirable. This could be achieved by including the complete bundle transport address (IP and Port) in the candidate or by providing some kind of bundle linkage within the ICE candidate lines.
OPEN ISSUE: Some analysis is required to determine whether it is also necessary to specify the bundle IP Address in the ICE candidate in addition to the bundleport. Explicitly stating the complete transport address for the bundle seems advantageous. This might also be necessary if for example different relay IP addresses are specified for audio and video in the non-bundled case but a single bundled IP address is required.
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 RFC 2119 [RFC2119].
5-tuple: A collection of the following values: source address, source port, destination address, destination port and protocol.
Bundled media: Two or more RTP streams using a single 5-tuple. The RTCP streams associated with the RTP streams also use a single 5-tuple, which might be the same, but can also be different, as the one used by the RTP streams.
This document defines an ICE candidate extension to the ICE candidate with an attribute named "bundleport" which specifies the port to be used to bundle media.
When generating an SDP offer which is to include a bundle group and also ICE candidates the offerer follows the procedures as specified in [draft-ietf-mmusic-sdp-bundle-negotiation] and in addition also includes in each ICE candidate which relates to a bundle the new bundleport extension which specifies the port to be used for the multiplex.
By following the additional procedures specified in this document the following advantages are realised:
An example SDP Offer is shown below. Note that the a=candidate: attributes are split over two lines.
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 192.0.2.2
t=0 0
a=group:BUNDLE 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 2001:db8::1 10000 typ host
bundleport 10000
a=candidate:2 1 UDP 1694498814 192.0.2.2 20000 typ host
bundleport 20000
a=candidate:1 2 UDP 1694498815 2001:db8::2:2 30000 typ srflx
raddr 2001:db8::1 rport 10000 bundleport 30000
a=candidate:2 2 UDP 1694498815 198.51.100.3 40000 typ srflx
raddr 192.0.2.2 rport 20000 bundleport 40000
a=candidate:1 3 UDP 1694498815 2001:db8::3:3 50000 typ relay
raddr 2001:db8::1 rport 10000 bundleport 50000
a=candidate:2 3 UDP 1694498815 203.0.113.4 60000 typ relay
raddr 192.0.2.2 rport 20000 bundleport 60000
m=video 10002 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 2001:db8::1 10002 typ host
bundleport 10000
a=candidate:2 1 UDP 1694498814 192.0.2.2 20002 typ host
bundleport 20000
a=candidate:1 2 UDP 1694498815 2001:db8::2:2 30002 typ srflx
raddr 2001:::1 rport 10002 bundleport 30000
a=candidate:2 2 UDP 1694498815 198.51.100.3 40002 typ srflx
raddr 192.0.2.2 rport 20002 bundleport 40000
a=candidate:1 3 UDP 1694498815 2001:db8::3:3 50002 typ relay
raddr 2001:db8::1 rport 10002 bundleport 50000
a=candidate:2 3 UDP 1694498815 203.0.113.4 60002 typ relay
raddr 192.0.2.2 rport 20002 bundleport 60000
When an SDP Answerer receives an SDP Offer which contains a "BUNDLE" group, and the SDP Answerer accepts the offered "BUNDLE" group, the SDP Answerer MUST generate an SDP Answer as specified in [draft-ietf-mmusic-sdp-bundle-negotiation] with the exception that rather than using the port associated with the first "m=" line in the "BUNDLE" group it MUST use the bundleport from the selected ICE candidates relating to the bundle.
Actually the requirement to use the port associated with the first "m=" line in the "BUNDLE" group whilst waiting for a second offer with identical ports in the m lines does not work in some ICE scenarios. For example when receiving an offer from a dual stack device the port on the "m=" line may refer to the transport for the wrong address family and may not even work if there is no connectivity
The ICE [RFC5245] a=candidate attribute is extended as follows:
candidate-attribute = "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP ;from RFC 4566 port ;port from RFC 4566 SP cand-type [SP rel-addr] [SP rel-port] [SP bundleport] *(SP extension-att-name SP extension-att-value) bundleport = "bundleport" SP port
Alternatively if the IP address and port is fully specified in the a=candidate attribute would be extended as follows:
candidate-attribute = "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP ;from RFC 4566 port ;port from RFC 4566 SP cand-type [SP rel-addr] [SP rel-port] [SP bundle] *(SP extension-att-name SP extension-att-value) bundle = "bundle" SP connection-address SP port
tbd
If this document moves forward, it requests a new extension attribute "bundleport", to be defined for the ICE candidate-attribute to be reserved.
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5245] | Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. |
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. |
| [draft-ietf-mmusic-sdp-bundle-negotiation] | C. Holmberg, H. Alvestrand, C. Jennings , "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers ", 2013. |