idnits 2.17.1 draft-ietf-mmusic-sdp-source-attributes-02.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 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 842. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 849. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 855. 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 (October 31, 2008) is 5649 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) == Missing Reference: 'RFCXXXX' is mentioned on line 664, but not defined ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-17 == 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) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Lennox 3 Internet-Draft Vidyo 4 Intended status: Standards Track J. Ott 5 Expires: May 4, 2009 Helsinki University of Technology 6 T. Schierl 7 Fraunhofer HHI 8 October 31, 2008 10 Source-Specific Media Attributes in the Session Description Protocol 11 (SDP) 12 draft-ietf-mmusic-sdp-source-attributes-02 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 May 4, 2009. 39 Abstract 41 The Session Description Protocol provides mechanisms to describe 42 attributes of multimedia sessions and of individual media streams 43 (e.g., Real-time Transport Protocol (RTP) sessions) within a 44 multimedia session, but does not provide any mechanism to describe 45 individual media sources within a media stream. This document 46 defines a mechanism to describe RTP media sources, identified by 47 their Synchronization Source Identifiers (SSRCs), in SDP, associate 48 attributes with these sources, and express relationships among 49 sources. It also defines several source-level attributes which can 50 be used to describe properties of media sources. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Media Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. The "ssrc" Media Attribute . . . . . . . . . . . . . . . . 5 59 4.2. The "ssrc-group" Media Attribute . . . . . . . . . . . . . 6 60 5. Usage of Identified Source Identifiers in RTP . . . . . . . . 7 61 6. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. The "cname" Source Attribute . . . . . . . . . . . . . . . 9 63 6.2. The "previous-ssrc" Source Attribute . . . . . . . . . . . 9 64 6.3. The "fmtp" Source Attribute . . . . . . . . . . . . . . . 10 65 6.4. Other Source Attributes . . . . . . . . . . . . . . . . . 10 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 11 68 9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 69 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 13 73 12.2. Registry for Source-Level Attributes . . . . . . . . . . . 14 74 12.3. Registry for Source Grouping Semantics . . . . . . . . . . 15 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 17 79 A.1. Changes From Working Group Draft -01 . . . . . . . . . . . 17 80 A.2. Changes From Working Group Draft -00 . . . . . . . . . . . 17 81 A.3. Changes From Individual Submission Draft -01 . . . . . . . 17 82 A.4. Changes From Individual Submission Draft -00 . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 Intellectual Property and Copyright Statements . . . . . . . . . . 19 86 1. Introduction 88 The Session Description Protocol (SDP) [RFC4566] provides mechanisms 89 to describe attributes of multimedia sessions and of media streams 90 (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within 91 a multimedia session, but does not provide any mechanism to describe 92 individual media sources within a media stream. 94 Several recently-proposed protocols, notably RTP Single-Source 95 Multicast [I-D.ietf-avt-rtcpssm] have found it useful to describe 96 specific media sources in SDP messages. Single-source multicast, in 97 particular, needs to ensure that receivers' RTP Synchronization 98 Source Identifiers (SSRCs) do not collide with those of media 99 senders, as the RTP specification [RFC3550] requires that colliding 100 sources change their SSRC values after a collision has been detected. 101 Earlier work has used mechanisms specific to each protocol to 102 describe the individual sources of an RTP session. 104 Moreover, whereas the Real-Time Transport Protocol (RTP) [RFC3550] is 105 defined as allowing multiple sources in an RTP session (for example, 106 if a user has more than one camera), SDP has no existing mechanism 107 for an endpoint to indicate that it will be using multiple sources, 108 or to describe their characteristics individually. 110 To address all these problems, this document defines a mechanism to 111 describe RTP sources, identified by their Synchronization Sources 112 Identifiers (SSRCs), in SDP, associate attributes with these sources, 113 and express relationships among individual sources. It also defines 114 a number of new SDP attributes that apply to individual sources 115 ("source-level" attributes); describes how a number of existing media 116 stream ("media-level") attributes can also be applied at the source 117 level; and establishes IANA registries for source-level attributes 118 and source grouping semantics. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119] and 125 indicate requirement levels for compliant implementations. 127 3. Overview 129 In the Real-Time Transport Protocol (RTP) [RFC3550], an association 130 among a group of communicating participants is known as an RTP 131 Session. An RTP session is typically associated with a single 132 transport address (in the case of multicast) or communication flow 133 (in the case of unicast), though RTP translators and single-source 134 multicast [I-D.ietf-avt-rtcpssm] can make the situation more complex. 135 RTP topologies are discussed in more detail in [RFC5117]. 137 Within an RTP session, the source of a single stream of RTP packets 138 is known as a synchronization source (SSRC). Every synchronization 139 source is identified by a 32-bit numeric identifier. In addition, 140 receivers (who may never send RTP packets) also have source 141 identifiers, which are used to identify their RTP Control Protocol 142 (RTCP) receiver reports and other feedback messages. 144 Messages of the Session Description Protocol (SDP) [RFC4566], known 145 as Session Descriptions, describe Multimedia Sessions. A multimedia 146 session is a set of multimedia senders and receivers, and the data 147 streams flowing from senders to receivers. A multimedia session 148 contains a number of Media Streams, which are the individual RTP 149 sessions or other media paths over which one type of multimedia data 150 is carried. Information that applies to an entire multimedia session 151 is called Session-Level information, while information pertaining to 152 one media stream is called Media-Level information. The collection 153 of all the information describing a media stream is known as a Media 154 Description. (Media descriptions are also sometimes known informally 155 as SDP "m"-lines, after the SDP syntax that begins a media 156 description.) Several standard information elements are defined at 157 both the session level and the media level. Extended information can 158 be included at both levels through the use of attributes. 160 (The term "Media Stream" does not appear in the SDP specification 161 itself, but is used by a number of SDP extensions, for instance 162 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], 163 to denote the object described by an SDP media description. This 164 term is unfortunately rather confusing, as the RTP specification 165 [RFC3550] uses the term "media stream" to refer to an individual 166 media source or RTP packet stream, identified by an SSRC, whereas an 167 SDP media stream describes an entire RTP session, which can contain 168 any number of RTP sources. In this document, the term "media stream" 169 means an SDP media stream, i.e. the thing described by an SDP media 170 description, whereas "media source" is used for a single source of 171 media packets, i.e. an RTP media stream.) 173 The core SDP specification does not have any way of describing 174 individual media sources, in particular RTP synchronization sources, 175 within a media stream. To address this problem, in this document we 176 introduce a third level of information, called Source-Level 177 information. Syntactically, source-level information is described by 178 a new SDP media-level attribute "ssrc", which identifies specific 179 synchronization sources within an RTP session, and acts as a meta- 180 attribute mapping source-level attribute information to these 181 sources. 183 This document also defines an SDP media-level attribute "ssrc-group", 184 which can represent relationships among media sources within an RTP 185 session, in much the same way as the "group" attribute [RFC3388] 186 represents relationships among media streams within a multimedia 187 session. 189 4. Media Attributes 191 This section defines two media-level attributes, "ssrc" and "ssrc- 192 group". 194 4.1. The "ssrc" Media Attribute 196 a=ssrc: 197 a=ssrc: : 199 The SDP media attribute "ssrc" indicates a property (known as a 200 "source-level attribute") of a media source (RTP stream) within an 201 RTP session. is the synchronizaton source ID (SSRC) of the 202 source being described, interpreted as a 32-bit unsigned integer in 203 network byte order and represented in decimal. or 204 : represent the source-level attribute specific to 205 the given media source. The source-level attribute follows the 206 syntax of the SDP "a=" line. It thus consists either of a single 207 attribute name (a flag), or an attribute name and value, e.g. 208 "cname:user@example.com". No attributes of the former type are 209 defined by this document. 211 Within a media stream, ssrc attributes with the same value of 212 describe different attributes of the same media sources. 213 Across media streams, values are not correlated (unless 214 correlation is indicated by media-stream grouping or some other 215 mechanism) and MAY be repeated. 217 Each "ssrc" media attribute specifies a single source-level attribute 218 for the given . For each source mentioned in SDP, the 219 source-level attribute "cname", defined in Section 6.1, MUST be 220 provided. Any number of other source-level attributes for the source 221 MAY also be provided. 223 The "ssrc" media attribute MAY be used for any RTP-based media 224 transport. It is not defined for other transports. 226 If any other SDP attributes also mention RTP SSRC values (for 227 example, MIKEY [RFC3830][RFC4567]), the values used MUST be 228 consistent. (These attributes MAY provide additional information 229 about a source described by an "ssrc" attribute, or MAY describe 230 additional sources.) 232 Though the source-level attributes specified by the ssrc property 233 follow the same syntax as session-level and media-level attributes, 234 they are defined independently. All source-level attributes MUST be 235 registered with IANA, using the registry defined in Section 12.2. 237 Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form 238 (ABNF) [RFC5234] grammar for the ssrc attribute. 240 The "ssrc" media attribute is not dependent on charset. 242 4.2. The "ssrc-group" Media Attribute 244 a=ssrc-group: ... 246 The SDP media attribute "ssrc-group" expresses a relationship among 247 several sources of an RTP session. It is analogous to the "group" 248 session-level attribute [RFC3388], which expresses a relationship 249 among media streams in an SDP multimedia session (i.e., a 250 relationship among several logically related RTP sessions). As 251 sources are already identified by their SSRC IDs, no analogous 252 property to the "mid" attribute is necessary; groups of sources are 253 identified by their SSRC IDs directly. 255 The parameter is taken from the specification of the 256 "group" attribute [RFC3388]. The initial semantics values defined 257 for the ssrc-group attribute are FID (Flow Identification) [RFC3388] 258 and FEC (Forward Error Correction) [RFC4756]. In each case, the 259 relationship among the grouped sources is the same as the 260 relationship among corresponding sources in media streams grouped 261 using the SDP "group" attribute. 263 Though the "ssrc-group" semantics values follow the same syntax as 264 "group" semantics values, they are defined independently. All "ssrc- 265 group" semantics values MUST be registered with IANA, using the 266 registry defined in Section 12.3. 268 (The other "group" semantics registered with IANA as of this writing 269 are not useful for source grouping. LS (Lip Synchronization) 270 [RFC3388] is redundant for sources within a media stream, as RTP 271 sources with the same CNAME are implicitly synchronized in RTP. SRF 272 (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network 273 Address Types) [RFC4091] refer specifically to the media stream's 274 transport characteristics. CS (Composite Session) 275 [I-D.mehta-rmt-flute-sdp] is used to group FLUTE sessions, and so is 276 not applicable to RTP.) 278 The ssrc-group attribute indicates the sources in a group by listing 279 the s of the sources in the group. It MUST list at least 280 one for a group, and MAY list any number of additional 281 ones. Every listed in an ssrc-group attribute MUST be 282 defined by a corresponding "ssrc:" line in the same media 283 description. 285 The "ssrc-group" media attribute is not dependent on charset. 287 Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form 288 (ABNF) [RFC5234] grammar for the ssrc-group attribute. 290 5. Usage of Identified Source Identifiers in RTP 292 The synchronization source identifiers used in an RTP session are 293 chosen randomly and independently by endpoints. As such, it is 294 possible for two RTP endpoints to choose the same SSRC identifier. 295 Though the probability of this is low, the RTP specification 296 [RFC3550] requires that all RTP endpoints MUST be prepared to detect 297 and resolve collisions. 299 As a result, all endpoints MUST be prepared for the fact that 300 information about specific sources identified in a media stream might 301 be out of date. The actual binding between SSRCs and source CNAMEs 302 can only be identified by the source description (SDES) RTCP packets 303 transmitted on the RTP session. 305 When endpoints are choosing their own local SSRC values for media 306 streams for which source-level attributes have been specified, they 307 MUST NOT use for themselves any SSRC identifiers mentioned in media 308 descriptions they have received for the media stream. 310 However, sources identified by SDP source-level attributes do not 311 otherwise affect RTP transport logic. Specifically, sources which 312 are only known through SDP, for which neither RTP nor RTCP packets 313 have been received, MUST NOT be counted for RTP group size 314 estimation, and report blocks MUST NOT be sent for them in SR or RR 315 RTCP messages. 317 Endpoints MUST NOT assume that only the sources mentioned in SDP will 318 be present in an RTP session; additional sources, with previously 319 unmentioned SSRC IDs, can be added at any time, and endpoints MUST be 320 prepared to receive packets from these sources. (How endpoints 321 handle such packets is not specified here; they SHOULD be handled in 322 the same manner as packets from additional sources would be handled 323 had the endpoint not received any a=ssrc: attributes at all.) 325 An endpoint that observes an SSRC collision between its explicitly- 326 signaled source and another entity that has not explicitly signaled 327 an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by 328 5*1.5*Td, where Td is the deterministic calculated reporting interval 329 for receivers defined in Section 6.3.1 of the RTP specification 330 [RFC3550], to see whether the conflict still exists. (This gives 331 precedence to explicitly-signaled sources, and places the burden of 332 collision resolution on non-signaled sources.) SSRC collisions 333 between multiple explicitly-signaled sources, however, MUST be acted 334 upon immediately. 336 If, following RTP's collision-resolution procedures [RFC3550], a 337 source identified by source-level attributes has been forced to 338 change its SSRC identifier, the author of the SDP containing the 339 source-level attributes for these sources SHOULD send out an updated 340 SDP session description with the new SSRC, if the mechanism by which 341 SDP is being distributed for the multimedia session has a mechanism 342 to distribute updated SDP. This updated SDP MUST include a previous- 343 ssrc source-level attribute, described in Section 6.2, listing the 344 source's previous SSRC ID. (If only a single source with a given 345 CNAME has collided, the other RTP session members can infer a 346 correspondence between the source's old and new SSRC IDs, without 347 requiring an updated session description. However, if more than one 348 source collides at once, or if sources are leaving and re-joining, 349 this inference is not possible. To avoid confusion, therefore, 350 sending updated SDP messages is always RECOMMENDED.) 352 Endpoints MUST NOT reuse the same SSRC ID for identified sources with 353 same CNAME for at least the duration of the RTP session's participant 354 timeout interval (see Section 6.3.5 of [RFC3550]). They SHOULD NOT 355 reuse any SSRC ID ever mentioned in SDP (either by themselves or by 356 other endpoints) for the entire lifetime of the RTP session. 358 Endpoints MUST be prepared for the possibility that other parties in 359 the session do not understand SDP source-level attributes, unless 360 some higher-level mechanism normatively requires them. See Section 9 361 for more discussion of this. 363 6. Source Attributes 365 This section describes specific source attributes that can be applied 366 to RTP sources. 368 6.1. The "cname" Source Attribute 370 a=ssrc: cname: 372 The "cname" source attribute associates a media source with its 373 Canonical End-Point Identifier (CNAME) source description (SDES) 374 item. This MUST be the CNAME value that the media sender will place 375 in its RTCP SDES packets; it therefore MUST follow the syntax 376 conventions of CNAME defined in the RTP specification [RFC3550]. If 377 a session participant receives an RTCP SDES packet associating this 378 SSRC with a different CNAME, it SHOULD assume there has been an SSRC 379 collision, and that the description of the source that was carried in 380 the SDP description is not applicable to the actual source being 381 received. This source attribute is REQUIRED to be present if any 382 source attributes are present for a source. The cname attribute MUST 383 NOT occur more than once for the same ssrc-id within a given media 384 stream. 386 The "cname" source attribute is not dependent on charset. 388 Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form 389 (ABNF) [RFC5234] grammar for the cname attribute. 391 6.2. The "previous-ssrc" Source Attribute 393 a=ssrc: previous-ssrc: ... 395 The "previous-ssrc" source attribute associates a media source with 396 previous source identifiers used for the same media source. 397 Following an SSRC change due to an SSRC collision involving a media 398 source described in SDP, the updated session description describing 399 the source's new SSRC (described in Section 5) MUST include the 400 previous-ssrc attribute associating the new SSRC with the old one. 401 If further updated SDP descriptions are published describing the 402 media source, the previous-ssrc attribute SHOULD be included if the 403 session description was generated before the participant timeout of 404 the old SSRC, and MAY be included after that point. This attribute, 405 if present, MUST list at least one previous SSRC, and MAY list any 406 number of additional SSRCs for the source, if the source has collided 407 more than once. This attribute MUST be present only once for each 408 source. 410 The "previous-ssrc" source attribute is not dependent on charset. 412 Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form 413 (ABNF) [RFC5234] grammar for the previous-ssrc attribute. 415 6.3. The "fmtp" Source Attribute 417 a=ssrc: fmtp: 419 The "fmtp" source attribute allows format-specific parameters to be 420 conveyed about a given source. The parameter MUST be one of 421 the media formats (i.e., RTP payload types) specified for the media 422 stream. The meaning of the is unique 423 for each media type. This parameter MUST only be used for media 424 types for which source-level format parameters have explicitly been 425 specified; media-level format parameters MUST NOT be carried over 426 blindly. 428 The "fmtp" source attribute is not dependent on charset. 430 6.4. Other Source Attributes 432 This document only defines source attributes which are necessary or 433 useful for an endpoint to decode and render the sources in a media 434 stream. It does include any attributes which would contribute to an 435 endpoint's decision to accept or reject a stream, e.g. in an offer/ 436 answer exchange. Such attributes are for future consideration. 438 7. Examples 440 This section gives several examples of SDP descriptions of media 441 sessions containing source attributes. For brevity, only the media 442 sections of the descriptions are given. 444 m=audio 49168 RTP/AVP 0 445 a=ssrc:314159 cname:user@example.com 447 Figure 1: Example: declaration of a single synchronization source 449 The example in Figure 1 shows an audio stream advertising a single 450 source. 452 m=video 49170 RTP/AVP 96 453 a=rtpmap:96 H264/90000 454 a=ssrc:12345 cname:another-user@example.com 455 a=ssrc:67890 cname:another-user@example.com 457 Figure 2: Example: a media stream containing several independent 458 sources from a single session member. 460 The example in Figure 2 shows a video stream where one participant 461 (identified by a single CNAME) has several cameras. The sources 462 could be further distinguished by RTCP Source Description (SDES) 463 information. 465 m=video 49174 RTP/AVPF 96 98 466 a=rtpmap:96 H.264/90000 467 a=rtpmap:98 rtx/90000 468 a=fmtp:98 apt=96;rtx-time=3000 469 a=ssrc-group:FID 11111 22222 470 a=ssrc:11111 cname:user3@example.com 471 a=ssrc:22222 cname:user3@example.com 472 a=ssrc-group:FID 33333 44444 473 a=ssrc:33333 cname:user3@example.com 474 a=ssrc:44444 cname:user3@example.com 476 Figure 3: Example: relationship among several sources: retransmission 477 sources 479 The example in Figure 3 shows how the relationships among sources 480 used for RTP Retransmission [RFC4588] can be explicitly signaled. 481 This prevents the complexity of associating original sources with 482 retransmission sources when SSRC multiplexing is used for RTP 483 retransmission, as is described in Section 5.3 of [RFC4588]. 485 8. Usage With the Offer/Answer Model 487 When used with the SDP Offer/Answer Model [RFC3264], SDP source- 488 specific attributes describe only the sources with which each party 489 is willing to send (whether it is sending RTP data or RTCP report 490 blocks). No mechanism is provided by which an answer can accept or 491 reject individual sources within a media stream; if the set of 492 sources in a media stream is unacceptable, the answerer's only option 493 is to reject the media stream or the entire multimedia session. 495 The SSRC IDs for sources described by an SDP answer MUST be distinct 496 from the SSRC IDs for sources of that media stream in the offer. 497 Similarly, new SSRC IDs in an updated offer MUST be distinct from the 498 ssrc IDs for that media stream established in the most recent offer/ 499 answer exchange for the session, and SHOULD be distinct from any SSRC 500 ID ever used by either party within the multimedia session (whether 501 or not it is still being used). 503 9. Backward Compatibility 505 According to the defintion of SDP, interpreters of SDP session 506 descriptions ignore unknown attributes. Thus, endpoints MUST be 507 prepared that recipients of their RTP media session may not 508 understand their explicit source descriptions, unless some external 509 mechanism indicates that they were understood. In some cases (such 510 as RTP Retransmission [RFC4588]) this may constrain some choices 511 about the bitstreams that are transmitted. 513 Source descriptions are specified in this document such that RTP 514 endpoints that are compliant with the RTP specification [RFC3550] 515 will be able to decode the media streams they describe whether or not 516 they support explicit source descriptions. However, some deployed 517 RTP implementations may not actually support multiple media sources 518 in a media stream. Media senders MAY wish to restrict themselves to 519 a single source at a time unless they have some means of concluding 520 that the receivers of the media stream support source multiplexing. 522 10. Formal Grammar 524 This section gives a formal Augmented Backus-Naur Form (ABNF) 525 [RFC5234] grammar for each of the new media and source attributes 526 defined in this document. Grammars for existing session or media 527 attributes which have been extended to be source attributes are not 528 included. 530 ssrc-attr = "ssrc:" ssrc-id SP attribute 531 ; The base definition of "attribute" is in RFC 4566. 532 ; (It is the content of "a=" lines.) 533 ssrc-id = integer ; 0 - 2**32 - 1 535 attribute =/ ssrc-attr 537 Figure 4: Syntax of the ssrc media attribute 539 ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id) 540 ; The definition of "semantics" is in RFC 3388. 541 ; (It is the type of grouping being done.) 543 attribute =/ ssrc-group-attr 545 Figure 5: Syntax of the ssrc-group media attribute 547 cname-attr = "cname:" cname 548 cname = byte-string 549 ; Following the syntax conventions for CNAME as defined in RFC 3550. 550 ; The definition of "byte-string" is in RFC 4566. 552 attribute =/ cname-attr 554 Figure 6: Syntax of the cname source attribute 556 previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id) 558 attribute =/ previous-ssrc-attr 560 Figure 7: Syntax of the previous-ssrc source attribute 562 11. Security Considerations 564 All the security implications of RTP [RFC3550] and of SDP [RFC4566] 565 apply. Explicitly describing the multiplexed sources of an RTP media 566 stream does not appear to add any further security issues. 568 12. IANA Considerations 570 12.1. New SDP Media-Level Attributes 572 This document defines two SDP media-level attributes: "ssrc" and 573 "ssrc-group". These attributes should be registered by IANA under 574 "Session Description Protocol (SDP) Parameters" under "att-field 575 (media level only)". 577 The "ssrc" attribute is used to identify characteristics of media 578 sources within a media stream. Its format is defined in Section 4.1. 580 The "ssrc-group" attribute is used to identify relationships among 581 media sources within a media stream. Its format is defined in 582 Section 4.2. 584 12.2. Registry for Source-Level Attributes 586 This specification creates a new IANA registry named "att-field 587 (source level)" within the SDP parameters registry. Source 588 attributes MUST be registered with IANA and documented, under the 589 same rules as for SDP session-level and media-level attributes as 590 specified in [RFC4566]: 592 New attribute registrations are accepted according to the 593 "Specification Required" policy of [RFC5226], provided that the 594 specification includes the following information: 596 o contact name, email address, and telephone number 597 o attribute name (as it will appear in SDP) 598 o long-form attribute name in English 599 o whether the attribute value is subject to the charset attribute 600 o a one-paragraph explanation of the purpose of the attribute 601 o a specification of appropriate attribute values for this attribute 603 The above is the minimum that IANA will accept. Attributes that are 604 expected to see widespread use and interoperability SHOULD be 605 documented with a standards-track RFC that specifies the attribute 606 more precisely. 608 Submitters of registrations should ensure that the specification is 609 in the spirit of SDP attributes, most notably that the attribute is 610 platform independent in the sense that it makes no implicit 611 assumptions about operating systems and does not name specific pieces 612 of software in a manner that might inhibit interoperability. 614 Source-level attributes which are substantially similar in semantics 615 to existing session-level or media-level attributes SHOULD re-use the 616 same attribute name as those session-level or media-level attributes. 617 Source-level attributes SHOULD NOT re-use attribute names of session- 618 level or media-level attributes that are unrelated or substantially 619 different. 621 The initial set of source attribute names, with definitions in 622 Section 6 of this document, is in Figure 8. 624 Type SDP Name Reference 625 ---- ------------------ --------- 626 att-field (source level) 627 cname [RFCXXXX] 628 previous-ssrc [RFCXXXX] 629 fmtp [RFCXXXX] 631 Figure 8: Initial Contents of IANA Source Attribute Registry 633 (Note to the RFC-Editor: please replace "XXXX" with the number of 634 this document prior to publication as an RFC.) 636 12.3. Registry for Source Grouping Semantics 638 This specification creates a new IANA registry named "Semantics for 639 the "ssrc-group" SDP Attribute" within the SDP parameters registry. 640 Source group semantics MUST be defined in standards-track RFCs, under 641 the same rules as [RFC3388]: 643 The IANA Considerations section of the RFC MUST include the following 644 information, which appears in the IANA registry along with the RFC 645 number of the publication. 647 o A brief description of the semantics. 648 o Token to be used within the group attribute. This token may be of 649 any length, but SHOULD be no more than four characters long. 650 o Reference to an standards track RFC. 652 Source grouping semantics values which are substantially similar to 653 existing media grouping semantics values SHOULD re-use the same 654 semantics name as that media gropuing semantics. Source grouping 655 semantics SHOULD NOT re-use source grouping semantics names that are 656 unrelated or substantially different. 658 The initial set of source grouping semantics values, for the 659 semantics specified in Section 4.2 of this document, is in Figure 9. 661 Semantics Token Reference 662 ------------------- ----- --------- 663 Flow Identification FID [RFCXXXX] 664 Forward Error Correction FEC [RFCXXXX] 666 Figure 9: Initial Contents of IANA Source Group Semantics Registry 668 (Note to the RFC-Editor: please replace "XXXX" with the number of 669 this document prior to publication as an RFC.) 671 13. References 673 13.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, March 1997. 678 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 679 with Session Description Protocol (SDP)", RFC 3264, 680 June 2002. 682 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 683 Schulzrinne, "Grouping of Media Lines in the Session 684 Description Protocol (SDP)", RFC 3388, December 2002. 686 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 687 Jacobson, "RTP: A Transport Protocol for Real-Time 688 Applications", STD 64, RFC 3550, July 2003. 690 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 691 Description Protocol", RFC 4566, July 2006. 693 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 694 Session Description Protocol", RFC 4756, November 2006. 696 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 697 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 698 May 2008. 700 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 701 Specifications: ABNF", STD 68, RFC 5234, January 2008. 703 13.2. Informative References 705 [I-D.ietf-avt-rtcpssm] 706 Ott, J., "RTCP Extensions for Single-Source Multicast 707 Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 708 (work in progress), January 2008. 710 [I-D.ietf-mmusic-ice] 711 Rosenberg, J., "Interactive Connectivity Establishment 712 (ICE): A Protocol for Network Address Translator (NAT) 713 Traversal for Offer/Answer Protocols", 714 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 716 [I-D.mehta-rmt-flute-sdp] 717 Mehta, H., "SDP Descriptors for FLUTE", 718 draft-mehta-rmt-flute-sdp-05 (work in progress), 719 January 2006. 721 [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to 722 Resource Reservation Flows", RFC 3524, April 2003. 724 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 725 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 726 August 2004. 728 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 729 Address Types (ANAT) Semantics for the Session Description 730 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 732 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 733 Carrara, "Key Management Extensions for Session 734 Description Protocol (SDP) and Real Time Streaming 735 Protocol (RTSP)", RFC 4567, July 2006. 737 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 738 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 739 July 2006. 741 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 742 January 2008. 744 Appendix A. Changes From Earlier Versions 746 Note to the RFC-Editor: please remove this section prior to 747 publication as an RFC. 749 A.1. Changes From Working Group Draft -01 751 o Updated reference to RFC 2434 to [RFC5226]. 753 A.2. Changes From Working Group Draft -00 755 o Removed discussion of ssrc-multiplexing for layered codecs. 756 o Clarified that each "ssrc" attribute specifies only a single 757 source-level attribute. 758 o Clarified that "ssrc-group" semantics are defined separately from 759 "group" semantics. 760 o Clarified reference for the Td parameter. 761 o Updated references. 762 o Corrected typographical errors. 764 A.3. Changes From Individual Submission Draft -01 766 o Added definitions of the new IANA registries and registrations 767 needed. 768 o Clarified that none of the attributes defined in the document are 769 dependent on the charset attribute. 770 o Clarified that ssrc attributes must be consistent with other SDP 771 mechanisms (such as MIKEY) that also specify SSRCs. 772 o Removed open issues section. 774 A.4. Changes From Individual Submission Draft -00 776 o Clarified that this document is expressly defining declarative 777 source descriptions, not source offer/answer or other information. 778 o Removed the definitions of the "information", "bandwidth", 779 "sendrecv", "sendonly", "recvonly", "inactive", "charset", 780 "sdplang", "lang", "framerate", and "quality" source attributes. 781 They are all unnecessary for source decodability, and to the 782 extent they are otherwise useful they are probably better handled 783 by RTCP Source Description (SDES) packets or feedback (AVPF) 784 messages. 785 o Added text to the Backward Compatibility and Security 786 Considerations sections. 788 Authors' Addresses 790 Jonathan Lennox 791 Vidyo, Inc. 792 433 Hackensack Avenue 793 Sixth Floor 794 Hackensack, NJ 07601 795 US 797 Email: jonathan@vidyo.com 799 Joerg Ott 800 Helsinki University of Technology (TKK) 801 Networking Laboratory 802 PO Box 3000 803 FIN-02015 TKK 804 Finland 806 Email: jo@acm.org 808 Thomas Schierl 809 Fraunhofer HHI 810 Einsteinufer 37 811 D-10587 Berlin 812 Germany 814 Phone: +49-30-31002-227 815 Email: schierl@hhi.fhg.de 817 Full Copyright Statement 819 Copyright (C) The IETF Trust (2008). 821 This document is subject to the rights, licenses and restrictions 822 contained in BCP 78, and except as set forth therein, the authors 823 retain all their rights. 825 This document and the information contained herein are provided on an 826 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 827 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 828 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 829 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 830 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 831 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 833 Intellectual Property 835 The IETF takes no position regarding the validity or scope of any 836 Intellectual Property Rights or other rights that might be claimed to 837 pertain to the implementation or use of the technology described in 838 this document or the extent to which any license under such rights 839 might or might not be available; nor does it represent that it has 840 made any independent effort to identify any such rights. Information 841 on the procedures with respect to rights in RFC documents can be 842 found in BCP 78 and BCP 79. 844 Copies of IPR disclosures made to the IETF Secretariat and any 845 assurances of licenses to be made available, or the result of an 846 attempt made to obtain a general license or permission for the use of 847 such proprietary rights by implementers or users of this 848 specification can be obtained from the IETF on-line IPR repository at 849 http://www.ietf.org/ipr. 851 The IETF invites any interested party to bring to its attention any 852 copyrights, patents or patent applications, or other proprietary 853 rights that may cover technology that may be required to implement 854 this standard. Please address the information to the IETF at 855 ietf-ipr@ietf.org.