idnits 2.17.1 draft-even-mmusic-multiple-streams-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 (February 17, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4796' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC5104' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC5117' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'RFC5285' is defined on line 566, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-multi-media-rtp-session-01 == Outdated reference: A later version (-05) exists of draft-lennox-mmusic-sdp-source-selection-04 == Outdated reference: A later version (-04) exists of draft-westerlund-avtcore-rtp-simulcast-01 == Outdated reference: A later version (-02) exists of draft-westerlund-avtcore-rtp-topologies-update-01 == Outdated reference: A later version (-01) exists of draft-westerlund-avtext-codec-operation-point-00 == Outdated reference: A later version (-03) exists of draft-westerlund-avtext-rtcp-sdes-srcname-01 == Outdated reference: A later version (-02) exists of draft-westerlund-mmusic-max-ssrc-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 0 errors (**), 0 flaws (~~), 12 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: August 21, 2013 Vidyo 6 Q. Wu 7 Huawei Technologies 8 February 17, 2013 10 Describing multiple RTP media streams in SDP 11 draft-even-mmusic-multiple-streams-02.txt 13 Abstract 15 This document describes issues when describing multiple RTP streams 16 in a single RTP session using SDP and considers the different RTP 17 topologies that should be supported. The document looks at current 18 solutions and provides paths toward addressing the issues. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 21, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. RTP topologies for CLUE . . . . . . . . . . . . . . . . . . . 5 57 4. Review of current directions in MMUSIC, AVText and AVTcore . . 7 58 5. Requirements from a solution . . . . . . . . . . . . . . . . . 9 59 6. SDP limitations and proposed solution . . . . . . . . . . . . 10 60 6.1. single RTP stream . . . . . . . . . . . . . . . . . . . . 11 61 6.2. One or multiple RTP streams . . . . . . . . . . . . . . . 11 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 Communication systems can send and receive multiple RTP media 73 streams. The streams can be multiple video streams from the same 74 source/camera representing, for example, different resolutions 75 (simulcast, scalable video (SVC)) or repair streams (FEC). They can 76 be different streams from the same endpoint but from different 77 cameras, for example a Telepresence system sending two views of the 78 room from two different cameras. They can also be multiple streams 79 from separate original endpoints, sent by a middlebox. 81 RTP [RFC3550] and [I-D.ietf-avtcore-multi-media-rtp-session] allow 82 the multiplexing of multiple media of the same and different types 83 (video with video and audio with video] in a single RTP session 84 identified by a single transport address. The RTP streams are 85 identified by their synchronization source identifiers (SSRC). 87 SIP offer answer [RFC3264] uses SDP [RFC4566] to negotiate RTP 88 [RFC3550] media streams. This document discusses the capabilities 89 and limitations of SDP when describing SSRC multiplexed streams. 91 When looking at the following offer 93 m=video 10000 RTP/AVP 31 32 95 a=rtpmap:31 H261/90000 97 a=rtpmap:32 MPV/90000 99 What does it mean one RTP session is offered with H.261 or MPV codecs 100 for the same content, or one RTP session is offered with H.261 and 101 MPV codecs each with different content? 103 This offer should really mean "arbitrarily many streams, with 104 potentially different content, any of which could use either H.261 or 105 MPV, potentially switching dynamically between them." Now how do we 106 provide enough information in SDP to allow the receiver to get a 107 better understanding of what the offer is. 109 Reading some text from RFC3264 it may look like a Media stream is 110 defined as a single media instance 112 "The offer will contain zero or more media streams (each media stream 113 is described by an "m=" line and its associated attributes)." 115 "In all cases, the formats in the "m=" line MUST be listed in order 116 of preference, with the first format listed being preferred. In this 117 case, preferred means that the recipient of the offer SHOULD use the 118 format with the highest preference that is acceptable to it." 120 "For each "m=" line in the offer, there MUST be a corresponding "m=" 121 line in the answer. The answer MUST contain exactly the same number 122 of "m=" lines as the offer. This allows for streams to be matched up 123 based on their order" 125 Since SDP and [RFC3264] offer/answer describe RTP sessions, SDP's 126 term "media stream" is poorly chosen. Careful reading reveals that a 127 single SDP "media stream" can be used by arbitrarily many RTP 128 streams. (Indeed, historically this was the case in SAP, the first 129 usage of SDP, which was used to describe loosely-coupled RTP 130 multicast sessions with arbitrarily many participants.) 132 The logic of RFC3264 about the preference does not work if you have 133 multiple RTP streams in the same m-line unless the same preference 134 applies to all the RTP streams. So when we look at solution we will 135 also need to clarify the text in RFC3264 and most probably will need 136 to have the right terminology for RTP session, media session across 137 the different documents. 139 SDP [RFC4566] is used to describe the multimedia session. The basic 140 model uses a two level hierarchy, consisting of session level and 141 media level. 143 SDP support of multiplexing multiple media streams in one RTP session 144 based on the RTP stream SSRC does not provide sufficient capabilities 145 to allow each of the multiplexed RTP streams identified by SSRC to 146 have unique attributes, for example different bandwidth. 147 Furthermore, when an offer has multiple payload type in a single 148 media level descriptor (m-line), this is identified as option to 149 receive all this payload types multiplexed. 151 SDP provides a framework to define grouping relations between SDP 152 media streams [RFC5888]. This framework specifies the grouping based 153 on the SDP media session and not on RTP stream. 155 Some tools for supporting RTP stream level attributes per RTP streams 156 as well as support for simulcast were proposed and this document will 157 look at them. It was not a major problem so far since most endpoints 158 are using a single audio and video stream and are using SDP media 159 level descriptors (m-lines) to describe each of the streams. Some of 160 the existing implementation when offering multiple payload types in a 161 single m-line are doing a second offer/answer exchange offering only 162 one of the payload types removing the rest in order to indicate that 163 they can only receive one media type encoding at a time. Every 164 change of media type requires an offer / answer exchange. 166 Currently both RTCweb and CLUE WGs have interest in better support 167 for multiplexing either multiple RTP media streams from the same type 168 or different types. The work in 169 [draft-ietf-mmusic-sdp-bundle-negotiation-01] and 170 [draft-holmberg-mmusic-sdp-mmt-negotiation-00] provides two different 171 directions for initial bundling support options for SDP negotiation 172 of multiplexing different media types but the problem of identifying 173 different RTP streams with different attributes is still not fully 174 solved. There is a dependency between what will be the bundling 175 approach and the solution for describing individual RTP streams 176 attributes. 178 This document discusses the different RTP topologies and describes 179 existing tools and see what they provide and how they can be extended 180 to provide better SDP support for SSRC multiplexed RTP streams while 181 supporting the different topologies. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC2119[RFC2119] and 188 indicate requirement levels for compliant RTP implementations. 190 3. RTP topologies for CLUE 192 The typical RTP topologies used by Telepresence systems specify 193 different behaviors for RTP and RTCP distribution. A number of RTP 194 topologies are described in 195 [I-D.westerlund-avtcore-rtp-topologies-update]. The CLUE WG 196 direction is to be able to support the relevant topologies including 197 point-to-point, as well as media mixers, media- switching mixers, and 198 source-projection mixers. 200 In the point-to-point topology, one peer communicates directly with a 201 single peer over unicast. There can be one or more RTP sessions, and 202 each RTP session can carry multiple RTP streams identified by their 203 SSRC. All SSRCs will be recognized by the peers based on the 204 information in the RTCP SDES report that will include the CNAME and 205 SSRC of the sent RTP streams. In some cases, a video conferencing 206 system with multiple video sources in a point-to-point may 207 nonetheless have RTP which is best described by one of the mixer 208 topologies below. For example, it can produce composed or switched 209 RTP streams to be used by a receiving system with fewer displays than 210 the sender has sources. 212 In the Media Mixer topology, the peers communicate only with the 213 mixer. The mixer provides mixed or composed media streams, using its 214 own SSRC for the sent streams. There are two cases here. In the 215 first case the mixer may have separate RTP sessions with each peer 216 (similar to the point to point topology) terminating the RTCP 217 sessions on the mixer; this is known as Topo-RTCP-Terminating MCU in 218 [I-D.westerlund-avtcore-rtp-topologies-update]. In the second case, 219 the mixer can use a conference-wide RTP session similar to 220 [I-D.westerlund-avtcore-rtp-topologies-update] Topo-mixer or Topo- 221 Video-switching. The major difference is that for the second case, 222 the mixer uses conference-wide RTP sessions, and distributes the RTCP 223 reports to all the RTP session participants, enabling them to learn 224 all the CNAMEs and SSRCs of the participants and know the 225 contributing source or sources (CSRCs) of the original streams from 226 the RTP header. In the first case, the Mixer terminates the RTCP and 227 the participants cannot know all the available sources based on the 228 RTCP information. The conference roster information including 229 conference participants, endpoints, media and media-id (SSRC) can be 230 available using the conference event package [RFC4575] element. 232 In the Media-Switching Mixer topology, the peer to mixer 233 communication is unicast with mixer RTCP feedback. It is 234 conceptually similar to a composing mixer as described in the 235 previous paragraph, except that rather than composing or mixing 236 multiple sources, the mixer provides one or more conceptual sources 237 selecting one source at a time from the original sources. The Mixer 238 creates a conference-wide RTP session by sharing remote SSRC values 239 as CSRCs to all conference participants. 241 In the Source-Projection Mixer (SPM) topology, the peer to mixer 242 communication is unicast with RTCP mixer feedback. Every potential 243 sender in the conference has a source which is "projected" by the 244 mixer into every other session in the conference; thus, every 245 original source is maintained with an independent RTP identity to 246 every receiver, maintaining separate decoding state and its original 247 RTCP SDES information. However, RTCP is terminated at the mixer, 248 which might also perform reliability, repair, rate adaptation, or 249 transcoding on the stream. Senders' SSRCs may be renumbered by the 250 mixer. The sender may turn the projected sources on and off at any 251 time, depending on which sources it thinks are most relevant for the 252 receiver; this is the primary reason why this topology must act as an 253 RTP mixer rather than as a translator, as otherwise these disabled 254 sources would appear to have enormous packet loss. Source switching 255 is accomplished through this process of enabling and disabling 256 projected sources, with the higher-level semantic assignment of 257 reason for the RTP streams assigned externally. 259 When looking at SSRC multiplexing we can see that in various 260 topologies, the SSRC behavior may be different: 262 1. The SSRCs are static (assigned by the MCU/Mixer), and there is an 263 SSRC for each media capture encoding defined in the CLUE 264 protocol. Source information may be conveyed using CSRC, or, in 265 the case of topo-RTCP-Terminating MCU, is not conveyed. 267 2. The SSRCs are dynamic, representing the original source and are 268 relayed by the Mixer/MCU to the participants. 270 In the source projecting mixer (SPM) topology, the number of sources 271 and their SSRCs may change dynamically. An example is a video 272 conference that starts with 4 participants and the (SPM) forwards the 273 video RTP streams from 3 of them to all participants. Later 10 more 274 participants join the conference and the SPM will forward 9 video 275 sources to each participant. The projected streams keep their 276 original SSRCs and each participant may get different streams relayed 277 by the SPM. The SPM creates a separate RTP session with each 278 participant and will convey the origin of the media using RTCP SDES 279 information. In this case the number of RTP streams and the sources 280 they are coming from may change dynamically. This will be a 281 challenge if we will need to explicitly provide in the SDP all the 282 sources in the initial offer, and change it whenever a party joins or 283 leaves. There is also a scaling issue to explicitly list all the 284 sources for large conferences. 286 4. Review of current directions in MMUSIC, AVText and AVTcore 288 This section provides an overview of the RFCs and drafts that tries 289 to provide more information about RTP streams based on their SSRC and 290 can be helpful to assign attribute to individual RTP streams that are 291 multiplexed to a single transport address. 293 When looking at the available tools based on current work in MMUSIC, 294 AVTcore and AVText for supporting SSRC multiplexing at the SDP level 295 the following documents are considered to be relevant. 297 SDP Source attribute [RFC5576] mechanisms to describe specific 298 attributes of RTP sources based on their SSRC. This document defines 299 a mechanism to describe RTP sources, identified by their 300 synchronization source(SSRC) identifier, in SDP, to associate 301 attributes with these sources, and to express relationships among 302 individual sources. It also defines a number of new SDP attributes 303 that apply to individual sources ("source-level" attributes), 304 describes how a number of existing media stream ("media-level") 305 attributes can also be applied at the source level, and establishes 306 IANA registries for source-level attributes and source grouping 307 semantics. This mechanism provides an extensible framework but that 308 implies that there will be a need to specify source level attributes 309 and probably to change the IANA procedure for attribute registration 310 adding the requirement to specify if it is also source level 311 attribute ( currently [RFC4566] requires for type of attribute to 312 specify (session level, media level, or both)) 314 [I-D.westerlund-mmusic-max-ssrc] a signaling solution for how to use 315 multiple SSRCs within one RTP session. This document also defines 316 two new SDP attributes, "max-send-ssrc" and" max-recv-ssrc". The 317 attributes allows an entity to, for a given media description, 318 indicate sending and receiving capabilities of multiple media 319 sources, based on codec usage . Since the number of payload type 320 numbers in an SDP m-line specifies that all these payloads can be 321 received this draft provides a way to specify how many can be sent 322 and received simultaneously. Still if there are more payload type 323 numbers in the m-line it is still implies that a receiver must be 324 able to receive any subset at any given time but no more than max- 325 ssrc. 327 A proposed solution to support simulcast is defined in 328 [I-D.westerlund-avtcore-rtp-simulcast]. Simulcast is an application 329 usage where multiple media streams derived from the same media source 330 may be sent simultaneously. The document discusses the best way of 331 accomplishing this in RTP using a session-based solution. The 332 document describes a solution where each stream from the unicast 333 stream will use a separate RTP session. Section 4.2 of the document 334 looks at using a single RTP session using RFC5576 [RFC5576] and the 335 proposed source name attribute specified in 336 [I-D.westerlund-avtext-rtcp-sdes-srcname]. Another way for a single 337 seesion support may be by using a different payload type numbers but 338 section 4.1 of [I-D.westerlund-avtcore-rtp-simulcast] discourages 339 such usage. 341 [I-D.westerlund-avtext-rtcp-sdes-srcname] provides an extension that 342 may be send in SDP, as an RTCP SDES information or as an RTP header 343 extension that uniquely identifies a single media source. It defines 344 a hierarchical order of the SRCNAME parameter that can be used, for 345 example, to describe multiple resolutions from the same source (see 346 section 5.1 of [I-D.westerlund-avtcore-rtp-simulcast]). Still all 347 the examples are using RTP session multiplexing and there is no 348 description of using a single RTP session. This can probably be 349 addressed using bundle with separate m-line for each resolution. 351 Other documents that discusses the media source issue and may be 352 required as part of the solution includes: 354 [I-D.lennox-mmusic-sdp-source-selection] specifies how participants 355 in a multimedia session can request a specific source from a remote 356 party. 358 [I-D.westerlund-avtext-codec-operation-point] extends the codec 359 control messages by specifying messages that let participants 360 communicate a set of codec configuration parameters. 362 Negotiation of generic image attributes in SDP [RFC6236] provides the 363 means to negotiate the image size. The image attribute can be used 364 to offer different image parameters like size but in order to offer 365 multiple RTP streams with different resolutions it does it using 366 separate RTP session for each image option. 368 5. Requirements from a solution 370 When two or more endpoints with multiple sources communicate with 371 each other and requires multiplexing multiple media types in the same 372 RTP session,the following requirements should be addressed: 374 o It should be possible to group relationships among sources of an 375 RTP session 377 o It should be possible to identify streams among sources of an RTP 378 session 380 o It should be possible to indicate the maximum number of Sources 381 and Receivers 383 o It should be possible to negotiate Codec Configuration parameters 385 o It should be possible to request the transmission of specific 386 sources 388 o It should be possible to indicate the priority of transmission of 389 sources 391 o It should be possible to indicate support of multiple media type 392 multiplexing 394 o It should be possible to support receipt of multiple RTP sources 395 without explicit per-source signaling or negotiation. 397 o It must be possible for a multimedia session to use multiple 398 transport flows for a given media type where it is considered 399 valuable (for example, for distributed media, or differential 400 quality-of-service). 402 o It must be possible for a source to be placed into a switched RTP 403 session even if the source is a "late joiner", i.e. was added to 404 the conference after the receiver requested the switched source. 406 o It must be possible for a receiver to identify the actual source 407 that is currently being mapped to a switched media stream, and 408 correlate it with out-of-band information such as rosters. 410 o If a given source is being sent on the same transport flow (media 411 track) for more than one reason (e.g. if it corresponds to more 412 than one RTCwen Mediastream at once), it should be possible for a 413 sender to send only one copy of the source. 415 o On the network, media flows should, as much as possible, look and 416 behave like currently-defined usages of existing protocols; 417 established semantics of existing protocols must not be redefined. 419 o The solution should seek to minimize the processing burden for 420 boxes that distribute media to decoding hardware. 422 o If multiple sources from a single synchronization context are 423 being sent simultaneously, it must be possible for a receiver to 424 associate and synchronize them properly. 426 6. SDP limitations and proposed solution 428 As the default behavior, Group relationship among sources of an RTP 429 session can be indicated by extending the Session Description 430 Protocol (SDP) Grouping Framework [RFC5888]. However the Session 431 Description Protocol (SDP) Grouping Framework is limited to one media 432 description per SFP m-line and does not support multiplexing multiple 433 media types in one RTP session. Alternatively, Group relationship 434 among sources of an RTP session can be implicitly indicated using 435 hierarchical order of the SRCNAME parameter defined in 436 [I-D.westerlund-avtext-rtcp-sdes-srcname]. 438 Normally each RTP stream in the multiplexed RTP streams is identified 439 by its SSRC. However in some cases, one media stream may include 440 multiple sub-stream sharing the same properties, e.g., scalable 441 media. In such cases, the capability to identify each sub-stream 442 among sources of an RTP session is required. 443 [I-D.westerlund-avtext-codec-operation-point] provides a means for 444 sub-stream identification. However such means are too much codec 445 specific and used together with codec control messages. 447 It is clear that the current SDP does not provide enough tools to 448 address all requirements. There are a couple of options to represent 449 multiple media streams, The major two options are: 451 o Use multiple m-line each describing a single RTP stream 453 o Use multiple m-lines each describing one or multiple RTP streams. 455 6.1. single RTP stream 457 When using a single RTP stream in each m-line provides an easy way to 458 describe the streams. This solution requires that all RTP media 459 streams MUST be declared explicitly in the initial offer or in a 460 later one before they can be used. As discussed above this solution 461 does not scale well when doing a multipoint conference using the 462 Source Projecting Mixer when the conference include multiple 463 participants and each participant may get a different subset of all 464 streams. Supporting this use case may require a lot of SIP re- 465 invites. 467 6.2. One or multiple RTP streams 469 For this option each m-line will specify the maximum number of SSRC 470 that can be sent or received using this m-line. So similar streams 471 can be added or removed implicitly without requiring more signaling. 472 The solution will use the maxssrc attribute to specify how many RTP 473 streams can be sent or received. If there is no maxssrc parameter it 474 will imply a single RTP stream is specified. This option allows the 475 SDP to use a single RTP stream per m-line if there is a need to 476 specify specific attribute that cannot be described in a single 477 m-line and bundle the m-lines. 479 7. Acknowledgements 481 Place Holder 483 8. IANA Considerations 485 TBD 487 9. Security Considerations 489 TBD. 491 10. References 492 10.1. Normative References 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 10.2. Informative References 499 [I-D.ietf-avtcore-multi-media-rtp-session] 500 Westerlund, M., Perkins, C., and J. Lennox, "Multiple 501 Media Types in an RTP Session", 502 draft-ietf-avtcore-multi-media-rtp-session-01 (work in 503 progress), October 2012. 505 [I-D.lennox-mmusic-sdp-source-selection] 506 Lennox, J. and H. Schulzrinne, "Mechanisms for Media 507 Source Selection in the Session Description Protocol 508 (SDP)", draft-lennox-mmusic-sdp-source-selection-04 (work 509 in progress), March 2012. 511 [I-D.westerlund-avtcore-rtp-simulcast] 512 Westerlund, M., Burman, B., Lindqvist, M., and F. Jansson, 513 "Using Simulcast in RTP sessions", 514 draft-westerlund-avtcore-rtp-simulcast-01 (work in 515 progress), July 2012. 517 [I-D.westerlund-avtcore-rtp-topologies-update] 518 Westerlund, M. and S. Wenger, "RTP Topologies", 519 draft-westerlund-avtcore-rtp-topologies-update-01 (work in 520 progress), October 2012. 522 [I-D.westerlund-avtext-codec-operation-point] 523 Westerlund, M., Burman, B., and L. Hamm, "Codec Operation 524 Point RTCP Extension", 525 draft-westerlund-avtext-codec-operation-point-00 (work in 526 progress), March 2012. 528 [I-D.westerlund-avtext-rtcp-sdes-srcname] 529 Westerlund, M., Burman, B., and P. Sandgren, "RTCP SDES 530 Item SRCNAME to Label Individual Sources", 531 draft-westerlund-avtext-rtcp-sdes-srcname-01 (work in 532 progress), July 2012. 534 [I-D.westerlund-mmusic-max-ssrc] 535 Holmberg, C., Westerlund, M., Burman, B., and F. Jansson, 536 "Multiple Synchronization Sources (SSRC) in SDP Media 537 Descriptions", draft-westerlund-mmusic-max-ssrc-00 (work 538 in progress), September 2012. 540 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 541 with Session Description Protocol (SDP)", RFC 3264, 542 June 2002. 544 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 545 Jacobson, "RTP: A Transport Protocol for Real-Time 546 Applications", STD 64, RFC 3550, July 2003. 548 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 549 Description Protocol", RFC 4566, July 2006. 551 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 552 Initiation Protocol (SIP) Event Package for Conference 553 State", RFC 4575, August 2006. 555 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 556 Protocol (SDP) Content Attribute", RFC 4796, 557 February 2007. 559 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 560 "Codec Control Messages in the RTP Audio-Visual Profile 561 with Feedback (AVPF)", RFC 5104, February 2008. 563 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 564 January 2008. 566 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 567 Header Extensions", RFC 5285, July 2008. 569 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 570 Media Attributes in the Session Description Protocol 571 (SDP)", RFC 5576, June 2009. 573 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 574 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 576 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 577 Attributes in the Session Description Protocol (SDP)", 578 RFC 6236, May 2011. 580 Authors' Addresses 582 Roni Even 583 Huawei Technologies 584 Tel Aviv, 585 Israel 587 Email: roni.even@mail01.huawei.com 589 Jonathan Lennox 590 Vidyo, Inc. 591 433 Hackensack Avenue 592 Seventh Floor 593 Hackensack, NJ 07601 594 US 596 Email: jonathan@vidyo.com 598 Qin Wu 599 Huawei Technologies 601 Email: bill.wu@huawei.com