idnits 2.17.1 draft-even-mmusic-application-token-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 3, 2014) is 3765 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-00 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-05 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-08 == Outdated reference: A later version (-04) exists of draft-westerlund-avtcore-rtp-simulcast-03 -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC WG R. Even 3 Internet-Draft Huawei Technologies 4 Intended status: Informational J. Lennox 5 Expires: July 7, 2014 Vidyo 6 Q. Wu 7 Huawei Technologies 8 January 3, 2014 10 The Session Description Protocol (SDP) Application Token Attribute 11 draft-even-mmusic-application-token-02.txt 13 Abstract 15 The RTP fixed header includes the payload type number and the SSRC 16 values of the RTP stream. RTP defines how to de-multiplex streams 17 within an RTP session, but in some use cases applications need 18 further identifiers in order to identify the application semantics 19 associated with particular streams within the session as conveyed in 20 the signaling. 22 This document defines a mechanism to provide the mapping between the 23 SSRCs of RTP streams and the application semantics by defining 24 extensions to RTP and RTCP messages. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 7, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Proposal for Application ID . . . . . . . . . . . . . . . . . 5 63 3.1. appId token . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.1. RTCP SDES message . . . . . . . . . . . . . . . . . . 8 65 3.1.2. RTP Header Extension . . . . . . . . . . . . . . . . . 9 66 3.1.3. recv-appId . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. The "appId-group" media attribute . . . . . . . . . . . . 10 68 3.3. appId attributes . . . . . . . . . . . . . . . . . . . . . 11 69 3.3.1. The "pt" appId attribute . . . . . . . . . . . . . . . 11 70 4. Using Application ID token in Offer / Answer . . . . . . . . . 11 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 The RTP [RFC3550] header includes the payload type number and the 82 SSRC values of the RTP stream. RTP defines how to de-multiplex 83 streams within an RTP session, but in some use cases, applications 84 need further identifiers in order to identify semantics associated 85 with particular streams within the session. 87 SDP [RFC4566] can be used to describe multiple RTP media streams in 88 one or more m-lines that define a single SSRC multiplexed RTP session 89 (as specified in [RFC3550]). This addresses the WebRTC architecture 90 [I-D.ietf-rtcweb-overview]. 92 A Unified Plan for Using SDP with Large Numbers of Media Flows 93 [I-D.roach-mmusic-unified-plan] proposes that each m-line will 94 represent a media source [I-D.ietf-avtext-rtp-grouping-taxonomy]. In 95 the simple case a media source will be one video or audio RTP stream. 96 Media source description becomes more complicated when, for robust 97 applications, techniques like retransmission (RTX) and Forward Error 98 Correction (FEC) are used to protect media, or simulcast or layered 99 coding can be used to provide support to heterogeneous receivers. In 100 these cases a media source may send more than one RTP stream: for 101 example, a scalable video stream base layer, an enhancement layer and 102 a FEC stream. 104 Multiple SDP m-lines can be multiplexed to a single RTP session using 105 [I-D.ietf-mmusic-sdp-bundle-negotiation]. The same payload type 106 number can be used in multiple bundled m-lines. 108 Some applications may require more information about the usage of the 109 RTP streams: for example, RTP streams from different cameras that 110 need to be identified by the application in order to render them 111 correctly, or a source that can send multiple versions of the same 112 stream in different resolutions (i.e. simulcast 113 [I-D.westerlund-avtcore-rtp-simulcast]). 115 A single RTP media stream can be identified in SDP by using the SSRC 116 attribute [RFC5576]. Relations between RTP streams in the same 117 session can be specified using the ssrc-group attribute [RFC5576]. 118 Using the SSRC to identify RTP streams in an SDP session assumes that 119 this information is available to the SDP signaling layer. The SSRC 120 is RTP layer information and may change in the RTP layer during a 121 session. 123 Support of FEC, SVC and simulcast brings more requirements as 124 explained using the following examples. 126 The following example is of a unified plan 128 [I-D.roach-mmusic-unified-plan] offer of one audio source and one 129 video source. The video source includes two SVC RTP streams a base 130 layer and an enhancement layer. There are also two FEC options: 132 Base layer S1 is protected by FEC repair stream R1 134 Base Layer S1 and Enhancement layer S2 are protected by FEC repair 135 stream R2. 137 This enables the answer to select the base layer with R1 or the Base 138 + enhancement layers both protected by R2. 140 This example uses the SSRC and SSRC-GROUP attributes which requires 141 the pre-knowledge of the SSRCs that are RTP layer values. 143 SDP Offer: 144 v=0 145 o=- 20518 0 IN IP4 198.51.100.1 146 s=FEC Grouping Semantics for SSRC Multiplexing 147 t=0 0 148 c=IN IP4 203.0.113.1 149 a=group:BUNDLE m1 m2 150 m=audio 56600 RTP/SAVPF 0 109 151 a=msid:ma ta 152 a=mid:m1 153 a=ssrc:53280 154 a=rtpmap:0 PCMU/8000 155 a=rtpmap:109 opus/48000 156 m=video 56602 RTP/AVPF 100 101 110 111 - Main camera 157 a=msid:ma tb 158 a=mid:m2 159 a=rtpmap:100 H264/90000 - Base layer 160 a=rtpmap:101 H264-SVC/90000 - Enhancement layer. 161 a=depend:101 lay L1:100 - dependencies 162 a=rtpmap:110 1d-interleaved-parityfec/90000 163 a=fmtp:110 L=5; D=10; repair-window=200000 164 a=rtpmap:111 1d-interleaved-parityfec/90000 165 a=fmtp:111 L=10; D=10; repair-window=400000 166 a=ssrc:1000 cname:MSTFEC@example.com 167 a=ssrc:1010 cname:MSTFEC@example.com 168 a=ssrc:2110 cname:MSTFEC@example.com 169 a=ssrc:2120 cname:MSTFEC@example.com 170 a=ssrc-group:FEC-FR 1000 2110 171 a=ssrc-group:FEC-FR 1000 1010 2120 172 a=ssrc-group:DDP 1000 1010 174 In this case all video streams are from the same source and can be 175 described using a single m-line. The grouping relations are 176 specified using the SSRCs values that need to be available in the 177 offer. It is also not clear based on the offer which rtpmap line 178 corresponds to each of the a=ssrc lines, e.g. which rtpmap line will 179 be sent using ssrc = 2110. The answerer can deduce the information 180 based on analyzing the ssrc-group information but there can be case 181 that it will not be possible.. 183 There are cases where the SSRCs of the RTP streams may not be 184 available. 186 A selective forwarding middlebox as described in RTP topologies 187 section 3.7 [topologies] may project the RTP stream from the source 188 to destination and forward new SSRCs without any signaling. 190 A three camera telepresence system may send two video media stream of 191 the two recent active speakers to a system with two monitors. In 192 this case it may send first the video from the left and center camera 193 (this will cause the video from the center camera to be displayed on 194 the right) and later the video from the center and right camera (this 195 will cause the video from the center camera to be displayed on the 196 left). The SSRC of the video stream from the center camera will 197 remain the same but the mapping to the stream description will 198 change. 200 As discussed in [I-D.roach-mmusic-unified-plan] during call 201 establishment, circumstances may arise under which an endpoint can 202 send an offer to receive a new stream, and begin receiving media for 203 that media stream prior to receiving the SDP that correlates its SSRC 204 to the m-line. For such cases, the endpoint will not know how to 205 handle the media, and will most probably be forced to discard it. 207 2. Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC2119[RFC2119] and 212 indicate requirement levels for compliant RTP implementations. 214 3. Proposal for Application ID 216 As we saw in the introduction, the SSRC of the RTP stream which 217 should be created by the RTP layer is used by the SDP in the offer to 218 map an RTP stream description to the SDP or application logic. There 219 are cases where the SSRCs of the RTP streams may not be available or 220 do not provide all the required information. 222 There is a need to have a token that will allow the mapping between a 223 single RTP stream in an m-line to the application logic and to the 224 actual RTP media stream. For example, stream1 is the RTP stream from 225 the left camera and stream2 is the RTP stream from the right camera 226 and stream3 is the FEC stream that protects both streams. 228 This token can be used for defining group semantics inside an SDP 229 m-line. There is also a need for a token that will allow the offerer 230 to correlate a received RTP stream to the application logic before 231 receiving the answer from the remote side. 233 In order to address these requirements this document defines an SDP 234 token attribute appId that provides a level of indirection for the 235 binding. The actual binding is done in RTP by associating the appId 236 with an SSRC using a new RTCP SDES message and a new RTP header 237 extension that define the mapping from appId to a specific SSRC. 238 Having the binding in RTP/RTCP allows the RTP layer to change the 239 SSRC of a media stream by sending a new binding message (SDES an RTP 240 header extension) without a need to have an SDP level offer/answer 241 exchange. 243 The document also defines an appId-group attribute that has similar 244 semantics to SSRC-group but uses the appId instead of SSRC to specify 245 the different RTP streams in the group. 247 For the case when the offerer receives an RTP stream before the SDP 248 answer, we define a new optional attribute recv-appId to be used for 249 correlating this received RTP stream. 251 3.1. appId token 253 AppId is a general-purpose token associated with an RTP stream, 254 allowing the binding of the SDP representation to an SSRC. This 255 allows the semantics of the stream with the token to be defined by 256 the application and mapped to an RTP stream without having to know 257 its SSRC in the application. 259 The token is chosen by the sender, and represents the RTP stream that 260 will be sent to the receiver. 262 The proposed token can be sent using SDP, RTCP SDES messages 263 [RFC3550], or an RTP header extension [RFC5285] 265 The SSRC mapping may be available to the receiver when receiving the 266 RTP stream through the RTP header extension, but may also be 267 available ahead of time via an RTCP SDES message conveyed before the 268 source starts sending, even if the receiver has not seen any RTP 269 packets from this source (as in a multipoint conference). 271 The receiver can receive new sources that may be of two kinds. 273 o A new RTP stream replacing an existing RTP stream, in which case 274 the AppId of the replaced RTP stream will be assigned to the new 275 SSRC. 276 o A new RTP stream requiring a different AppId, for example, when 277 adding a presentation stream to an existing call with two video 278 cameras from a room. 280 The solution supports an RTP session as described using SDP. The RTP 281 session may use Bundle [I-D.ietf-mmusic-sdp-bundle-negotiation] with 282 more than one m-line. In this case, if the SSRCs of all RTP streams 283 are not known in advance, the AppIds associated with each m-line need 284 to be available to the media receiver in order to map each SSRC to a 285 specific m-line configuration. The appIds MUST be unique in an SDP 286 session. 288 Editor Note (is this required?): It is preferable that they will be 289 unique in an RTP session which is not a problem in a point to point 290 call or in a multipoint conference with a central signaling point. 292 The document defines a new SDP media level attribute a=appId that can 293 be used to list all the appIds that an application may use. 295 The appId syntax provides a token identifier. Each value of the 296 AppId maps to one SSRC at a time. When a new SSRC is mapped to an 297 existing AppId using an RTP header extension or SDES message, it 298 replaces the previous RTP stream for this application usage. 300 The definition is 302 a=appId:token 304 a=appId:token 306 a=appId:token : 308 The formal representation of the appId token is: 309 appId-attribute = "appId:" token *[WSP attribute] 310 attribute =/ appId-attr 311 ; The base definition of "attribute" is in [RFC4566]. 312 ; (It is the content of "a=" lines.) 313 ; WSP and DIGIT defined in [RFC5234] 314 ; token defined in [RFC4566] 316 Examples: 318 The SDP offer specifies an appId that will be used for mapping to 319 specific SSRCs. The example shows two RTP streams having different 320 content [RFC4796] with the same payload type number. The appId can 321 be used to identify the content of the RTP stream. 323 a=group:BUNDLE m1 m2 324 m=video 49200 RTP/AVP 99 325 a=rtpmap:99 H264/90000 326 a=mid:m1 327 a=content:main 328 a=appId:2 329 m=video 49200 RTP/AVP 99 330 a=rtpmap:99 H264/90000 331 a=mid:m2 332 a=content:alt 333 a=appId:3 335 The second example is when the application usage of the RTP stream is 336 specified using SDP to specify different content [RFC4796] , and each 337 RTP stream has a Retransmission stream. The media receiver can map 338 the received SSRC of the RTP stream or the retransmission to the 339 specific content based on the appId. 341 a=group:BUNDLE m1 m2 342 m=video 49200 RTP/AVP 97,98 343 a=rtpmap:98 H264/90000 344 a=mid:m1 345 a=content:main 346 a=rtpmap:97 rtx/90000 347 a=fmtp:97 apt=98;rtx-time=3000 348 a=appId:2 349 a=appId:3 350 m=video 49200 RTP/AVP 97,98 351 a=rtpmap:98 H264/90000 352 a=mid:m2 353 a=content:alt 354 a=rtpmap:97 rtx/90000 355 a=fmtp:97 apt=98;rtx-time=3000 356 a=appId:4 357 a=appId:5 359 3.1.1. RTCP SDES message 361 This document specifies a new RTCP SDES message 362 0 1 2 3 363 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | AppId = XXX | length |AppId token 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | .... 369 This AppId is the same token as defined in the new SDP attribute and 370 is also used in the RTP header extension. 372 This SDES message MAY be sent in a compound RTCP packet based on the 373 application need. 375 Editor Note: Need guidance on how often the SDES message should be 376 sent. 378 3.1.2. RTP Header Extension 380 The Application ID is carried within the RTP header extension field, 381 using [RFC5285] two bytes header extension. 383 Support is negotiated within the SDP, i.e. 385 a=extmap:1 urn:ietf:params:rtp-hdrext:App-ID 387 Packets tagged by the sender with the AppId then contain a header 388 extension as shown below 390 0 1 2 3 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | ID=1 | Len-1 | AppId 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | AppID .............. | 396 +-+-+-+-+-+-+-+-+ 398 To add or modify the AppId by an intermediary can be an expensive 399 operation, particularly if SRTP is used to authenticate the packet. 400 Modification to the contents of the RTP header requires a re- 401 authentication of the complete packet, and this could prove to be a 402 limiting factor in the throughput of a multipoint device. 404 There is no need to send the AppId header extension with all RTP 405 packets. Senders MAY choose to send it only when a new SSRC is sent, 406 or when an SSRC changes its association to an AppId. If such a mode 407 is being used, the header extension SHOULD be sent in the first few 408 RTP packets to reduce the risk of losing it due to packet loss. For 409 codecs with decoder refresh points (such as I-Frames in video 410 codecs), senders also SHOULD send the AppId header extension along 411 with the packets carrying the decoder refresh. 413 3.1.3. recv-appId 415 An offer may include a recv-appId attribute allowing the offerer to 416 request from the answerer to use this token for the RTP stream sent 417 from the answerer for a sendrecv or recvonly RTP stream. This is 418 important in order to support early media from the answerer that may 419 be received by the offerer before the answer SDP arrives. 421 The formal representation of the appId token is: 422 appId-attribute = "recv-appId:" token 423 ; The base definition of "attribute" is in [RFC4566]. 424 ; (It is the content of "a=" lines.) 426 3.2. The "appId-group" media attribute 428 a=appId-group: ... 430 The SDP media attribute "appId-group" expresses a relationship among 431 several media sources specified in the same SDP m-line. It is 432 analogous to the "group" session-level attribute [RFC3388], which 433 expresses a relationship among media streams in an SDP multimedia 434 session (i.e., a relationship among several logically related RTP 435 sessions). As media sources are already identified by their appId, 436 no analogous property to the "mid" attribute is necessary. 438 Editor note: Since the appId is unique in an SDP session the app-Id 439 group can be used also at the session level - do we want it? 441 The parameter is taken from the specification of the 442 "group" attribute [RFC3388]. The initial semantic values defined for 443 the "appId-group" attribute are FID (Flow Identification) [RFC3388] 444 and FEC (Forward Error Correction) [RFC4756]. In each case, the 445 relationship among the grouped sources is the same as the 446 relationship among corresponding sources in media streams grouped 447 using the SDP "group" attribute. 449 Though the "appId-group" semantic values follow the same syntax as 450 "group" semantic values, they are defined independently. All "appId- 451 group" semantic values MUST be registered with IANA, using the 452 registry defined in Section 6 454 The "appId-group" attribute indicates the sources in a group by 455 listing the appIds of the sources in the group. It MUST list at 456 least one appId for a group and MAY list any number of additional 457 ones. Every appId listed in an "appId-group" attribute MUST be 458 defined by a corresponding "appId" line in the same media 459 description. 461 3.3. appId attributes 463 3.3.1. The "pt" appId attribute 465 The SDP offer example in the introduction demonstrated that when 466 there are multiple RTP streams in the offer each have a different pt 467 number it it is not clear which SSRC specified using a=ssrc: is 468 correlated to each of the rtpmap lines. In order to provide the 469 mapping we define an appId attribute "pt". 471 a=appId:token pt:value 473 appId-attrib = "pt:" pt-value 475 pt-value = 1*3DIGIT 477 4. Using Application ID token in Offer / Answer 479 The appId may be used in offer answer. Some use cases are provided. 480 They only show part of the SDP that can demonstrate the usage. 482 A simple case is when each SDP m-line describes one RTP stream and 483 the m-lines are bundled . The recv-appId is offered so when the 484 offerer sees an RTP stream with appId token value 10 it knows it is 485 the main video. 487 The offer is: 488 a=group:BUNDLE m1 m2 489 m=video 49200 RTP/AVP 98 490 a=rtpmap:98 H264/90000 491 a=mid:m1 492 a=content:main 493 a=appId:2 494 a=recv-appId:10 495 m=video 49200 RTP/AVP 99 496 a=rtpmap:99 H264/90000 497 a=mid:m2 498 a=content:alt 499 a=appId:3 500 a=recv-appId:20 502 A second example is using the same case as in section one (SVC with 503 FEC) This example shows how to use the appId optional pt parameter to 504 map to a specific stream description. 506 v=0 507 o=- 20518 0 IN IP4 198.51.100.1 508 s=FEC Grouping Semantics for SSRC Multiplexing 509 t=0 0 510 c=IN IP4 203.0.113.1 511 a=group:BUNDLE m1 m2 512 m=audio 56600 RTP/SAVPF 0 109 513 a=mid:m1 514 a=rtpmap:0 PCMU/8000 515 a=rtpmap:109 opus/48000 516 a=appId:10 517 m=video 56602 RTP/AVPF 100 101 110 111 - Main camera 518 a=mid:m2 519 a=rtpmap:100 H264/90000 - Base layer 520 a=rtpmap:101 H264-SVC/90000 - Enhancement layer. 521 a=depend:101 lay L1:100 - dependencies 522 a=rtpmap:110 1d-interleaved-parityfec/90000 523 a=fmtp:110 L=5; D=10; repair-window=200000 524 a=rtpmap:111 1d-interleaved-parityfec/90000 525 a=fmtp:111 L=10; D=10; repair-window=400000 526 a=appId:1000 pt=100 527 a=appId:1010 pt=101 528 a=appId:2110 pt=110 529 a=appId:2120 pt=111 530 a=appId-group:FEC-FR 1000 2110 531 a=appId-group:FEC-FR 1000 1010 2120 532 a=appId-group:DDP 1000 1010 534 5. Acknowledgements 536 Place Holder 538 6. IANA Considerations 540 TBD 542 7. Security Considerations 544 TBD. 546 8. References 547 8.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 553 Jacobson, "RTP: A Transport Protocol for Real-Time 554 Applications", STD 64, RFC 3550, July 2003. 556 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 557 Specifications: ABNF", STD 68, RFC 5234, January 2008. 559 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 560 Header Extensions", RFC 5285, July 2008. 562 8.2. Informative References 564 [I-D.ietf-avtext-rtp-grouping-taxonomy] 565 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 566 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 567 Time Transport Protocol (RTP) Sources", 568 draft-ietf-avtext-rtp-grouping-taxonomy-00 (work in 569 progress), November 2013. 571 [I-D.ietf-mmusic-sdp-bundle-negotiation] 572 Holmberg, C., Alvestrand, H., and C. Jennings, 573 "Multiplexing Negotiation Using Session Description 574 Protocol (SDP) Port Numbers", 575 draft-ietf-mmusic-sdp-bundle-negotiation-05 (work in 576 progress), October 2013. 578 [I-D.ietf-rtcweb-overview] 579 Alvestrand, H., "Overview: Real Time Protocols for Brower- 580 based Applications", draft-ietf-rtcweb-overview-08 (work 581 in progress), September 2013. 583 [I-D.roach-mmusic-unified-plan] 584 Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for 585 Using SDP with Large Numbers of Media Flows", 586 draft-roach-mmusic-unified-plan-00 (work in progress), 587 July 2013. 589 [I-D.westerlund-avtcore-rtp-simulcast] 590 Westerlund, M., Lindqvist, M., and F. Jansson, "Using 591 Simulcast in RTP Sessions", 592 draft-westerlund-avtcore-rtp-simulcast-03 (work in 593 progress), October 2013. 595 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 596 Schulzrinne, "Grouping of Media Lines in the Session 597 Description Protocol (SDP)", RFC 3388, December 2002. 599 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 600 Description Protocol", RFC 4566, July 2006. 602 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 603 Session Description Protocol", RFC 4756, November 2006. 605 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 606 Protocol (SDP) Content Attribute", RFC 4796, 607 February 2007. 609 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 610 Media Attributes in the Session Description Protocol 611 (SDP)", RFC 5576, June 2009. 613 Authors' Addresses 615 Roni Even 616 Huawei Technologies 617 Tel Aviv, 618 Israel 620 Email: roni.even@mail01.huawei.com 622 Jonathan Lennox 623 Vidyo, Inc. 624 433 Hackensack Avenue 625 Seventh Floor 626 Hackensack, NJ 07601 627 US 629 Email: jonathan@vidyo.com 631 Qin Wu 632 Huawei Technologies 634 Email: bill.wu@huawei.com