Internet DRAFT - draft-hutton-mmusic-bundled-ice-candidates
draft-hutton-mmusic-bundled-ice-candidates
Internet Engineering Task Force A. Hutton, Ed.
Internet-Draft T. Stach
Intended status: Standards Track Siemens Enterprise Communications
Expires: September 29, 2013 March 28, 2013
Multiplexing Negotiation Using ICE Candidate Extension
draft-hutton-mmusic-bundled-ice-candidates-00
Abstract
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].
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 September 29, 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
Hutton & Stach Expires September 29, 2013 [Page 1]
Internet-Draft BUNDLE WITH ICE CANDIDATES March 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SDP Offerer Procedures . . . . . . . . . . . . . . . . . . . 3
4. SDP Answerer Procedures . . . . . . . . . . . . . . . . . . . 5
5. Extension to ICE candidate attribute . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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
Hutton & Stach Expires September 29, 2013 [Page 2]
Internet-Draft BUNDLE WITH ICE CANDIDATES March 2013
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.
1.1. Requirements Language
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].
2. Terminology
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.
3. SDP Offerer Procedures
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
Hutton & Stach Expires September 29, 2013 [Page 3]
Internet-Draft BUNDLE WITH ICE CANDIDATES March 2013
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:
o In the case when the answerer supports ICE the initial offer can
be both bundle and non-bundle compatible.
o Only one offer/answer cycle is needed to negotiate bundle or non-
bundle cases. A second offer/answer may be needed following the
initial negotiation which is normal ICE procedures
o It works for the dual stack scenario in which the port eventually
used may only initially be signalled in the candidate line..
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
Hutton & Stach Expires September 29, 2013 [Page 4]
Internet-Draft BUNDLE WITH ICE CANDIDATES March 2013
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
4. SDP Answerer Procedures
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
5. Extension to ICE candidate attribute
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]
Hutton & Stach Expires September 29, 2013 [Page 5]
Internet-Draft BUNDLE WITH ICE CANDIDATES March 2013
[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
6. Acknowledgements
tbd
7. IANA considerations
If this document moves forward, it requests a new extension attribute
"bundleport", to be defined for the ICE candidate-attribute to be
reserved.
8. Security Considerations
TBD
Hutton & Stach Expires September 29, 2013 [Page 6]
Internet-Draft BUNDLE WITH ICE CANDIDATES March 2013
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[draft-ietf-mmusic-sdp-bundle-negotiation]
C. Holmberg, H. Alvestrand, C. Jennings , "Multiplexing
Negotiation Using Session Description Protocol (SDP) Port
Numbers ", 2013, <http://tools.ietf.org/html/draft-ietf-
mmusic-sdp-bundle-negotiation>.
Authors' Addresses
Andrew Hutton (editor)
Siemens Enterprise Communications
Technology Drive
Nottingham NG9 1LA
UK
Email: andrew.hutton@siemens-enterprise.com
Thomas Stach
Siemens Enterprise Communications
Dietrichgasse 27-29
Vienna 1030
AT
Email: thomas.stach@siemens-enterprise.com
Hutton & Stach Expires September 29, 2013 [Page 7]
