idnits 2.17.00 (12 Aug 2021) /tmp/idnits27536/draft-even-mmusic-application-token-03.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 (April 11, 2014) is 2955 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3388' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC4756' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: draft-ietf-avtext-rtp-grouping-taxonomy has been published as RFC 7656 == Outdated reference: draft-ietf-mmusic-sdp-bundle-negotiation has been published as RFC 8843 == Outdated reference: draft-ietf-rtcweb-overview has been published as RFC 8825 == 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 (~~), 7 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: October 13, 2014 Vidyo 6 Q. Wu 7 Huawei Technologies 8 April 11, 2014 10 The Session Description Protocol (SDP) Application Token Attribute 11 draft-even-mmusic-application-token-03.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 signaling descriptions 19 associated with particular RTP media streams. 21 This document defines a mechanism to provide the mapping between the 22 SSRCs of RTP streams and the SDP m-line description by defining 23 extensions to RTP and RTCP messages. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 13, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Proposal for Application ID . . . . . . . . . . . . . . . . . 4 62 3.1. appId token . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1.1. RTCP SDES message . . . . . . . . . . . . . . . . . . 7 64 3.1.2. RTP Header Extension . . . . . . . . . . . . . . . . . 8 65 3.1.3. recv-appId . . . . . . . . . . . . . . . . . . . . . . 8 66 4. Using Application ID token in Offer / Answer . . . . . . . . . 9 67 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 The RTP [RFC3550] header includes the payload type number and the 79 SSRC values of the RTP stream. RTP defines how to de-multiplex 80 streams within an RTP session, but in some use cases, applications 81 need further identifiers in order to map an RTP media stream to its 82 SDP m-line description. 84 SDP [RFC4566] can be used to describe multiple RTP media streams in 85 one or more m-lines that define a single SSRC multiplexed RTP session 86 (as specified in [RFC3550]). This addresses the WebRTC architecture 87 [I-D.ietf-rtcweb-overview]. 89 A Unified Plan for Using SDP with Large Numbers of Media Flows 90 [I-D.roach-mmusic-unified-plan] proposes that each m-line will 91 represent a media source [I-D.ietf-avtext-rtp-grouping-taxonomy]. In 92 the simple case a media source will be one video or audio RTP stream. 93 Media source description becomes more complicated when, for robust 94 applications, techniques like retransmission (RTX) and Forward Error 95 Correction (FEC) are used to protect media, or simulcast or layered 96 coding can be used to provide support to heterogeneous receivers. In 97 these cases a media source may send more than one RTP stream: for 98 example, a scalable video stream base layer, an enhancement layer and 99 a FEC stream. 101 Multiple SDP m-lines can be multiplexed to a single RTP session using 102 [I-D.ietf-mmusic-sdp-bundle-negotiation]. The same payload type 103 number can be used in multiple bundled m-lines. An [RFC3264] offerer 104 may receive an RTP media stream before the SDP answer, and if the 105 same payload type number is used in multiple bundled m-lines, the 106 offerer will not be able to associate incoming media using that pt 107 number to a specific m-line. 109 Some applications may require more information about the usage of the 110 RTP streams: for example, RTP streams from different cameras that 111 need to be identified by the application in order to render them 112 correctly, or a source that can send multiple versions of the same 113 stream in different resolutions (i.e. simulcast 114 [I-D.westerlund-avtcore-rtp-simulcast]). 116 A selective forwarding middlebox as described in RTP topologies 117 section 3.7 [topologies] may project the RTP stream from the source 118 to the destination and forward new SSRCs without any signaling. 120 A three camera telepresence system may send two video media stream of 121 the two recent active speakers to a system with two monitors. In 122 this case it may send first the video from the left and center camera 123 (this will cause the video from the center camera to be displayed on 124 the right) and later the video from the center and right camera (this 125 will cause the video from the center camera to be displayed on the 126 left). The SSRC of the video stream from the center camera will 127 remain the same but the mapping to the stream description will 128 change. 130 As discussed in [I-D.roach-mmusic-unified-plan] during call 131 establishment, circumstances may arise under which an endpoint can 132 send an offer to receive a new stream, and begin receiving media for 133 that media stream prior to receiving the SDP that correlates its SSRC 134 to the m-line. For such cases, the endpoint will not know how to 135 handle the media, and will most probably be forced to discard it. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC2119[RFC2119] and 142 indicate requirement levels for compliant RTP implementations. 144 3. Proposal for Application ID 146 As we saw in the introduction, the SSRC of the RTP stream which 147 should be created by the RTP layer is used by the SDP in the offer to 148 map an RTP stream description to the SDP description. There are 149 cases where the SSRCs of the RTP streams may not be available or do 150 not provide all the required information. 152 There is a need to have a token that will allow the mapping between a 153 single RTP stream configuration in an m-line to the actual RTP media 154 stream. For example, stream1 is the RTP stream from the left camera 155 and stream2 is the RTP stream from the right camera and stream3 is 156 the FEC stream that protects both streams. 158 There is also a need for a token that will allow the offerer to 159 correlate a received RTP stream to an SDP m-line before receiving the 160 answer from the remote side. 162 In order to address these requirements this document defines an SDP 163 token attribute appId that provides a level of indirection for the 164 binding. The actual binding is done in RTP by associating the appId 165 with an SSRC using a new RTCP SDES message and a new RTP header 166 extension that define the mapping from appId to a specific SSRC. 167 Having the binding in RTP/RTCP allows the RTP layer to change the 168 SSRC of a media stream by sending a new binding message (SDES an RTP 169 header extension) without a need to have an SDP level offer/answer 170 exchange. 172 For the case when the offerer receives an RTP stream before the SDP 173 answer, we define a new optional attribute recv-appId to be used for 174 correlating this received RTP stream. 176 Note: the name appId does not represent the token functionality very 177 well. We are looking for a better name (SSID source stream ID was 178 proposed on the mailing list but is also well know for wifi networks) 180 3.1. appId token 182 AppId is a general-purpose token associated with an RTP stream, 183 allowing the binding of the SDP representation to an SSRC. 185 The token is chosen by the sender, and represents the RTP stream that 186 will be sent to the receiver. 188 The proposed token can be sent using SDP, RTCP SDES messages 189 [RFC3550], or an RTP header extension [RFC5285] 191 The SSRC mapping may be available to the receiver when receiving the 192 RTP stream through the RTP header extension, but may also be 193 available ahead of time via an RTCP SDES message conveyed before the 194 source starts sending, even if the receiver has not seen any RTP 195 packets from this source (as in a multipoint conference). 197 The receiver can receive new sources that may be of two kinds. 199 o A new RTP stream replacing an existing RTP stream, in which case 200 the AppId of the replaced RTP stream will be assigned to the new 201 SSRC. 202 o A new RTP stream requiring a different AppId, for example, when 203 adding a presentation stream to an existing call with two video 204 cameras from a room. 206 The solution supports an RTP session as described using SDP. The RTP 207 session may use Bundle [I-D.ietf-mmusic-sdp-bundle-negotiation] with 208 more than one m-line. In this case, if the SSRCs of all RTP streams 209 are not known in advance, the AppIds associated with each m-line need 210 to be available to the media receiver in order to map each SSRC to a 211 specific m-line configuration. The appIds MUST be unique in an SDP 212 session. 214 Editor Note (is this required?): It is preferable that they will be 215 unique in an RTP session which is not a problem in a point to point 216 call or in a multipoint conference with a central signaling point. 218 The document defines a new SDP media level attribute a=appId that can 219 be used to list all the appIds that an application may use. 221 The appId syntax provides a token identifier. Each value of the 222 AppId maps to one SSRC at a time. When a new SSRC is mapped to an 223 existing AppId using an RTP header extension or SDES message, it 224 replaces the previous RTP stream for this application usage. 226 The definition is 228 a=appId:token 230 a=appId:token 232 a=appId:token : 234 The formal representation of the appId token is: 235 appId-attribute = "appId:" token *[WSP attribute] 236 attribute =/ appId-attr 237 ; The base definition of "attribute" is in [RFC4566]. 238 ; (It is the content of "a=" lines.) 239 ; WSP and DIGIT defined in [RFC5234] 240 ; token defined in [RFC4566] 242 AppId attributes are not defined in this specification but are 243 provided for future extensibility. (TODO: define an IANA registry 244 for them.) 246 Examples: 248 The SDP offer specifies an appId that will be used for mapping to 249 specific SSRCs. The example shows two RTP streams having different 250 content [RFC4796] with the same payload type number. The appId can 251 be used to identify the content of the RTP stream. 253 a=group:BUNDLE m1 m2 254 m=video 49200 RTP/AVP 99 255 a=rtpmap:99 H264/90000 256 a=mid:m1 257 a=content:main 258 a=appId:2 259 m=video 49200 RTP/AVP 99 260 a=rtpmap:99 H264/90000 261 a=mid:m2 262 a=content:alt 263 a=appId:3 265 The second example is when the application usage of the RTP stream is 266 specified using SDP to specify different content [RFC4796] , and each 267 RTP stream has a Retransmission stream. The media receiver can map 268 the received SSRC of the RTP stream or the retransmission to the 269 specific content based on the appId. 271 a=group:BUNDLE m1 m2 272 m=video 49200 RTP/AVP 97,98 273 a=rtpmap:98 H264/90000 274 a=mid:m1 275 a=content:main 276 a=rtpmap:97 rtx/90000 277 a=fmtp:97 apt=98;rtx-time=3000 278 a=appId:2 279 a=appId:3 280 m=video 49200 RTP/AVP 97,98 281 a=rtpmap:98 H264/90000 282 a=mid:m2 283 a=content:alt 284 a=rtpmap:97 rtx/90000 285 a=fmtp:97 apt=98;rtx-time=3000 286 a=appId:4 287 a=appId:5 289 In this example, the SDP signaling does not provide enough 290 information to establish which appId value will be used for the H.264 291 encoded stream, and which will be used for the RTX retransmission 292 stream. However, it does establish the relationships among the 293 streams identified by appId values, allowing the receiver to properly 294 associate the related streams once it receives them. 296 3.1.1. RTCP SDES message 298 This document specifies a new RTCP SDES message 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | AppId = XXX | length |AppId token 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | .... 307 This AppId is the same token as defined in the new SDP attribute and 308 is also used in the RTP header extension. 310 This SDES message MAY be sent in a compound RTCP packet based on the 311 application need. 313 Editor Note: Need guidance on how often the SDES message should be 314 sent. 316 3.1.2. RTP Header Extension 318 The Application ID is carried within the RTP header extension field, 319 using [RFC5285] two bytes header extension. 321 Support is negotiated within the SDP, i.e. 323 a=extmap:1 urn:ietf:params:rtp-hdrext:AppId 325 Packets tagged by the sender with the AppId then contain a header 326 extension as shown below 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | ID=1 | Len-1 | AppId 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | AppID .............. | 334 +-+-+-+-+-+-+-+-+ 336 To add or modify the AppId by an intermediary can be an expensive 337 operation, particularly if SRTP is used to authenticate the packet. 338 Modification to the contents of the RTP header requires a re- 339 authentication of the complete packet, and this could prove to be a 340 limiting factor in the throughput of a multipoint device. 342 There is no need to send the AppId header extension with all RTP 343 packets. Senders MAY choose to send it only when a new SSRC is sent, 344 or when an SSRC changes its association to an AppId. If such a mode 345 is being used, the header extension SHOULD be sent in the first few 346 RTP packets to reduce the risk of losing it due to packet loss. For 347 codecs with decoder refresh points (such as I-Frames in video 348 codecs), senders also SHOULD send the AppId header extension along 349 with the packets carrying the decoder refresh. 351 3.1.3. recv-appId 353 An offer may include a recv-appId attribute allowing the offerer to 354 request from the answerer to use this token for the RTP stream sent 355 from the answerer for a sendrecv or recvonly RTP stream. This is 356 important in order to support early media from the answerer that may 357 be received by the offerer before the answer SDP arrives. 359 The answerer should use the recv-appId as the token in the RTCP SDES 360 and RTP header extension for the RTP stream sent to the offerer. 362 The formal representation of the appId token is: 363 appId-attribute = "recv-appId:" token 364 ; The base definition of "attribute" is in [RFC4566]. 365 ; (It is the content of "a=" lines.) 367 An example of an offer using bundle with two video streams using the 368 same payload type number: 370 a=group:BUNDLE m1 m2 371 m=video 49200 RTP/AVP 99 372 a=rtpmap:99 H264/90000 373 a=mid:m1 374 a=content:main 375 a=appId:2 376 a=recv-appId:4 377 m=video 49200 RTP/AVP 99 378 a=rtpmap:99 H264/90000 379 a=mid:m2 380 a=content:alt 381 a=appId:3 382 a=recv-appId:5 384 4. Using Application ID token in Offer / Answer 386 The appId may be used in offer answer. Some use cases are provided. 387 They only show part of the SDP that can demonstrate the usage. 389 A simple case is when each SDP m-line describes one RTP stream and 390 the m-lines are bundled . The recv-appId is offered so when the 391 offerer sees an RTP stream with appId token value 10 it knows it is 392 the main video. 394 The offer is: 395 a=group:BUNDLE m1 m2 396 m=video 49200 RTP/AVP 98 397 a=rtpmap:98 H264/90000 398 a=mid:m1 399 a=content:main 400 a=appId:2 401 a=recv-appId:10 402 m=video 49200 RTP/AVP 99 403 a=rtpmap:99 H264/90000 404 a=mid:m2 405 a=content:alt 406 a=appId:3 407 a=recv-appId:20 409 An offerer sending a BUNDLE group MUST indicate at least one recv- 410 appId for every RTP m=line in the group on which it could receive 411 media (i.e., for every m-line which is marked a=sendrecv (possibly 412 implicitly) or a=recvonly. On m-lines whose configuration is such 413 that multiple packet streams are expected to be sent simultaneously 414 (e.g., one with rtx or fec payload types configured), the offerer 415 MUST specify as many recv-appId values as the number of simultaneous 416 packet streams. 418 Additionally, an offerer sending a BUNDLE group MUST indicate at 419 least one appId for every m= line on which it expects to send media 420 (i.e., every a=sendrecv or a=sendonly m= line), and MUST send 421 multiple appIds for m= lines on which it expects to send multiple 422 packet streams simultaneously. 424 An answerer, receiving an offer containing appId or recv-appId 425 attributes, MUST respond with mirrored recv-appId and appId values 426 for the subset of m= lines and packet streams indicated in the 427 answer, maintaining the same recv-appId and appId values. 429 In subsequent offers, appId and recv-appId values SHOULD be 430 maintained per m=line unless the offer is recycling the m=line for a 431 fundamentally new purpose, in which case new appId and recv-appId 432 values SHOULD be used. AppId and recv-appId values MUST NOT be 433 reused, in the same session, for a different m= line than the one to 434 which they were originally assigned, unless at least two times the 435 maximum segment lifetime (MSL) has passed since the previous offer/ 436 answer exchange in which the values were used. 438 5. Other Considerations 440 During the work on the document we identified that there are two 441 different problems that we were trying to address. One has to do 442 with mapping the RTP stream to an m-line addressed in the current 443 version of the document. The other problem is to provide semantics 444 to an RTP stream description in the SDP description for the cases 445 where the SSRC of the RTP stream is not known to the SDP signaling 446 layer and we also identified issues not addressed by the SSRC 447 attribute [RFC5576]. 449 A single RTP media stream can be identified in SDP by using the SSRC 450 attribute [RFC5576]. Relations between RTP streams in the same 451 session can be specified using the ssrc-group attribute [RFC5576]. 452 Using the SSRC to identify RTP streams in an SDP session assumes that 453 this information is available to the SDP signaling layer. The SSRC 454 is RTP layer information and may change in the RTP layer during a 455 session. 457 Support of FEC, SVC and simulcast brings more requirements as 458 explained using the following examples. 460 The following example is of a unified plan 461 [I-D.roach-mmusic-unified-plan] offer of one audio source and one 462 video source. The video source includes two SVC RTP streams a base 463 layer and an enhancement layer. There are also two FEC options: 465 Base layer S1 is protected by FEC repair stream R1 467 Base Layer S1 and Enhancement layer S2 are protected by FEC repair 468 stream R2. 470 This enables the answer to select the base layer with R1 or the Base 471 + enhancement layers both protected by R2. 473 This example uses the SSRC and SSRC-GROUP attributes which requires 474 the pre-knowledge of the SSRCs that are RTP layer values. 476 SDP Offer: 477 v=0 478 o=- 20518 0 IN IP4 198.51.100.1 479 s=FEC Grouping Semantics for SSRC Multiplexing 480 t=0 0 481 c=IN IP4 203.0.113.1 482 a=group:BUNDLE m1 m2 483 m=audio 56600 RTP/SAVPF 0 109 484 a=msid:ma ta 485 a=mid:m1 486 a=ssrc:53280 487 a=rtpmap:0 PCMU/8000 488 a=rtpmap:109 opus/48000 489 m=video 56602 RTP/AVPF 100 101 110 111 - Main camera 490 a=msid:ma tb 491 a=mid:m2 492 a=rtpmap:100 H264/90000 - Base layer 493 a=rtpmap:101 H264-SVC/90000 - Enhancement layer. 494 a=depend:101 lay L1:100 - dependencies 495 a=rtpmap:110 1d-interleaved-parityfec/90000 496 a=fmtp:110 L=5; D=10; repair-window=200000 497 a=rtpmap:111 1d-interleaved-parityfec/90000 498 a=fmtp:111 L=10; D=10; repair-window=400000 499 a=ssrc:1000 cname:MSTFEC@example.com 500 a=ssrc:1010 cname:MSTFEC@example.com 501 a=ssrc:2110 cname:MSTFEC@example.com 502 a=ssrc:2120 cname:MSTFEC@example.com 503 a=ssrc-group:FEC-FR 1000 2110 504 a=ssrc-group:FEC-FR 1000 1010 2120 505 a=ssrc-group:DDP 1000 1010 507 In this case all video streams are from the same source and can be 508 described using a single m-line. The grouping relations are 509 specified using the SSRCs values that need to be available in the 510 offer. It is also not clear based on the offer which rtpmap line 511 corresponds to each of the a=ssrc lines, e.g. which rtpmap line will 512 be sent using ssrc = 2110. The answerer can deduce the information 513 based on analyzing the ssrc-group information but there can be case 514 that it will not be possible.. 516 Note: These issues will be addressed in a separate document based on 517 the feedback from the working group that even though these are real 518 issues they should have a separate solution in order to differentiate 519 between the token and the semantics needed. 521 6. Acknowledgements 523 Place Holder 525 7. IANA Considerations 527 TBD 529 8. Security Considerations 531 TBD. 533 9. References 535 9.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 541 Jacobson, "RTP: A Transport Protocol for Real-Time 542 Applications", STD 64, RFC 3550, July 2003. 544 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 545 Specifications: ABNF", STD 68, RFC 5234, January 2008. 547 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 548 Header Extensions", RFC 5285, July 2008. 550 9.2. Informative References 552 [I-D.ietf-avtext-rtp-grouping-taxonomy] 553 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 554 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 555 Time Transport Protocol (RTP) Sources", 556 draft-ietf-avtext-rtp-grouping-taxonomy-01 (work in 557 progress), February 2014. 559 [I-D.ietf-mmusic-sdp-bundle-negotiation] 560 Holmberg, C., Alvestrand, H., and C. Jennings, 561 "Multiplexing Negotiation Using Session Description 562 Protocol (SDP) Port Numbers", 563 draft-ietf-mmusic-sdp-bundle-negotiation-06 (work in 564 progress), April 2014. 566 [I-D.ietf-rtcweb-overview] 567 Alvestrand, H., "Overview: Real Time Protocols for Brower- 568 based Applications", draft-ietf-rtcweb-overview-09 (work 569 in progress), February 2014. 571 [I-D.roach-mmusic-unified-plan] 572 Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for 573 Using SDP with Large Numbers of Media Flows", 574 draft-roach-mmusic-unified-plan-00 (work in progress), 575 July 2013. 577 [I-D.westerlund-avtcore-rtp-simulcast] 578 Westerlund, M., Lindqvist, M., and F. Jansson, "Using 579 Simulcast in RTP Sessions", 580 draft-westerlund-avtcore-rtp-simulcast-03 (work in 581 progress), October 2013. 583 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 584 with Session Description Protocol (SDP)", RFC 3264, 585 June 2002. 587 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 588 Schulzrinne, "Grouping of Media Lines in the Session 589 Description Protocol (SDP)", RFC 3388, December 2002. 591 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 592 Description Protocol", RFC 4566, July 2006. 594 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 595 Session Description Protocol", RFC 4756, November 2006. 597 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 598 Protocol (SDP) Content Attribute", RFC 4796, 599 February 2007. 601 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 602 Media Attributes in the Session Description Protocol 603 (SDP)", RFC 5576, June 2009. 605 Authors' Addresses 607 Roni Even 608 Huawei Technologies 609 Tel Aviv, 610 Israel 612 Email: roni.even@mail01.huawei.com 614 Jonathan Lennox 615 Vidyo, Inc. 616 433 Hackensack Avenue 617 Seventh Floor 618 Hackensack, NJ 07601 619 US 621 Email: jonathan@vidyo.com 623 Qin Wu 624 Huawei Technologies 626 Email: bill.wu@huawei.com