idnits 2.17.1 draft-westerlund-avtext-rtcp-sdes-srcname-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 (October 22, 2012) is 4203 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) == Outdated reference: A later version (-06) exists of draft-ietf-avtext-rtp-duplication-00 == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-duplication-grouping-00 -- 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 5117 (Obsoleted by RFC 7667) -- 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 (~~), 3 warnings (==), 7 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: April 25, 2013 Ericsson 6 October 22, 2012 8 RTCP SDES Item SRCNAME to Label Individual Sources 9 draft-westerlund-avtext-rtcp-sdes-srcname-02 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 logically 17 related to the same source. It can equally be used to label SSRC 18 multiplexed related streams, such as FEC or Retransmission streams 19 related to the original source stream in the same session. In 20 addition the new SDES item is also defined for usage with the SDP 21 source specific media attribute ("a=ssrc"), enabling an end-point to 22 declare and learn the source bindings through signalling ahead of 23 receiving RTP/RTCP packets. 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 April 25, 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 . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.2. SVC with multi-session transmission . . . . . . . . . . . 13 79 10.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 15 80 10.4. Forward Error Correction . . . . . . . . . . . . . . . . . 16 81 11. Usage with the Offer/Answer Model . . . . . . . . . . . . . . 17 82 12. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 17 83 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 15.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 15.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 RTP [RFC3550] has always been a protocol that supports multiple 93 participants, each sending their own media streams in RTP sessions. 94 Previously, many implementations have aimed only at point to point 95 voice over IP with a single source in each end-point. Even client 96 implementations aimed at video conferences have often been built with 97 the assumption around central mixers that only deliver a single media 98 stream per media type. However, more advanced client implementations 99 may transmit multiple streams in the same RTP session and there may 100 be 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 [RFC5117], on the other hand, must have all the SDP 127 information available and can provide it to any number of 128 participants, since there must be a mapping from the original sources 129 to the Mixer's own streams, which are in turn distributed to all 130 other participants. That is also true for a source projecting mixer, 131 since there is a projection algorithm that must be made to work. It 132 is even likely that the Mixer is allowed to provide the stream 133 relation and impose that onto all of the clients, rather than trying 134 to map a wide 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. In 160 addition, there are defined milestones for RTP stream duplication 161 [I-D.ietf-avtext-rtp-duplication] in IETF AVTEXT and stream 162 duplication grouping [I-D.ietf-mmusic-duplication-grouping] in MMUSIC 163 WG that makes normative references to this document. 165 4.1. RTP SSRC 167 To rely on using the same RTP Synchronization SouRCe (SSRC) for all 168 streams related to a particular media source is many times not 169 possible when the related streams are part of the same RTP session, 170 since the SSRC itself is the identifier to tell the streams apart. 171 This method is not robust against SSRC collision and potentially 172 forces cascading SSRC changes between sessions. It does also not 173 provide any information in how the streams are related. 175 4.2. RTCP SDES CNAME 177 CNAME is not sufficient to express the necessary type of relation, 178 although that is commonly inferred from end-points that have only one 179 media stream per media type. The primary use of CNAME in multi- 180 source usages is instead to indicate which end-point and what 181 synchronization context a particular media stream relates to, and 182 that usually means that all streams sent from a client have the same 183 CNAME. 185 4.3. SDP 187 A common solution is to use SDP [RFC4566] attributes to convey the 188 relation between streams. Session-multiplexed streams can be 189 associated with an attribute that groups different SDP m-lines 190 [RFC5888], and SSRC-multiplexed streams can be grouped at the media 191 level for each SDP m-line [RFC5576]. For example, Forward Error 192 Correction Grouping Semantics in the Session Description Protocol 193 [RFC5956] uses that media level grouping with the "FEC-FR" tag to 194 group FEC associations when the different streams from a source are 195 SSRC-multiplexed in the same RTP session. 197 Using SDP attributes may work fine in the case when the receivers of 198 the streams also get an SDP describing the bindings of all the 199 streams, but that is not always the case. One such example is a 200 highly dynamic conference session where a large amount of clients are 201 communicating with each other via an RTP Translator [RFC5117]. The 202 RTP Translator forwards all RTP and RTCP traffic from a client to all 203 other clients and the clients can be prepared to receive any number 204 of streams of certain specified media. When a new client joins the 205 session, the other clients may not be notified via explicit 206 signalling before starting to receive media streams from this new 207 client. Such notification could for example be made through a SIP 208 Update with a new SDP containing an explicit list of the new streams, 209 but there are also other possibilities. The clients will instead 210 detect the new client's streams directly via RTP and RTCP. Similar 211 situations typically arise in multicast scenarios. In those cases, 212 there is no way for a client or middle node to identify if and how 213 certain streams are related to each other, since that information was 214 only included in the SDP, if at all. 216 4.4. Implicit Methods 218 RTP Retransmission Payload Format [RFC4588] describes a solution for 219 finding the association between original streams and retransmission 220 streams when SSRC-multiplexing is used. The association can be 221 resolved when the receiver receives a retransmission packet matching 222 a retransmission request sent earlier. However, the RFC states that 223 this mechanism might fail if there are two outstanding requests for 224 the same packet sequence number in two different original streams of 225 a session. Therefore, to avoid ambiguity in unicast a receiver MUST 226 NOT have two outstanding requests for the same packet sequence number 227 in two different original streams before the association is resolved. 228 For multicast, however, this ambiguity cannot be avoided and SSRC- 229 multiplexing of original and retransmission streams is therefore 230 prohibited in multicast. By defining a solution for one to one 231 mapping between an original stream and any supporting streams, this 232 issue can be avoided in the future. 234 Note: This document does not update RFC 4588 to use the proposed 235 solution, but it may be done in the future. 237 5. Proposed Solution 239 To enable an RTP session participant to determine the close relation 240 of different streams without the above mentioned problems, a new 241 method for identifying such sources is needed. This identification 242 is called Source Name, or SRCNAME and is a unique identifier 243 identifying a single media source, like a camera, a microphone, a 244 particular media mix, or conceptual stream. 246 5.1. SRCNAME Contents 248 The basic idea is that streams with matching SRCNAME are related, 249 similar to the idea with RTCP SDES CNAME. 251 It is assumed that related streams will share the same 252 synchronization context, meaning that the SRCNAME is scoped by CNAME 253 and need not duplicate any CNAME information. 255 The SRCNAME format includes "." (%x2E) as a hierarchy separator, 256 allowing a stream to relate to another stream at a certain hierarchy 257 level. Each hierarchy level is then a node in a hierarchy tree. For 258 example, assume a video stream being provided in two different 259 resolutions, named "lowres" and "hires", each being protected by a 260 Forward Error Correction stream, with another additive FEC stream 261 covering both resolutions. The low resolution video media stream 262 could have a SRCNAME being "program1.video.lowres.media", and its FEC 263 stream "program1.video.lowres.fec". By this, and although it is not 264 a stream in itself, it is possible to use "program1.video.lowres" to 265 refer to the set of related streams (in this case media and FEC) 266 belonging to "lowres". If needed, it is still possible to refer to 267 the individual, physical, streams by using one more level of the 268 hierarchy (".media" and ".fec"). The SRCNAME for the additive FEC 269 stream, covering both resolutions and their per-stream FEC, could be 270 "program1.video.fec". Building on the same example, an high fidelity 271 audio stream belonging to the above video could use an SRCNAME of 272 "program1.audio.hifi". 274 Note that the hierarchy structure can be chosen entirely by the media 275 sender, but it is anyway possible to decide stream relations, at what 276 level the streams relate, and which other streams that are included 277 in the relation at that level by matching SRCNAME hierarchically 278 left-to-right between "." hierarchy separators. The specific type of 279 relation is not encoded into SRCNAME in any mandated way, but need to 280 be stringently described by other means, for example SDP, and is out 281 of scope for this specification. SRCNAME needs only express that 282 streams are related, not exactly how the related streams should be 283 processed together. 285 Note that SRCNAME need not be particularly human-readable as long as 286 each node in the hierarchy has a tag that is unique for that CNAME 287 context, which makes it possible to limit the SRCNAME size. 289 5.2. SRCNAME in SDES 291 RTP [RFC3550] defines the Source Description RTCP Packet (SDES), 292 which contains one or more chunks, each of which is composed of SDES 293 items describing the SSRC identified in that chunk. None of the 294 present SDES items is, however, suitable for uniquely identifying a 295 media source. 297 Therefore, we propose to define a new SDES item called the SRCNAME, 298 which uses a unique label to identify a single media source, like a 299 camera or a microphone. The source may also be a particular media 300 mix or conceptual stream, such as the "most active speaker" output by 301 a RTP mixer performing stream switching. That way, anyone receiving 302 the SDES information from a set of interlinked RTP sessions or 303 multiple SSRCs in the same session can determine which SSRCs are the 304 same source. Connecting streams with SRCNAME can be done 305 irrespective of which multiplexing type is used and it solves the 306 problems with the current solutions described above. 308 5.3. SRCNAME in SDP 310 It is, however, possible that a receiver will receive the RTP streams 311 before receiving SDES packets with all SRCNAME items and that would 312 mean that the receiver cannot make the connections between SSRCs and 313 SRCNAMEs when starting to receive the media. "Source-Specific Media 314 Attributes in the Session Description Protocol (SDP)" [RFC5576] 315 defines a way of declaring different attributes for SSRCs in each 316 session in SDP, and if a new source attribute is added to this 317 framework, it would be suitable for conveying the connections between 318 SSRCs and SRCNAMEs before the media communication starts. Thus, in 319 addition to the new SDES item we also define a new SDP source- 320 specific media attribute called "srcname", which enables an end-point 321 to declare and learn the source bindings ahead of receiving RTP/RTCP 322 packets. Of course, this new SDP source attribute will not be useful 323 for the case described above when clients did not get updates with 324 new client's stream bindings, but it will be useful in most other 325 cases. 327 5.4. SRCNAME in RTP Header Extension 329 There is a risk that neither RTCP SDES nor SDP attributes are timely 330 enough in cases where RTP streams are received before the SDES has 331 arrived, in which case an RTP header extension [RFC5285] could be 332 negotiated for use, containing a combination of CNAME and SRCNAME 333 information. This type of rapid information synchronization through 334 RTP header extension is similar to what is described in [RFC6051]. 335 The RTP header extension need not be present in every RTP packet, for 336 example only in the beginning of the stream, at key points, or 337 periodically, according to the application's needs and as chosen by 338 the media sender. 340 6. SRCNAME Format 342 The SRCNAME MUST fulfill the requirements Section 6.5 in RTP 343 [RFC3550] puts on SDES item values in general. These requirements is 344 that it is a UTF-8 [RFC3629] string that have a maximum length of 255 345 bytes. 347 In addition, there are format restrictions to accommodate the 348 relation hierarchy and multiple roles, as described by the following 349 ABNF [RFC5234]: 351 srcname-node = 1*(%x01-09 / %x0B-0C / %x0E-2D / %x2F-FF) 352 ; Same as RFC 4566 "byte-string" 353 ; except for the hierarchy separator 355 srcname-content = srcname-node *(%x2E srcname-node) 357 Figure 1: SRCNAME Format ABNF 359 It is RECOMMENDED to use per communication session unique random 360 identifiers, applying srcname-node restrictions, as srcname-node. 361 The length of such srcname-node identifiers MAY be limited down to a 362 single character, especially when the resulting SRCNAME has several 363 nodes. 365 7. SDES Item SRCNAME 367 Source Descriptions are a method that should work with all RTP 368 topologies (assuming that any intermediary node is supporting this 369 item) and existing RTP extensions. We propose to define a new SDES 370 item called SRCNAME. That way, anyone receiving the SDES information 371 from a set of interlinked RTP sessions or SSRCs in a single session 372 can determine which SSRCs are related to the same source, and at what 373 hierarchy level. 375 This SRCNAME's relation to CNAME is the following. CNAME represents 376 an end-point and a synchronization context. If the different sources 377 identified by SRCNAMEs should be played out synchronized when 378 receiving them in a multi-stream context, then the sources need to be 379 in the same synchronization context. Thus in all cases, all SSRCs 380 with the same SRCNAME will have the same CNAME. A given CNAME may 381 contain multiple sets of sources using different SRCNAMEs. 383 The SDES SRCNAME item follows the same format as the other SDES items 384 defined in RTP [RFC3550]: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | SRCNAME=TBA1 | length | source name ... 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 2: SDES SRCNAME Format 394 The source name field MUST follow the above srcname-content 395 definition. Multiple SDES SRCNAME describing different relation 396 roles MAY be included. 398 When using the SRCNAME SDES item, it is equally important as CNAME. 399 Thus SRCNAME is RECOMMENDED to be included in all full compound RTCP 400 packets being sent. It MAY also be included in non-compound packets 401 in cases where the implementation believes that there might be new 402 receivers needing the information. 404 8. SRCNAME in SDP 406 "Source-Specific Media Attributes in the Session Description Protocol 407 (SDP)" [RFC5576] defines a way of declaring attributes for SSRC in 408 each session in SDP. With a new SDES item, it is possible to use 409 this framework to define how SRCNAME can also be provided in the SDP 410 for each SSRC in each RTP session, thus enabling an end-point to 411 declare and learn the source bindings ahead of receiving RTP/RTCP 412 packets. 414 Hence, we propose a new SDP source attribute called srcname with the 415 following structure: 417 a=ssrc: srcname: 418 The srcname value MUST be identical to the SRCNAME value the media 419 sender will send in the SDES SRCNAME item in the SDES RTCP packets. 420 Multiple srcname attributes MAY be used to describe multiple relation 421 roles. 423 FormalABNF syntax [RFC5234] for the "srcname" attribute: 425 srcname-attr = "srcname:" srcname 427 srcname = srcname-content 429 attribute =/ srcname-attr 430 ; The definition of "attribute" is in RFC 4566. 432 Figure 3: SRCNAME Attribute ABNF 434 When used in SDP, srcname-content MUST use ISO 10646 in UTF-8 435 encoding, and MUST be independent of any "a=charset". 437 9. SRCNAME as RTP Header Extension 439 When SRCNAME information is carried as RTP header extension 440 [RFC5285], the header extension MUST contain both CNAME and SRCNAME 441 information, since SRCNAME is scoped by CNAME. Separate header 442 extension identities are defined for SRCNAME and CNAME. This is 443 motivated by the fact that a single RTP stream can have several 444 SRCNAME, but only a single CNAME. 446 The RTP header extensions for CNAME and SRCNAME MAY use either one of 447 the one-byte or two-byte header formats, depending on the CNAME and 448 SRCNAME value size. The one-byte header SHOULD be used when the 449 value contains at most 16 bytes. Note that the RTP header extension 450 specification does not allow to mix one-byte and two-byte headers for 451 the same stream, so if the value size of either SRCNAME or CNAME 452 requires the two-byte header, the other MUST also use that header 453 format. 455 The header extension payload for SRCNAME contains the srcname- 456 content, as defined in Section 6. The header extension payload for 457 CNAME contains the CNAME value as defined in [RFC3550]. Figures 458 Figure 4 and Figure 5 show samples of the structure of the header 459 extension payload for the two header formats. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | ID | len | CNAME or SRCNAME value ... | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 4 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | ID | len | CNAME or SRCNAME value ... | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 5 477 The URN identifiers to use with "a=extmap" SDP signaling for SRCNAME 478 and CNAME, respectively, MUST be 480 urn:ietf:params:rtp-hdrext:srcname 481 urn:ietf:params:rtp-hdrext:cname 483 10. Examples 485 This section shows SDP examples of declaring the SRCNAME in SDP. 487 10.1. Simulcast 489 In this use case the end-point is a client with a single audio source 490 and two video sources, and it uses simulcast for sending different 491 encodings of the same video source. This example is based on Using 492 Simulcast in RTP sessions [I-D.westerlund-avtcore-rtp-simulcast]. 493 The following SDP describes this. 495 v=0 496 o=alice 3203093520 3203093520 IN IP4 foo.example.com 497 s=Simulcast enabled client 498 t=0 0 499 c=IN IP4 foo.example.com 500 m=audio 49200 RTP/AVP 96 501 a=rtpmap:96 G719/48000/2 502 a=ssrc:521923924 cname:alice@foo.example.com 503 a=ssrc:521923924 srcname:a1 504 a=mid:1 505 m=video 49300 RTP/AVP 96 506 a=rtpmap:96 H264/90000 507 a=fmtp:96 profile-level-id=42c01e 508 a=imageattr:96 send [x=640,y=360] recv [x=640,y=360] [x=320,y=180] 509 a=ssrc:192392452 cname:alice@foo.example.com 510 a=ssrc:192392452 srcname:v1 511 a=ssrc:834753488 cname:alice@foo.example.com 512 a=ssrc:834753488 srcname:v2 513 a=mid:2 514 a=content:main 515 m=video 49400 RTP/AVP 97 516 a=rtpmap:97 H264/90000 517 a=fmtp:97 profile-level-id=42c00d 518 a=imageattr:97 send [x=320,y=180] 519 a=ssrc:239245219 cname:alice@foo.example.com 520 a=ssrc:239245219 srcname:v1 521 a=ssrc:734623563 cname:alice@foo.example.com 522 a=ssrc:734623563 srcname:v2 523 a=mid:3 524 a=sendonly 526 The audio session is proposing to use one stereo stream of G.719 and 527 the video sessions are proposing to send two different encodings of 528 each video source, one with the resolution 640x360 and one with 529 320x180. The end-point also declares the SSRCs it intends to use 530 with bindings to CNAME and SRCNAME, enabling the receiver of the SDP 531 to bind together the video streams that originate from the same video 532 camera. For example, the two streams having an SRCNAME of "v1" 533 originate from the same video camera and belong together. 535 The use of the srcname attribute in the SDP is optional and the 536 information can be retrieved from RTCP reporting, but it will then 537 not be possible to correctly relate the video sources until the first 538 RTCP report is received. 540 10.2. SVC with multi-session transmission 542 Here an example is shown of a client that uses SVC with multi-session 543 transmission as described in RTP Payload Format for Scalable Video 544 Coding [RFC6190]. RTP Payload Format for Scalable Video Coding 545 [RFC6190] only describes examples for a client with one video source 546 and the decoder dependencies of the different sessions are grouped 547 using the Session grouping DDP attribute as defined in Signaling 548 Media Decoding Dependency in the Session Description Protocol (SDP) 549 [RFC5583] and implicitly CNAME. 551 However, if a client has two video sources and wishes to use multi- 552 session transmission and send streams from both sources in each 553 session, an additional grouping mechanism is needed to group the 554 different streams in the different sessions. SRCNAME is suitable for 555 this and here we show an example where the DDP attribute groups the 556 different sessions and the SRCNAME is used to relate the different 557 SSRCs in each RTP session to one of the two video sources. 559 v=0 560 o=bob 8473948250 8473948250 IN IP4 foo.example.com 561 s=SVC MST client 562 t=0 0 563 c=IN IP4 foo.example.com 564 a=group:DDP L1 L2 L3 565 m=audio 49500 RTP/AVP 96 566 a=rtpmap:96 G719/48000/2 567 a=ssrc:293848928 cname:bob@foo.example.com 568 a=mid:A1 569 m=video 20000 RTP/AVP 96 570 a=rtpmap:96 H264/90000 571 a=fmtp:96 profile-level-id=4de00a; packetization-mode=1; 572 mst-mode=NI-TC; sprop-parameter-sets={sps0},{pps0}; 573 a=ssrc:743947584 cname:bob@foo.example.com 574 a=ssrc:743947584 srcname:V1.L1 575 a=ssrc:283894947 cname:bob@foo.example.com 576 a=ssrc:283894947 srcname:V2.L1 577 a=mid:L1 578 m=video 20002 RTP/AVP 97 579 a=rtpmap:97 H264-SVC/90000 580 a=fmtp:97 profile-level-id=53000c; packetization-mode=1; 581 mst-mode=NI-T; sprop-parameter-sets={sps1},{pps1}; 582 a=ssrc:492784823 cname:bob@foo.example.com 583 a=ssrc:492784823 srcname:V1.L2 584 a=ssrc:892362397 cname:bob@foo.example.com 585 a=ssrc:892362397 srcname:V2.L2 586 a=mid:L2 587 a=depend:97 lay L1:96 588 m=video 20004 RTP/AVP 98 589 a=rtpmap:98 H264-SVC/90000 590 a=fmtp:98 profile-level-id=53001F; packetization-mode=1; 591 mst-mode=NI-T; sprop-parameter-sets={sps2},{pps2}; 592 a=ssrc:184562894 cname:bob@foo.example.com 593 a=ssrc:184562894 srcname:V1.L3 594 a=ssrc:305605682 cname:bob@foo.example.com 595 a=ssrc:305605682 srcname:V2.L3 596 a=mid:L3 597 a=depend:98 lay L1:96 L2:97 599 Thus, the client declares that it will send two video streams in each 600 RTP session and the receiver is then able to relate the streams in 601 the different sessions by using the SRCNAME binding, with matching 602 (first parts of the) SRCNAME value. Without the SRCNAME binding it 603 would not be possible for the receiver to know which streams belong 604 to the same source. Note that the audio stream does not have an 605 explicit srcname attribute in this example, but only relate to the 606 video streams through the same CNAME. Note that the last part of the 607 SRCNAMEs in the example, ".L1", ".L2" and ".L3" are not necessary but 608 allowed and will not impact the ability to tell that the streams 609 belong together, since related streams have the first part in common. 611 10.3. Retransmission 613 This use case shows how SRCNAME can be used to connect retransmission 614 streams to the original streams in the case of SSRC multiplexed RTP 615 retransmission [RFC4588]. This is included to exemplify how RTP 616 retransmission could be updated to provide explicit bindings between 617 the source and the repair stream, but just an example and not a 618 specification. 620 v=0 621 o=carol 3462534872 3462534872 IN IP4 foo.example.com 622 s=SSRC-multiplexed retransmission client 623 t=0 0 624 c=IN IP4 foo.example.com 625 m=audio 49800 RTP/AVP 96 626 a=rtpmap:96 G719/48000/2 627 a=ssrc:8372496978 cname:carol@foo.example.com 628 a=mid:1 629 m=video 49300 RTP/AVP 96 97 630 a=rtpmap:96 H264/90000 631 a=rtcp-fb:96 nack 632 a=fmtp:96 profile-level-id=42c01e 633 a=rtpmap:97 rtx/90000 634 a=fmtp:97 apt=96;rtx-time=200 635 a=ssrc:192392452 cname:carol@foo.example.com 636 a=ssrc:192392452 srcname:v1.o 637 a=ssrc:834753488 cname:carol@foo.example.com 638 a=ssrc:834753488 srcname:v1.r 639 a=ssrc:682394013 cname:carol@foo.example.com 640 a=ssrc:682394013 srcname:v2.o 641 a=ssrc:284576129 cname:carol@foo.example.com 642 a=ssrc:284576129 srcname:v2.r 643 a=mid:2 645 The client proposes to send two original video streams in the video 646 session and a retransmission stream for each one of them. The 647 retransmission streams are associated with the respective original 648 stream by using matching SRCNAME and a receiver would then know which 649 original stream a certain retransmission stream is associated with. 650 This solves the ambiguity problem when SSRC-multiplexing is used for 651 retransmission and it enables SSRC-multiplexing of original and 652 retransmission streams to be used also in multicast sessions. Note 653 that ".o" and ".r" parts of SRCNAME are not needed, but may improve 654 understanding of the example and will not affect the ability to match 655 related streams. 657 10.4. Forward Error Correction 659 Forward Error Correction Grouping Semantics in the Session 660 Description Protocol [RFC5956] defines two SDP attributes for 661 grouping the associated source and FEC-based repair streams. One can 662 be used for grouping different RTP sessions and the other can be used 663 for grouping SSRCs in the same RTP session, i.e. when session- 664 respective SSRC-multiplexing is used. However, it may be 665 advantageous to SSRC-multiplex the source streams in one RTP session 666 and the repair streams in another since that gives a receiver the 667 possibility to reject the repair session in case it does not support 668 the proposed FEC. In this case, the above mentioned grouping 669 attributes cannot be used to associate the repair streams with the 670 respective source stream since grouping of SSRCs cannot be made 671 across RTP sessions. The following example shows how SRCNAME can be 672 used for that. 674 v=0 675 o=dave 7352395826 7352395826 IN IP4 foo.example.com 676 s=FEC client 677 t=0 0 678 c=IN IP4 foo.example.com 679 a=group:FEC-FR 2 3 680 m=audio 49300 RTP/AVP 96 681 a=rtpmap:96 G719/48000/2 682 a=ssrc:237847298 cname:dave@foo.example.com 683 a=mid:1 684 m=video 49200 RTP/AVP 100 685 a=rtpmap:100 MP2T/90000 686 a=ssrc:847612849 cname:dave@foo.example.com 687 a=ssrc:847612849 srcname:v1.o 688 a=ssrc:558237845 cname:dave@foo.example.com 689 a=ssrc:558237845 srcname:v2.o 690 a=exthdr:1 urn:ietf:params:rtp-hdrext:cname 691 a=exthdr:4 urn:ietf:params:rtp-hdrext:srcname 692 a=mid:2 693 m=application 49300 RTP/AVP 101 694 a=rtpmap:101 1d-interleaved-parityfec/90000 695 a=fmtp:101 L=5; D=10; repair-window=200000 696 a=ssrc:389572053 cname:dave@foo.example.com 697 a=ssrc:389572053 srcname:v1.r 698 a=ssrc:185729479 cname:dave@foo.example.com 699 a=ssrc:185729479 srcname:v2.r 700 a=exthdr:2 urn:ietf:params:rtp-hdrext:cname 701 a=exthdr:5 urn:ietf:params:rtp-hdrext:srcname 702 a=mid:3 704 In this example the client proposes to send two video streams in one 705 session and two repair streams in the other session. The repair 706 streams are associated with the respective video stream by using a 707 matching SRCNAME. When receiving either this SDP, the SDES SRCNAME 708 packets, or the SRCNAME/CNAME RTP header extensions (which are also 709 offered), a receiver can make the connection between the source 710 streams and the repair streams. Even a client not receiving the SDP 711 will be able to do the association, by SRCNAME in either SDES or RTP 712 header extension, if it has established one RTP session for receiving 713 source streams and another for receiving repair streams. Note that 714 ".o" and ".r" parts of SRCNAME are not needed, but may improve 715 understanding of the example and will not affect the ability to match 716 related streams (since they match on the highest hierarchical level). 718 11. Usage with the Offer/Answer Model 720 The SDP offer/answer procedures for a=ssrc are specified in Source- 721 Specific Media Attributes in the Session Description Protocol (SDP) 722 [RFC5576]. The SDP offer/answer procedures for a=exthdr are 723 specified in A General Mechanism for RTP Header Extensions [RFC5285]. 725 12. Backward Compatibility 727 Clients not supporting SRCNAME will not have the possibility to bind 728 different streams to a specific media source, since they will not 729 understand the SRCNAME SDES item or the RTP header extension. 730 However, sending SRCNAME SDES items to a client not supporting it 731 should not impose any problems since all clients should be prepared 732 that new SDES items may be specified according to RTP [RFC3550]. 734 According to the definition of SDP attributes in SDP: Session 735 Description Protocol [RFC4566], if an attribute is received that is 736 not understood, it MUST be ignored by the receiver. So a receiver 737 not supporting the ssrc attribute will simply ignore it. 739 Source-Specific Media Attributes in the Session Description Protocol 740 (SDP) [RFC5576] defines rules of how new source attributes should be 741 registered, which means that a receiver supporting RFC 5576 should be 742 prepared that new source attributes may be defined. This means that 743 a user supporting some of the source attributes should not have any 744 problems when the user receives an SDP with unknown source 745 attributes. 747 RTP header extension will only be used when successfully negotiated 748 in SDP, which requires support in both sender and receiver. 750 13. IANA Considerations 752 Following the guidelines in SDP [RFC4566], in The Session Description 753 Protocol (SDP) Grouping Framework [RFC5888], and in RTP [RFC3550], 754 the IANA is requested to register: 756 1. A new SDES item named SRCNAME, as defined in Section 7. This 757 item needs to be assigned an identifier TBA1. 759 2. A new SDP source attribute named srcname, as defined in 760 Section 8. 762 3. New RTP header extension URN identifiers for SRCNAME and CNAME, 763 as defined in Section 9. 765 14. Security Considerations 767 The SDES or header extension SRCNAMEs being close to opaque 768 identifiers could potentially carry additional meanings or function 769 as overt channel. If the SRCNAME would be permanent between 770 sessions, they have the potential for compromising the users' privacy 771 as they can be tracked between sessions. See Guidelines for Choosing 772 RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [RFC6222] for 773 more discussion. 775 A third party modification of the srcname labels either in the RTCP 776 SDES items, in the SDP a=ssrc attribute, or in the RTP header 777 extension can cause service disruption. By modifying labels the 778 wrong streams could be associated, with potentially serious effects 779 including media disruptions. If streams that are to be associated 780 aren't associated, then another type of failures occur. To prevent 781 modification, insertion or deletion of the srcname labels, the 782 carrying channel needs to be protected by integrity protection and 783 source authentication. For RTCP and RTP header extension, various 784 solutions exist, such as SRTP [RFC3711], DTLS [RFC6347], or IPsec 785 [RFC4301]. For protecting the SDP, the signalling channel needs to 786 provide protection. For SIP S/MIME [RFC3261] are the ideal, and hop 787 by hopTLS [RFC5246] provides at least some protection, although not 788 perfect. For SDPs retrieved using RTSP DESCRIBE [RFC2326], TLS would 789 be the RECOMMENDED solution. 791 15. References 792 15.1. Normative References 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, March 1997. 797 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 798 Jacobson, "RTP: A Transport Protocol for Real-Time 799 Applications", STD 64, RFC 3550, July 2003. 801 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 802 10646", STD 63, RFC 3629, November 2003. 804 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 805 Specifications: ABNF", STD 68, RFC 5234, January 2008. 807 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 808 Media Attributes in the Session Description Protocol 809 (SDP)", RFC 5576, June 2009. 811 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 812 Choosing RTP Control Protocol (RTCP) Canonical Names 813 (CNAMEs)", RFC 6222, April 2011. 815 15.2. Informative References 817 [I-D.ietf-avtext-rtp-duplication] 818 Begen, A. and C. Perkins, "Duplicating RTP Streams", 819 draft-ietf-avtext-rtp-duplication-00 (work in progress), 820 July 2012. 822 [I-D.ietf-mmusic-duplication-grouping] 823 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 824 Semantics in the Session Description Protocol", 825 draft-ietf-mmusic-duplication-grouping-00 (work in 826 progress), October 2012. 828 [I-D.westerlund-avtcore-rtp-simulcast] 829 Westerlund, M., Burman, B., Lindqvist, M., and F. Jansson, 830 "Using Simulcast in RTP sessions", 831 draft-westerlund-avtcore-rtp-simulcast (work in progress), 832 October 2011. 834 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 835 Streaming Protocol (RTSP)", RFC 2326, April 1998. 837 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 838 A., Peterson, J., Sparks, R., Handley, M., and E. 839 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 840 June 2002. 842 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 843 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 844 RFC 3711, March 2004. 846 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 847 Internet Protocol", RFC 4301, December 2005. 849 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 850 Description Protocol", RFC 4566, July 2006. 852 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 853 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 854 July 2006. 856 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 857 January 2008. 859 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 860 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 862 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 863 Header Extensions", RFC 5285, July 2008. 865 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 866 Dependency in the Session Description Protocol (SDP)", 867 RFC 5583, July 2009. 869 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 870 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 872 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 873 the Session Description Protocol", RFC 5956, 874 September 2010. 876 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 877 Flows", RFC 6051, November 2010. 879 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 880 "RTP Payload Format for Scalable Video Coding", RFC 6190, 881 May 2011. 883 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 884 Security Version 1.2", RFC 6347, January 2012. 886 Authors' Addresses 888 Magnus Westerlund 889 Ericsson 890 Farogatan 6 891 SE-164 80 Kista 892 Sweden 894 Phone: +46 10 714 82 87 895 Email: magnus.westerlund@ericsson.com 897 Bo Burman 898 Ericsson 899 Farogatan 6 900 SE-164 80 Kista 901 Sweden 903 Phone: +46 10 714 13 11 904 Email: bo.burman@ericsson.com 906 Patrik Sandgren 907 Ericsson 908 Farogatan 6 909 SE-164 80 Kista 910 Sweden 912 Phone: +46 10 717 97 41 913 Email: patrik.sandgren@ericsson.com