idnits 2.17.1 draft-lennox-mmusic-sdp-source-selection-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4205 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 637, 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: April 25, 2013 Columbia U. 6 October 22, 2012 8 Mechanisms for Media Source Selection in the Session Description 9 Protocol (SDP) 10 draft-lennox-mmusic-sdp-source-selection-05 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 April 25, 2013. 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 -04 . . . . . . . 16 81 B.2. Changes From Individual Submission Draft -03 . . . . . . . 16 82 B.3. Changes From Individual Submission Draft -02 . . . . . . . 16 83 B.4. Changes From Individual Submission Draft -01 . . . . . . . 17 84 B.5. Changes From Individual Submission Draft -00 . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 The source-attribute specification [RFC5576] provides declarative 90 definitions for Real-Time Protocol (RTP) [RFC3550] media sources in 91 the Session Description Protocol (SDP) [RFC4566]. 93 In some architectures (such as those described in Section 3), it is 94 useful to provide the capability for endpoints to request specific 95 sources of a remote party, asking the sender to selectively enable or 96 disable them, and to specify characteristics of the sources 97 requested. To accomplish this, this document defines a new media 98 attribute, "remote-ssrc", which allows a receiver to indicate that it 99 wishes to receive a remote source, and also allows it to specify 100 attributes of the remote source. This document defines several such 101 remote source attributes: "recv" and "preference" which are 102 applicable to any media type, and "framerate" and "imageattr" which 103 are specific to video sources. Currently no attributes are defined 104 that are specific to audio or other media types. 106 Additionally, several new declarative ([RFC5576]) source attributes 107 are defined: "information", providing human-readable information 108 about a local source, and "sending", which is complementary to the 109 "recv" remote source attribute. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119] and 116 indicate requirement levels for compliant implementations. 118 3. Architecture 120 The primary use envisioned for this mechanism is for multimedia 121 conferences controlled by a central system. This is similar to the 122 topologies described by RTP Topologies [RFC5117] as Topo-Mixer, Topo- 123 Video-switch-MCU, or Topo-RTCP-terminating-MCU (depending on the 124 treatment of RTCP), with one crucial difference: rather than only 125 forwarding either a single media source, or an MCU-mixed media 126 source, to receivers, the central mixer can instead simultaneously 127 forward multiple media sources independently to each receiver, as 128 constrained by available bandwidth. 130 In this architecture, the conference server can notify each 131 participant as sources become available in the conference. 132 Participants can then either explicitly request sources from the 133 server, or allow the server to choose which sources to forward based 134 on its own criteria and policy. A hybrid mode is also possible, in 135 which participants explicitly request some sources while allowing the 136 server to choose others. 138 Receivers can specify parameters for how they wish to view sources, 139 e.g., the image size or frame rate in which they will display video 140 sources. They can also specify priority among sources in case the 141 server has insufficient bandwidth to send them all. 143 When the first receiver starts viewing a source, the conference 144 server tells the sender to start sending it; prior to this, the 145 sender does not send it. Similarly, when the last receiver stops 146 viewing a source, the server tells the sender to stop sending it. 148 For large conferences, sending each conference source over a separate 149 RTP session, each with its own m= line, would not be practical, due 150 to issues such as server port consumption, NAT binding exhaustion, 151 and ICE setup time. Thus, sources of the same media type are instead 152 sent over a single RTP session, distinguished by their SSRC. This 153 document defines the source negotiation mechanisms needed in SDP to 154 enable the mechanisms defined in this architecture. 156 4. Overview 158 This mechanism builds upon the declarative source definitions defined 159 in [RFC5576]. That document defines how to describe individual RTP 160 sources within an RTP session in SDP. Each source is identified by 161 its Synchronization Source (SSRC) identifier, and is associated with 162 its CNAME (canonical-name) SDP attribute. 164 To enable the architecture defined in Section 3, this document 165 defines a complementary SDP media attribute which allows the receiver 166 of some RTP sources to let the the sources' sender know which sources 167 the receiver would like to receive. This attribute, "remote-ssrc", 168 is defined in Section 5. 170 A simple example SDP exchange using this mechanism is shown in 171 Figure 1 and Figure 2. For brevity, only the relevant portions of 172 the media sections of the SDP descriptions are given. 174 m=video 49168 RTP/AVP 96 175 a=rtpmap:96 H264/90000 176 a=ssrc:12345 cname:user1@host1.example.com 177 a=ssrc:67890 cname:user2@host2.example.com 179 Figure 1: Notification of media sources 181 In Figure 1 an SDP description indicates, using the mechanisms of 182 [RFC5576], two sources that are available in an RTP session. 184 m=video 49170 RTP/AVP 96 185 a=rtpmap:96 H264/90000 186 a=remote-ssrc:12345 recv:on 187 a=remote-ssrc:12345 imageattr:* [x=720,y=576] 188 a=remote-ssrc:12345 framerate:15 190 Figure 2: Request for a media source. 192 In Figure 2 an SDP description sent in response requests that a 193 specific source be sent, with resolution 720 by 576 and a framerate 194 of 15 frames per second. 196 5. The "remote-ssrc" Media Attribute 198 The "remote-ssrc" SDP media-level attribute allows a receiver to 199 requested a specific a remote source. 201 a=remote-ssrc: 202 a=remote-ssrc: : 204 The SDP media attribute "remote-ssrc" indicates a property, known as 205 a "remote source-level attribute", of a remote media source (RTP 206 stream) within an RTP session. is the synchronization 207 source ID (SSRC) of the remote source being described, interpreted as 208 a 32-bit unsigned integer in network byte order and represented in 209 decimal. or : represent the source- 210 level receive attribute specific to the given remote media source. 211 The source-level receive attribute follows the syntax of the SDP "a=" 212 line. It thus consists either of a single attribute name (a flag), 213 or an attribute name and value, e.g., "framerate:30". No attributes 214 of the former type are defined by this document. The order of 215 multiple "remote-ssrc" media attributes within an SDP message is not 216 significant. 218 These remote source IDs correspond to sources in the RTP session that 219 may be sent by other session members. The author of the SDP message 220 may have learned about these sources by observing them in the RTP 221 session (either by receiving RTP packets or seeing RTCP reports about 222 them), from earlier SDP messages containing "ssrc" attributes 223 describing the sources, or from other means such as the SIP 224 conference event package [RFC4575] or the XCON conference event 225 package [RFC6502]. 227 The "remote-ssrc" media attribute may be used for any RTP-based media 228 transport. It is not defined for other transport protocols. 230 Though the remote source attributes specified by the "remote-ssrc" 231 property follow the same syntax as (local) source attributes, they 232 are defined independently. All remote source attributes MUST be 233 registered with IANA, using the registry defined in Section 12.3. 235 Figure 3 in Section 10 gives a formal Augmented Backus-Naur Form 236 (ABNF) [RFC5234] grammar for the ssrc attribute. 238 The "remote-ssrc" media attribute does not (itself) depend on the SDP 239 charset, though specific remote source attributes may be defined to 240 be. 242 6. Remote Source Attributes 244 This section defines several specific remote source-level attributes 245 that can be applied to RTP sources. 247 6.1. The "recv" Remote Source-Level Attribute 249 a=remote-ssrc: recv: 251 The "recv" remote source attribute indicates whether the author of an 252 SDP message is interested in receiving a source. A "recv" remote 253 source attribute with a value of "on" indicates a source that 254 the author of an SDP message is interested in receiving. Similarly, 255 a "recv" remote source attribute with a value of "off" 256 indicates a source that the author of an SDP message is not 257 interested in receiving. There MUST be at most one "recv" remote 258 source-level attribute per remote media source. A "recv" attribute 259 with a value other than "on" or "off" MUST be ignored (for 260 future extensibility). 262 If the media stream containing the source has the media attributes 263 "sendonly" or "inactive", the SDP message MUST NOT list any remote 264 sources with a "recv" attribute with the "on" for that media 265 stream. 267 If "remote-ssrc" attributes are given for a particular remote source, 268 but "recv" is not specified for it, "recv:on" is the default if the 269 media stream is "sendrecv" or "recvonly". 271 If no remote-ssrc attributes at all are listed for a particular 272 remote source, the choice of whether to send it is left at the 273 sender's discretion. However, for sources associated in with an 274 "ssrc-group" [RFC5576], any unlisted sources of a group SHOULD be 275 treated the same as any listed ones if the requests are consistent, 276 unless the semantics specified for the "ssrc-group" dictates 277 otherwise. 279 Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form 280 (ABNF) [RFC5234] grammar for the "recv" attribute. 282 Section 8 describes how the "recv" remote source attribute is used 283 with SDP offer/answer [RFC3264]. 285 The "recv" remote source attribute does not depend on the SDP 286 charset. 288 6.2. The "framerate" Remote Source Attribute 290 a=remote-ssrc: framerate: 292 The "framerate" remote source-level attribute gives the maximum frame 293 rate, in frames per second, which the receiver of a video source 294 would like receive for the video. Higher framerates are likely not 295 to be useful to the receiver. This attribute is analogous in 296 function and syntax to the SDP "framerate" media attribute [RFC4566]. 297 Decimal representations of fractional values using the notation 298 "." are allowed. The frame rate specified MUST be 299 greater than zero. 301 The "framerate" attribute is advisory; a sender MAY send a framerate 302 other than that requested by the receiver if it is not able to send 303 the framerate required. The sender SHOULD attempt to come as close 304 as it can to the requested framerate, subject to other constraints of 305 the system. 307 The "framerate" attribute is defined only for video media. There 308 MUST be at most one "framerate" remote source attribute per remote 309 media source. The "framerate" requested MUST NOT be inconsistent 310 with any fmtp parameters specified for the media stream's payload 311 types. 313 Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form 314 (ABNF) [RFC5234] grammar for the "framerate" attribute. 316 The "framerate" remote source attribute does not depend on the SDP 317 charset. 319 6.3. The "imageattr" Remote Source Attribute 321 a=remote-ssrc: imageattr: 323 The "imageattr" remote source-level attribute describes the image 324 resolution and other image characteristics with which a video source 325 would like receive the video. Larger resolutions are likely not to 326 be useful to the receiver. It is analogous in function and syntax to 327 the "recv" portion of the SDP "imageattr" media attribute [RFC6236]. 329 The "imageattr" attribute is advisory; a sender MAY send a resolution 330 other than that requested by the receiver if it is not able to send 331 the resolution required. The sender SHOULD attempt to come as close 332 as it can to the requested resolution, subject to other constraints 333 of the system. 335 Different image attributes MAY be defined per payload type defined in 336 the media stream. The parameter MAY either be one of the media 337 formats (RTP payload types) specified for the media stream, or the 338 character "*" indicating that the "imageattr" attribute applies to 339 all payload types of the session. 341 The parameter gives a list of resolutions and image 342 aspect ratios with which the receiver wishes to display the source. 343 It is described in detail in [RFC6236]. 345 The "imageattr" attribute is defined only for video media. There 346 MUST be at most one "imageattr" remote source attribute per payload 347 type per remote media source. If an "imageattr" attribute is present 348 with a PT value of "*", it MUST be the only "imageattr" attribute 349 defined for that remote media source. The "imageattr" requested MUST 350 NOT be inconsistent with any fmtp parameters specified for the media 351 stream's payload types. 353 Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form 354 (ABNF) [RFC5234] grammar for the "imageattr" attribute. 356 The "imageattr" remote source attribute does not depend on the SDP 357 charset. 359 6.4. The "priority" Remote Source Attribute 361 a=remote-ssrc: priority: 362 The "priority" remote source-level attribute gives the relative 363 priority among the remote sources requested by a receiver. The 364 parameter is a non-negative decimal integer indicating 365 which streams should be given higher preference if the sender 366 determines that there is insufficient bandwidth (or other resource) 367 available to transmit all the requested streams. Larger numbers 368 indicate a greater priority. Priority values MUST be less than 2**31 369 - 1, but otherwise their specific values have no semantic 370 significance. 372 Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form 373 (ABNF) [RFC5234] grammar for the "priority" attribute. 375 The "priority" remote source attribute does not depend on the SDP 376 charset. 378 7. Source Attributes 380 This section describes sending source attributes that a sender can 381 use to describe RTP sources. 383 7.1. The "information" Source Attribute 385 a=ssrc: information: 387 The "information" source attribute provides textual information about 388 a source. It is analogous in function and syntax to the SDP "i=" 389 field for session and media information. There MUST be at most one 390 "information" source attribute per media source. If the "charset" 391 attribute is present at the session or media level, it specifies the 392 character set used in the source description. If the "charset" 393 attribute is not present, the "information" attribute MUST contain 394 ISO 10646 characters in UTF-8 encoding. 396 The "information" attribute is intended to provide a free-form human- 397 readable description of a media source. It is not suitable for 398 parsing by automata. 400 Figure 8 in Section 10 gives a formal Augmented Backus-Naur Form 401 (ABNF) [RFC5234] grammar for the "information" attribute. 403 7.2. The "sending" Source-Level Attribute 405 a=ssrc: sending: 406 The "sending" remote source attribute indicates whether the author of 407 an SDP message is interested in currently actively sending a source, 408 due to it having been requested by the other party with a "recv" 409 remote source attribute in an SDP offer/answer exchange. A "sending" 410 source attribute with a value of "on" indicates a source that 411 the author of an SDP message is currently actively sending, due to it 412 having been requested by the other party with a "recv:on" remote 413 source attribute. Similarly, the "sending" source attribute with a 414 value of "off" indicates a source that the other party has 415 rejected with a previous the "recv:off" remote source attribute, or 416 that the author of the SDP message is no longer interested in 417 sending. There MUST be at most one "sending" source-level attribute 418 per media source. Sources which were not listed with "recv-ssrc" in 419 the previous offer or answer SHOULD NOT have a "sending" attribute 420 included. The "sending" attribute is only defined in the context of 421 SDP offer/answer [RFC3264]. A "sending" attribute with a 422 value other than "on" or "off" MUST be ignored (for future 423 extensibility). 425 If the media stream containing the source has the media attributes 426 "recvonly" or "inactive", the stream MUST NOT list any sources with 427 the "sending" attribute with the on. 429 A source that is indicated in an offer or answer with "sending:off" 430 SHOULD still be considered a member of the RTP session, and thus RTCP 431 SHOULD be sent for it, unless it has left the RTP session (with an 432 RTCP BYE message) subsequent to the sending of the offer or answer. 434 Figure 9 in Section 10 gives a formal Augmented Backus-Naur Form 435 (ABNF) [RFC5234] grammar for the "sending" attribute. 437 Further description of how the "sending" source attribute is used 438 with SDP offer/answer [RFC3264] is given in Section 8. 440 The "sending" source attribute is not dependent on charset. 442 8. Usage With the Offer/Answer Model 444 When used with the SDP Offer/Answer Model [RFC3264], the "remote- 445 ssrc" attribute MAY be included either in an SDP offer or answer. 446 Both offers and answers MAY contain both "ssrc" and "remote-ssrc" 447 media attributes. 449 If "remote-ssrc" attributes are present in an SDP offer, the answerer 450 (if it accepts the offer) MUST include all the remotely-requested 451 active sources in "ssrc" attributes in its answer, except for any 452 sources which are no longer available when the answer is sent. If 453 "remote-ssrc" attributes are present in an answer, no immediate 454 update to SDP is necessary; however, if the endpoint subsequently 455 sends a new SDP offer, it SHOULD include all the remotely-requested 456 sources from the previous offer/answer exchange, unless those sources 457 are no longer available. In both cases, remote sources with the 458 "recv:on" remote source attribute included (implicitly or explicitly) 459 MUST be listed in the next response -- with the "sending:on" local 460 source attribute if the sender accepted the request to send the 461 source, or "sending:off" if the sender does not wish to send the 462 source. Remote sources with the "recv:off" remote source attribute 463 MUST have the "sending:off" local source attribute. If the send/recv 464 mode of the media stream has changed to "recvonly" or "inactive", 465 sources MUST NOT be listed with the "sending:on" attribute, and thus 466 all remotely-requested sources MUST be listed as "sending:off" 467 instead. 469 If a sender receives a "recv:on" in an answer and does not wish to 470 send the source, it SHOULD send a updated offer with "sending:off" as 471 soon as is practical. If a sender wishes to stop sending a source 472 for which its previous offer or answer had included "sending:on", it 473 SHOULD send an updated offer with "sending:off" as soon as practical, 474 and MUST include "sending:off" for the source in its next offer or 475 answer (assuming the source is still in the session, and it still 476 wishes not to send the source by the time of the offer or answer). 478 In general, all participants in an offer/answer exchange SHOULD list 479 all currently available sources, unless information about available 480 sources is being provided through some other mechanism, such as the 481 SIP conference event package [RFC4575] or the XCON conference event 482 package [RFC6502]. (Because these event packages support partial 483 updates, whereas SDP does not, source notification through event 484 packages can be more efficient, where applicable, than SDP can be.) 485 In the latter case sources that were not explicitly requested in the 486 most recent SDP offer or answer MAY be omitted. 488 9. Backward Compatibility 490 The default behavior, for remote sources which are listed neither as 491 "recv:on" nor "recv:off", is that whether sources are to be sent is 492 left to the sender's discretion. This is also the implicit behavior 493 for standard RTP; thus, a device does not need to know, upon 494 receiving an SDP message containing no "remote-ssrc" attributes, 495 whether its peer does not understand the "remote-ssrc" attribute at 496 all, or is simply choosing to leave source selection up to the 497 sender's discretion. 499 Because offer/answer exchanges are required to include "sending" 500 source attributes in response to previous "recv" remote source 501 attributes, it is possible to determine based on an SDP answer, or on 502 a subsequent offer/answer exchange, whether the peer understands the 503 "remote-ssrc" attribute. 505 10. Formal Grammar 507 This section gives a formal Augmented Backus-Naur Form (ABNF) 508 [RFC5234] grammar for each of the new media and source attributes 509 defined in this document. Grammars for existing session or media 510 attributes which have been extended to be source attributes are not 511 included. 513 remote-ssrc-attr = "remote-ssrc:" ssrc-id SP attribute 514 ; The base definition of "attribute" is in RFC 4566. 515 ; (It is the content of "a=" lines.) 516 ssrc-id = integer ; 0 .. 2**32 - 1 518 attribute =/ remote-ssrc-attr 520 Figure 3: Syntax of the "remote-ssrc" media attribute 522 recv-attr = "recv:" recv-state 524 recv-state = "on" / "off" / token 526 attribute =/ recv-attr 528 Figure 4: Syntax of the "recv" and "inactive" receive source 529 attributes 531 framerate-attr = "framerate:" integer [ "." 1*DIGIT ] 533 attribute =/ framerate-attr 535 Figure 5: Syntax of the "framerate" receive source attribute 537 imageattr-attr = "imageattr:" PT WSP attr_list 538 ; The definition of PT and attr_list are in 539 ; [RFC6236] 541 attribute =/ imageattr-attr 543 Figure 6: Syntax of the "imageattr" receive source attribute 545 priority-attr = "priority:" integer 547 attribute =/ priority-attr 549 Figure 7: Syntax of the "priority" receive source attribute 551 information-attr = "information:" text 552 ; The definition of text is in [RFC4566] 554 attribute =/ information-attr 556 Figure 8: Syntax of the "information" source attribute 558 sending-attr = "sending:" sending-state 560 sending-state = "on" / "off" / token 562 attribute =/ sending-attr 564 Figure 9: Syntax of the "sending" and "inactive" source attributes 566 11. Security Considerations 568 All the security considerations of RTP [RFC3550] and of SDP [RFC4566] 569 apply. Explicitly requesting sources of an RTP media stream does not 570 appear to add further security issues. 572 12. IANA Considerations 574 12.1. New SDP Media-Level Attributes 576 This document defines a new SDP media-level attribute, "remote-ssrc". 577 This attribute should be registered by IANA under "Session 578 Description Protocol (SDP) Parameters" under "att-field (media level 579 only)". 581 The "remote-ssrc" attribute is used to identify characteristics of 582 remote media sources within a media stream. Its format is defined in 583 Section 5. 585 12.2. New SDP Source-Level Attributes 587 This document defines two new SDP source-level attributes, 588 "information" and "sending". These attributes should be registered 589 by IANA under "Session Description Protocol (SDP) Parameters" under 590 "att-field (source level)". Their format is defined in Section 7. 592 12.3. Registry for Remote Source-Level Attributes 594 This specification creates a new IANA registry named "att-field 595 (remote source level)" within the SDP parameters registry. Remote 596 source attributes MUST be registered with IANA and documented, under 597 the same rules as for SDP source-level attributes as specified in 598 [RFC5576]: 600 New attribute registrations are accepted according to the 601 "Specification Required" policy of [RFC5226], provided that the 602 specification includes the following information: 604 o contact name, email address, and telephone number 605 o attribute name (as it will appear in SDP) 606 o long-form attribute name in English 607 o whether the attribute value is subject to the charset attribute 608 o a one-paragraph explanation of the purpose of the attribute 609 o a specification of appropriate attribute values for this attribute 611 The above is the minimum that IANA will accept. Attributes that are 612 expected to see widespread use and interoperability SHOULD be 613 documented with a standards-track RFC that specifies the attribute 614 more precisely. 616 Submitters of registrations should ensure that the specification is 617 in the spirit of SDP attributes, most notably that the attribute is 618 platform independent in the sense that it makes no implicit 619 assumptions about operating systems and does not name specific pieces 620 of software in a manner that might inhibit interoperability. 622 Remote source-level attributes which are substantially similar in 623 semantics to existing source-level, session-level or media-level 624 attributes SHOULD re-use the same attribute name as those attributes. 625 Remote source-level attributes SHOULD NOT re-use attribute names of 626 other level attributes that are unrelated or substantially different. 628 The initial set of remote source attribute names, with definitions in 629 Section 6 of this document, is in Figure 10. 631 Type SDP Name Reference 632 ---- ------------------ --------- 633 att-field (remote source level) 634 recv [RFCXXXX] 635 framerate [RFCXXXX] 636 imageattr [RFCXXXX] 637 priority [RFCXXXX] 639 Figure 10: Initial Contents of IANA Remote Source Attribute Registry 641 (Note to the RFC-Editor: please replace "XXXX" with the number of 642 this document prior to publication as an RFC.) 644 13. References 646 13.1. Normative References 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, March 1997. 651 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 652 with Session Description Protocol (SDP)", RFC 3264, 653 June 2002. 655 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 656 Jacobson, "RTP: A Transport Protocol for Real-Time 657 Applications", STD 64, RFC 3550, July 2003. 659 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 660 Description Protocol", RFC 4566, July 2006. 662 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 663 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 664 May 2008. 666 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 667 Specifications: ABNF", STD 68, RFC 5234, January 2008. 669 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 670 Media Attributes in the Session Description Protocol 671 (SDP)", RFC 5576, June 2009. 673 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 674 Attributes in the Session Description Protocol (SDP)", 675 RFC 6236, May 2011. 677 13.2. Informative References 679 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 680 Initiation Protocol (SIP) Event Package for Conference 681 State", RFC 4575, August 2006. 683 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 684 January 2008. 686 [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. 687 Urpalainen, "Conference Event Package Data Format 688 Extension for Centralized Conferencing (XCON)", RFC 6502, 689 March 2012. 691 Appendix A. Open issues 693 o Does the model described in Section 8, where sources can be 694 requested in an an answer and responded to in a subsequent offer 695 or answer, actually work for all failure cases? Or do we need a 696 full bi-directional offer/answer exchange? 698 Appendix B. Changes From Earlier Versions 700 Note to the RFC-Editor: please remove this section prior to 701 publication as an RFC. 703 B.1. Changes From Individual Submission Draft -04 705 Document refresh; reference updates only. 707 B.2. Changes From Individual Submission Draft -03 709 Changed logic to indicate that it is valid to reject a "recv:on" 710 request with "sending:off", either immediately or at a subsequent 711 time. 713 Clarified that sources with "sending:off" are still members of the 714 RTP session, and so still have RTCP sent for them. 716 B.3. Changes From Individual Submission Draft -02 718 Document refresh; reference updates only. 720 B.4. Changes From Individual Submission Draft -01 722 o Clarified backward compatibility discussion. 723 o Minor editorial improvements. 725 B.5. Changes From Individual Submission Draft -00 727 o The "recv" and "inactive" remote source attributes have been 728 changed to "recv:on" and "recv:off" respectively. Similarly, the 729 "send" and "inactive" source attributes have been changed to 730 "sending:on" and "sending:off". 731 o Clarified that "imageattr" and "framerate" parameters are 732 advisory, and MUST NOT be inconsistent with payload type 733 parameters. 734 o Tightened some SHOULD requirements to be MUST, and clarified when 735 others apply. 736 o Tightened up ABNF grammar (e.g., to eliminate leading 0 values 737 from integers). 738 o Added Henning Schulzrinne as co-author. 739 o Numerous editorial improvements. 741 Authors' Addresses 743 Jonathan Lennox 744 Vidyo, Inc. 745 433 Hackensack Avenue 746 Seventh Floor 747 Hackensack, NJ 07601 748 US 750 Email: jonathan@vidyo.com 752 Henning Schulzrinne 753 Columbia University Department of Computer Science 754 450 Computer Science 755 1214 Amsterdam Ave., Mailcode: 0401 756 New York, NY 10027 757 US 759 Email: hgs@cs.columbia.edu 760 URI: http://www.cs.columbia.edu/~hgs/