idnits 2.17.1 draft-petithuguenin-mmusic-ice-attributes-level-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 : ---------------------------------------------------------------------------- == There are 45 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5245, updated by this document, for RFC5378 checks: 2003-10-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2012) is 4210 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) == Missing Reference: 'ITU-T Q.1970' is mentioned on line 458, but not defined ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Updates: 5245 (if approved) October 8, 2012 5 Intended status: Standards Track 6 Expires: April 11, 2013 8 Media level ice-options SDP attribute 9 draft-petithuguenin-mmusic-ice-attributes-level-04 11 Abstract 13 This document normatively updates RFC 5245 by redefining the ice- 14 options SDP attribute as a session-level and media-level attribute. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, except to format it 21 for publication as an RFC or to translate it into languages other 22 than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 11, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The ice-options Attribute . . . . . . . . . . . . . . . . . . 3 56 4. The ice-lite Attribute . . . . . . . . . . . . . . . . . . . . 3 57 5. The ice-mismatch Attribute . . . . . . . . . . . . . . . . . . 4 58 6. Specific Aggregation Rule for the rtp+ecn ICE Option . . . . . 4 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 10.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 5 66 A.1. Aggregating media all supporting ICE . . . . . . . . . . 5 67 A.2. Aggregating media partially supporting ICE . . . . . . . 8 68 Appendix B. Analysis of similar issues in other attributes . . . 11 69 B.1. The type:broadcast Attribute . . . . . . . . . . . . . . 12 70 B.2. The charset Attribute . . . . . . . . . . . . . . . . . . 12 71 B.3. The tool Attribute . . . . . . . . . . . . . . . . . . . 12 72 B.4. The ipbcp, bcastversion, 3GPP-Integrity-Key, 73 3GPP-SDP-Auth, alt-group, PSCid, bc_service, 74 bc_program and bc_service_package Attributes . . . . . . 13 75 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . . 13 76 C.1. Modifications between -04 and -03 . . . . . . . . . . . . 13 77 C.2. Design Notes . . . . . . . . . . . . . . . . . . . . . . 13 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 ICE [RFC5245] defines the ice-options SDP attribute as session-level 83 only attribute, but when ICE is used with disaggregated media (see 84 section 3 of [I-D.loreto-splices-disaggregated-media] ), there is a 85 possibility that different media use different ICE implementations 86 and/or different networks, and so these different media will require 87 different values for this attribute. 89 As an example, the ice-options attribute value "rtp+ecn" (defined in 90 [RFC6679] ) signals ECN capability. Two aggregated media using two 91 different RTP implementations may want to use different values for 92 this attribute. 94 Note that there is a similar problem for the ice-lite attribute but 95 unfortunately it does not seem possible to design a way to use the 96 ice-lite attribute at the media level that is compatible with legacy 97 implementations that recognize only the session-level attribute. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119] . 105 3. The ice-options Attribute 107 The ice-options attribute is redefined by this document as a session- 108 level and media-level attribute. 110 All future new ICE options MUST also define how media-level ICE 111 options using this new value are aggregated to eventually generate 112 the value of the session-level ICE option, so legacy implementations 113 that only recognize session-level ICE options can interoperate with 114 implementations that recognize ICE options at both levels. 116 Before applying this specific aggregation rule, the session-level 117 ice-options attribute MUST be copied as media-level attribute in each 118 media. 120 4. The ice-lite Attribute 122 The ice-lite attribute is not redefined by this specification. 124 5. The ice-mismatch Attribute 126 [RFC5245] section 15.3 defines this attribute as been media level, 127 which seems correct, but section 21.1.4 erroneously registered this 128 attribute in IANA as session level. An errata [1] has been filled 129 and the IANA registry has been accordingly fixed. 131 6. Specific Aggregation Rule for the rtp+ecn ICE Option 133 If all aggregated media using ICE contain a media-level "rtp+ecn" ICE 134 option, as defined by [RFC6064] , then an "rtp+ecn" ICE option MUST 135 be inserted at the session-level. 137 7. Security Considerations 139 This document does not add any security considerations beyond what is 140 discussed in [RFC5245] . 142 8. IANA Considerations 144 No IANA considerations. 146 9. Acknowledgements 148 This document was written with the xml2rfc tool described in 149 [RFC2629] . 151 10. References 153 10.1. Normative References 155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, March 1997. 158 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 159 (ICE): A Protocol for Network Address Translator (NAT) 160 Traversal for Offer/Answer Protocols", RFC 5245, 161 April 2010. 163 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 164 and K. Carlberg, "Explicit Congestion Notification (ECN) 165 for RTP over UDP", RFC 6679, August 2012. 167 10.2. Informative References 169 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 170 June 1999. 172 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 173 Description Protocol", RFC 4566, July 2006. 175 [RFC5159] Dondeti, L. and A. Jerichow, "Session Description Protocol 176 (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast 177 (BCAST) Service and Content Protection", RFC 5159, 178 March 2008. 180 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 181 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 183 [RFC6064] Westerlund, M. and P. Frojdh, "SDP and RTSP Extensions 184 Defined for 3GPP Packet-Switched Streaming Service and 185 Multimedia Broadcast/Multicast Service", RFC 6064, 186 January 2011. 188 [I-D.loreto-splices-disaggregated-media] 189 Camarillo, G., Loreto, S., and R. Shekh-Yusef, 190 "Disaggregated Media in the Session Initiation Protocol 191 (SIP)", draft-loreto-splices-disaggregated-media-02 (work 192 in progress), June 2011. 194 URIs 196 [1] 198 Appendix A. Examples 200 A.1. Aggregating media all supporting ICE 202 In this example, we have two SDP to aggregate. The first SDP 203 contains an ice-options attribute at the media level: 205 v=0 206 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 207 s= 208 c=IN IP4 192.0.2.3 209 t=0 0 210 a=ice-options:rtp+ecn 211 a=ice-pwd:asd88fgpdd777uzjYhagZg 212 a=ice-ufrag:8hhY 213 m=audio 45664 RTP/AVP 0 214 b=RS:0 215 b=RR:0 216 a=rtpmap:0 PCMU/8000 217 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 218 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 219 10.0.1.1 rport 8998 220 m=text 45666 RTP/AVP 98 221 b=RS:0 222 b=RR:0 223 a=rtpmap:98 t140/1000 224 a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host 225 a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr 226 10.0.1.1 rport 9000 228 The second SDP also have an ice-options attribute at the media level: 229 v=0 230 o=jdoe 1 1 IN IP4 10.0.1.2 231 s= 232 c=IN IP4 192.0.2.4 233 t=0 0 234 a=ice-options:rtp+ecn 235 a=ice-pwd:f7sD7f7dF87s87d7da5564 236 a=ice-ufrag:776G 237 m=video 10000 RTP/AVP 238 b=RS:0 239 b=RR:0 240 a=rtpmap:0 PCMU/8000 241 a=candidate:1 1 UDP 2130706431 10.0.1.2 10000 typ host 242 a=candidate:2 1 UDP 1694498815 192.0.2.4 45000 typ srflx raddr 243 10.0.1.1 rport 10000 245 The first step is to copy the session-level ice-options attribute as 246 media-level attribute. The first SDP is modified like this: 248 v=0 249 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 250 s= 251 c=IN IP4 192.0.2.3 252 t=0 0 253 a=ice-options:rtp+ecn 254 a=ice-pwd:asd88fgpdd777uzjYhagZg 255 a=ice-ufrag:8hhY 256 m=audio 45664 RTP/AVP 0 257 b=RS:0 258 b=RR:0 259 a=rtpmap:0 PCMU/8000 260 a=ice-options:rtp+ecn 261 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 262 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 263 10.0.1.1 rport 8998 264 m=text 45666 RTP/AVP 98 265 b=RS:0 266 b=RR:0 267 a=rtpmap:98 t140/1000 268 a=ice-options:rtp+ecn 269 a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host 270 a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr 271 10.0.1.1 rport 9000 273 The second SDP is modified like this: 274 v=0 275 o=jdoe 1 1 IN IP4 10.0.1.2 276 s= 277 c=IN IP4 192.0.2.4 278 t=0 0 279 a=ice-options:rtp+ecn 280 a=ice-pwd:f7sD7f7dF87s87d7da5564 281 a=ice-ufrag:776G 282 m=video 10000 RTP/AVP 283 b=RS:0 284 b=RR:0 285 a=rtpmap:0 PCMU/8000 286 a=ice-options:rtp+ecn 287 a=candidate:1 1 UDP 2130706431 10.0.1.2 10000 typ host 288 a=candidate:2 1 UDP 1694498815 192.0.2.4 45000 typ srflx raddr 289 10.0.1.1 rport 10000 291 After aggregation, all the individual media keep their media-level 292 ice-options attribute, and a session-level ice-options attribute is 293 added as per the rule in Section 3 : 295 v=0 296 o=- 1309452627 1309452627 IN IP4 10.0.1.1 297 s= 298 t=0 0 299 a=ice-options:rtp+ecn 300 m=audio 45664 RTP/AVP 0 301 c=IN IP4 192.168.2.3 302 b=RS:0 303 b=RR:0 304 a=rtpmap:0 PCMU/8000 305 a=ice-options:rtp+ecn 306 a=ice-pwd:asd88fgpdd777uzjYhagZg 307 a=ice-ufrag:8hhY 308 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 309 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 310 10.0.1.1 rport 8998 311 m=text 45666 RTP/AVP 98 312 c=IN IP4 192.168.2.3 313 b=RS:0 314 b=RR:0 315 a=rtpmap:98 t140/1000 316 a=ice-options:rtp+ecn 317 a=ice-pwd:asd88fgpdd777uzjYhagZg 318 a=ice-ufrag:8hhY 319 a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host 320 a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr 321 10.0.1.1 rport 9000 322 m=video 10000 RTP/AVP 323 c=IN IP4 192.168.2.4 324 b=RS:0 325 b=RR:0 326 a=rtpmap:0 PCMU/8000 327 a=ice-options:rtp+ecn 328 a=candidate:1 1 UDP 2130706431 10.0.1.2 10000 typ host 329 a=candidate:2 1 UDP 1694498815 192.0.2.4 45000 typ srflx raddr 330 10.0.1.1 rport 10000 332 A.2. Aggregating media partially supporting ICE 334 In this example, we have two SDP to aggregate, but the second one 335 does not use ICE. The first SDP contains an ice-options attribute at 336 the media level: 338 v=0 339 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 340 s= 341 c=IN IP4 192.0.2.3 342 t=0 0 343 a=ice-options:rtp+ecn 344 a=ice-pwd:asd88fgpdd777uzjYhagZg 345 a=ice-ufrag:8hhY 346 m=audio 45664 RTP/AVP 0 347 b=RS:0 348 b=RR:0 349 a=rtpmap:0 PCMU/8000 350 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 351 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 352 10.0.1.1 rport 8998 353 m=text 45666 RTP/AVP 98 354 b=RS:0 355 b=RR:0 356 a=rtpmap:98 t140/1000 357 a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host 358 a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr 359 10.0.1.1 rport 9000 361 The second SDP does not contain any ice-options attribute: 362 v=0 363 o=jdoe 1 1 IN IP4 10.0.1.2 364 s= 365 c=IN IP4 192.0.2.4 366 t=0 0 367 m=video 10000 RTP/AVP 368 a=rtpmap:0 PCMU/8000 370 The first step is to copy the session-level ice-options attribute as 371 media-level attribute. Only the first SDP is modified in this 372 example: 374 v=0 375 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 376 s= 377 c=IN IP4 192.0.2.3 378 t=0 0 379 a=ice-options:rtp+ecn 380 a=ice-pwd:asd88fgpdd777uzjYhagZg 381 a=ice-ufrag:8hhY 382 m=audio 45664 RTP/AVP 0 383 b=RS:0 384 b=RR:0 385 a=rtpmap:0 PCMU/8000 386 a=ice-options:rtp+ecn 387 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 388 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 389 10.0.1.1 rport 8998 390 m=text 45666 RTP/AVP 98 391 b=RS:0 392 b=RR:0 393 a=rtpmap:98 t140/1000 394 a=ice-options:rtp+ecn 395 a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host 396 a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr 397 10.0.1.1 rport 9000 399 After aggregation, all the individual media keep their media-level 400 ice-options attribute, and a session-level ice-options attribute is 401 added as per the rule in Section 3 : 403 v=0 404 o=- 1309452627 1309452627 IN IP4 10.0.1.1 405 s= 406 t=0 0 407 a=ice-options:rtp+ecn 408 m=audio 45664 RTP/AVP 0 409 c=IN IP4 192.168.2.3 410 b=RS:0 411 b=RR:0 412 a=rtpmap:0 PCMU/8000 413 a=ice-options:rtp+ecn 414 a=ice-pwd:asd88fgpdd777uzjYhagZg 415 a=ice-ufrag:8hhY 416 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 417 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 418 10.0.1.1 rport 8998 419 m=text 45666 RTP/AVP 98 420 c=IN IP4 192.168.2.3 421 b=RS:0 422 b=RR:0 423 a=rtpmap:98 t140/1000 424 a=ice-options:rtp+ecn 425 a=ice-pwd:asd88fgpdd777uzjYhagZg 426 a=ice-ufrag:8hhY 427 a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host 428 a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr 429 10.0.1.1 rport 9000 430 m=video 10000 RTP/AVP 431 c=IN IP4 192.168.2.4 432 a=rtpmap:0 PCMU/8000 434 Appendix B. Analysis of similar issues in other attributes 436 In the MMUSIC WG session in Quebec City, it was suggested that the 437 problem was perhaps larger than just ICE attributes. This section is 438 the result of a systematic look at all the session level only SDP 439 attributes registered by IANA at the date of this document. The 440 conclusion is that only the ICE attributes are of concern but that 441 steps should be taken to ensure that these problems cannot happen for 442 future new attributes. 444 +--------------------+----------------------------+--------------+ 445 | Attribute | Reference | Comments | 446 +--------------------+----------------------------+--------------+ 447 | cat | [RFC4566] | OK | 448 | keywds | [RFC4566] | OK | 449 | type | [RFC4566] | OK | 450 | type:broadcast | [RFC4566] | Appendix B.1 | 451 | type:H332 | [ITU Recommendation H.332] | OK | 452 | type:meeting | [RFC4566] | OK | 453 | type:moderated | [RFC4566] | OK | 454 | type:test | [RFC4566] | OK | 455 | charset | [RFC4566] | Appendix B.2 | 456 | charset:iso8895-1 | [RFC4566] | Appendix B.2 | 457 | tool | [RFC4566] | Appendix B.3 | 458 | ipbcp | [ITU-T Q.1970] | Appendix B.4 | 459 | group | [RFC5888] | OK | 460 | ice-lite | [RFC5245] | Section 4 | 461 | ice-mismatch | [RFC5245] | Section 5 | 462 | ice-options | [RFC5245] | Section 3 | 463 | bcastversion | [RFC5159] | Appendix B.4 | 464 | 3GPP-Integrity-Key | [RFC6064] | Appendix B.4 | 465 | 3GPP-SDP-Auth | [RFC6064] | Appendix B.4 | 466 | alt-group | [RFC6064] | Appendix B.4 | 467 | PSCid | [TS 183 063] | Appendix B.4 | 468 | bc_service | [TS 183 063] | Appendix B.4 | 469 | bc_program | [TS 183 063] | Appendix B.4 | 470 | bc_service_package | [TS 183 063] | Appendix B.4 | 471 +--------------------+----------------------------+--------------+ 473 B.1. The type:broadcast Attribute 475 The "type:broadcast" does not have any issue by itself, but it should 476 be noted that it implies a default attribute of recvonly, so the 477 disaggregation process must take this in account. 479 B.2. The charset Attribute 481 Because the main reason to use a different charset for a session 482 description is to generate a more compact representation, it is 483 probably OK that this attribute exists only at the session level. 484 But the aggregation/disaggregation rules must explicitly convert the 485 individual media descriptions to and from the common charset, ISO- 486 10646. 488 B.3. The tool Attribute 490 The definition of this attribute make it clear that this attribute 491 contains the name and version number of the tool that created the 492 session description as a whole. But it probably would be useful to 493 define this attribute at the media level too, so we can know the 494 tools used for create the individual media descriptions. 496 B.4. The ipbcp, bcastversion, 3GPP-Integrity-Key, 3GPP-SDP-Auth, alt- 497 group, PSCid, bc_service, bc_program and bc_service_package 498 Attributes 500 These attributes were not defined in IETF Standard Track documents, 501 so the analysis is left to the SDOs that produced this 502 specifications. 504 Appendix C. Release notes 506 This section must be removed before publication as an RFC. 508 C.1. Modifications between -04 and -03 510 o Updated rtp+ecn reference. 511 o IANA registry for ice-mismatch fixed. 513 C.2. Design Notes 515 o It has been proposed multiple times to use a different attribute 516 name for the ice-options attribute when used at the media-level. 517 Using a different name does not solve the aggregation problem and, 518 in the opinion of this author, could create confusion. 520 Author's Address 522 Marc Petit-Huguenin 523 Impedance Mismatch 525 Email: petithug@acm.org