idnits 2.17.1 draft-lennox-mmusic-sdp-source-selection-04.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 (March 12, 2012) is 4427 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 636, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 H. Schulzrinne 5 Expires: September 13, 2012 Columbia U. 6 March 12, 2012 8 Mechanisms for Media Source Selection in the Session Description 9 Protocol (SDP) 10 draft-lennox-mmusic-sdp-source-selection-04 12 Abstract 14 Source-specific media attributes in the Session Description Protocol 15 (SDP) allow endpoints to describe Real-Time Transport Protocol (RTP) 16 sources within a media stream. This document extends that mechanism 17 by defining how participants in a multimedia session can request 18 specific sources from a remote party. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 13, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. The "remote-ssrc" Media Attribute . . . . . . . . . . . . . . 5 59 6. Remote Source Attributes . . . . . . . . . . . . . . . . . . . 6 60 6.1. The "recv" Remote Source-Level Attribute . . . . . . . . . 6 61 6.2. The "framerate" Remote Source Attribute . . . . . . . . . 7 62 6.3. The "imageattr" Remote Source Attribute . . . . . . . . . 8 63 6.4. The "priority" Remote Source Attribute . . . . . . . . . . 8 64 7. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. The "information" Source Attribute . . . . . . . . . . . . 9 66 7.2. The "sending" Source-Level Attribute . . . . . . . . . . . 9 67 8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 10 68 9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 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. New SDP Source-Level Attributes . . . . . . . . . . . . . 13 74 12.3. Registry for Remote Source-Level Attributes . . . . . . . 14 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 16 79 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 16 80 B.1. Changes From Individual Submission Draft -03 . . . . . . . 16 81 B.2. Changes From Individual Submission Draft -02 . . . . . . . 16 82 B.3. Changes From Individual Submission Draft -01 . . . . . . . 16 83 B.4. Changes From Individual Submission Draft -00 . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 The source-attribute specification [RFC5576] provides declarative 89 definitions for Real-Time Protocol (RTP) [RFC3550] media sources in 90 the Session Description Protocol (SDP) [RFC4566]. 92 In some architectures (such as those described in Section 3), it is 93 useful to provide the capability for endpoints to request specific 94 sources of a remote party, asking the sender to selectively enable or 95 disable them, and to specify characteristics of the sources 96 requested. To accomplish this, this document defines a new media 97 attribute, "remote-ssrc", which allows a receiver to indicate that it 98 wishes to receive a remote source, and also allows it to specify 99 attributes of the remote source. This document defines several such 100 remote source attributes: "recv" and "preference" which are 101 applicable to any media type, and "framerate" and "imageattr" which 102 are specific to video sources. Currently no attributes are defined 103 that are specific to audio or other media types. 105 Additionally, several new declarative ([RFC5576]) source attributes 106 are defined: "information", providing human-readable information 107 about a local source, and "sending", which is complementary to the 108 "recv" remote source attribute. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119] and 115 indicate requirement levels for compliant implementations. 117 3. Architecture 119 The primary use envisioned for this mechanism is for multimedia 120 conferences controlled by a central system. This is similar to the 121 topologies described by RTP Topologies [RFC5117] as Topo-Mixer, Topo- 122 Video-switch-MCU, or Topo-RTCP-terminating-MCU (depending on the 123 treatment of RTCP), with one crucial difference: rather than only 124 forwarding either a single media source, or an MCU-mixed media 125 source, to receivers, the central mixer can instead simultaneously 126 forward multiple media sources independently to each receiver, as 127 constrained by available bandwidth. 129 In this architecture, the conference server can notify each 130 participant as sources become available in the conference. 131 Participants can then either explicitly request sources from the 132 server, or allow the server to choose which sources to forward based 133 on its own criteria and policy. A hybrid mode is also possible, in 134 which participants explicitly request some sources while allowing the 135 server to choose others. 137 Receivers can specify parameters for how they wish to view sources, 138 e.g., the image size or frame rate in which they will display video 139 sources. They can also specify priority among sources in case the 140 server has insufficient bandwidth to send them all. 142 When the first receiver starts viewing a source, the conference 143 server tells the sender to start sending it; prior to this, the 144 sender does not send it. Similarly, when the last receiver stops 145 viewing a source, the server tells the sender to stop sending it. 147 For large conferences, sending each conference source over a separate 148 RTP session, each with its own m= line, would not be practical, due 149 to issues such as server port consumption, NAT binding exhaustion, 150 and ICE setup time. Thus, sources of the same media type are instead 151 sent over a single RTP session, distinguished by their SSRC. This 152 document defines the source negotiation mechanisms needed in SDP to 153 enable the mechanisms defined in this architecture. 155 4. Overview 157 This mechanism builds upon the declarative source definitions defined 158 in [RFC5576]. That document defines how to describe individual RTP 159 sources within an RTP session in SDP. Each source is identified by 160 its Synchronization Source (SSRC) identifier, and is associated with 161 its CNAME (canonical-name) SDP attribute. 163 To enable the architecture defined in Section 3, this document 164 defines a complementary SDP media attribute which allows the receiver 165 of some RTP sources to let the the sources' sender know which sources 166 the receiver would like to receive. This attribute, "remote-ssrc", 167 is defined in Section 5. 169 A simple example SDP exchange using this mechanism is shown in 170 Figure 1 and Figure 2. For brevity, only the relevant portions of 171 the media sections of the SDP descriptions are given. 173 m=video 49168 RTP/AVP 96 174 a=rtpmap:96 H264/90000 175 a=ssrc:12345 cname:user1@host1.example.com 176 a=ssrc:67890 cname:user2@host2.example.com 178 Figure 1: Notification of media sources 180 In Figure 1 an SDP description indicates, using the mechanisms of 181 [RFC5576], two sources that are available in an RTP session. 183 m=video 49170 RTP/AVP 96 184 a=rtpmap:96 H264/90000 185 a=remote-ssrc:12345 recv:on 186 a=remote-ssrc:12345 imageattr:* [x=720,y=576] 187 a=remote-ssrc:12345 framerate:15 189 Figure 2: Request for a media source. 191 In Figure 2 an SDP description sent in response requests that a 192 specific source be sent, with resolution 720 by 576 and a framerate 193 of 15 frames per second. 195 5. The "remote-ssrc" Media Attribute 197 The "remote-ssrc" SDP media-level attribute allows a receiver to 198 requested a specific a remote source. 200 a=remote-ssrc: 201 a=remote-ssrc: : 203 The SDP media attribute "remote-ssrc" indicates a property, known as 204 a "remote source-level attribute", of a remote media source (RTP 205 stream) within an RTP session. is the synchronization 206 source ID (SSRC) of the remote source being described, interpreted as 207 a 32-bit unsigned integer in network byte order and represented in 208 decimal. or : represent the source- 209 level receive attribute specific to the given remote media source. 210 The source-level receive attribute follows the syntax of the SDP "a=" 211 line. It thus consists either of a single attribute name (a flag), 212 or an attribute name and value, e.g., "framerate:30". No attributes 213 of the former type are defined by this document. The order of 214 multiple "remote-ssrc" media attributes within an SDP message is not 215 significant. 217 These remote source IDs correspond to sources in the RTP session that 218 may be sent by other session members. The author of the SDP message 219 may have learned about these sources by observing them in the RTP 220 session (either by receiving RTP packets or seeing RTCP reports about 221 them), from earlier SDP messages containing "ssrc" attributes 222 describing the sources, or from other means such as the SIP 223 conference event package [RFC4575] or the XCON conference event 224 package [I-D.ietf-xcon-event-package]. 226 The "remote-ssrc" media attribute may be used for any RTP-based media 227 transport. It is not defined for other transport protocols. 229 Though the remote source attributes specified by the "remote-ssrc" 230 property follow the same syntax as (local) source attributes, they 231 are defined independently. All remote source attributes MUST be 232 registered with IANA, using the registry defined in Section 12.3. 234 Figure 3 in Section 10 gives a formal Augmented Backus-Naur Form 235 (ABNF) [RFC5234] grammar for the ssrc attribute. 237 The "remote-ssrc" media attribute does not (itself) depend on the SDP 238 charset, though specific remote source attributes may be defined to 239 be. 241 6. Remote Source Attributes 243 This section defines several specific remote source-level attributes 244 that can be applied to RTP sources. 246 6.1. The "recv" Remote Source-Level Attribute 248 a=remote-ssrc: recv: 250 The "recv" remote source attribute indicates whether the author of an 251 SDP message is interested in receiving a source. A "recv" remote 252 source attribute with a value of "on" indicates a source that 253 the author of an SDP message is interested in receiving. Similarly, 254 a "recv" remote source attribute with a value of "off" 255 indicates a source that the author of an SDP message is not 256 interested in receiving. There MUST be at most one "recv" remote 257 source-level attribute per remote media source. A "recv" attribute 258 with a value other than "on" or "off" MUST be ignored (for 259 future extensibility). 261 If the media stream containing the source has the media attributes 262 "sendonly" or "inactive", the SDP message MUST NOT list any remote 263 sources with a "recv" attribute with the "on" for that media 264 stream. 266 If "remote-ssrc" attributes are given for a particular remote source, 267 but "recv" is not specified for it, "recv:on" is the default if the 268 media stream is "sendrecv" or "recvonly". 270 If no remote-ssrc attributes at all are listed for a particular 271 remote source, the choice of whether to send it is left at the 272 sender's discretion. However, for sources associated in with an 273 "ssrc-group" [RFC5576], any unlisted sources of a group SHOULD be 274 treated the same as any listed ones if the requests are consistent, 275 unless the semantics specified for the "ssrc-group" dictates 276 otherwise. 278 Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form 279 (ABNF) [RFC5234] grammar for the "recv" attribute. 281 Section 8 describes how the "recv" remote source attribute is used 282 with SDP offer/answer [RFC3264]. 284 The "recv" remote source attribute does not depend on the SDP 285 charset. 287 6.2. The "framerate" Remote Source Attribute 289 a=remote-ssrc: framerate: 291 The "framerate" remote source-level attribute gives the maximum frame 292 rate, in frames per second, which the receiver of a video source 293 would like receive for the video. Higher framerates are likely not 294 to be useful to the receiver. This attribute is analogous in 295 function and syntax to the SDP "framerate" media attribute [RFC4566]. 296 Decimal representations of fractional values using the notation 297 "." are allowed. The frame rate specified MUST be 298 greater than zero. 300 The "framerate" attribute is advisory; a sender MAY send a framerate 301 other than that requested by the receiver if it is not able to send 302 the framerate required. The sender SHOULD attempt to come as close 303 as it can to the requested framerate, subject to other constraints of 304 the system. 306 The "framerate" attribute is defined only for video media. There 307 MUST be at most one "framerate" remote source attribute per remote 308 media source. The "framerate" requested MUST NOT be inconsistent 309 with any fmtp parameters specified for the media stream's payload 310 types. 312 Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form 313 (ABNF) [RFC5234] grammar for the "framerate" attribute. 315 The "framerate" remote source attribute does not depend on the SDP 316 charset. 318 6.3. The "imageattr" Remote Source Attribute 320 a=remote-ssrc: imageattr: 322 The "imageattr" remote source-level attribute describes the image 323 resolution and other image characteristics with which a video source 324 would like receive the video. Larger resolutions are likely not to 325 be useful to the receiver. It is analogous in function and syntax to 326 the "recv" portion of the SDP "imageattr" media attribute [RFC6236]. 328 The "imageattr" attribute is advisory; a sender MAY send a resolution 329 other than that requested by the receiver if it is not able to send 330 the resolution required. The sender SHOULD attempt to come as close 331 as it can to the requested resolution, subject to other constraints 332 of the system. 334 Different image attributes MAY be defined per payload type defined in 335 the media stream. The parameter MAY either be one of the media 336 formats (RTP payload types) specified for the media stream, or the 337 character "*" indicating that the "imageattr" attribute applies to 338 all payload types of the session. 340 The parameter gives a list of resolutions and image 341 aspect ratios with which the receiver wishes to display the source. 342 It is described in detail in [RFC6236]. 344 The "imageattr" attribute is defined only for video media. There 345 MUST be at most one "imageattr" remote source attribute per payload 346 type per remote media source. If an "imageattr" attribute is present 347 with a PT value of "*", it MUST be the only "imageattr" attribute 348 defined for that remote media source. The "imageattr" requested MUST 349 NOT be inconsistent with any fmtp parameters specified for the media 350 stream's payload types. 352 Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form 353 (ABNF) [RFC5234] grammar for the "imageattr" attribute. 355 The "imageattr" remote source attribute does not depend on the SDP 356 charset. 358 6.4. The "priority" Remote Source Attribute 360 a=remote-ssrc: priority: 361 The "priority" remote source-level attribute gives the relative 362 priority among the remote sources requested by a receiver. The 363 parameter is a non-negative decimal integer indicating 364 which streams should be given higher preference if the sender 365 determines that there is insufficient bandwidth (or other resource) 366 available to transmit all the requested streams. Larger numbers 367 indicate a greater priority. Priority values MUST be less than 2**31 368 - 1, but otherwise their specific values have no semantic 369 significance. 371 Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form 372 (ABNF) [RFC5234] grammar for the "priority" attribute. 374 The "priority" remote source attribute does not depend on the SDP 375 charset. 377 7. Source Attributes 379 This section describes sending source attributes that a sender can 380 use to describe RTP sources. 382 7.1. The "information" Source Attribute 384 a=ssrc: information: 386 The "information" source attribute provides textual information about 387 a source. It is analogous in function and syntax to the SDP "i=" 388 field for session and media information. There MUST be at most one 389 "information" source attribute per media source. If the "charset" 390 attribute is present at the session or media level, it specifies the 391 character set used in the source description. If the "charset" 392 attribute is not present, the "information" attribute MUST contain 393 ISO 10646 characters in UTF-8 encoding. 395 The "information" attribute is intended to provide a free-form human- 396 readable description of a media source. It is not suitable for 397 parsing by automata. 399 Figure 8 in Section 10 gives a formal Augmented Backus-Naur Form 400 (ABNF) [RFC5234] grammar for the "information" attribute. 402 7.2. The "sending" Source-Level Attribute 404 a=ssrc: sending: 405 The "sending" remote source attribute indicates whether the author of 406 an SDP message is interested in currently actively sending a source, 407 due to it having been requested by the other party with a "recv" 408 remote source attribute in an SDP offer/answer exchange. A "sending" 409 source attribute with a value of "on" indicates a source that 410 the author of an SDP message is currently actively sending, due to it 411 having been requested by the other party with a "recv:on" remote 412 source attribute. Similarly, the "sending" source attribute with a 413 value of "off" indicates a source that the other party has 414 rejected with a previous the "recv:off" remote source attribute, or 415 that the author of the SDP message is no longer interested in 416 sending. There MUST be at most one "sending" source-level attribute 417 per media source. Sources which were not listed with "recv-ssrc" in 418 the previous offer or answer SHOULD NOT have a "sending" attribute 419 included. The "sending" attribute is only defined in the context of 420 SDP offer/answer [RFC3264]. A "sending" attribute with a 421 value other than "on" or "off" MUST be ignored (for future 422 extensibility). 424 If the media stream containing the source has the media attributes 425 "recvonly" or "inactive", the stream MUST NOT list any sources with 426 the "sending" attribute with the on. 428 A source that is indicated in an offer or answer with "sending:off" 429 SHOULD still be considered a member of the RTP session, and thus RTCP 430 SHOULD be sent for it, unless it has left the RTP session (with an 431 RTCP BYE message) subsequent to the sending of the offer or answer. 433 Figure 9 in Section 10 gives a formal Augmented Backus-Naur Form 434 (ABNF) [RFC5234] grammar for the "sending" attribute. 436 Further description of how the "sending" source attribute is used 437 with SDP offer/answer [RFC3264] is given in Section 8. 439 The "sending" source attribute is not dependent on charset. 441 8. Usage With the Offer/Answer Model 443 When used with the SDP Offer/Answer Model [RFC3264], the "remote- 444 ssrc" attribute MAY be included either in an SDP offer or answer. 445 Both offers and answers MAY contain both "ssrc" and "remote-ssrc" 446 media attributes. 448 If "remote-ssrc" attributes are present in an SDP offer, the answerer 449 (if it accepts the offer) MUST include all the remotely-requested 450 active sources in "ssrc" attributes in its answer, except for any 451 sources which are no longer available when the answer is sent. If 452 "remote-ssrc" attributes are present in an answer, no immediate 453 update to SDP is necessary; however, if the endpoint subsequently 454 sends a new SDP offer, it SHOULD include all the remotely-requested 455 sources from the previous offer/answer exchange, unless those sources 456 are no longer available. In both cases, remote sources with the 457 "recv:on" remote source attribute included (implicitly or explicitly) 458 MUST be listed in the next response -- with the "sending:on" local 459 source attribute if the sender accepted the request to send the 460 source, or "sending:off" if the sender does not wish to send the 461 source. Remote sources with the "recv:off" remote source attribute 462 MUST have the "sending:off" local source attribute. If the send/recv 463 mode of the media stream has changed to "recvonly" or "inactive", 464 sources MUST NOT be listed with the "sending:on" attribute, and thus 465 all remotely-requested sources MUST be listed as "sending:off" 466 instead. 468 If a sender receives a "recv:on" in an answer and does not wish to 469 send the source, it SHOULD send a updated offer with "sending:off" as 470 soon as is practical. If a sender wishes to stop sending a source 471 for which its previous offer or answer had included "sending:on", it 472 SHOULD send an updated offer with "sending:off" as soon as practical, 473 and MUST include "sending:off" for the source in its next offer or 474 answer (assuming the source is still in the session, and it still 475 wishes not to send the source by the time of the offer or answer). 477 In general, all participants in an offer/answer exchange SHOULD list 478 all currently available sources, unless information about available 479 sources is being provided through some other mechanism, such as the 480 SIP conference event package [RFC4575] or the XCON conference event 481 package [I-D.ietf-xcon-event-package]. (Because these event packages 482 support partial updates, whereas SDP does not, source notification 483 through event packages can be more efficient, where applicable, than 484 SDP can be.) In the latter case sources that were not explicitly 485 requested in the most recent SDP offer or answer MAY be omitted. 487 9. Backward Compatibility 489 The default behavior, for remote sources which are listed neither as 490 "recv:on" nor "recv:off", is that whether sources are to be sent is 491 left to the sender's discretion. This is also the implicit behavior 492 for standard RTP; thus, a device does not need to know, upon 493 receiving an SDP message containing no "remote-ssrc" attributes, 494 whether its peer does not understand the "remote-ssrc" attribute at 495 all, or is simply choosing to leave source selection up to the 496 sender's discretion. 498 Because offer/answer exchanges are required to include "sending" 499 source attributes in response to previous "recv" remote source 500 attributes, it is possible to determine based on an SDP answer, or on 501 a subsequent offer/answer exchange, whether the peer understands the 502 "remote-ssrc" attribute. 504 10. Formal Grammar 506 This section gives a formal Augmented Backus-Naur Form (ABNF) 507 [RFC5234] grammar for each of the new media and source attributes 508 defined in this document. Grammars for existing session or media 509 attributes which have been extended to be source attributes are not 510 included. 512 remote-ssrc-attr = "remote-ssrc:" ssrc-id SP attribute 513 ; The base definition of "attribute" is in RFC 4566. 514 ; (It is the content of "a=" lines.) 515 ssrc-id = integer ; 0 .. 2**32 - 1 517 attribute =/ remote-ssrc-attr 519 Figure 3: Syntax of the "remote-ssrc" media attribute 521 recv-attr = "recv:" recv-state 523 recv-state = "on" / "off" / token 525 attribute =/ recv-attr 527 Figure 4: Syntax of the "recv" and "inactive" receive source 528 attributes 530 framerate-attr = "framerate:" integer [ "." 1*DIGIT ] 532 attribute =/ framerate-attr 534 Figure 5: Syntax of the "framerate" receive source attribute 536 imageattr-attr = "imageattr:" PT WSP attr_list 537 ; The definition of PT and attr_list are in 538 ; [RFC6236] 540 attribute =/ imageattr-attr 542 Figure 6: Syntax of the "imageattr" receive source attribute 544 priority-attr = "priority:" integer 546 attribute =/ priority-attr 548 Figure 7: Syntax of the "priority" receive source attribute 550 information-attr = "information:" text 551 ; The definition of text is in [RFC4566] 553 attribute =/ information-attr 555 Figure 8: Syntax of the "information" source attribute 557 sending-attr = "sending:" sending-state 559 sending-state = "on" / "off" / token 561 attribute =/ sending-attr 563 Figure 9: Syntax of the "sending" and "inactive" source attributes 565 11. Security Considerations 567 All the security considerations of RTP [RFC3550] and of SDP [RFC4566] 568 apply. Explicitly requesting sources of an RTP media stream does not 569 appear to add further security issues. 571 12. IANA Considerations 573 12.1. New SDP Media-Level Attributes 575 This document defines a new SDP media-level attribute, "remote-ssrc". 576 This attribute should be registered by IANA under "Session 577 Description Protocol (SDP) Parameters" under "att-field (media level 578 only)". 580 The "remote-ssrc" attribute is used to identify characteristics of 581 remote media sources within a media stream. Its format is defined in 582 Section 5. 584 12.2. New SDP Source-Level Attributes 586 This document defines two new SDP source-level attributes, 587 "information" and "sending". These attributes should be registered 588 by IANA under "Session Description Protocol (SDP) Parameters" under 589 "att-field (source level)". Their format is defined in Section 7. 591 12.3. Registry for Remote Source-Level Attributes 593 This specification creates a new IANA registry named "att-field 594 (remote source level)" within the SDP parameters registry. Remote 595 source attributes MUST be registered with IANA and documented, under 596 the same rules as for SDP source-level attributes as specified in 597 [RFC5576]: 599 New attribute registrations are accepted according to the 600 "Specification Required" policy of [RFC5226], provided that the 601 specification includes the following information: 603 o contact name, email address, and telephone number 604 o attribute name (as it will appear in SDP) 605 o long-form attribute name in English 606 o whether the attribute value is subject to the charset attribute 607 o a one-paragraph explanation of the purpose of the attribute 608 o a specification of appropriate attribute values for this attribute 610 The above is the minimum that IANA will accept. Attributes that are 611 expected to see widespread use and interoperability SHOULD be 612 documented with a standards-track RFC that specifies the attribute 613 more precisely. 615 Submitters of registrations should ensure that the specification is 616 in the spirit of SDP attributes, most notably that the attribute is 617 platform independent in the sense that it makes no implicit 618 assumptions about operating systems and does not name specific pieces 619 of software in a manner that might inhibit interoperability. 621 Remote source-level attributes which are substantially similar in 622 semantics to existing source-level, session-level or media-level 623 attributes SHOULD re-use the same attribute name as those attributes. 624 Remote source-level attributes SHOULD NOT re-use attribute names of 625 other level attributes that are unrelated or substantially different. 627 The initial set of remote source attribute names, with definitions in 628 Section 6 of this document, is in Figure 10. 630 Type SDP Name Reference 631 ---- ------------------ --------- 632 att-field (remote source level) 633 recv [RFCXXXX] 634 framerate [RFCXXXX] 635 imageattr [RFCXXXX] 636 priority [RFCXXXX] 638 Figure 10: Initial Contents of IANA Remote Source Attribute Registry 640 (Note to the RFC-Editor: please replace "XXXX" with the number of 641 this document prior to publication as an RFC.) 643 13. References 645 13.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 651 with Session Description Protocol (SDP)", RFC 3264, 652 June 2002. 654 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 655 Jacobson, "RTP: A Transport Protocol for Real-Time 656 Applications", STD 64, RFC 3550, July 2003. 658 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 659 Description Protocol", RFC 4566, July 2006. 661 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 662 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 663 May 2008. 665 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 666 Specifications: ABNF", STD 68, RFC 5234, January 2008. 668 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 669 Media Attributes in the Session Description Protocol 670 (SDP)", RFC 5576, June 2009. 672 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 673 Attributes in the Session Description Protocol (SDP)", 674 RFC 6236, May 2011. 676 13.2. Informative References 678 [I-D.ietf-xcon-event-package] 679 Camarillo, G., Srinivasan, S., Even, R., and J. 680 Urpalainen, "Conference Event Package Data Format 681 Extension for Centralized Conferencing (XCON)", 682 draft-ietf-xcon-event-package-01 (work in progress), 683 September 2008. 685 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 686 Initiation Protocol (SIP) Event Package for Conference 687 State", RFC 4575, August 2006. 689 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 690 January 2008. 692 Appendix A. Open issues 694 o Does the model described in Section 8, where sources can be 695 requested in an an answer and responded to in a subsequent offer 696 or answer, actually work for all failure cases? Or do we need a 697 full bi-directional offer/answer exchange? 699 Appendix B. Changes From Earlier Versions 701 Note to the RFC-Editor: please remove this section prior to 702 publication as an RFC. 704 B.1. Changes From Individual Submission Draft -03 706 Changed logic to indicate that it is valid to reject a "recv:on" 707 request with "sending:off", either immediately or at a subsequent 708 time. 710 Clarified that sources with "sending:off" are still members of the 711 RTP session, and so still have RTCP sent for them. 713 B.2. Changes From Individual Submission Draft -02 715 Document refresh; reference updates only. 717 B.3. Changes From Individual Submission Draft -01 719 o Clarified backward compatibility discussion. 721 o Minor editorial improvements. 723 B.4. Changes From Individual Submission Draft -00 725 o The "recv" and "inactive" remote source attributes have been 726 changed to "recv:on" and "recv:off" respectively. Similarly, the 727 "send" and "inactive" source attributes have been changed to 728 "sending:on" and "sending:off". 729 o Clarified that "imageattr" and "framerate" parameters are 730 advisory, and MUST NOT be inconsistent with payload type 731 parameters. 732 o Tightened some SHOULD requirements to be MUST, and clarified when 733 others apply. 734 o Tightened up ABNF grammar (e.g., to eliminate leading 0 values 735 from integers). 736 o Added Henning Schulzrinne as co-author. 737 o Numerous editorial improvements. 739 Authors' Addresses 741 Jonathan Lennox 742 Vidyo, Inc. 743 433 Hackensack Avenue 744 Seventh Floor 745 Hackensack, NJ 07601 746 US 748 Email: jonathan@vidyo.com 750 Henning Schulzrinne 751 Columbia University Department of Computer Science 752 450 Computer Science 753 1214 Amsterdam Ave., Mailcode: 0401 754 New York, NY 10027 755 US 757 Email: hgs@cs.columbia.edu 758 URI: http://www.cs.columbia.edu/~hgs/