idnits 2.17.1 draft-lennox-mmusic-sdp-source-attributes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 754. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2007) is 6111 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 3388 (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-13 == Outdated reference: A later version (-27) exists of draft-ietf-avt-rtp-svc-01 == Outdated reference: A later version (-07) exists of draft-ietf-avt-topologies-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-16 == Outdated reference: A later version (-06) exists of draft-mehta-rmt-flute-sdp-05 -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Lennox 3 Internet-Draft Layered Media 4 Intended status: Standards Track J. Ott 5 Expires: January 7, 2008 Helsinki University of Technology 6 T. Schierl 7 Fraunhofer HHI 8 July 6, 2007 10 Source-Specific Media Attributes in the Session Description Protocol 11 (SDP) 12 draft-lennox-mmusic-sdp-source-attributes-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 7, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Session Description Protocol provides mechanisms to describe 46 attributes of multimedia sessions and of individual media streams 47 (e.g., Real-time Transport Protocol (RTP) sessions) within a 48 multimedia session, but does not provide any mechanism to describe 49 individual media sources within a media stream. This document 50 defines a mechanism to describe RTP media sources, identified by 51 their Synchronization Source Identifiers (SSRCs), in SDP, associate 52 attributes with these sources, and express relationships among 53 sources. It also defines several source-level attributes which can 54 be used to describe properties of media sources. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Media Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. The "ssrc" Media Attribute . . . . . . . . . . . . . . . . 5 63 4.2. The "ssrc-group" Media Attribute . . . . . . . . . . . . . 6 64 5. Usage of Identified Source Identifiers in RTP . . . . . . . . 7 65 6. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. The "cname" Source Attribute . . . . . . . . . . . . . . . 9 67 6.2. The "previous-ssrc" Source Attribute . . . . . . . . . . . 9 68 6.3. The "fmtp" Source Attribute . . . . . . . . . . . . . . . 10 69 6.4. Other Attributes . . . . . . . . . . . . . . . . . . . . . 10 70 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 11 72 9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 73 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 15 80 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 15 81 B.1. Changes From Draft -00 . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 Intellectual Property and Copyright Statements . . . . . . . . . . 17 85 1. Introduction 87 The Session Description Protocol (SDP) [RFC4566] provides mechanisms 88 to describe attributes of multimedia sessions and of media streams 89 (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within 90 a multimedia session, but does not provide any mechanism to describe 91 individual media sources within a media stream. 93 Several recently-proposed protocols, notably RTP Single-Source 94 Multicast [I-D.ietf-avt-rtcpssm] have found it useful to describe 95 specific media sources in SDP messages. Single-source multicast, in 96 particular, needs to ensure that receivers' RTP Syncronization Source 97 Identifiers (SSRCs) do not collide with those of media senders, as 98 the RTP specification [RFC3550] requires that colliding sources 99 change their SSRC values after a collision has been detected. 100 Earlier work has used mechanisms specific to each protocol to 101 describe the individual sources of an RTP session. 103 Moreover, whereas the Real-Time Transport Protocol (RTP) [RFC3550] is 104 defined as allowing multiple sources in an RTP session (for example, 105 if a user has more than one camera), SDP has no existing mechanism 106 for an endpoint to indicate that it will be using multiple sources, 107 or to describe their characteristics individually. 109 To address all these problems, this document defines a mechanism to 110 describe RTP sources, identified by their Synchronization Sources 111 Identifiers (SSRCs), in SDP, associate attributes with these sources, 112 and express relationships among individual sources. It also defines 113 a number of new SDP attributes that apply to individual sources 114 ("source-level" attributes); describes how a number of existing media 115 stream ("media-level") attributes can also be applied at the source 116 level; and establishes an IANA repository for source-level 117 attributes. 119 During the still-ongoing discussion in the AVT and MMUSIC working 120 groups on the transport [I-D.ietf-avt-rtp-svc] and signaling 121 [I-D.schierl-mmusic-layered-codec] of the Scalable Video Coding (SVC) 122 Extensions of H.264, SSRC multiplexing of layered video was 123 considered as an appropriate multiplexing technique, if the use case 124 strongly requires this. It was considered that a compelling use case 125 exists for identifying RTP packet streams carrying different layers 126 of a single SVC media stream. One use case was pointed out, which is 127 the adaptation of an SRTP encrypted SVC stream by a middle-box not 128 being in the security context. Since the authentication and 129 integrity mechanism of SRTP still requires the middle-boy being in 130 the security context, the authors of [I-D.ietf-avt-rtp-svc] and 131 [I-D.schierl-mmusic-layered-codec] currently do not consider SSRC 132 multiplexing. Since the process for both memos is still going on, 133 however, a requirement for SSRC multiplexing for SVC may come up 134 again. SSRC multiplexing would anyway make an easy identification of 135 layers of a scalable media stream in a middle-box possible, without 136 the need of parsing into RTP payload headers. A potential use case 137 is shown in Section 7, the examples section. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119] and 144 indicate requirement levels for compliant implementations. 146 3. Overview 148 In the Real-Time Transport Protocol (RTP) [RFC3550], an association 149 among a group of communicating participants is known as an RTP 150 Session. An RTP session is typically associated with a single 151 transport address (in the case of multicast) or communication flow 152 (in the case of unicast), though RTP translators and single-source 153 multicast [I-D.ietf-avt-rtcpssm] can make the situation more complex. 154 RTP topologies are discussed in more detail in 155 [I-D.ietf-avt-topologies]. 157 Within an RTP session, the source of a single stream of RTP packets 158 is known as a synchronization source (SSRC). Every synchronization 159 source is identified by a 32-bit numeric identifier. In addition, 160 receivers (who may never send RTP packets) also have source 161 identifiers, which are used to identify their RTP Control Protocol 162 (RTCP) receiver reports and other feedback messages. 164 Messages of the Session Description Protocol (SDP) [RFC4566], known 165 as Session Descriptions, describe Multimedia Sessions. A multimedia 166 session is a set of multimedia senders and receivers, and the data 167 streams flowing from senders to receivers. A multimedia session 168 contains a number of Media Streams, which are the individual RTP 169 sessions or other media paths over which one type of multimedia data 170 is carried. Information that applies to an entire multimedia session 171 is called Session-Level information, while information pertaining to 172 one media stream is called Media-Level information. The collection 173 of all the information describing a media stream is known as a Media 174 Description. (Media descriptions are also sometimes known informally 175 as SDP "m"-lines, after the SDP syntax that begins a media 176 description.) Several standard information elements are defined at 177 both the session level and the media level. Extended information can 178 be included at both levels through the use of attributes. 180 (The term "Media Stream" does not appear in the SDP specification 181 itself, but is used by a number of SDP extensions, for instance 182 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], 183 to denote the object described by an SDP media description. This 184 term is unfortunately rather confusing, as the RTP specification 185 [RFC3550] uses the term "media stream" to refer to an individual 186 media source or RTP packet stream, identified by an SSRC, whereas an 187 SDP media stream describes an entire RTP session, which can contain 188 any number of RTP sources. In this document, the term "media stream" 189 means an SDP media stream, i.e. the thing described by an SDP media 190 description, whereas "media source" is used for a single source of 191 media packets, i.e. an RTP media stream.) 193 The core SDP specification does not have any way of describing 194 individual media sources, in particular RTP synchronization sources, 195 within a media stream. To address this problem, in this document we 196 introduce a third level of information, called Source-Level 197 information. Syntactically, source-level information is described by 198 a new SDP media-level attribute "ssrc", which identifies specific 199 synchronization sources within an RTP session, and acts as a meta- 200 attribute mapping source-level attribute information to these 201 sources. 203 This document also defines an SDP media-level attribute "ssrc-group", 204 which can represent relationships among media sources within an RTP 205 session, in much the same way as the "group" attribute [RFC3388] 206 represents relationships among media streams within a multimedia 207 session. 209 4. Media Attributes 211 This section defines two media-level attributes, "ssrc" and "ssrc- 212 group". 214 4.1. The "ssrc" Media Attribute 216 a=ssrc: 217 a=ssrc: : 219 The SDP media attribute "ssrc" indicates a property (known as a 220 "source-level attribute") of a media source (RTP stream) within an 221 RTP session. is the synchronizaton source ID (SSRC) of the 222 source being described, interpreted as a 32-bit unsigned integer in 223 network byte order and represented in decimal. or 224 : represent the source-level attribute specific to 225 the given media source. The source-level attribute follows the 226 syntax of the SDP "a=" line. It thus consists either of a single 227 attribute name (a flag), or an attribute name and value, e.g. 228 "cname:user@example.com". No attributes of the former type are 229 defined by this document. 231 Within a media stream, ssrc attributes with the same value of 232 describe different attributes of the same media sources. 233 Across media streams, values are not correlated (unless 234 correlation is indicated by media-stream grouping or some other 235 mechanism) and MAY be repeated. 237 For each source mentioned in SDP, the source-level attribute "cname", 238 defined in Section 6.1, MUST be provided. Any number of other 239 source-level attributes for the source MAY also be provided. 241 The "ssrc" media attribute MAY be used for any RTP-based media 242 transport. It is not defined for other transports. 244 Though the source-level attributes specified by the ssrc property 245 follow the same syntax as session-level and media-level attributes, 246 they are defined independently. All source-level attributes MUST be 247 registered with IANA, using the registry defined in Section 12. 249 Figure 10 in Section 10 gives a formal Augmented Backus-Naur Form 250 (ABNF) [RFC4234] grammar for the ssrc attribute. 252 4.2. The "ssrc-group" Media Attribute 254 a=ssrc-group: ... 256 The SDP media attribute "ssrc-group" expresses a relationship among 257 several sources of an RTP session. It is analogous to the "group" 258 session-level attribute [RFC3388], which expresses a relationship 259 among media streams in an SDP multimedia session (i.e., a 260 relationship among several logically related RTP sessions). As 261 sources are already identified by their SSRC IDs, no analogous 262 property to the "mid" attribute is necessary; groups of sources are 263 identified by their SSRC IDs directly. 265 The parameter is taken from the specification of the 266 "group" attribute [RFC3388]. Its potential parameters are defined by 267 IANA in "Semantics for the 'group' SDP Attribute" under "SDP 268 Parameters". The semantics defined for the ssrc-group attribute are 269 FID (Flow Identification) [RFC3388] and FEC (Forward Error 270 Correction) [RFC4756]. In each case, the relationship among the 271 grouped sources is the same as the relationship among corresponding 272 sources in media streams grouped using the SDP "group" attribute. 274 (None of the other "group" semantics registered with IANA as of this 275 writing are useful for source grouping. LS (Lip Synchronization) 276 [RFC3388] is redundant for sources within a media stream, as RTP 277 sources with the same CNAME are implicitly synchronized in RTP. SRF 278 (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network 279 Address Types) [RFC4091] refer specifically to the media stream's 280 transport characteristics. CS (Composite Session) 281 [I-D.mehta-rmt-flute-sdp] is used to group FLUTE sessions, and so is 282 not applicable to RTP.) 284 The ssrc-group attribute indicates the sources in a group by listing 285 the s of the sources in the group. It MUST list at least 286 one for a group, and MAY list any number of additional 287 ones. Every listed in an ssrc-group attribute MUST be 288 defined by a corresponding "ssrc:" line in the same media 289 description. 291 Figure 11 in Section 10 gives a formal Augmented Backus-Naur Form 292 (ABNF) [RFC4234] grammar for the ssrc-group attribute. 294 5. Usage of Identified Source Identifiers in RTP 296 The synchronization source identifiers used in an RTP session are 297 chosen randomly and independently by endpoints. As such, it is 298 possible for two RTP endpoints to choose the same SSRC identifier. 299 Though the probability of this is low, the RTP specification 300 [RFC3550] requires that all RTP endpoints MUST be prepared to detect 301 and resolve collisions. 303 As a result, all endpoints MUST be prepared for the fact that 304 information about specific sources identified in a media stream might 305 be out of date. The actual binding between SSRCs and source CNAMEs 306 can only be identified by the source description (SDES) RTCP packets 307 transmitted on the RTP session. 309 When endpoints are choosing their own local SSRC values for media 310 streams for which source-level attributes have been specified, they 311 MUST NOT use for themselves any SSRC identifiers mentioned in media 312 descriptions they have received for the media stream. 314 However, sources identified by SDP source-level attributes do not 315 otherwise affect RTP transport logic. Specifically, sources which 316 are only known through SDP, for which neither RTP nor RTCP packets 317 have been received, MUST NOT be counted for RTP group size 318 estimation, and report blocks MUST NOT be sent for them in SR or RR 319 RTCP messages. 321 Endpoints MUST NOT assume that only the sources mentioned in SDP will 322 be present in an RTP session; additional sources, with previously 323 unmentioned SSRC IDs, can be added at any time, and endpoints MUST be 324 prepared to receive packets from these sources. (How endpoints 325 handle such packets is not specified here; they SHOULD be handled in 326 the same manner as packets from additional sources would be handled 327 had the endpoint not received any a=ssrc: attributes at all.) 329 An endpoint that observes an SSRC collision between its explicitly- 330 signaled source and another entity that has not explicitly signaled 331 an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by 332 5*1.5*Td, with Td being the deterministic calculated reporting 333 interval for receivers, to see whether the conflict still exists. 334 (This gives precedence to explicitly-signaled sources, and places the 335 burden of collision resolution on non-signaled sources.) SSRC 336 collisions between multiple explicitly-signaled sources, however, 337 MUST be acted upon immediately. 339 If, following RTP's collision-resolution procedures [RFC3550], a 340 source identified by source-level attributes has been forced to 341 change its SSRC identifier, the author of the SDP containing the 342 source-level attributes for these sources SHOULD send out an updated 343 SDP session description with the new SSRC, if the mechanism by which 344 SDP is being distributed for the multimedia session has a mechanism 345 to distribute updated SDP. This updated SDP MUST include a previous- 346 ssrc source-level attribute, described in Section 6.2, listing the 347 source's previous SSRC ID. (If only a single source with a given 348 CNAME has collided, the other RTP session members can infer a 349 correspondence between the source's old and new SSRC IDs, without 350 requiring an updated session description. However, if more than one 351 source collides at once, or if sources are leaving and re-joining, 352 this inference is not possible. To avoid confusion, therefore, 353 sending updated SDP messages is always RECOMMENDED.) 355 Endpoints MUST NOT reuse the same SSRC ID for identified sources with 356 same CNAME for at least the duration of the RTP session's participant 357 timeout interval (see Section 6.3.5 of [RFC3550]). They SHOULD NOT 358 reuse any SSRC ID ever mentioned in SDP (either by themselves or by 359 other endpoints) for the entire lifetime of the RTP session. 361 Endpoints MUST be prepared for the possibility that other parties in 362 the session do not understand SDP source-level attributes, unless 363 some higher-level mechanism normatively requires them. See Section 9 364 for more discussion of this. 366 6. Source Attributes 368 This section describes specific source attributes that can be applied 369 to RTP sources. 371 6.1. The "cname" Source Attribute 373 a=ssrc: cname: 375 The "cname" source attribute associates a media source with its 376 Canonical End-Point Identifier (CNAME) source description (SDES) 377 item. This MUST be the CNAME value that the media sender will place 378 in its RTCP SDES packets; it therefore MUST follow the syntax 379 conventions of CNAME defined in the RTP specification [RFC3550]. If 380 a session participant receives an RTCP SDES packet associating this 381 SSRC with a different CNAME, it SHOULD assume there has been an SSRC 382 collision, and that the description of the source that was carried in 383 the SDP description is not applicable to the actual source being 384 received. This source attribute is REQUIRED to be present if any 385 source attributes are present for a source. The cname attribute MUST 386 NOT occur more than once for the same ssrc-id within a given media 387 stream. 389 Figure 12 in Section 10 gives a formal Augmented Backus-Naur Form 390 (ABNF) [RFC4234] grammar for the cname attribute. 392 6.2. The "previous-ssrc" Source Attribute 394 a=ssrc: previous-ssrc: ... 396 The "previous-ssrc" source attribute associates a media source with 397 previous source identifiers used for the same media source. 398 Following an SSRC change due to an SSRC collision involving a media 399 source described in SDP, the updated session description describing 400 the source's new SSRC (described in Section 5) MUST include the 401 previous-ssrc attribute associating the new SSRC with the old one. 402 If further updated SDP descriptions are published describing the 403 media source, the previous-ssrc attribute SHOULD be included if the 404 session description was generated before the participant timeout of 405 the old SSRC, and MAY be included after that point. This attribute, 406 if present, MUST list at least one previous SSRC, and MAY list any 407 number of additional SSRCs for the source, if the source has collided 408 more than once. This attribute MUST be present only once for each 409 source. 411 Figure 13 in Section 10 gives a formal Augmented Backus-Naur Form 412 (ABNF) [RFC4234] grammar for the previous-ssrc attribute. 414 6.3. The "fmtp" Source Attribute 416 a=ssrc: fmtp: 418 The "fmtp" source attribute allows format-specific parameters to be 419 conveyed about a given source. The parameter MUST be one of 420 the media formats (i.e., RTP payload types) specified for the media 421 stream. The meaning of the is unique 422 for each media type. This parameter MUST only be used for media 423 types for which source-level format parameters have explicitly been 424 specified; media-level format parameters MUST NOT be carried over 425 blindly. 427 6.4. Other Attributes 429 This document only defines source attributes which are necessary or 430 useful for an endpoint to decode and render the sources in a media 431 stream. It does include any attributes which would contribute to an 432 endpoint's decision to accept or reject a stream, e.g. in an offer/ 433 answer exchange. Such attributes are for future consideration. 435 7. Examples 437 This section gives several examples of SDP descriptions of media 438 sessions containing source attributes. For brevity, only the media 439 sections of the descriptions are given. 441 m=audio 49168 RTP/AVP 0 442 a=ssrc:314159 cname:user@example.com 444 Figure 6: Example: declaration of a single synchronization source 446 The example in Figure 6 shows an audio stream advertising a single 447 source. 449 m=video 49170 RTP/AVP 96 450 a=rtpmap:96 H264/90000 451 a=ssrc:12345 cname:another-user@example.com 452 a=ssrc:67890 cname:another-user@example.com 454 Figure 7: Example: a media stream containing several independent 455 sources from a single session member. 457 The example in Figure 7 shows a video stream where one participant 458 (identified by a single CNAME) has several cameras. The sources 459 could be further distinguished by RTCP Source Description (SDES) 460 information. 462 m=video 49172 RTP/AVP 97 463 a=rtpmap:97 SVC/90000 464 a=ssrc-group:DDP 271828 14142135 465 a=ssrc:271828 cname:layered-codec@example.com 466 a=ssrc:14142135 cname:layered-codec@example.com 467 a=ssrc:14142135 depend:lay 271828 469 Figure 8: Example: relationship among several sources: layered coding 471 The example in Figure 8 shows a relationship among several sources, 472 grouped by the "DDP" grouping semantics defined in Signaling of 473 Layered and Multi-Description Media 474 [I-D.schierl-mmusic-layered-codec]. (Note that this is only an 475 example; multiplexing of layered codecs among several sources in an 476 RTP session is currently not specified or encouraged.) 478 m=video 49174 RTP/AVPF 96 98 479 a=rtpmap:96 H.264/90000 480 a=rtpmap:98 rtx/90000 481 a=fmtp:98 apt=96;rtx-time=3000 482 a=ssrc-group:FID 11111 22222 483 a=ssrc:11111 cname:user3@example.com 484 a=ssrc:22222 cname:user3@example.com 485 a=ssrc-group:FID 33333 44444 486 a=ssrc:33333 cname:user3@example.com 487 a=ssrc:44444 cname:user3@example.com 489 Figure 9: Example: relationship among several sources: retransmission 490 sources 492 The example in Figure 9 shows how the relationships among sources 493 used for RTP Retransmission [RFC4588] can be explicitly signaled. 494 This prevents the complexity of associating original sources with 495 retransmission sources when SSRC multiplexing is used for RTP 496 retransmission, as is described in Section 5.3 of [RFC4588]. 498 8. Usage With the Offer/Answer Model 500 When used with the SDP Offer/Answer Model [RFC3264], SDP source- 501 specific attributes describe only the sources with which each party 502 is willing to send (whether it is sending RTP data or RTCP report 503 blocks). No mechanism is provided by which an answer can accept or 504 reject individual sources within a media stream; if the set of 505 sources in a media stream is unacceptable, the answerer's only option 506 is to reject the media stream or the entire multimedia session. 508 The SSRC IDs for sources described by an SDP answer MUST be distinct 509 from the SSRC IDs for sources of that media stream in the offer. 510 Similarly, new SSRC IDs in an updated offer MUST be distinct from the 511 ssrc IDs for that media stream established in the most recent offer/ 512 answer exchange for the session, and SHOULD be distinct from any SSRC 513 ID ever used by either party within the multimedia session (whether 514 or not it is still being used). 516 9. Backward Compatibility 518 According to the defintion of SDP, interpreters of SDP session 519 descriptions ignore unknown attributes. Thus, endpoints MUST be 520 prepared that recipients of their RTP media session may not 521 understand their explicit source descriptions, unless some external 522 mechanism indicates that they were understood. In some cases (such 523 as RTP Retransmission [RFC4588]) this may constrain some choices 524 about the bitstreams that are transmitted. 526 Source descriptions are specified in this document such that RTP 527 endpoints that are compliant with the RTP specification [RFC3550] 528 will be able to decode the media streams they describe whether or not 529 they support explicit source descriptions. However, some deployed 530 RTP implementations may not actually support multiple media sources 531 in a media stream. Media senders MAY wish to restrict themselves to 532 a single source at a time unless they have some means of concluding 533 that the receivers of the media stream support source multiplexing. 535 10. Formal Grammar 537 This section gives a formal Augmented Backus-Naur Form (ABNF) 538 [RFC4234] grammar for each of the new media and source attributes 539 defined in this document. Grammars for existing session or media 540 attributes which have been extended to be source attributes are not 541 included. 543 ssrc-attr = "ssrc:" ssrc-id SP attribute 544 ; The base definition of "attribute" is in RFC 4566. 545 ; (It is the content of "a=" lines.) 546 ssrc-id = integer ; 0 - 2**32 - 1 548 attribute /= ssrc-attr 549 Figure 10: Syntax of the ssrc media attribute 551 ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id) 552 ; The definition of "semantics" is in RFC 3388. 553 ; (It is the type of grouping being done.) 555 attribute /= ssrc-group-attr 557 Figure 11: Syntax of the ssrc-group media attribute 559 cname-attr = "cname:" cname 560 cname = byte-string 561 ; Following the syntax conventions for CNAME as defined in RFC 3550. 562 ; The definition of "byte-string" is in RFC 4566. 564 attribute /= cname-attr 566 Figure 12: Syntax of the cname source attribute 568 previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id) 570 attribute /= previous-ssrc-attr 572 Figure 13: Syntax of the previous-ssrc source attribute 574 11. Security Considerations 576 All the security implications of RTP [RFC3550] and of SDP [RFC4566] 577 apply. Explicitly describing the multiplexed sources of an RTP media 578 stream does not appear to add any further security issues. 580 12. IANA Considerations 582 Add ssrc and ssrc-group in Section 4 as media-level attributes. 584 Define source-level IANA registry and populate it with source 585 attributes from Section 6. 587 13. References 588 13.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 594 with Session Description Protocol (SDP)", RFC 3264, 595 June 2002. 597 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 598 Schulzrinne, "Grouping of Media Lines in the Session 599 Description Protocol (SDP)", RFC 3388, December 2002. 601 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 602 Jacobson, "RTP: A Transport Protocol for Real-Time 603 Applications", STD 64, RFC 3550, July 2003. 605 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 606 Specifications: ABNF", RFC 4234, October 2005. 608 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 609 Description Protocol", RFC 4566, July 2006. 611 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 612 Session Description Protocol", RFC 4756, November 2006. 614 13.2. Informative References 616 [I-D.ietf-avt-rtcpssm] 617 Chesterfield, J., "RTCP Extensions for Single-Source 618 Multicast Sessions with Unicast Feedback", 619 draft-ietf-avt-rtcpssm-13 (work in progress), March 2007. 621 [I-D.ietf-avt-rtp-svc] 622 Wenger, S., "RTP Payload Format for SVC Video", 623 draft-ietf-avt-rtp-svc-01 (work in progress), March 2007. 625 [I-D.ietf-avt-topologies] 626 Westerlund, M. and S. Wenger, "RTP Topologies", 627 draft-ietf-avt-topologies-04 (work in progress), 628 February 2007. 630 [I-D.ietf-mmusic-ice] 631 Rosenberg, J., "Interactive Connectivity Establishment 632 (ICE): A Protocol for Network Address Translator (NAT) 633 Traversal for Offer/Answer Protocols", 634 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 636 [I-D.mehta-rmt-flute-sdp] 637 Mehta, H., "SDP Descriptors for FLUTE", 638 draft-mehta-rmt-flute-sdp-05 (work in progress), 639 January 2006. 641 [I-D.schierl-mmusic-layered-codec] 642 Wenger, S. and T. Schierl, "Signaling media decoding 643 dependency in Session Description Protocol (SDP)", 644 draft-schierl-mmusic-layered-codec-04 (work in progress), 645 June 2007. 647 [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to 648 Resource Reservation Flows", RFC 3524, April 2003. 650 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 651 Address Types (ANAT) Semantics for the Session Description 652 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 654 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 655 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 656 July 2006. 658 Appendix A. Open issues 660 o Does a separate IANA registry need to be defined for "ssrc-group" 661 semantics, distinct from "group" semantics? 662 o What additional SDP media-level attributes should be defined, in 663 this or other documents? 664 o Does there need to be some way of saying in SDP "I understand that 665 RTP media streams can contain multiple sources, and I'm prepared 666 to accept them"? 668 Appendix B. Changes From Earlier Versions 670 Note to the RFC-Editor: please remove this section prior to 671 publication as an RFC. 673 B.1. Changes From Draft -00 675 o Clarified that this document is expressly defining declarative 676 source descriptions, not source offer/answer or other information. 677 o Removed the definitions of the "information", "bandwidth", 678 "sendrecv", "sendonly", "recvonly", "inactive", "charset", 679 "sdplang", "lang", "framerate", and "quality" source attributes. 680 They are all unnecessary for source decodability, and to the 681 extent they are otherwise useful they are probably better handled 682 by RTCP Source Description (SDES) packets or feedback (AVPF) 683 messages. 684 o Added text to the Backward Compatibility and Security 685 Considerations sections. 687 Authors' Addresses 689 Jonathan Lennox 690 Layered Media, Inc. 691 433 Hackensack Avenue 692 Sixth Floor 693 Hackensack, NJ 07601 694 US 696 Email: jonathan@layeredmedia.com 698 Joerg Ott 699 Helsinki University of Technology (TKK) 700 Networking Laboratory 701 PO Box 3000 702 FIN-02015 TKK 703 Finland 705 Email: jo@acm.org 707 Thomas Schierl 708 Fraunhofer HHI 709 Einsteinufer 37 710 D-10587 Berlin 711 Germany 713 Phone: +49-30-31002-227 714 Email: schierl@hhi.fhg.de 716 Full Copyright Statement 718 Copyright (C) The IETF Trust (2007). 720 This document is subject to the rights, licenses and restrictions 721 contained in BCP 78, and except as set forth therein, the authors 722 retain all their rights. 724 This document and the information contained herein are provided on an 725 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 726 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 727 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 728 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 729 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 730 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 732 Intellectual Property 734 The IETF takes no position regarding the validity or scope of any 735 Intellectual Property Rights or other rights that might be claimed to 736 pertain to the implementation or use of the technology described in 737 this document or the extent to which any license under such rights 738 might or might not be available; nor does it represent that it has 739 made any independent effort to identify any such rights. Information 740 on the procedures with respect to rights in RFC documents can be 741 found in BCP 78 and BCP 79. 743 Copies of IPR disclosures made to the IETF Secretariat and any 744 assurances of licenses to be made available, or the result of an 745 attempt made to obtain a general license or permission for the use of 746 such proprietary rights by implementers or users of this 747 specification can be obtained from the IETF on-line IPR repository at 748 http://www.ietf.org/ipr. 750 The IETF invites any interested party to bring to its attention any 751 copyrights, patents or patent applications, or other proprietary 752 rights that may cover technology that may be required to implement 753 this standard. Please address the information to the IETF at 754 ietf-ipr@ietf.org. 756 Acknowledgment 758 Funding for the RFC Editor function is provided by the IETF 759 Administrative Support Activity (IASA).