idnits 2.17.1 draft-holmberg-mmusic-sdp-mmt-negotiation-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 : ---------------------------------------------------------------------------- == There are 11 instances 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 (October 8, 2012) is 4218 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track H. Alvestrand 5 Expires: April 11, 2013 Google 6 J. Lennox 7 Vidyo 8 October 8, 2012 10 Multiplexed Media Types (MMT) Using Session Description Protocol (SDP) 11 Port Numbers 12 draft-holmberg-mmusic-sdp-mmt-negotiation-00.txt 14 Abstract 16 This specification defines a new SDP Grouping Framework SDP grouping 17 framework extension, "MMT", and a new SDP media type, "anymedia". 18 Together they can be used with the Session Description Protocol (SDP) 19 Offer/Answer mechanism to negotiate the usage of multiplexed media 20 types, which refers to the usage of a single 5-tuple for different 21 media types. 23 This specification also defined a new SDP attribute, "mmtype", which 24 can be used within a "anymedia" SDP Media Description to map PT 25 (Payload Type) values to a specific media type. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 11, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 65 5. SDP Grouping Framework MMT Extension Semantics . . . . . . . . 4 66 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.2.2. SDP Offer/Answer Usage . . . . . . . . . . . . . . . . 5 70 6. anymedia SDP Media Type . . . . . . . . . . . . . . . . . . . 6 71 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6.2. SDP Extensions . . . . . . . . . . . . . . . . . . . . . . 6 73 6.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 6 74 6.4. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.5. ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.6. RTP Sessions . . . . . . . . . . . . . . . . . . . . . . . 7 77 7. mmtype SDP attribute . . . . . . . . . . . . . . . . . . . . . 7 78 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 7.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 82 7.3.2. SDP Offer/Answer Usage . . . . . . . . . . . . . . . . 8 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 87 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and 96 receiving media associated with multiple SDP Media Descriptions 97 [RFC4566] has been identified. This would e.g. allow the usage of a 98 single set of Interactive Connectivity Establishment (ICE) [RFC5245] 99 candidates for multiple media descriptions. Normally different media 100 types (audio, video etc) will be described using different SDP Media 101 Descriptions. 103 As defined in RFC 4566 [RFC4566], the semantics of using the same 104 port number for multiple SDP Media Descriptions is undefined. 105 Therefore, in order to be able to use the same port value for 106 multiple media types, it must be possible to describe multiple media 107 types within a single SDP Media Description. 109 This specification defines a new SDP Grouping Framework SDP grouping 110 framework [RFC5888] extension, "MMT", and a new SDP media type, 111 "anymedia". Together they can be used with the Session Description 112 Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the 113 usage of multiplexed media types, which refers to the usage of a 114 single 5-tuple for different media types. 116 This specification also defined a new SDP attribute, "mmtype", which 117 can be used within a "anymedia" SDP Media Description to map PT 118 (Payload Type) values to a specific media type. 120 When an endpoint generates an SDP Offer or SDP Answer, which 121 includeds one or more "MMT" groups, each group will contain one 122 "anymedia" SDP Media Description and one or more SDP Media 123 Descriptions for specific media types (audio, video, etc). 125 When media is transported using the Real-Time Protocol (RTP) 126 [RFC3550], each SDP Media Description is assumed to form a separate 127 RTP Session [RFC3550]. The same applies to media associated with a 128 "anymedia" SDP Media Description, ie all media types associated with 129 a "anymedia" SDP Media Description is by default assumed to form a 130 single RTP Session. 132 The mechanism is backward compatible. Entities that do not support 133 (or, for a given session, are not willing to use) the "MMT" grouping 134 extension and the "anymedia" media type, are expected to generate an 135 SDP Answer, which does not contain a "MMT" group, and where the 136 "anymedia" SDP Media Description is rejected. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 5-tuple: A collection of the following values: source address, source 145 port, destination address, destination port and protocol. 147 Multiplexed media types: Two or more RTP streams, possibly of 148 different media types, using a single 5-tuple. The RTCP streams 149 associated with the RTP streams also use a single 5-tuple, which 150 might be the same, but can also be different, as the one used by the 151 RTP streams. 153 3. Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in BCP 14, RFC 2119 158 [RFC2119]. 160 4. Applicability Statement 162 The mechanism in this specification only applies to the Session 163 Description Protocol (SDP) [RFC4566], when used together with the SDP 164 Offer/Answer mechanism [RFC3264]. 166 5. SDP Grouping Framework MMT Extension Semantics 168 5.1. General 170 This section defines a new SDP Grouping Framework extension, "MMT". 172 The "MMT" extension can be indicated using a "group" SDP session- 173 level attribute. Each SDP Media Description ("m=" line) that is 174 grouped together, using a "mid" SDP media-level attribute, is part of 175 a specific "MMT" group. 177 A "MMT" group is not usable standalone. It MUST be used together 178 with a "anymedia" SDP Media Description. 180 5.2. Usage 182 5.2.1. General 184 A "MMT" group MUST contain a "anymedia" SDP Media Description, and at 185 least one SDP Media Description for a specific SDP Media Type (audio, 186 video, etc). 188 An SDP Offerer [RFC3264] uses the "MMT" group to offer at least one 189 SDP Media Description for specific SDP Media Types, and a "anymedia" 190 SDP Media Description, which can contain multiple SDP Media Types 191 sharing a single SDP Media Description. From a "MMT" group the SDP 192 Answerer [RFC3264] will accept either the SDP Media Descriptions for 193 the specific SDP Media Types, or the "anymedia" SDP Media 194 Description. 196 It is RECOMMENDED that the capabilities of the "anymedia" SDP Media 197 Description match the capabilities (codecs, RTCP multiplexing etc) of 198 the SDP Media Descriptions for the specific SDP Media Types, in order 199 to provide the same capabilities no matter whether SDP Media 200 Descriptions for specific SDP Media Types, or the "anymedia" SDP 201 Media Description, is used to establish the session. 203 NOTE: An SDP Message Body can contain multiple "MMT" groups. 205 5.2.2. SDP Offer/Answer Usage 207 5.2.2.1. SDP Offererer Procedures 209 When an SDP Offerer generates an SDP Offer, which contains one or 210 more "MMT" groups, for each "MMT" group the SDP Offerer MUST: 212 1) Include a "anymedia" SDP Media Description; and 214 2) Include at least one SDP Media Description for a specific media 215 type (audio, video, etc). 217 5.2.2.2. SDP Answerer Procedures 219 When an SDP Answerer generates an SDP Answer, for each "MMT" group in 220 the associated SDP Offer it MUST either: 222 1) Accept the "anymedia" SDP Media Description, and reject all other 223 SDP Media Descriptions associated with the "MMT" group; or 225 2) Reject the "anymedia" SDP Media Description, and accept some or 226 all of the other SDP Media Descriptions associated with the MMT 227 group. 229 NOTE: As described in [RFC3264], an SDP Media Description can be 230 rejected by setting the port value of the associated m- line to zero 231 in the SDP Answer. 233 NOTE: As described in [RFC3264] the SDP Answer must contain the same 234 number of SDP Media Descriptions as the associated SDP Offer. 236 6. anymedia SDP Media Type 238 6.1. General 240 This section describes a new SDP media type [RFC4566], "anymedia", 241 for SDP Media Descriptions [RFC4566]. "anymedia" does not refer to a 242 specific media type, but allows multiple media types (audio, video 243 etc) to be associated with a single SDP Media Description. All media 244 associated with a "anymedia" SDP Media Description will share the 245 same IP address+port, protocol (e.g. RTP/AVP) and other information 246 (e.g. ICE candidates) associated with the SDP Media Description. It 247 allows, if both endpoints support the mechanism, multiple media typex 248 to be multiplexed on a single 5-tuple. PT (Payload Type) values will 249 be listed in a normal fashion in the format list of the SDP Media 250 Description. The SDP rtpmap attribute [RFC4566] will be used in a 251 normal fashion to map each PT to a codec, and the SDP mmtype 252 attribute will be used to map each PT to a specific media type (e.g. 253 audio, video, etc). 255 Within a "anymedia" SDP Media Description, each PT value SHOULD be 256 described using an "rtpmap" SDP Attribute [RFC4566], even if the PT 257 value is static. In addition, as it might not always be possible to 258 retreive the media type from the "rtpmap" SDP Attribute value, each 259 PT value MUST be mapped to a specific media type, using the "mmtype" 260 SDP Attribute. 262 6.2. SDP Extensions 264 OPEN ISSUE: Which, if any, SDP Extensions shall we require support 265 of? 267 6.3. SDP Attributes 269 In a normal fashion, any media level SDP Attribute (e.g. the 270 directionality attributes) associated with the "anymedia" SDP Media 271 Description applies to all media associated with the SDP Media 272 Description. 274 NOTE: Additional extensions are needed in order to specify SDP 275 Attribute values for individual media types, or individual media 276 sources, associated with the "anymedia" SDP Media Description. 278 6.4. Bandwidth 280 The SDP bandwidth parameter, b=, is used in a normal fashion, as 281 described in [RFC4566] 283 NOTE: Additional extensions are needed in order to specify SDP 284 Bandwidth values for individual media types, and for a specific media 285 direction. 287 6.5. ICE Usage 289 ICE [RFC5245], if supported, will be used in a normal fashion, and 290 the ICE Candidate information will apply to all media types 291 associated with the "anymedia" SDP Media Description. 293 6.6. RTP Sessions 295 By default, all media associated with a "anymedia" SDP Media 296 Description is considered to be part of a single RTP Session 297 [RFC3550]. 299 7. mmtype SDP attribute 301 7.1. General 303 This section defines a new SDP media level attribute [RFC4566], 304 "mmtype" (Multiplexed Media Type). The attribute is used within 305 "anymedia" SDP Media Descriptions to indicate the media type 306 associated with a specific PT value. 308 7.2. Syntax 310 a=mmtype: format media 312 format and media as defined in [RFC4566]. 314 7.3. Usage 316 7.3.1. General 318 The attribute is used within "anymedia" SDP Media Descriptions to 319 indicate the media type associated with a specific PT value. This 320 specification does not define the usage of the attribute within other 321 types of SDP Media Descriptions. 323 For each instance of the "mmtype" attribute, the associated PT value 324 MUST also be listed in the format list of the associated SDP m- line. 325 Within a given SDP Media Description, there MUST only be one 'mmtype' 326 attribute associated with a given PT value. An entity MUST either 327 reject or discard an SDP Media Description that contains 'mmtype' 328 attributes with PT values not listed in the associated m- line. An 329 entity MUST either reject or discard an SDP Media Description that 330 contains multiple 'mmtype' attributes for the same PT value. 332 7.3.2. SDP Offer/Answer Usage 334 There are no SDP Offer/Answer specific procedures defined for the 335 "mmtype" SDP attribute. 337 8. Security Considerations 339 TBA 341 9. Example 343 The example below shows an SDP Offer, where multiplexed media types 344 is offered. The example also shows two SDP Answer alternatives: one 345 where multiplexed media types is accepted, and one where multiplexed 346 media types is rejected (or, not even supported) by the SDP Answerer. 348 SDP Offer (multiplexed media types offered) 350 v=0 351 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com 352 s= 353 c=IN IP4 host.atlanta.com 354 t=0 0 355 a=group:MMT foo bar zoe 356 m=audio 10000 RTP/AVP 0 8 97 357 a=mid:foo 358 b=AS:200 359 a=rtpmap:0 PCMU/8000 360 a=rtpmap:8 PCMA/8000 361 a=rtpmap:97 iLBC/8000 362 m=video 20000 RTP/AVP 31 32 363 a=mid:bar 364 b=AS:1000 365 a=rtpmap:31 H261/90000 366 a=rtpmap:32 MPV/90000 367 m=anymedia 30000 RTP/AVP 0 8 97 31 32 368 a=mid:zoe 369 a=rtpmap:0 PCMU/8000 370 a=rtpmap:8 PCMA/8000 371 a=rtpmap:97 iLBC/8000 372 a=rtpmap:31 H261/90000 373 a=rtpmap:32 MPV/90000 374 a=mmtype: 0 audio 375 a=mmtype: 8 audio 376 a=mmtype: 97 audio 377 a=mmtype: 31 video 378 a=mmtype: 32 video 380 SDP Answer (multiplexed media types accepted) 382 v=0 383 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com 384 s= 385 c=IN IP4 host.biloxi.com 386 t=0 0 387 a=group:MMT foo bar 388 m=audio 0 RTP/AVP 0 389 a=mid:foo 390 a=rtpmap:0 PCMU/8000 391 m=video 0 RTP/AVP 32 392 a=mid:bar 393 a=rtpmap:32 MPV/90000 394 m=anymedia 60000 RTP/AVP 0 32 395 a=mid:zoe 396 a=rtpmap:0 PCMU/8000 397 a=rtpmap:32 MPV/90000 398 a=mmtype: 0 audio 399 a=mmtype: 32 video 401 SDP Answer (multiplexed media types not accepted) 403 v=0 404 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com 405 s= 406 c=IN IP4 host.biloxi.com 407 t=0 0 408 a=group:MMT foo bar 409 m=audio 40000 RTP/AVP 0 410 a=mid:foo 411 a=rtpmap:0 PCMU/8000 412 m=video 50000 RTP/AVP 32 413 a=mid:bar 414 a=rtpmap:32 MPV/90000 415 m=anymedia 0 RTP/AVP 0 32 416 a=mid:zoe 418 SDP Offer with ICE (multiplexed media types offered) 420 v=0 421 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com 422 s= 423 c=IN IP4 host.atlanta.com 424 t=0 0 425 a=group:MMT foo bar zoe 426 m=audio 10000 RTP/AVP 0 8 97 427 a=mid:foo 428 b=AS:200 429 a=rtpmap:0 PCMU/8000 430 a=rtpmap:8 PCMA/8000 431 a=rtpmap:97 iLBC/8000 432 a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host 433 m=video 20000 RTP/AVP 31 32 434 a=mid:bar 435 b=AS:1000 436 a=rtpmap:31 H261/90000 437 a=rtpmap:32 MPV/90000 438 a=candidate:1 1 UDP 1694498815 host.atlanta.com 20000 typ host 439 m=anymedia 30000 RTP/AVP 0 8 97 31 32 440 a=mid:zoe 441 a=rtpmap:0 PCMU/8000 442 a=rtpmap:8 PCMA/8000 443 a=rtpmap:97 iLBC/8000 444 a=rtpmap:31 H261/90000 445 a=rtpmap:32 MPV/9000 446 a=mmtype: 0 audio 447 a=mmtype: 8 audio 448 a=mmtype: 97 audio 449 a=mmtype: 31 video 450 a=mmtype: 32 video 451 a=candidate:1 1 UDP 1694498815 host.atlanta.com 30000 typ host 453 10. IANA Considerations 455 This document requests IANA to register the new SDP Grouping semantic 456 extension called MMT. 458 11. Acknowledgements 460 The usage of the SDP grouping mechanism is based on a similar 461 alternative proposed by Harald Alvestrand. The SDP examples are also 462 modified versions from the ones in the Alvestrand proposal. 464 The usage of a dedicated SDP media type to described multiplexed 465 media types types is based on input from Jonathan Lennox. 467 12. Change Log 469 [RFC EDITOR NOTE: Please remove this section when publishing] 471 Changes from draft-holmberg-mmusic-sdp-mmt-negotiation-xx 472 o Add change. 474 13. References 476 13.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 482 with Session Description Protocol (SDP)", RFC 3264, 483 June 2002. 485 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 486 Description Protocol", RFC 4566, July 2006. 488 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 489 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 491 13.2. Informative References 493 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 494 Jacobson, "RTP: A Transport Protocol for Real-Time 495 Applications", STD 64, RFC 3550, July 2003. 497 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 498 (ICE): A Protocol for Network Address Translator (NAT) 499 Traversal for Offer/Answer Protocols", RFC 5245, 500 April 2010. 502 Authors' Addresses 504 Christer Holmberg 505 Ericsson 506 Hirsalantie 11 507 Jorvas 02420 508 Finland 510 Email: christer.holmberg@ericsson.com 512 Harald Tveit Alvestrand 513 Google 514 Kungsbron 2 515 Stockholm 11122 516 Sweden 518 Email: harald@alvestrand.no 520 Jonathan Lennox 521 Vidyo, Inc. 522 433 Hackensack Avenue 523 Seventh Floor 524 Hackensack, NJ 07601 525 US 527 Email: jonathan@vidyo.com