idnits 2.17.1 draft-westerlund-avtext-rtcp-sdes-srcname-01.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 (July 16, 2012) is 4299 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 6222 (Obsoleted by RFC 7022) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft B. Burman 4 Intended status: Standards Track P. Sandgren 5 Expires: January 17, 2013 Ericsson 6 July 16, 2012 8 RTCP SDES Item SRCNAME to Label Individual Sources 9 draft-westerlund-avtext-rtcp-sdes-srcname-01 11 Abstract 13 This document defines a new SDES item called SRCNAME which uniquely 14 identifies a single media source, like a camera or a microphone. 15 That way anyone receiving the SDES information from a set of 16 interlinked RTP sessions can determine which SSRCs are related to the 17 same source. It can equally be used to label SSRC multiplexed 18 related streams, such as FEC or Retransmission streams related to the 19 original source stream in the same session. In addition the new SDES 20 item is also defined for usage with the SDP source specific media 21 attribute ("a=ssrc") enabling an end-point to declare and learn the 22 source bindings ahead of receiving RTP/RTCP packets through 23 signalling. 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 January 17, 2013. 42 Copyright Notice 44 Copyright (c) 2012 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 62 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. RTP SSRC . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. RTCP SDES CNAME . . . . . . . . . . . . . . . . . . . . . 4 65 4.3. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. Implicit Methods . . . . . . . . . . . . . . . . . . . . . 5 67 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. SRCNAME Contents . . . . . . . . . . . . . . . . . . . . . 6 69 5.2. SRCNAME in SDES . . . . . . . . . . . . . . . . . . . . . 7 70 5.3. SRCNAME in SDP . . . . . . . . . . . . . . . . . . . . . . 7 71 5.4. SRCNAME in RTP Header Extension . . . . . . . . . . . . . 7 72 6. SRCNAME Format . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. SDES Item SRCNAME . . . . . . . . . . . . . . . . . . . . . . 8 74 8. SRCNAME in SDP . . . . . . . . . . . . . . . . . . . . . . . . 9 75 9. SRCNAME as RTP Header Extension . . . . . . . . . . . . . . . 10 76 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10.1. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.2. SVC with multi-session transmission . . . . . . . . . . . 12 79 10.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 14 80 10.4. Forward Error Correction . . . . . . . . . . . . . . . . . 15 81 11. Usage with the Offer/Answer Model . . . . . . . . . . . . . . 16 82 12. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 83 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 15.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 RTP has always been a protocol that supports multiple participants, 93 each sending their own media streams in RTP sessions. Previously, 94 many implementations have aimed only at point to point voice over IP 95 with a single source in each end-point. Even client implementations 96 aimed at video conferences have often been built with the assumption 97 around central mixers that only deliver a single media stream per 98 media type. However, more advanced client implementations may 99 transmit multiple streams in the same RTP session and there may be 100 tight relations between different streams and their SSRCs. For 101 example, a client with several cameras that uses simulcast to send 102 streams with different encodings of the video from each camera have 103 the need of conveying the relation of the streams to the receiver. A 104 similar example is a client with several cameras that uses SVC multi- 105 session transmission [RFC6190] and also here the receiver needs to 106 know which streams relate to which video source. Other examples of 107 tight RTP relations are a retransmission stream and its original 108 stream, and cases of forward error correction (FEC), where a client 109 needs to associate a number of source streams with, in general, a 110 different number of repair streams. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Problem Description 120 In a scenario where an endpoint needs to send several RTP media 121 streams, in a single RTP session or spread across several RTP 122 sessions, and where two or more of those streams are somehow related, 123 that relation information is today not always possible to convey in a 124 timely manner to entities (endpoints and middle nodes) that need it. 126 An RTP Mixer, on the other hand, must have all the SDP information 127 available and can provide it to any number of participants, since 128 there must be a mapping from the original sources to the Mixer's own 129 streams, which is in turn distributed to all other participants. 130 That is also true for a source projecting mixer, since there is a 131 projection algorithm that must be made to work. It is even likely 132 that the Mixer is allowed to provide the stream relation and impose 133 that onto all of the clients, rather than trying to map a wide 134 variety of different relations onto what it provides. 136 A single relation between two or more streams means that each stream 137 has a certain "role" in that specific relation. A "role" is related 138 to a specific reason to group a set of streams. The number of 139 different grouping tags defined in various RFC for use with the SDP 140 group attribute [RFC5888], as well as the media decoding dependency 141 attribute [RFC5583] can be used as an indication of the different 142 roles that may need to be described. 144 Those stream relational roles are typically application-specific, can 145 sometimes be complex, and a single stream can even take on several 146 roles. The major difference between roles is that they commonly do 147 not share the same hierarchy root node and sometimes also middle 148 nodes differ between roles. All roles however use the same hierarchy 149 leaves, being the RTP media streams, but different roles may want to 150 name leaves differently. It should be possible to express such 151 relation structure and allow a single stream to hold several roles. 152 It is believed to be sufficient if a single stream role can be 153 described as being part of a relation hierarchy. 155 4. Motivation 157 This section contains a brief description of existing techniques that 158 conceivably could be used to provide information on RTP stream 159 relations, and a motivation why those are not always sufficient. 161 4.1. RTP SSRC 163 To rely on using the same RTP Synchronization SouRCe (SSRC) for all 164 streams related to a particular media source is many times not 165 possible when the related streams are part of the same RTP session, 166 since the SSRC itself is the identifier to tell the streams apart. 167 This method is not robust against SSRC collision and potentially 168 forces cascading SSRC changes between sessions. It does also not 169 provide any information in how the streams are related. 171 4.2. RTCP SDES CNAME 173 CNAME is not sufficient to express the necessary type of relation, 174 although that is commonly inferred from end-points that have only one 175 media stream per media type. The primary use of CNAME in multi- 176 source usages is instead to indicate which end-point and what 177 synchronization context a particular media stream relates to, and 178 that usually means that all streams sent from a client have the same 179 CNAME. 181 4.3. SDP 183 A common solution is to use SDP attributes to convey the relation 184 between streams. Session-multiplexed streams can be associated with 185 an attribute that groups different RTP sessions [RFC5888], and SSRC- 186 multiplexed streams can be grouped at the media level for each RTP 187 session [RFC5576]. For example, Forward Error Correction Grouping 188 Semantics in the Session Description Protocol [RFC5956] uses that 189 media level grouping with the "FEC-FR" tag to group FEC associations 190 when the different streams from a source are SSRC-multiplexed in the 191 same RTP session. 193 Using SDP attributes may work fine in the case when the receivers of 194 the streams also get an SDP describing the bindings of all the 195 streams, but that is not always the case. One such example is a 196 highly dynamic conference session where a large amount of clients are 197 communicating with each other via an RTP Translator. The RTP 198 Translator forwards all RTP and RTCP traffic from a client to all 199 other clients and the clients can be prepared to receive any number 200 of streams of certain specified media. When a new client joins the 201 session, the other clients may not be notified via explicit 202 signalling before starting to receive media streams from this new 203 client. Such notification could for example be made through a SIP 204 Update with a new SDP containing an explicit list of the new streams, 205 but there are also other possibilities. The clients will instead 206 detect the new client's streams directly via RTP and RTCP. Similar 207 situations typically arise in multicast scenarios. In those cases, 208 there is no way for a client or middle node to identify if and how 209 certain streams are related to each other, since that information was 210 only included in the SDP, if at all. 212 4.4. Implicit Methods 214 RTP Retransmission Payload Format [RFC4588] describes a solution for 215 finding the association between original streams and retransmission 216 streams when SSRC-multiplexing is used. The association can be 217 resolved when the receiver receives a retransmission packet matching 218 a retransmission request sent earlier. However, the RFC continues 219 with describing that this mechanism might fail if there are two 220 outstanding requests for the same packet sequence number in two 221 different original streams of a session. Therefore, to avoid 222 ambiguity in unicast a receiver MUST NOT have two outstanding 223 requests for the same packet sequence number in two different 224 original streams before the association is resolved. For multicast, 225 however, this ambiguity cannot be avoided and SSRC-multiplexing of 226 original and retransmission streams is therefore prohibited in 227 multicast. By defining a solution for one to one mapping between an 228 original stream and any supporting streams, this issue can be avoided 229 in the future. 231 Note: This document does not update RFC 4588 to use this solution, 232 but it may be done in the future. 234 5. Proposed Solution 236 To enable an RTP session participant to determine the close relation 237 of different streams without the above mentioned problems, a new 238 method for identifying such sources is needed. This identification 239 is called Source Name, or SRCNAME and is a unique identifier 240 identifying a single media source, like a camera, a microphone, a 241 particular media mix, or conceptual stream. 243 5.1. SRCNAME Contents 245 The basic idea is that streams with matching SRCNAME are related, 246 similar to the idea with RTCP SDES CNAME. 248 It is assumed that related streams will share the same 249 synchronization context, meaning that the SRCNAME is scoped by CNAME 250 and need not duplicate any CNAME information. 252 The SRCNAME format includes "." (%x2E) as a hierarchy separator, 253 allowing a stream to relate to another stream at a certain hierarchy 254 level. Each hierarchy level is then a node in a hierarchy tree. For 255 example, assume a video stream being provided in two different 256 resolutions, "lowres" and "hires", each being protected by a Forward 257 Error Correction stream, with another additive FEC stream covering 258 both resolutions. The low resolution video could have a SRCNAME 259 being "program1.video.lowres", and its FEC stream 260 "program1.video.lowres.fec". The SRCNAME for the additive FEC 261 stream, covering both resolutions and their per-stream FEC, could be 262 "program1.video.fec". Building on the same example, the high 263 fidelity audio stream belonging to the above video could be 264 "program1.audio.hifi". 266 Note that the hierarchy structure can be chosen entirely by the media 267 sender, but it is anyway possible to decide stream relations, at what 268 level the streams relate, and which other streams that are included 269 in the relation at that level by matching SRCNAME hierarchically 270 left-to-right between "." hierarchy separators. The specific type of 271 relation is not encoded into SRCNAME in any mandated way, but need to 272 be stringently described by other means, for example SDP, and is out 273 of scope for this specification. SRCNAME needs only express that 274 streams are related, not exactly how the related streams should be 275 processed together. 277 Note that SRCNAME need not be particularly human-readable as long as 278 each node in the hierarchy has a tag that is unique for that CNAME 279 context, which makes it possible to limit the SRCNAME size. 281 5.2. SRCNAME in SDES 283 RTP [RFC3550] defines the Source Description RTCP Packet (SDES), 284 which contains one or more chunks, each of which is composed of SDES 285 items describing the SSRC identified in that chunk. None of the 286 present SDES items is, however, suitable for uniquely identifying a 287 media source. 289 Therefore, we propose to define a new SDES item called the SRCNAME, 290 which uses a unique label to identify a single media source, like a 291 camera or a microphone. The source may also be a particular media 292 mix or conceptual stream, such as the "most active speaker" output by 293 a RTP mixer performing stream switching. That way, anyone receiving 294 the SDES information from a set of interlinked RTP sessions or 295 multiple SSRCs in the same session can determine which SSRCs are the 296 same source. Connecting streams with SRCNAME can be done 297 irrespective of which multiplexing type is used and it solves the 298 problems with the current solutions described above. 300 5.3. SRCNAME in SDP 302 It is, however, possible that a receiver will receive the RTP streams 303 before receiving SDES packets with all SRCNAME items and that would 304 mean that the receiver cannot make the connections between SSRCs and 305 SRCNAMEs when starting to receive the media. "Source-Specific Media 306 Attributes in the Session Description Protocol (SDP)" [RFC5576] 307 defines a way of declaring different attributes for SSRCs in each 308 session in SDP, and if a new source attribute is added to this 309 framework, it would be suitable for conveying the connections between 310 SSRCs and SRCNAMEs before the media communication starts. Thus, in 311 addition to the new SDES item we also define a new SDP source- 312 specific media attribute called srcname, which enables an end-point 313 to declare and learn the source bindings ahead of receiving RTP/RTCP 314 packets. Of course, this new SDP source attribute will not be useful 315 for the case described above when clients did not get updates with 316 new client's stream bindings, but it will be useful in most other 317 cases. 319 5.4. SRCNAME in RTP Header Extension 321 There is a risk that neither RTCP SDES nor SDP attributes are timely 322 enough in cases where RTP streams are received before the SDES has 323 arrived, in which case an RTP header extension [RFC5285] could be 324 used, containing a combination of CNAME and SRCNAME information. 326 This type of rapid information synchronization through RTP header 327 extension is similar to what is described in [RFC6051]. The RTP 328 header extension need not be present in every RTP packet, for example 329 only in the beginning of the stream, at key points, or periodically, 330 according to the application's needs and as chosen by the media 331 sender. 333 6. SRCNAME Format 335 The SRCNAME MUST fulfill the requirements Section 6.5 in RTP 336 [RFC3550] puts on SDES item values in general. These requirements is 337 that it is a UTF-8 [RFC3629] string that have a maximum length of 255 338 bytes. 340 In addition, there are format restrictions to accommodate the 341 relation hierarchy and multiple roles, as described by the following 342 ABNF [RFC5234]: 344 srcname-node = 1*(%x01-09 / %x0B-0C / %x0E-2D / %x2F-FF) 345 ; Same as RFC 4566 "byte-string" 346 ; except for the hierarchy separator 348 srcname-content = srcname-node *(%x2E srcname-node) 350 Figure 1: SRCNAME Format ABNF 352 It is RECOMMENDED to use per communication session unique random 353 identifiers, applying srcname-node restrictions, as srcname-node. 354 The length of such srcname-node identifiers MAY be limited down to a 355 single character, especially when the resulting SRCNAME has several 356 nodes. 358 7. SDES Item SRCNAME 360 Source Descriptions are a method that should work with all RTP 361 topologies (assuming that any intermediary node is supporting this 362 item) and existing RTP extensions. We propose to define a new SDES 363 item called SRCNAME. That way, anyone receiving the SDES information 364 from a set of interlinked RTP sessions or SSRCs in a single session 365 can determine which SSRCs are related to the same source. 367 This SRCNAME's relation to CNAME is the following. CNAME represents 368 an end-point and a synchronization context. If the different sources 369 identified by SRCNAMEs should be played out synchronized when 370 receiving them in a multi-stream context, then the sources need to be 371 in the same synchronization context. Thus in all cases, all SSRCs 372 with the same SRCNAME will have the same CNAME. A given CNAME may 373 contain multiple sets of sources using different SRCNAMEs. 375 The SDES SRCNAME item follows the same format as the other SDES items 376 defined in RTP [RFC3550]: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | SRCNAME=TBA1 | length | source name ... 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 2: SDES SRCNAME Format 386 The source name field MUST follow the above srcname-content 387 definition. Multiple SDES SRCNAME describing different relation 388 roles MAY be included. 390 When using the SRCNAME SDES item, it is equally important as CNAME. 391 Thus SRCNAME is RECOMMENDED to be included in all full compound RTCP 392 packets being sent. It MAY also be included in non-compound packets 393 in cases where the implementation believes that there might be new 394 receivers needing the information. 396 8. SRCNAME in SDP 398 "Source-Specific Media Attributes in the Session Description Protocol 399 (SDP)" [RFC5576] defines a way of declaring attributes for SSRC in 400 each session in SDP. With a new SDES item, it is possible to use 401 this framework to define how SRCNAME can also be provided in the SDP 402 for each SSRC in each RTP session, thus enabling an end-point to 403 declare and learn the source bindings ahead of receiving RTP/RTCP 404 packets. 406 Hence, we propose a new SDP source attribute called srcname with the 407 following structure: 409 a=ssrc: srcname: 411 The srcname value MUST be identical to the SRCNAME value the media 412 sender will send in the SDES SRCNAME item in the SDES RTCP packets. 413 Multiple srcname attributes MAY be used to describe multiple relation 414 roles. 416 FormalABNF syntax [RFC5234] for the "srcname" attribute: 418 srcname-attr = "srcname:" srcname 420 srcname = srcname-content 422 attribute =/ srcname-attr 423 ; The definition of "attribute" is in RFC 4566. 425 Figure 3: SRCNAME Attribute ABNF 427 9. SRCNAME as RTP Header Extension 429 The RTP Header Extension [RFC5285] MUST contain both CNAME and 430 SRCNAME information, since SRCNAME is scoped by CNAME. 432 Editor's note: To be amended with more explicit information. 434 10. Examples 436 This section shows SDP examples of declaring the SRCNAME in SDP. 438 10.1. Simulcast 440 In this use case the end-point is a client with a single audio source 441 and two video sources, and it uses simulcast for sending different 442 encodings of the same video source. This example is based on Using 443 Simulcast in RTP sessions [I-D.westerlund-avtcore-rtp-simulcast]. 444 The following SDP describes this. 446 v=0 447 o=alice 3203093520 3203093520 IN IP4 foo.example.com 448 s=Simulcast enabled client 449 t=0 0 450 c=IN IP4 foo.example.com 451 m=audio 49200 RTP/AVP 96 452 a=rtpmap:96 G719/48000/2 453 a=ssrc:521923924 cname:alice@foo.example.com 454 a=ssrc:521923924 srcname:a1 455 a=mid:1 456 m=video 49300 RTP/AVP 96 457 a=rtpmap:96 H264/90000 458 a=fmtp:96 profile-level-id=42c01e 459 a=imageattr:96 send [x=640,y=360] recv [x=640,y=360] [x=320,y=180] 460 a=ssrc:192392452 cname:alice@foo.example.com 461 a=ssrc:192392452 srcname:v1 462 a=ssrc:834753488 cname:alice@foo.example.com 463 a=ssrc:834753488 srcname:v2 464 a=mid:2 465 a=content:main 466 m=video 49400 RTP/AVP 97 467 a=rtpmap:97 H264/90000 468 a=fmtp:97 profile-level-id=42c00d 469 a=imageattr:97 send [x=320,y=180] 470 a=ssrc:239245219 cname:alice@foo.example.com 471 a=ssrc:239245219 srcname:v1 472 a=ssrc:734623563 cname:alice@foo.example.com 473 a=ssrc:734623563 srcname:v2 474 a=mid:3 475 a=sendonly 477 The audio session is proposing to use one stereo stream of G.719 and 478 the video sessions are proposing to send two different encodings of 479 each video source, one with the resolution 640x360 and one with 480 320x180. The end-point also declares the SSRCs it intends to use 481 with bindings to CNAME and SRCNAME, enabling the receiver of the SDP 482 to bind together the video streams that originate from the same video 483 camera. For example, the two streams having an SRCNAME of "v1" 484 originate from the same video camera and belong together. 486 The use of the srcname attribute in the SDP is optional and the 487 information can be retrieved from RTCP reporting, but it will then 488 not be possible to correctly relate the video sources until the first 489 RTCP report is received. 491 10.2. SVC with multi-session transmission 493 Here an example is shown of a client that uses SVC with multi-session 494 transmission as described in RTP Payload Format for Scalable Video 495 Coding [RFC6190]. RTP Payload Format for Scalable Video Coding 496 [RFC6190] only describes examples for a client with one video source 497 and the decoder dependencies of the different sessions are grouped 498 using the Session grouping DDP attribute as defined in Signaling 499 Media Decoding Dependency in the Session Description Protocol (SDP) 500 [RFC5583] and implicitly CNAME. 502 However, if a client has two video sources and wishes to use multi- 503 session transmission and send streams from both sources in each 504 session, an additional grouping mechanism is needed to group the 505 different streams in the different sessions. SRCNAME is suitable for 506 this and here we show an example where the DDP attribute groups the 507 different sessions and the SRCNAME is used to relate the different 508 SSRCs in each RTP session to one of the two video sources. 510 v=0 511 o=bob 8473948250 8473948250 IN IP4 foo.example.com 512 s=SVC MST client 513 t=0 0 514 c=IN IP4 foo.example.com 515 a=group:DDP L1 L2 L3 516 m=audio 49500 RTP/AVP 96 517 a=rtpmap:96 G719/48000/2 518 a=ssrc:293848928 cname:bob@foo.example.com 519 a=mid:A1 520 m=video 20000 RTP/AVP 96 521 a=rtpmap:96 H264/90000 522 a=fmtp:96 profile-level-id=4de00a; packetization-mode=1; 523 mst-mode=NI-TC; sprop-parameter-sets={sps0},{pps0}; 524 a=ssrc:743947584 cname:bob@foo.example.com 525 a=ssrc:743947584 srcname:V1.L1 526 a=ssrc:283894947 cname:bob@foo.example.com 527 a=ssrc:283894947 srcname:V2.L1 528 a=mid:L1 529 m=video 20002 RTP/AVP 97 530 a=rtpmap:97 H264-SVC/90000 531 a=fmtp:97 profile-level-id=53000c; packetization-mode=1; 532 mst-mode=NI-T; sprop-parameter-sets={sps1},{pps1}; 533 a=ssrc:492784823 cname:bob@foo.example.com 534 a=ssrc:492784823 srcname:V1.L2 535 a=ssrc:892362397 cname:bob@foo.example.com 536 a=ssrc:892362397 srcname:V2.L2 537 a=mid:L2 538 a=depend:97 lay L1:96 539 m=video 20004 RTP/AVP 98 540 a=rtpmap:98 H264-SVC/90000 541 a=fmtp:98 profile-level-id=53001F; packetization-mode=1; 542 mst-mode=NI-T; sprop-parameter-sets={sps2},{pps2}; 543 a=ssrc:184562894 cname:bob@foo.example.com 544 a=ssrc:184562894 srcname:V1.L3 545 a=ssrc:305605682 cname:bob@foo.example.com 546 a=ssrc:305605682 srcname:V2.L3 547 a=mid:L3 548 a=depend:98 lay L1:96 L2:97 550 Thus, the client declares that it will send two video streams in each 551 RTP session and the receiver is then able to relate the streams in 552 the different sessions by using the SRCNAME binding, with matching 553 (first parts of the) SRCNAME value. Without the SRCNAME binding it 554 would not be possible for the receiver to know which streams belong 555 to the same source. Note that the audio stream does not have an 556 explicit srcname attribute in this example, but only relate to the 557 video streams through the same CNAME. Note that the last part of the 558 SRCNAMEs in the example, ".L1", ".L2" and ".L3" are not necessary but 559 allowed and will not impact the ability to tell that the streams 560 belong together, since related streams have the first part in common. 562 10.3. Retransmission 564 This use case shows how SRCNAME can be used to connect retransmission 565 streams to the original streams in the case of SSRC multiplexed RTP 566 retransmission [RFC4588]. This is included to exemplify how RTP 567 retransmission could be updated to provide explicit bindings between 568 the source and the repair stream, but just an example and not a 569 specification. 571 v=0 572 o=carol 3462534872 3462534872 IN IP4 foo.example.com 573 s=SSRC-multiplexed retransmission client 574 t=0 0 575 c=IN IP4 foo.example.com 576 m=audio 49800 RTP/AVP 96 577 a=rtpmap:96 G719/48000/2 578 a=ssrc:8372496978 cname:carol@foo.example.com 579 a=mid:1 580 m=video 49300 RTP/AVP 96 97 581 a=rtpmap:96 H264/90000 582 a=rtcp-fb:96 nack 583 a=fmtp:96 profile-level-id=42c01e 584 a=rtpmap:97 rtx/90000 585 a=fmtp:97 apt=96;rtx-time=200 586 a=ssrc:192392452 cname:carol@foo.example.com 587 a=ssrc:192392452 srcname:v1.o 588 a=ssrc:834753488 cname:carol@foo.example.com 589 a=ssrc:834753488 srcname:v1.r 590 a=ssrc:682394013 cname:carol@foo.example.com 591 a=ssrc:682394013 srcname:v2.o 592 a=ssrc:284576129 cname:carol@foo.example.com 593 a=ssrc:284576129 srcname:v2.r 594 a=mid:2 596 The client proposes to send two original video streams in the video 597 session and a retransmission stream for each one of them. The 598 retransmission streams are associated with the respective original 599 stream by using matching SRCNAME and a receiver would then know which 600 original stream a certain retransmission stream is associated with. 601 This solves the ambiguity problem when SSRC-multiplexing is used for 602 retransmission and it enables SSRC-multiplexing of original and 603 retransmission streams to be used also in multicast sessions. Note 604 that ".o" and ".r" parts of SRCNAME are not needed, but may improve 605 understanding of the example and will not affect the ability to match 606 related streams. 608 10.4. Forward Error Correction 610 Forward Error Correction Grouping Semantics in the Session 611 Description Protocol [RFC5956] defines two SDP attributes for 612 grouping the associated source and FEC-based repair streams. One can 613 be used for grouping different RTP sessions and the other can be used 614 for grouping SSRCs in the same RTP session, i.e. when session- 615 respective SSRC-multiplexing is used. However, it may be 616 advantageous to SSRC-multiplex the source streams in one RTP session 617 and the repair streams in another since that gives a receiver the 618 possibility to reject the repair session in case it does not support 619 the proposed FEC. In this case, the above mentioned grouping 620 attributes cannot be used to associate the repair streams with the 621 respective source stream since grouping of SSRCs cannot be made 622 across RTP sessions. The following example shows how SRCNAME can be 623 used for that. 625 v=0 626 o=dave 7352395826 7352395826 IN IP4 foo.example.com 627 s=FEC client 628 t=0 0 629 c=IN IP4 foo.example.com 630 a=group:FEC-FR 2 3 631 m=audio 49300 RTP/AVP 96 632 a=rtpmap:96 G719/48000/2 633 a=ssrc:237847298 cname:dave@foo.example.com 634 a=mid:1 635 m=video 49200 RTP/AVP 100 636 a=rtpmap:100 MP2T/90000 637 a=ssrc:847612849 cname:dave@foo.example.com 638 a=ssrc:847612849 srcname:v1.o 639 a=ssrc:558237845 cname:dave@foo.example.com 640 a=ssrc:558237845 srcname:v2.o 641 a=mid:2 642 m=application 49300 RTP/AVP 101 643 a=rtpmap:101 1d-interleaved-parityfec/90000 644 a=fmtp:101 L=5; D=10; repair-window=200000 645 a=ssrc:389572053 cname:dave@foo.example.com 646 a=ssrc:389572053 srcname:v1.r 647 a=ssrc:185729479 cname:dave@foo.example.com 648 a=ssrc:185729479 srcname:v2.r 649 a=mid:3 651 In this example the client proposes to send two video streams in one 652 session and two repair streams in the other session. The repair 653 streams are associated with the respective video stream by using a 654 matching SRCNAME. When receiving either this SDP or the SDES SRCNAME 655 packets, a receiver can make the connection between the source 656 streams and the repair streams. Even a client not receiving the SDP 657 will be able to do the association, if it has established one RTP 658 session for receiving source streams and another for receiving repair 659 streams. Note that ".o" and ".r" parts of SRCNAME are not needed, 660 but may improve understanding of the example and will not affect the 661 ability to match related streams. 663 11. Usage with the Offer/Answer Model 665 The SDP offer/answer procedures for the a=ssrc is specified in 666 Source-Specific Media Attributes in the Session Description Protocol 667 (SDP) [RFC5576]. 669 12. Backward Compatibility 671 Clients not supporting SRCNAME will not have the possibility to bind 672 different streams to a specific media source, since they will not 673 understand the SRCNAME SDES item. However, sending SRCNAME SDES 674 items to a client not supporting it should not impose any problems 675 since all clients should be prepared that new SDES items may be 676 specified according to RTP [RFC3550]. 678 According to the definition of SDP attributes in SDP: Session 679 Description Protocol [RFC4566], if an attribute is received that is 680 not understood, it MUST be ignored by the receiver. So a receiver 681 not supporting the ssrc attribute will simply ignore it. 683 Source-Specific Media Attributes in the Session Description Protocol 684 (SDP) [RFC5576] defines rules of how new source attributes should be 685 registered, which means that a receiver supporting RFC 5576 should be 686 prepared that new source attributes may be defined. This means that 687 a user supporting some of the source attributes should not have any 688 problems when the user receives an SDP with unknown source 689 attributes. 691 13. IANA Considerations 693 Following the guidelines in SDP [RFC4566], in The Session Description 694 Protocol (SDP) Grouping Framework [RFC5888], and in RTP [RFC3550], 695 the IANA is requested to register: 697 1. A new SDES item named SRCNAME, as defined in Section 7. This 698 item needs to be assigned an identifier TBA1. 700 2. A new SDP source attribute named srcname, as defined in 701 Section 8. 703 14. Security Considerations 705 The SDES SRCNAMEs being close to opaque identifiers could potentially 706 carry additional meanings or function as overt channel. If the 707 SRCNAME would be permanent between sessions, they have the potential 708 for compromising the users' privacy as they can be tracked between 709 sessions. See Guidelines for Choosing RTP Control Protocol (RTCP) 710 Canonical Names (CNAMEs) [RFC6222] for more discussion. 712 A third party modification of the srcname labels either in the RTCP 713 SDES items or in the SDP a=ssrc attribute can cause service 714 disruption. By modifying labels the wrong streams could be 715 associated, with potentially serious effects including media 716 disruptions. If streams that are to be associated aren't associated, 717 then another type of failures occur. To prevent modification, 718 insertion or deletion of the srcname labels, the carrying channel 719 needs to be protected by integrity protection and source 720 authentication. For RTCP various solutions exist, such as SRTP 721 [RFC3711], DTLS [RFC6347], or IPsec [RFC4301]. For protecting the 722 SDP, the signalling channel needs to provide protection. For SIP 723 S/MIME [RFC3261] are the ideal, and hop by hopTLS [RFC5246] provides 724 at least some protection, although not perfect. For SDPs retrieved 725 using RTSP DESCRIBE [RFC2326], TLS would be the RECOMMENDED solution. 727 15. References 729 15.1. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 735 Jacobson, "RTP: A Transport Protocol for Real-Time 736 Applications", STD 64, RFC 3550, July 2003. 738 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 739 10646", STD 63, RFC 3629, November 2003. 741 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 742 Specifications: ABNF", STD 68, RFC 5234, January 2008. 744 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 745 Media Attributes in the Session Description Protocol 746 (SDP)", RFC 5576, June 2009. 748 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 749 Choosing RTP Control Protocol (RTCP) Canonical Names 750 (CNAMEs)", RFC 6222, April 2011. 752 15.2. Informative References 754 [I-D.westerlund-avtcore-rtp-simulcast] 755 Westerlund, M., Burman, B., Lindqvist, M., and F. Jansson, 756 "Using Simulcast in RTP sessions", 757 draft-westerlund-avtcore-rtp-simulcast (work in progress), 758 October 2011. 760 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 761 Streaming Protocol (RTSP)", RFC 2326, April 1998. 763 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 764 A., Peterson, J., Sparks, R., Handley, M., and E. 765 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 766 June 2002. 768 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 769 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 770 RFC 3711, March 2004. 772 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 773 Internet Protocol", RFC 4301, December 2005. 775 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 776 Description Protocol", RFC 4566, July 2006. 778 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 779 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 780 July 2006. 782 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 783 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 785 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 786 Header Extensions", RFC 5285, July 2008. 788 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 789 Dependency in the Session Description Protocol (SDP)", 790 RFC 5583, July 2009. 792 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 793 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 795 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 796 the Session Description Protocol", RFC 5956, 797 September 2010. 799 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 800 Flows", RFC 6051, November 2010. 802 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 803 "RTP Payload Format for Scalable Video Coding", RFC 6190, 804 May 2011. 806 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 807 Security Version 1.2", RFC 6347, January 2012. 809 Authors' Addresses 811 Magnus Westerlund 812 Ericsson 813 Farogatan 6 814 SE-164 80 Kista 815 Sweden 817 Phone: +46 10 714 82 87 818 Email: magnus.westerlund@ericsson.com 820 Bo Burman 821 Ericsson 822 Farogatan 6 823 SE-164 80 Kista 824 Sweden 826 Phone: +46 10 714 13 11 827 Email: bo.burman@ericsson.com 828 Patrik Sandgren 829 Ericsson 830 Farogatan 6 831 SE-164 80 Kista 832 Sweden 834 Phone: +46 10 717 97 41 835 Email: patrik.sandgren@ericsson.com