idnits 2.17.1 draft-westerlund-dispatch-stream-selection-00.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 24, 2011) is 4539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) -- Obsolete informational reference (is this intentional?): RFC 4583 (Obsoleted by RFC 8856) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Grondal 3 Internet-Draft B. Burman 4 Intended status: Standards Track M. Westerlund 5 Expires: April 26, 2012 Ericsson AB 6 October 24, 2011 8 Media Stream Selection (MESS) 9 draft-westerlund-dispatch-stream-selection-00 11 Abstract 13 This document describes how media stream selection can be achieved in 14 both a conferencing scenario and peer to peer communication. To 15 allow endpoints to select specific media streams, all available media 16 in the session must be identifiable and there is a need for messages 17 than can be securely transported between endpoints and network nodes. 18 This document also describes a way to distribute the identification 19 information to all participating endpoints. The necessary messages 20 can potentially be mapped onto several different encodings, and this 21 document proposes one mapping that uses an extended version of the 22 Binary Floor Control Protocol. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 26, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Use Cases for MESS . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Include Media Content . . . . . . . . . . . . . . . . . . 5 64 3.2. Exclude Media Content . . . . . . . . . . . . . . . . . . 5 65 3.3. Substitute Media Content . . . . . . . . . . . . . . . . . 5 66 3.4. Reset Media Content . . . . . . . . . . . . . . . . . . . 6 67 3.5. Reset All . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Media Information . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Unique Media ID . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Distribution of Media Information . . . . . . . . . . . . 7 71 4.3. Publishing Media Information from Endpoints . . . . . . . 7 72 4.4. Publishing Media Information from Conference Nodes . . . . 7 73 4.5. Receiving Media Information . . . . . . . . . . . . . . . 7 74 4.6. RTP Media Transport . . . . . . . . . . . . . . . . . . . 8 75 4.7. SDP Media Description . . . . . . . . . . . . . . . . . . 8 76 4.7.1. Point to Point Communication . . . . . . . . . . . . . 10 77 4.7.2. Conferencing Scenario . . . . . . . . . . . . . . . . 10 78 5. MESS Requests . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2. BFCP Extensions . . . . . . . . . . . . . . . . . . . . . 11 81 5.2.1. OPERATION . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2.2. MEDIA-IDENTIFICATION . . . . . . . . . . . . . . . . . 12 83 5.2.3. CHANNEL-IDENTIFICATION . . . . . . . . . . . . . . . . 13 84 5.3. Defined Messages . . . . . . . . . . . . . . . . . . . . . 14 85 5.3.1. MediaSelectionAck . . . . . . . . . . . . . . . . . . 14 86 5.3.2. Include . . . . . . . . . . . . . . . . . . . . . . . 14 87 5.3.3. Exclude . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.3.4. Substitute . . . . . . . . . . . . . . . . . . . . . . 15 89 5.3.5. Reset . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5.3.6. Reset All . . . . . . . . . . . . . . . . . . . . . . 17 91 6. MESS Responses . . . . . . . . . . . . . . . . . . . . . . . . 18 92 7. RTP Implications . . . . . . . . . . . . . . . . . . . . . . . 18 93 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 8.1. Client joins a conference . . . . . . . . . . . . . . . . 19 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 100 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Introduction 105 Multimedia conferencing is becoming more and more important. The 106 setup up of a multimedia conference is well defined, using for 107 example SIP and SDP. However, as SIP/SDP is used for session setup 108 it leaves little or no dynamic control over what media content to 109 receive from other participants during the session. This document 110 targets this weakness and describes functionality that grants 111 receiving endpoints capabilities to dynamically select what 112 information and media content are received from other participating 113 clients. 115 1.1. Terminology 117 These terms are commonly used throughout the document: 119 Media Content: Media being sent from one specific media capture 120 device, such as a microphone for audio media, or video camera for 121 video media. 123 Endpoint: An device that handles media that either originates a 124 number of media content, terminates a number of media content, or 125 some combination of both. As an example, an RTP Mixer is 126 considered as an endpoint, while a simple RTP Translator that 127 simply forwards all input streams is not. 129 1.2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2. Motivation 137 In a communication scenario where one or more endpoints offers more 138 than one media content, but where a receiving endpoint cannot handle 139 all simultaneous media content at once, there may be a need for that 140 endpoint to actively and dynamically during an ongoing conference 141 select what content to receive. A typical scenario would be a video 142 conference where some endpoints have multiple cameras capturing 143 different aspects of a room and a receiving endpoint can only render 144 one video stream due to e.g. hardware limitations. Today, the only 145 way to solve this is to have an RTP mixer handle the conference and 146 let that choose one of the streams based on some criteria. It is up 147 to the RTP mixer implementation which stream to choose, but a common 148 criteria is some type of speaker activity. 150 It would be possible to let the receiving endpoints to choose which 151 media content(s) to receive, given that endpoints publish information 152 about what media content is available to all other endpoints and if 153 there would exist a protocol to request specific media content from 154 other endpoints. This functionality is what Media Stream Selection 155 (MESS) described in this document targets. It describes how to 156 generate and distribute media content information in both 157 conferencing scenarios as well as in point to point sessions. It 158 also describes how to set up a control channel to send messages 159 between endpoints and finally defines a set of messages that can be 160 used to handle media content requests. 162 3. Use Cases for MESS 164 This section presents some typical use cases targeted by MESS. The 165 scenario is an endpoint participating in a conference, receiving 166 media from a centralized conference node. It is assumed that all 167 participating endpoints have published information about what media 168 content they are offering. There are more available media from other 169 participants in the conference than what the receiving endpoint in 170 the use case can present simultaneously, and the conference node has 171 some implemented policy how to select which media to forward. 173 3.1. Include Media Content 175 An endpoint selects what content to receive from another endpoint 176 based on that endpoint's published media content information. An 177 endpoint can make new decisions about what content to receive 178 dynamically at any time during the session. 180 3.2. Exclude Media Content 182 An endpoint wishes to stop receiving content from another endpoint 183 e.g. due to low quality or other reasons. The set of excluded media 184 during a session is subject to change and an endpoint can make new 185 decisions to exclude content dynamically at any time during the 186 session. 188 3.3. Substitute Media Content 190 An endpoint renders received media and wants to replace the received 191 media with some other available media content. It can be seen as an 192 atomic combination of the two use-cases above, first excluding one 193 media content and effectively replacing it by including another. And 194 endpoint can make new substitute decisions dynamically at any time 195 during the session. 197 3.4. Reset Media Content 199 An endpoint no longer has any specific wish to always include or 200 always exclude a certain content, but wants to return the decision to 201 forward streams or not to the conference node. An endpoint can reset 202 any previously included or excluded stream at any time during the 203 session. At the beginning of the session, all media streams SHALL 204 have a state corresponding to being reset and thus be under the 205 conference node policy control. 207 3.5. Reset All 209 An endpoint wishes to remove all previous decisions about included 210 and excluded media. This method is a shortcut to avoid repeated 211 reset messages described in Section 3.4. 213 4. Media Information 215 To be able to identify the available media content, all different 216 content must be given a unique media ID. The given ID must also be 217 distributed to all participating endpoints. The following sections 218 describe how to generate such IDs and how to distribute them. 220 The text in SDP Media Description (Section 4.7) describes the 221 specific case where media description is signaled with SDP [RFC4566], 222 but other signaling methods MAY be used, in which case the mapping to 223 SDP-specific lines and attributes do not apply and other mandatory 224 mappings SHOULD instead be defined in a separate RFC. 226 The text in Section 4.6 describes the specific case when RTP 227 [RFC3550] is used for media transport. Other media transports MAY be 228 used, in which case the mapping to RTP does not apply and other 229 mandatory mappings SHOULD instead be defined in a separate RFC. 231 4.1. Unique Media ID 233 To request specific media content, all involved endpoints need to 234 agree on how to uniquely identify different content with a unique 235 media ID. 237 There is no particular algorithm specified how to generate unique 238 media IDs, as it will depend on which media transport is used. The 239 main requirements on such an algorithm are that media IDs are unique 240 among all communicating endpoints and that all endpoints share the 241 same definitions on what media streams are identified by what media 242 IDs. 244 4.2. Distribution of Media Information 246 Assuming all available media content from all communicating endpoints 247 are associated with some kind of media ID, those media IDs need to be 248 distributed to endpoints wishing to actively control what content to 249 receive. There might also be other interesting per-media related 250 information that needs distribution, such as e.g. naming or 251 describing individual media content to aid selection. 253 4.3. Publishing Media Information from Endpoints 255 Endpoints wishing to join a session are responsible to send 256 information about media content they will make available to the other 257 party or parties. This is done by generating media IDs, or other 258 sufficiently unique identification that can be used for generation of 259 media IDs, for all transmitted media content. Depending on the 260 capabilities of the signaling protocol used, an endpoint can also 261 have the opportunity to convey other information than the media ID, 262 such as e.g. describing or naming media content explicitly. 264 4.4. Publishing Media Information from Conference Nodes 266 The SIP Event Package for Conference State [RFC4575] defines an XML 267 schema used for distribution of conference information. The schema 268 defines elements (among others) for users, endpoints and media. The 269 defined element contains a media ID attribute. This 270 attribute SHALL be used to carry generated media IDs. This means 271 that media ID only needs to be unique within an endpoint context and 272 referring clients MUST use both user, endpoint information and media 273 ID to uniquely identify media content. User and endpoint information 274 are relevant in a scenario covering multiple users and/or endpoints 275 (e.g. where a middle node is responsible for forwarding requests or 276 making decisions about media content selection), but may be redundant 277 for a point to point scenario. 279 Any description or naming of individual media content published by 280 endpoints (as described in the previous section) SHOULD be included 281 in the XML as body of , which is another sub element of 282 . There may exist alternatives to obtain naming and 283 description information, but it will in general depend on what is 284 supported by the used media description protocol. 286 4.5. Receiving Media Information 288 Reception of media content information is dependent upon in what 289 context the endpoint exists. In a conferencing scenario, the 290 distribution of media information is in general different than 291 distribution of media content information in a point to point 292 session, which must be taken into account when defining use of MESS 293 with media description protocols. 295 4.6. RTP Media Transport 297 When RTP is used for transmission of media content, a single RTP 298 session can transfer a number of different media content. In such 299 case every received data packet must carry an identifier, or 300 something that can be used as identifier, to separate individual 301 content. Without such an identifier it is simply not possible to 302 demultiplex incoming packets correctly. Using other protocols for 303 transmission offers similar problems when multiplexing. 305 In the case of RTP, SSRC could be used as the sole identifier, but to 306 avoid changing ID if the SSRC changes (e.g. due to an SSRC collision) 307 an identifier not dependent on, but related to, SSRC is the best 308 choice. 310 RFC 4575 [RFC4575], a sub element of defines an element 311 that MUST be used to carry the SSRC selected for the 312 corresponding media content. This enables an endpoint to do reverse 313 look-up of media ID on incoming packets using SSRC, or CSRC in the 314 case media streams are aggregated by an RTP mixer. 316 4.7. SDP Media Description 318 This section applies when SDP media description is used with RTP 319 Media Transport. Use of MESS with other media transport in SDP MAY 320 be used, but that is out of scope for this document and SHOULD 321 instead be described in a separate RFC. 323 The generated RTP media IDs MUST be included as ssrc attributes 324 (described in Source-Specific SDP Attributes [RFC5576]). 326 Assuming a single media in an SDP media block, using an i-line (as 327 described in SDP [RFC4566]) is sufficient to name an individual media 328 content. If a media block carries information about multiple SSRCs, 329 this method is not enough to name all different media content. For 330 this purpose a new source-specific attribute is proposed (previously 331 mentioned in draft-lennox-mmusic-sdp-source-selection-02). 332 a=ssrc: information: 334 The new, optional, source-specific attribute, with identical syntax 335 and semantics of as the i-line in 336 SDP, except that it is specified per SSRC, provides a textual 337 description of the media content represented by the SSRC included in 338 the attribute declaration. 340 In the case of RTP, an intercepting node in the network could be 341 responsible for generating media descriptions upon reception of the 342 actual RTP stream. However, such a solution will suffer from the 343 fact that not all media may be sent to that node at all times. This 344 would introduce a delay of media description creation until the 345 intercepting node has received RTP packets from all media sources. 347 In cases where a Media Gateway and it's controller are separate 348 entities (see e.g. Media Gateway Control Protocol [RFC3435]), such 349 as in 3GPP IMS split architecture where MRFP and an MRFC exchange SDP 350 information, e.g. through H.248 or SIP, the MRFC receives the SIP 351 INVITE with SDP from participants and therefore also information 352 about what SSRCs the endpoint intends to use. The MRFP will see 353 incoming SSRCs in the actual RTP streams, but not before any media 354 traffic has occurred. The MRFC is also responsible for publishing 355 the conference XML data [RFC4575], e.g. as a body in SIP NOTIFY to 356 SUBSCRIBE'd endpoints. In short, the MRFC, or any other node acting 357 as Conference AS, has the best information for generating and 358 distributing media IDs and is chosen as the responsible node. 360 There is no big difference in a call-out conferencing scenario where 361 a conferencing node calls out to invited participants. The initial 362 SDP will hold information about the capabilities of the network node 363 and responding endpoints provide answer SDP's with media description 364 (including SSRC) of there intended/offered media. 366 In a distributed conference with several involved Conferencing AS'es, 367 and also if 3GPP IMS split architecture is not used, the protocol to 368 transfer media ID and SSRC information between Conferencing AS'es / 369 MRFC's is out of scope for this document. 371 A conference node SHOULD try to locate information from endpoints 372 that name or describe individual media content in the SDP, and 373 include the information in the body of the per-media 374 tag. The information SHOULD be taken from, in this order if more 375 preferred information is missing: 377 1. The value from an "information" SSRC attribute described above 379 2. The value from an i-line within the media block 381 3. The value field of a label attribute [RFC4574] within the media 382 block 384 4. The value from an i-line at the SDP session level 386 Other sources of information MAY be used, MAY be more preferred, and 387 the MAY also be empty. The receiving client MAY e.g. 389 use the content to amend originating user/endpoint 390 information presented to the receiving user with the media content 391 specific information. 393 4.7.1. Point to Point Communication 395 In point to point communication, endpoints could publish SSRC 396 information using SDP in request and response. This is e.g. valid 397 for the SDP in both the SIP INVITE and the corresponding 200 OK, or 398 in any provisional responses. 400 The list of published SSRCs is the list of offered media content 401 available for request. Also, the SDP can be searched for the 402 information attribute described in Section 4.4 to extract information 403 about naming of media content. 405 4.7.2. Conferencing Scenario 407 In a conferencing scenario, the media content information is 408 distributed using an XML body following the schema defined in 409 Conference package [RFC4575], e.g. carried by a SIP NOTIFY. For use 410 with SIP and once a client has SUBSCRIBEd for conference information, 411 it SHOULD be prepared to receive SIP NOTIFYs. If the SIP NOTIFY 412 carries this type of XML, the receiving endpoint can extract 413 information about media IDs and media content descriptions by finding 414 all elements in the received XML. This produces a valid 415 request list of available media ID's and their corresponding SSRC 416 values. 418 5. MESS Requests 420 To request media streams, a communication channel between the 421 endpoint and the node in control of the media streams needs to be 422 setup. This document describes use of SIP/SDP for this purpose, but 423 other methods MAY be used and SHOULD then be described in a separate 424 RFC. The basic requirements on the communication channel used for 425 MESS are to offer reliable transmission and a near real time 426 response. 428 5.1. Transport 430 Binary Floor Control Protocol is described in RFC 4582 [RFC4582]. 431 BFCP is a protocol that is likely to already be supported by 432 conference-aware nodes and clients. This makes it easy to extend 433 existing implementations to handle any new defined message. It also 434 uses a reliable transport. In the context of media stream selection 435 it is highly related and is thus regarded a feasible choice. 437 All MESS messages defined in this document are extensions to the 438 existing messages described in BFCP [RFC4582]. This means that they 439 are not dependent upon any other message and can be implemented 440 separately from legacy messages. 442 The legacy floor control functionality of BFCP requires additional 443 protocols to handle floor creation. That is not needed by MESS and 444 thus out of scope for this document. A possible way is described in 445 SDP for BFCP [RFC4583]. 447 5.2. BFCP Extensions 449 BFCP [RFC4582] defines 13 primitives used in BFCP. To implement MESS 450 as an extension to BFCP requires this set of primitives to be 451 extended with two other called "MediaSelection" having a value of 32 452 and "MediaSelectionAck" having a value of 33. MESS uses the same 453 common header, referred to as COMMON-HEADER, as defined in BFCP 454 [RFC4582]. The attributes also follows the same pattern as described 455 in that RFC, i.e. they are in the format Type-Length-Value. 456 +-------+----------------------+---------------------------+ 457 | Value | Primitive | Direction | 458 +-------+----------------------+---------------------------+ 459 | 32 | MediaSelection | FloorParticipant -> FCS | 460 | 33 | MediaSelectionAck | FCS -> FloorParticipant | 461 +-------+----------------------+---------------------------+ 462 FCS = Floor Control Server 464 Media Selection Primitives 466 Table 1: Media Selection Primitives 468 In addition to these new primitives, MESS also defines a set of new 469 attributes. 470 +------+--------------------------+-------------+ 471 | Type | Attribute | Format | 472 +------+--------------------------+-------------+ 473 | 32 | OPERATION | Unsigned16 | 474 | 33 | MEDIA-IDENTIFICATION | Grouped | 475 | 34 | CHANNEL-IDENTIFICATION | OctetString | 476 +------+--------------------------+-------------+ 478 Table 2: Media Selection Attributes 480 5.2.1. OPERATION 482 The following is the format of the OPERATION attribute. 484 0 1 2 3 485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |0 1 0 0 0 0 0|M|0 0 0 0 0 1 0 0| Operation id | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Operation id: This field contains a 16-bit vale that identifies an 491 operation to be performed. Defined entries in this document is 492 Include, Exclude, Substitute, Reset, and Reset All. 493 +-------+------------+ 494 | Value | Operation | 495 +-------+------------+ 496 | 0 | Include | 497 | 1 | Exclude | 498 | 2 | Substitute | 499 | 3 | Reset | 500 | 4 | Reset All | 501 +-------+------------+ 503 Table 3: MESS Operations 505 5.2.2. MEDIA-IDENTIFICATION 507 The MEDIA-IDENTIFICATION attribute is a grouped attribute consisting 508 of a header, referred to as MEDIA-IDENTIFICATION-HEADER with 509 identification type information followed by a sequence of other 510 MEDIA-IDENTIFICATION attributes. The following is the format of the 511 MEDIA-IDENTIFICATION-HEADER 512 0 1 2 3 513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |0 1 0 0 0 0 1|M| Length | ID Type | | 516 +-------------+-+---------------+---------------+ | 517 | | 518 / Media ID / 519 / +--------------------+ 520 | | Padding | 521 +------------------------------------------+--------------------+ 523 The ID Type field is a 8 bit field describing the type of media id. 524 Defined types in this document are: 525 +-------+------------+ 526 | Value | Type | 527 +-------+------------+ 528 | 0 | User | 529 | 1 | Endpoint | 530 | 2 | Media | 531 +-------+------------+ 532 Table 4: MESS Media Identification Types 534 The following describes the format of the grouped attribute. The 535 Media ID field will contain different information based on the ID 536 Type. The Media ID field in MEDIA-IDENTIFICATION attributes of type 537 "User" is only allowed to hold MEDIA-IDENTIFICATION of type 538 "Endpoint", and Media ID field in MEDIA-IDENTIFICATION attributes of 539 type "Endpoint" is only allowed to hold MEDIA-IDENTIFICATION 540 attributes of type "Media". The Media ID field in MEDIA- 541 IDENTIFICATION attributes of type "Media" holds the actual media ID 542 number. 544 This allows expression of tree-like identifications with attributes 545 of type User being root node with attributes of Endpoints as leafs 546 containing only attributes of type "Media". The following expresses 547 this relationship in ABNF [RFC5234] syntax. 548 MEDIA-IDENTIFICATION = (USER-SUB-IDENTIFICATION / 549 ENDPOINT-SUB-IDENTIFICATION / 550 MEDIA-SUB-IDENTIFICATION) 552 USER-SUB-IDENTIFICATION = (MEDIA-IDENTIFICATION-HEADER) 553 [ENDPOINT-SUB-IDENTIFICATION] 555 ENDPOINT-SUB-IDENTIFICATION = (MEDIA-IDENTIFICATION-HEADER) 556 [MEDIA-SUB-IDENTIFICATION] 558 MEDIA-SUB-IDENTIFICATION = (MEDIA-IDENTIFICATION-HEADER) 560 ABNF for MEDIA-IDENTIFICATION attribute 562 5.2.3. CHANNEL-IDENTIFICATION 564 The following is a description of the CHANNEL-IDENTIFICATION 565 attribute. 566 0 1 2 3 567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |0 1 0 0 0 1 0|M| Length | | 570 +-------------+-+---------------+ | 571 | | 572 / Channel Id / 573 / +--------------------+ 574 | | Padding | 575 +------------------------------------------+--------------------+ 577 This attribute is used to identify a specific channel to/from an 578 endpoint. 580 5.3. Defined Messages 582 MESS defines 5 messages used to control what media content to 583 receive. 585 Floor participants MAY use the messages in this clause without having 586 obtained a floor, and floor servers MAY accept the messages from 587 participants not owning the floor. When floor control is bypassed in 588 this way, the FLOOR-ID SHALL be ignored by receivers of this message 589 implementing this RFC, and senders implementing this RFC SHALL set it 590 to 0. 592 If a floor chair requires a floor participant to own the floor before 593 using the messages of this clause, they SHALL both follow regular 594 BFCP floor control procedures as defined in BFCP [RFC4582]. For 595 example, a floor participant not allowed to access the floor will 596 receive a BFCP Error message containing Error Code 5 (Not 597 authorized). 599 When a floor control server implementing this RFC sends a BFCP 600 SUPPORTED-PRIMITIVES attribute, the codes for messages defined in 601 this clause MUST be included in the Primitives list. 603 Extension attributes that may be defined in the future are referred 604 to as EXTENSION-ATTRIBUTE in the ABNF, similarly as was done in 605 section 5.3. of BFCP [RFC4582]. 607 5.3.1. MediaSelectionAck 609 All MediaSelectionMessages MUST be replied to with a 610 MediaSelectionAck. The format of the MediaSelectionAck is as 611 follows: 612 MediaSelectionAck = (COMMON-HEADER) 613 *[EXTENSION-ATTRIBUTE] 615 The COMMON-HEADER of such a message MUST contain the transaction id 616 of the acknowledged message. 618 5.3.2. Include 620 MESS Include messages are sent as BFCP messages with primitive "Media 621 Selection" and the OPERATION attribute set to value "Include". Then 622 follows a list of media identifications representing media streams 623 that are always to be included from now on. Since there might be 624 more than one transport channel in between the requesting node and 625 the receiving node, the message MAY also contain information about 626 which transport channel to use, a channel ID. In case RTP is used as 627 transport, this channel ID SHOULD be a combination of SSRC and RTP 628 session identification. If channel ID is missing there are no 629 restrictions on the used transport and any transport channel MAY be 630 used to deliver the stream. Other transports are out of scope for 631 this document but need a similar identification possibility. 632 Requests to Include an already included media SHALL be ignored. Note 633 that the message is defined in a way that makes it additive and 634 identifications for previously included media SHOULD NOT be included 635 for every new request. 637 A receiver of an include message MUST respond with a 638 MediaSelectionAck containing the same transaction id. 639 Include = (COMMON-HEADER) 640 1*(FLOOR-ID) 641 (OPERATION) 642 1*(MEDIA-IDENTIFICATION) 643 1*(CHANNEL-IDENTIFICATION) 644 *[EXTENSION-ATTRIBUTE] 646 5.3.3. Exclude 648 MESS Exclude messages are sent as BFCP messages with primitive "Media 649 Selection" and the OPERATION attribute set to value "Exclude". Then 650 follows a list of media identifications representing media streams 651 that are always to be excluded from now on. Requests to Exclude an 652 already excluded media SHALL be ignored. Note that the message is 653 defined in a way that makes it additive and identifications for 654 previously excluded media SHOULD NOT be included for every new 655 request. The exclude message MAY contain an optional channel ID 656 limiting the exclude message so that the excluded stream might be 657 sent using any other transport channel if available. If the channel 658 ID is missing in the exclude message this means that the exclude 659 concerns any channel between an endpoint and a sender. 660 Exclude = (COMMON-HEADER) 661 1*(FLOOR-ID) 662 (OPERATION) 663 1*(MEDIA-IDENTIFICATION) 664 1*(CHANNEL-IDENTIFICATION) 665 *[EXTENSION-ATTRIBUTE] 667 A receiver of an exclude message MUST respond with a 668 MediaSelectionAck containing the same transaction id. 670 5.3.4. Substitute 672 MESS Substitute messages are sent as BFCP messages with primitive 673 "Media Selection" and the OPERATION attribute set to "Substitute". 675 Then follows a list of pairs of tuples called MEDIA-TUPLE. A MEDIA- 676 TUPLE contains a MEDIA-IDENTIFICATION and an optional CHANNEL- 677 IDENTIFICATION. 679 The following is a formal description of MEDIA-TUPLE. 680 MEDIA-TUPLE = (MEDIA IDENTIFICATION) 681 1*(CHANNEL-IDENTIFICATION) 683 The following is a formal description of the Substitute message. 684 Substitute = (COMMON-HEADER) 685 1*(FLOOR-ID) 686 (OPERATION) 687 1*(MEDIA-TUPLE MEDIA-TUPLE) 688 *[EXTENSION-ATTRIBUTE] 690 In the list of pairs of MEDIA-TUPLEs, the pair MUST be interpret as 691 follows. The first MEDIA-TUPLE defines the media stream, and 692 possibly a transport channel, that should be replaced and the second 693 MEDIA-TUPLE defines the media stream, and optionally a transport 694 channel, to use as a replacement for the first MEDIA-TUPLE. 696 Note that the included MEDIA-INDENTIFICATIONs typically need to be of 697 type USER-SUB-IDENTIFICATION, since they in general do not refer to 698 media from the same user, but other addressing MAY be sufficient. 700 Since CHANNEL-IDENTIFICATION is optional and might be missing for any 701 MEDIA-TUPLE in the above description, such a missing attribute should 702 be interpreted as follows. 704 No Channel ID in any tuple: All media occurrences should be replaced 705 using the already used channels. This is the same as an atomic 706 version of a message series containing an exclude message and an 707 include message without CHANNEL-IDENTIFICATION attributes. 709 Channel ID in the replaced media tuple: Replace the identified media 710 only on the identified channel. This is the same as an atomic 711 version of a message series containing an exclude message with a 712 CHANNEL-IDENTIFICATION attribute and an include message without 713 CHANNEL-IDENTIFICATION attribute. 715 Channel Id present in the replacing media tuple: Replace all 716 occurrences of an identified media with the replacing media stream 717 using the identified channel. This is the same as an atomic 718 version of an exclude message without CHANNEL-IDENTIFICATION 719 attribute followed by an include message with a CHANNEL- 720 IDENTIFICATION. 722 Channel Id present in both media tuples: Replace the identified 723 media on the identified channel with the replacing media using the 724 identified channel. This is the same as an atomic version of an 725 exclude message followed by an include message, both holding a 726 CHANNEL-IDENTIFICATION attribute. 728 A receiver of a substitute message MUST respond with a 729 MediaSelectionAck containing the same transaction id. 731 5.3.5. Reset 733 MESS Reset messages are sent as BFCP messages with primitive "Media 734 Selection" and the OPERATION attribute set to "Reset". The message 735 carries a list of MEDIA-IDENTIFICATION to be reset. It does not 736 matter if the media described by MEDIA-IDENTIFICATION has been 737 excluded, included or neither of them before. The result at the 738 floor control is always the same, the media associated with the 739 received id will no longer be subject to explicit inclusion/ 740 exclusion. Requests to Reset an already reset media SHALL be 741 ignored. 743 A receiver of a reset message MUST respond with a MediaSelectionAck 744 containing the same transaction id. 745 Reset = (COMMON-HEADER) 746 1*(FLOOR-ID) 747 (OPERATION) 748 1*(MEDIA-IDENTIFICATION) 749 *[EXTENSION-ATTRIBUTE] 751 5.3.6. Reset All 753 MESS Reset All messages are sent as BFCP messages with primitive 754 "Media Selection" and the OPERATION attribute set to "Reset All". It 755 has no attributes. The message is equivalent to a MESS Reset message 756 including MEDIA-IDENTIFICATION attributes of all streams that have 757 previously been specified in "Include", "Exclude" or as second MEDIA- 758 IDENTIFICATION attribute in "Substitute", effectively releasing all 759 existing media streams from being subject to inclusion/exclusion. 760 This operation can fully reset the inclusion/exclusion state even if 761 the requesting endpoint has lost track of what restrictions were 762 previously put. 763 Reset All = (COMMON-HEADER) 764 1*(FLOOR-ID) 765 (OPERATION) 766 *[EXTENSION-ATTRIBUTE] 768 A receiver of a reset all message MUST respond with a 769 MediaSelectionAck containing the same transaction id. 771 6. MESS Responses 773 This document does define an acknowledge response (Section 5.3.1) as 774 well as an error message with several different error reasons. 776 BFCP [RFC4582] defines attributes for error handling. The BFCP Error 777 message in BFCP section 5.3.13 [RFC4582] SHALL be used also for error 778 reporting applicable to this RFC. 780 BFCP [RFC4582] Table 5 defines 9 error codes used in floor control. 781 This document defines the following additional error codes that MAY 782 be used in MESS responses: 783 +--------+-------------------------------------+ 784 | Value | Meaning | 785 +--------+-------------------------------------+ 786 | 16 | Media does not exist | 787 | 17 | Endpoint does not exist | 788 | 18 | Cannot include media | 789 | 20 | Cannot exclude media | 790 | 21 | Cannot substitute media | 791 +--------+-------------------------------------+ 793 Table 5: Media Selection Error Codes 795 The exact reason for the failure MAY be included as UTF8 encoded text 796 in the field "Error specific details" of the BFCP ERROR-CODE 797 attribute. The ERROR-INFO attribute MAY also be used. 799 7. RTP Implications 801 RTP is a widely used protocol to transfer media. Usage of MESS when 802 media transport is handled using RTP might impact how RTCP reports 803 must be handled when excluding media. In the case where RTP 804 Translators [RFC5117] exists in between endpoints and if the RTP 805 Transport Translators are able to adjust their forwarding rules based 806 on the signalling defined in this document, RTCP reporting may become 807 inconsistent for excluded media content. How this should be handled 808 is out of scope for this document. The operations described in MESS 809 are consistent with the operation of RTP mixers or direct end-point 810 to end-point topologies. 812 8. Examples 814 Note that the SDP in the examples below is not complete. Only 815 relevant parts have been included. 817 8.1. Client joins a conference 819 A clients joins a conference by sending an SDP according to the 820 following: 821 s=MESS Example Client 822 m=audio 49200 RTP/AVP 96 823 a=rtpmap:96 G719/48000/2 824 a=ssrc:521923924 cname:alice@foo.example.com 825 a=mid:1 826 m=video 49300 RTP/AVP 96 827 a=rtpmap:96 H264/90000 828 a=ssrc:834753488 cname:alice@foo.example.com 829 a=ssrc:834753488 information:"Alice cam" 830 a=label:main video 831 a=mid:2 832 a=content:main 833 m=application 50000 TCP/BFCP * 834 a=setup:passive 835 a=connection:new 837 In this SDP Alice explicitly names her video stream "Alice cam" by 838 using the new attribute defined in this document. This information 839 is associated with a specific SSRC. 841 A conferencing node in the network then sends the following SIP 842 NOTIFY sample body to subscribed clients. 844 845 849 850 851 852 853 Alice 854 855 857 connected 858 859 860 861 Alice cam 862 Video 863 864 834753488 865 sendrecv 866 867 868 869 870 871 872 873 874 876 Any subscribing endpoint that receives this information can now 877 actively request the "Alice cam" media from sip:alice@example.com to 878 be explicitly included in received media streams. This is done by 879 sending an Include message as defined in this document (some fields 880 not encoded for clarity): 882 0 1 2 3 883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 |0 0 1|0 0 0 0 0|0 0 1 0 0 0 0 0| Payload Length | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Conference ID | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Transaction ID | User ID | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 |0 1 0 0 0 0 0|1|0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |0 1 0 0 0 0 1|1|0 0 0 1 0 1 0 1|0 0 0 0 0 0 0 0| | 896 +-------------+-+---------------+---------------+ | 897 | | 898 / sip:alice@example.com / 899 / +--------------------+ 900 | | Padding | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 |0 1 0 0 0 0 1|1| Length |0 0 0 0 0 0 0 1| | 903 +-------------+-+---------------+---------------+ | 904 | | 905 / sip:4kfk4j392jsu@example.com;grid=433kj4j3u / 906 / +--------------------+ 907 | | Padding | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 |0 1 0 0 0 0 1|1| Length |0 0 0 0 0 0 1 1| | 910 +-------------+-+---------------+---------------+ | 911 | | 912 / 1 / 913 / +--------------------+ 914 | | Padding | 915 +------------------------------------------+--------------------+ 916 |0 1 0 0 0 1 0|1| Length | | 917 +-------------+-+---------------+ | 918 | Channel Id +--------------------+ 919 | | Padding | 920 +------------------------------------------+--------------------+ 922 The receiver of this message MUST send an acknowledgement using the 923 same transaction ID as soon as possible. 925 9. IANA Considerations 927 Following the guidelines in SDP [RFC4566], in SDP Grouping Framework 928 [RFC5888] and in RTP [RFC3550], the IANA is requested to register: 930 A new source-specific attribute named "information" as defined in 931 Section 4.3. 933 Add the following entries to the BFCP [RFC4582] registry: 935 o Primitives from Table 1 937 o Attributes from Table 2 939 o Error Codes from Table 5 941 Start a new registry for this document with: 943 o Operations from Table 3 945 o Media Identification Types from Table 4 947 10. Security Considerations 949 When using MESS there is a potential risk of exposing client behavior 950 to other participants. Consider the case where multiple endpoints 951 participates in a conference. Also assume that media transport is 952 done using RTP. If the network between endpoints contains one (or 953 more) RTP translators and even if MESS communication is strictly 954 between floor server and floor participant, the RTCP traffic to/from 955 endpoints could expose information about endpoints excluding other 956 endpoints. Previously received RTCP traffic replaced with no traffic 957 could be leaking information about an endpoint excluding other 958 endpoints. 960 11. Acknowledgements 962 Jonanthan Lennox and Henning Schulzrinne for their proposal of a 963 source-specific information attribute in the expired Internet Draft 964 draft-lennox-mmusic-sdp-source-selection-02. 966 12. References 968 12.1. Normative References 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, March 1997. 973 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 974 Jacobson, "RTP: A Transport Protocol for Real-Time 975 Applications", STD 64, RFC 3550, July 2003. 977 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 978 Description Protocol", RFC 4566, July 2006. 980 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 981 Initiation Protocol (SIP) Event Package for Conference 982 State", RFC 4575, August 2006. 984 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 985 Control Protocol (BFCP)", RFC 4582, November 2006. 987 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 988 Specifications: ABNF", STD 68, RFC 5234, January 2008. 990 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 991 Media Attributes in the Session Description Protocol 992 (SDP)", RFC 5576, June 2009. 994 12.2. Informative References 996 [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control 997 Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 999 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1000 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1002 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 1003 for Binary Floor Control Protocol (BFCP) Streams", 1004 RFC 4583, November 2006. 1006 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1007 January 2008. 1009 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1010 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1012 Authors' Addresses 1014 Daniel Grondal 1015 Ericsson AB 1016 Farogatan 6 1017 SE - 164 80 Kista, 1018 Sweden 1020 Phone: +46107147505 1021 Fax: +46107175550 1022 Email: daniel.grondal@ericsson.com 1023 URI: www.ericsson.com 1025 Bo Burman 1026 Ericsson AB 1027 Farogatan 6 1028 SE - 164 90 Kista, 1029 Sweden 1031 Phone: +46107141311 1032 Fax: +46107175550 1033 Email: bo.burman@ericsson.com 1034 URI: www.ericsson.com 1036 Magnus Westerlund 1037 Ericsson AB 1038 Farogatan 6 1039 SE- Kista 164 90, 1040 Sweden 1042 Phone: +46107148287 1043 Fax: 1044 Email: magnus.westerlund@ericsson.com 1045 URI: www.ericsson.com