idnits 2.17.1 draft-hutton-mmusic-bundled-ice-candidates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5245]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2013) is 4046 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4566' is defined on line 280, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Hutton, Ed. 3 Internet-Draft T. Stach 4 Intended status: Standards Track Siemens Enterprise Communications 5 Expires: September 29, 2013 March 28, 2013 7 Multiplexing Negotiation Using ICE Candidate Extension 8 draft-hutton-mmusic-bundled-ice-candidates-00 10 Abstract 12 This document describes a mechanism for extending ICE candidates with 13 an optional parameter which can be used to negotiate the usage of 14 bundled media, which refers to the usage of a single 5-tuple for 15 multiple RTP streams. In a scenario where a party initiating the 16 negotiation supports ICE [RFC5245] this mechanism provides the 17 ability to provide an SDP offer which is both backwards compatible 18 and able to fully specify the use of bundled media. Therefore, this 19 mechanism allows bundled and non-bundled media to be negotiated in a 20 single offer/answer exchange when both parties support ICE and this 21 extension. The mechanism complements the procedures described in 22 [draft-ietf-mmusic-sdp-bundle-negotiation]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 29, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. SDP Offerer Procedures . . . . . . . . . . . . . . . . . . . 3 62 4. SDP Answerer Procedures . . . . . . . . . . . . . . . . . . . 5 63 5. Extension to ICE candidate attribute . . . . . . . . . . . . 5 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 This document describes a mechanism for extending ICE candidates with 73 an optional parameter which can be used to negotiate the usage of 74 bundled media, which refers to the usage of a single 5-tuple for 75 multiple RTP streams. In a scenario where a party initiating the 76 negotiation supports ICE [RFC5245] this mechanism provides the 77 ability to provide an SDP offer which is both backwards compatible 78 and able to fully specify the use of bundled media. Therefore, this 79 mechanism allows bundled and non-bundled media to be negotiated in a 80 single offer/answer exchange when both parties support ICE and this 81 extension. 83 The mechanism complements the procedures within 84 [draft-ietf-mmusic-sdp-bundle-negotiation] with explicitly signalled 85 ports (OPEN ISSUE: Possibly also IP Address for the bundle media in 86 each candidate that may form part of a bundle). If the MMUSIC 87 working group agrees this could be considered as an enhancement for 88 incorporation in to [draft-ietf-mmusic-sdp-bundle-negotiation]. 90 A problem with the existing bundling proposals is that it does not 91 appear possible to create a single initial offer that will allow 92 bundle to be negotiated but maintain interworking with bundle unaware 93 implementations and therefore it is necessary to perform an initial 94 offer/answer exchange which does not fully describe or at least only 95 implicitly describes what the offerer really wants to offer. The 96 existing bundle proposals also don't take account of the fact that 97 when both parties support ICE [RFC5245] the port in the m-line of the 98 initial offer may not be used at all, for example due to a dual stack 99 offer endpoint offering IPv4 and IPv6 addresses in parallel. 101 Also the existing bundle proposals have not considered some of the 102 more complex ICE scenarios involving multiple candidates. For 103 example when an SDP m-line contains multiple ICE host candidates 104 during dual stack negotiation, the candidates cannot be considered 105 equivalent with regard to bundling with candidates on in another 106 m-line and therefore some way of indicating which candidates can be 107 bundled seems to be desirable. This could be achieved by including 108 the complete bundle transport address (IP and Port) in the candidate 109 or by providing some kind of bundle linkage within the ICE candidate 110 lines. 112 OPEN ISSUE: Some analysis is required to determine whether it is also 113 necessary to specify the bundle IP Address in the ICE candidate in 114 addition to the bundleport. Explicitly stating the complete 115 transport address for the bundle seems advantageous. This might also 116 be necessary if for example different relay IP addresses are 117 specified for audio and video in the non-bundled case but a single 118 bundled IP address is required. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Terminology 128 5-tuple: A collection of the following values: source address, source 129 port, destination address, destination port and protocol. 131 Bundled media: Two or more RTP streams using a single 5-tuple. The 132 RTCP streams associated with the RTP streams also use a single 133 5-tuple, which might be the same, but can also be different, as the 134 one used by the RTP streams. 136 3. SDP Offerer Procedures 138 This document defines an ICE candidate extension to the ICE candidate 139 with an attribute named "bundleport" which specifies the port to be 140 used to bundle media. 142 When generating an SDP offer which is to include a bundle group and 143 also ICE candidates the offerer follows the procedures as specified 144 in [draft-ietf-mmusic-sdp-bundle-negotiation] and in addition also 145 includes in each ICE candidate which relates to a bundle the new 146 bundleport extension which specifies the port to be used for the 147 multiplex. 149 By following the additional procedures specified in this document the 150 following advantages are realised: 152 o In the case when the answerer supports ICE the initial offer can 153 be both bundle and non-bundle compatible. 155 o Only one offer/answer cycle is needed to negotiate bundle or non- 156 bundle cases. A second offer/answer may be needed following the 157 initial negotiation which is normal ICE procedures 159 o It works for the dual stack scenario in which the port eventually 160 used may only initially be signalled in the candidate line.. 162 An example SDP Offer is shown below. Note that the a=candidate: 163 attributes are split over two lines. 165 v=0 166 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com 167 s= 168 c=IN IP4 192.0.2.2 169 t=0 0 170 a=group:BUNDLE foo bar 171 m=audio 10000 RTP/AVP 0 8 97 172 a=mid:foo 173 b=AS:200 174 a=rtpmap:0 PCMU/8000 175 a=rtpmap:8 PCMA/8000 176 a=rtpmap:97 iLBC/8000 177 a=candidate:1 1 UDP 1694498815 2001:db8::1 10000 typ host 178 bundleport 10000 179 a=candidate:2 1 UDP 1694498814 192.0.2.2 20000 typ host 180 bundleport 20000 181 a=candidate:1 2 UDP 1694498815 2001:db8::2:2 30000 typ srflx 182 raddr 2001:db8::1 rport 10000 bundleport 30000 183 a=candidate:2 2 UDP 1694498815 198.51.100.3 40000 typ srflx 184 raddr 192.0.2.2 rport 20000 bundleport 40000 185 a=candidate:1 3 UDP 1694498815 2001:db8::3:3 50000 typ relay 186 raddr 2001:db8::1 rport 10000 bundleport 50000 187 a=candidate:2 3 UDP 1694498815 203.0.113.4 60000 typ relay 188 raddr 192.0.2.2 rport 20000 bundleport 60000 189 m=video 10002 RTP/AVP 31 32 190 a=mid:bar 191 b=AS:1000 192 a=rtpmap:31 H261/90000 193 a=rtpmap:32 MPV/90000 194 a=candidate:1 1 UDP 1694498815 2001:db8::1 10002 typ host 195 bundleport 10000 196 a=candidate:2 1 UDP 1694498814 192.0.2.2 20002 typ host 197 bundleport 20000 198 a=candidate:1 2 UDP 1694498815 2001:db8::2:2 30002 typ srflx 199 raddr 2001:::1 rport 10002 bundleport 30000 200 a=candidate:2 2 UDP 1694498815 198.51.100.3 40002 typ srflx 201 raddr 192.0.2.2 rport 20002 bundleport 40000 202 a=candidate:1 3 UDP 1694498815 2001:db8::3:3 50002 typ relay 203 raddr 2001:db8::1 rport 10002 bundleport 50000 204 a=candidate:2 3 UDP 1694498815 203.0.113.4 60002 typ relay 205 raddr 192.0.2.2 rport 20002 bundleport 60000 207 4. SDP Answerer Procedures 209 When an SDP Answerer receives an SDP Offer which contains a "BUNDLE" 210 group, and the SDP Answerer accepts the offered "BUNDLE" group, the 211 SDP Answerer MUST generate an SDP Answer as specified in 212 [draft-ietf-mmusic-sdp-bundle-negotiation] with the exception that 213 rather than using the port associated with the first "m=" line in the 214 "BUNDLE" group it MUST use the bundleport from the selected ICE 215 candidates relating to the bundle. 217 Actually the requirement to use the port associated with the first 218 "m=" line in the "BUNDLE" group whilst waiting for a second offer 219 with identical ports in the m lines does not work in some ICE 220 scenarios. For example when receiving an offer from a dual stack 221 device the port on the "m=" line may refer to the transport for the 222 wrong address family and may not even work if there is no 223 connectivity 225 5. Extension to ICE candidate attribute 227 The ICE [RFC5245] a=candidate attribute is extended as follows: 229 candidate-attribute = "candidate" ":" foundation SP component-id SP 230 transport SP 231 priority SP 232 connection-address SP ;from RFC 4566 233 port ;port from RFC 4566 234 SP cand-type 235 [SP rel-addr] 237 [SP rel-port] 238 [SP bundleport] 239 *(SP extension-att-name SP 240 extension-att-value) 242 bundleport = "bundleport" SP port 244 Alternatively if the IP address and port is fully specified in the 245 a=candidate attribute would be extended as follows: 247 candidate-attribute = "candidate" ":" foundation SP component-id SP 248 transport SP 249 priority SP 250 connection-address SP ;from RFC 4566 251 port ;port from RFC 4566 252 SP cand-type 253 [SP rel-addr] 254 [SP rel-port] 255 [SP bundle] 256 *(SP extension-att-name SP 257 extension-att-value) 259 bundle = "bundle" SP connection-address SP port 261 6. Acknowledgements 263 tbd 265 7. IANA considerations 267 If this document moves forward, it requests a new extension attribute 268 "bundleport", to be defined for the ICE candidate-attribute to be 269 reserved. 271 8. Security Considerations 273 TBD 275 9. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 281 Description Protocol", RFC 4566, July 2006. 283 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 284 (ICE): A Protocol for Network Address Translator (NAT) 285 Traversal for Offer/Answer Protocols", RFC 5245, April 286 2010. 288 [draft-ietf-mmusic-sdp-bundle-negotiation] 289 C. Holmberg, H. Alvestrand, C. Jennings , "Multiplexing 290 Negotiation Using Session Description Protocol (SDP) Port 291 Numbers ", 2013, . 294 Authors' Addresses 296 Andrew Hutton (editor) 297 Siemens Enterprise Communications 298 Technology Drive 299 Nottingham NG9 1LA 300 UK 302 Email: andrew.hutton@siemens-enterprise.com 304 Thomas Stach 305 Siemens Enterprise Communications 306 Dietrichgasse 27-29 307 Vienna 1030 308 AT 310 Email: thomas.stach@siemens-enterprise.com