Internet DRAFT - draft-westerlund-dispatch-stream-selection
draft-westerlund-dispatch-stream-selection
Network Working Group D. Grondal
Internet-Draft B. Burman
Intended status: Standards Track M. Westerlund
Expires: April 26, 2012 Ericsson AB
October 24, 2011
Media Stream Selection (MESS)
draft-westerlund-dispatch-stream-selection-00
Abstract
This document describes how media stream selection can be achieved in
both a conferencing scenario and peer to peer communication. To
allow endpoints to select specific media streams, all available media
in the session must be identifiable and there is a need for messages
than can be securely transported between endpoints and network nodes.
This document also describes a way to distribute the identification
information to all participating endpoints. The necessary messages
can potentially be mapped onto several different encodings, and this
document proposes one mapping that uses an extended version of the
Binary Floor Control Protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Grondal, et al. Expires April 26, 2012 [Page 1]
Internet-Draft MESS October 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Grondal, et al. Expires April 26, 2012 [Page 2]
Internet-Draft MESS October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases for MESS . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Include Media Content . . . . . . . . . . . . . . . . . . 5
3.2. Exclude Media Content . . . . . . . . . . . . . . . . . . 5
3.3. Substitute Media Content . . . . . . . . . . . . . . . . . 5
3.4. Reset Media Content . . . . . . . . . . . . . . . . . . . 6
3.5. Reset All . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Media Information . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Unique Media ID . . . . . . . . . . . . . . . . . . . . . 6
4.2. Distribution of Media Information . . . . . . . . . . . . 7
4.3. Publishing Media Information from Endpoints . . . . . . . 7
4.4. Publishing Media Information from Conference Nodes . . . . 7
4.5. Receiving Media Information . . . . . . . . . . . . . . . 7
4.6. RTP Media Transport . . . . . . . . . . . . . . . . . . . 8
4.7. SDP Media Description . . . . . . . . . . . . . . . . . . 8
4.7.1. Point to Point Communication . . . . . . . . . . . . . 10
4.7.2. Conferencing Scenario . . . . . . . . . . . . . . . . 10
5. MESS Requests . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. BFCP Extensions . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. OPERATION . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2. MEDIA-IDENTIFICATION . . . . . . . . . . . . . . . . . 12
5.2.3. CHANNEL-IDENTIFICATION . . . . . . . . . . . . . . . . 13
5.3. Defined Messages . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. MediaSelectionAck . . . . . . . . . . . . . . . . . . 14
5.3.2. Include . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.3. Exclude . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.4. Substitute . . . . . . . . . . . . . . . . . . . . . . 15
5.3.5. Reset . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.6. Reset All . . . . . . . . . . . . . . . . . . . . . . 17
6. MESS Responses . . . . . . . . . . . . . . . . . . . . . . . . 18
7. RTP Implications . . . . . . . . . . . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Client joins a conference . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Grondal, et al. Expires April 26, 2012 [Page 3]
Internet-Draft MESS October 2011
1. Introduction
Multimedia conferencing is becoming more and more important. The
setup up of a multimedia conference is well defined, using for
example SIP and SDP. However, as SIP/SDP is used for session setup
it leaves little or no dynamic control over what media content to
receive from other participants during the session. This document
targets this weakness and describes functionality that grants
receiving endpoints capabilities to dynamically select what
information and media content are received from other participating
clients.
1.1. Terminology
These terms are commonly used throughout the document:
Media Content: Media being sent from one specific media capture
device, such as a microphone for audio media, or video camera for
video media.
Endpoint: An device that handles media that either originates a
number of media content, terminates a number of media content, or
some combination of both. As an example, an RTP Mixer is
considered as an endpoint, while a simple RTP Translator that
simply forwards all input streams is not.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Motivation
In a communication scenario where one or more endpoints offers more
than one media content, but where a receiving endpoint cannot handle
all simultaneous media content at once, there may be a need for that
endpoint to actively and dynamically during an ongoing conference
select what content to receive. A typical scenario would be a video
conference where some endpoints have multiple cameras capturing
different aspects of a room and a receiving endpoint can only render
one video stream due to e.g. hardware limitations. Today, the only
way to solve this is to have an RTP mixer handle the conference and
let that choose one of the streams based on some criteria. It is up
to the RTP mixer implementation which stream to choose, but a common
criteria is some type of speaker activity.
Grondal, et al. Expires April 26, 2012 [Page 4]
Internet-Draft MESS October 2011
It would be possible to let the receiving endpoints to choose which
media content(s) to receive, given that endpoints publish information
about what media content is available to all other endpoints and if
there would exist a protocol to request specific media content from
other endpoints. This functionality is what Media Stream Selection
(MESS) described in this document targets. It describes how to
generate and distribute media content information in both
conferencing scenarios as well as in point to point sessions. It
also describes how to set up a control channel to send messages
between endpoints and finally defines a set of messages that can be
used to handle media content requests.
3. Use Cases for MESS
This section presents some typical use cases targeted by MESS. The
scenario is an endpoint participating in a conference, receiving
media from a centralized conference node. It is assumed that all
participating endpoints have published information about what media
content they are offering. There are more available media from other
participants in the conference than what the receiving endpoint in
the use case can present simultaneously, and the conference node has
some implemented policy how to select which media to forward.
3.1. Include Media Content
An endpoint selects what content to receive from another endpoint
based on that endpoint's published media content information. An
endpoint can make new decisions about what content to receive
dynamically at any time during the session.
3.2. Exclude Media Content
An endpoint wishes to stop receiving content from another endpoint
e.g. due to low quality or other reasons. The set of excluded media
during a session is subject to change and an endpoint can make new
decisions to exclude content dynamically at any time during the
session.
3.3. Substitute Media Content
An endpoint renders received media and wants to replace the received
media with some other available media content. It can be seen as an
atomic combination of the two use-cases above, first excluding one
media content and effectively replacing it by including another. And
endpoint can make new substitute decisions dynamically at any time
during the session.
Grondal, et al. Expires April 26, 2012 [Page 5]
Internet-Draft MESS October 2011
3.4. Reset Media Content
An endpoint no longer has any specific wish to always include or
always exclude a certain content, but wants to return the decision to
forward streams or not to the conference node. An endpoint can reset
any previously included or excluded stream at any time during the
session. At the beginning of the session, all media streams SHALL
have a state corresponding to being reset and thus be under the
conference node policy control.
3.5. Reset All
An endpoint wishes to remove all previous decisions about included
and excluded media. This method is a shortcut to avoid repeated
reset messages described in Section 3.4.
4. Media Information
To be able to identify the available media content, all different
content must be given a unique media ID. The given ID must also be
distributed to all participating endpoints. The following sections
describe how to generate such IDs and how to distribute them.
The text in SDP Media Description (Section 4.7) describes the
specific case where media description is signaled with SDP [RFC4566],
but other signaling methods MAY be used, in which case the mapping to
SDP-specific lines and attributes do not apply and other mandatory
mappings SHOULD instead be defined in a separate RFC.
The text in Section 4.6 describes the specific case when RTP
[RFC3550] is used for media transport. Other media transports MAY be
used, in which case the mapping to RTP does not apply and other
mandatory mappings SHOULD instead be defined in a separate RFC.
4.1. Unique Media ID
To request specific media content, all involved endpoints need to
agree on how to uniquely identify different content with a unique
media ID.
There is no particular algorithm specified how to generate unique
media IDs, as it will depend on which media transport is used. The
main requirements on such an algorithm are that media IDs are unique
among all communicating endpoints and that all endpoints share the
same definitions on what media streams are identified by what media
IDs.
Grondal, et al. Expires April 26, 2012 [Page 6]
Internet-Draft MESS October 2011
4.2. Distribution of Media Information
Assuming all available media content from all communicating endpoints
are associated with some kind of media ID, those media IDs need to be
distributed to endpoints wishing to actively control what content to
receive. There might also be other interesting per-media related
information that needs distribution, such as e.g. naming or
describing individual media content to aid selection.
4.3. Publishing Media Information from Endpoints
Endpoints wishing to join a session are responsible to send
information about media content they will make available to the other
party or parties. This is done by generating media IDs, or other
sufficiently unique identification that can be used for generation of
media IDs, for all transmitted media content. Depending on the
capabilities of the signaling protocol used, an endpoint can also
have the opportunity to convey other information than the media ID,
such as e.g. describing or naming media content explicitly.
4.4. Publishing Media Information from Conference Nodes
The SIP Event Package for Conference State [RFC4575] defines an XML
schema used for distribution of conference information. The schema
defines elements (among others) for users, endpoints and media. The
defined <media> element contains a media ID attribute. This
attribute SHALL be used to carry generated media IDs. This means
that media ID only needs to be unique within an endpoint context and
referring clients MUST use both user, endpoint information and media
ID to uniquely identify media content. User and endpoint information
are relevant in a scenario covering multiple users and/or endpoints
(e.g. where a middle node is responsible for forwarding requests or
making decisions about media content selection), but may be redundant
for a point to point scenario.
Any description or naming of individual media content published by
endpoints (as described in the previous section) SHOULD be included
in the XML as body of <display-text>, which is another sub element of
<media>. There may exist alternatives to obtain naming and
description information, but it will in general depend on what is
supported by the used media description protocol.
4.5. Receiving Media Information
Reception of media content information is dependent upon in what
context the endpoint exists. In a conferencing scenario, the
distribution of media information is in general different than
distribution of media content information in a point to point
Grondal, et al. Expires April 26, 2012 [Page 7]
Internet-Draft MESS October 2011
session, which must be taken into account when defining use of MESS
with media description protocols.
4.6. RTP Media Transport
When RTP is used for transmission of media content, a single RTP
session can transfer a number of different media content. In such
case every received data packet must carry an identifier, or
something that can be used as identifier, to separate individual
content. Without such an identifier it is simply not possible to
demultiplex incoming packets correctly. Using other protocols for
transmission offers similar problems when multiplexing.
In the case of RTP, SSRC could be used as the sole identifier, but to
avoid changing ID if the SSRC changes (e.g. due to an SSRC collision)
an identifier not dependent on, but related to, SSRC is the best
choice.
RFC 4575 [RFC4575], a sub element of <media> defines an element
<src-id> that MUST be used to carry the SSRC selected for the
corresponding media content. This enables an endpoint to do reverse
look-up of media ID on incoming packets using SSRC, or CSRC in the
case media streams are aggregated by an RTP mixer.
4.7. SDP Media Description
This section applies when SDP media description is used with RTP
Media Transport. Use of MESS with other media transport in SDP MAY
be used, but that is out of scope for this document and SHOULD
instead be described in a separate RFC.
The generated RTP media IDs MUST be included as ssrc attributes
(described in Source-Specific SDP Attributes [RFC5576]).
Assuming a single media in an SDP media block, using an i-line (as
described in SDP [RFC4566]) is sufficient to name an individual media
content. If a media block carries information about multiple SSRCs,
this method is not enough to name all different media content. For
this purpose a new source-specific attribute is proposed (previously
mentioned in draft-lennox-mmusic-sdp-source-selection-02).
a=ssrc:<ssrc> information:<description>
The new, optional, source-specific attribute, with identical syntax
and semantics of <description> as the i-line <session description> in
SDP, except that it is specified per SSRC, provides a textual
description of the media content represented by the SSRC included in
the attribute declaration.
Grondal, et al. Expires April 26, 2012 [Page 8]
Internet-Draft MESS October 2011
In the case of RTP, an intercepting node in the network could be
responsible for generating media descriptions upon reception of the
actual RTP stream. However, such a solution will suffer from the
fact that not all media may be sent to that node at all times. This
would introduce a delay of media description creation until the
intercepting node has received RTP packets from all media sources.
In cases where a Media Gateway and it's controller are separate
entities (see e.g. Media Gateway Control Protocol [RFC3435]), such
as in 3GPP IMS split architecture where MRFP and an MRFC exchange SDP
information, e.g. through H.248 or SIP, the MRFC receives the SIP
INVITE with SDP from participants and therefore also information
about what SSRCs the endpoint intends to use. The MRFP will see
incoming SSRCs in the actual RTP streams, but not before any media
traffic has occurred. The MRFC is also responsible for publishing
the conference XML data [RFC4575], e.g. as a body in SIP NOTIFY to
SUBSCRIBE'd endpoints. In short, the MRFC, or any other node acting
as Conference AS, has the best information for generating and
distributing media IDs and is chosen as the responsible node.
There is no big difference in a call-out conferencing scenario where
a conferencing node calls out to invited participants. The initial
SDP will hold information about the capabilities of the network node
and responding endpoints provide answer SDP's with media description
(including SSRC) of there intended/offered media.
In a distributed conference with several involved Conferencing AS'es,
and also if 3GPP IMS split architecture is not used, the protocol to
transfer media ID and SSRC information between Conferencing AS'es /
MRFC's is out of scope for this document.
A conference node SHOULD try to locate information from endpoints
that name or describe individual media content in the SDP, and
include the information in the body of the per-media <display-text>
tag. The information SHOULD be taken from, in this order if more
preferred information is missing:
1. The value from an "information" SSRC attribute described above
2. The value from an i-line within the media block
3. The value field of a label attribute [RFC4574] within the media
block
4. The value from an i-line at the SDP session level
Other sources of information MAY be used, MAY be more preferred, and
the <display-text> MAY also be empty. The receiving client MAY e.g.
Grondal, et al. Expires April 26, 2012 [Page 9]
Internet-Draft MESS October 2011
use the <display-text> content to amend originating user/endpoint
information presented to the receiving user with the media content
specific information.
4.7.1. Point to Point Communication
In point to point communication, endpoints could publish SSRC
information using SDP in request and response. This is e.g. valid
for the SDP in both the SIP INVITE and the corresponding 200 OK, or
in any provisional responses.
The list of published SSRCs is the list of offered media content
available for request. Also, the SDP can be searched for the
information attribute described in Section 4.4 to extract information
about naming of media content.
4.7.2. Conferencing Scenario
In a conferencing scenario, the media content information is
distributed using an XML body following the schema defined in
Conference package [RFC4575], e.g. carried by a SIP NOTIFY. For use
with SIP and once a client has SUBSCRIBEd for conference information,
it SHOULD be prepared to receive SIP NOTIFYs. If the SIP NOTIFY
carries this type of XML, the receiving endpoint can extract
information about media IDs and media content descriptions by finding
all <media> elements in the received XML. This produces a valid
request list of available media ID's and their corresponding SSRC
values.
5. MESS Requests
To request media streams, a communication channel between the
endpoint and the node in control of the media streams needs to be
setup. This document describes use of SIP/SDP for this purpose, but
other methods MAY be used and SHOULD then be described in a separate
RFC. The basic requirements on the communication channel used for
MESS are to offer reliable transmission and a near real time
response.
5.1. Transport
Binary Floor Control Protocol is described in RFC 4582 [RFC4582].
BFCP is a protocol that is likely to already be supported by
conference-aware nodes and clients. This makes it easy to extend
existing implementations to handle any new defined message. It also
uses a reliable transport. In the context of media stream selection
it is highly related and is thus regarded a feasible choice.
Grondal, et al. Expires April 26, 2012 [Page 10]
Internet-Draft MESS October 2011
All MESS messages defined in this document are extensions to the
existing messages described in BFCP [RFC4582]. This means that they
are not dependent upon any other message and can be implemented
separately from legacy messages.
The legacy floor control functionality of BFCP requires additional
protocols to handle floor creation. That is not needed by MESS and
thus out of scope for this document. A possible way is described in
SDP for BFCP [RFC4583].
5.2. BFCP Extensions
BFCP [RFC4582] defines 13 primitives used in BFCP. To implement MESS
as an extension to BFCP requires this set of primitives to be
extended with two other called "MediaSelection" having a value of 32
and "MediaSelectionAck" having a value of 33. MESS uses the same
common header, referred to as COMMON-HEADER, as defined in BFCP
[RFC4582]. The attributes also follows the same pattern as described
in that RFC, i.e. they are in the format Type-Length-Value.
+-------+----------------------+---------------------------+
| Value | Primitive | Direction |
+-------+----------------------+---------------------------+
| 32 | MediaSelection | FloorParticipant -> FCS |
| 33 | MediaSelectionAck | FCS -> FloorParticipant |
+-------+----------------------+---------------------------+
FCS = Floor Control Server
Media Selection Primitives
Table 1: Media Selection Primitives
In addition to these new primitives, MESS also defines a set of new
attributes.
+------+--------------------------+-------------+
| Type | Attribute | Format |
+------+--------------------------+-------------+
| 32 | OPERATION | Unsigned16 |
| 33 | MEDIA-IDENTIFICATION | Grouped |
| 34 | CHANNEL-IDENTIFICATION | OctetString |
+------+--------------------------+-------------+
Table 2: Media Selection Attributes
5.2.1. OPERATION
The following is the format of the OPERATION attribute.
Grondal, et al. Expires April 26, 2012 [Page 11]
Internet-Draft MESS October 2011
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0|M|0 0 0 0 0 1 0 0| Operation id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operation id: This field contains a 16-bit vale that identifies an
operation to be performed. Defined entries in this document is
Include, Exclude, Substitute, Reset, and Reset All.
+-------+------------+
| Value | Operation |
+-------+------------+
| 0 | Include |
| 1 | Exclude |
| 2 | Substitute |
| 3 | Reset |
| 4 | Reset All |
+-------+------------+
Table 3: MESS Operations
5.2.2. MEDIA-IDENTIFICATION
The MEDIA-IDENTIFICATION attribute is a grouped attribute consisting
of a header, referred to as MEDIA-IDENTIFICATION-HEADER with
identification type information followed by a sequence of other
MEDIA-IDENTIFICATION attributes. The following is the format of the
MEDIA-IDENTIFICATION-HEADER
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 1|M| Length | ID Type | |
+-------------+-+---------------+---------------+ |
| |
/ Media ID /
/ +--------------------+
| | Padding |
+------------------------------------------+--------------------+
The ID Type field is a 8 bit field describing the type of media id.
Defined types in this document are:
+-------+------------+
| Value | Type |
+-------+------------+
| 0 | User |
| 1 | Endpoint |
| 2 | Media |
+-------+------------+
Grondal, et al. Expires April 26, 2012 [Page 12]
Internet-Draft MESS October 2011
Table 4: MESS Media Identification Types
The following describes the format of the grouped attribute. The
Media ID field will contain different information based on the ID
Type. The Media ID field in MEDIA-IDENTIFICATION attributes of type
"User" is only allowed to hold MEDIA-IDENTIFICATION of type
"Endpoint", and Media ID field in MEDIA-IDENTIFICATION attributes of
type "Endpoint" is only allowed to hold MEDIA-IDENTIFICATION
attributes of type "Media". The Media ID field in MEDIA-
IDENTIFICATION attributes of type "Media" holds the actual media ID
number.
This allows expression of tree-like identifications with attributes
of type User being root node with attributes of Endpoints as leafs
containing only attributes of type "Media". The following expresses
this relationship in ABNF [RFC5234] syntax.
MEDIA-IDENTIFICATION = (USER-SUB-IDENTIFICATION /
ENDPOINT-SUB-IDENTIFICATION /
MEDIA-SUB-IDENTIFICATION)
USER-SUB-IDENTIFICATION = (MEDIA-IDENTIFICATION-HEADER)
[ENDPOINT-SUB-IDENTIFICATION]
ENDPOINT-SUB-IDENTIFICATION = (MEDIA-IDENTIFICATION-HEADER)
[MEDIA-SUB-IDENTIFICATION]
MEDIA-SUB-IDENTIFICATION = (MEDIA-IDENTIFICATION-HEADER)
ABNF for MEDIA-IDENTIFICATION attribute
5.2.3. CHANNEL-IDENTIFICATION
The following is a description of the CHANNEL-IDENTIFICATION
attribute.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1 0|M| Length | |
+-------------+-+---------------+ |
| |
/ Channel Id /
/ +--------------------+
| | Padding |
+------------------------------------------+--------------------+
This attribute is used to identify a specific channel to/from an
endpoint.
Grondal, et al. Expires April 26, 2012 [Page 13]
Internet-Draft MESS October 2011
5.3. Defined Messages
MESS defines 5 messages used to control what media content to
receive.
Floor participants MAY use the messages in this clause without having
obtained a floor, and floor servers MAY accept the messages from
participants not owning the floor. When floor control is bypassed in
this way, the FLOOR-ID SHALL be ignored by receivers of this message
implementing this RFC, and senders implementing this RFC SHALL set it
to 0.
If a floor chair requires a floor participant to own the floor before
using the messages of this clause, they SHALL both follow regular
BFCP floor control procedures as defined in BFCP [RFC4582]. For
example, a floor participant not allowed to access the floor will
receive a BFCP Error message containing Error Code 5 (Not
authorized).
When a floor control server implementing this RFC sends a BFCP
SUPPORTED-PRIMITIVES attribute, the codes for messages defined in
this clause MUST be included in the Primitives list.
Extension attributes that may be defined in the future are referred
to as EXTENSION-ATTRIBUTE in the ABNF, similarly as was done in
section 5.3. of BFCP [RFC4582].
5.3.1. MediaSelectionAck
All MediaSelectionMessages MUST be replied to with a
MediaSelectionAck. The format of the MediaSelectionAck is as
follows:
MediaSelectionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
The COMMON-HEADER of such a message MUST contain the transaction id
of the acknowledged message.
5.3.2. Include
MESS Include messages are sent as BFCP messages with primitive "Media
Selection" and the OPERATION attribute set to value "Include". Then
follows a list of media identifications representing media streams
that are always to be included from now on. Since there might be
more than one transport channel in between the requesting node and
the receiving node, the message MAY also contain information about
which transport channel to use, a channel ID. In case RTP is used as
transport, this channel ID SHOULD be a combination of SSRC and RTP
Grondal, et al. Expires April 26, 2012 [Page 14]
Internet-Draft MESS October 2011
session identification. If channel ID is missing there are no
restrictions on the used transport and any transport channel MAY be
used to deliver the stream. Other transports are out of scope for
this document but need a similar identification possibility.
Requests to Include an already included media SHALL be ignored. Note
that the message is defined in a way that makes it additive and
identifications for previously included media SHOULD NOT be included
for every new request.
A receiver of an include message MUST respond with a
MediaSelectionAck containing the same transaction id.
Include = (COMMON-HEADER)
1*(FLOOR-ID)
(OPERATION)
1*(MEDIA-IDENTIFICATION)
1*(CHANNEL-IDENTIFICATION)
*[EXTENSION-ATTRIBUTE]
5.3.3. Exclude
MESS Exclude messages are sent as BFCP messages with primitive "Media
Selection" and the OPERATION attribute set to value "Exclude". Then
follows a list of media identifications representing media streams
that are always to be excluded from now on. Requests to Exclude an
already excluded media SHALL be ignored. Note that the message is
defined in a way that makes it additive and identifications for
previously excluded media SHOULD NOT be included for every new
request. The exclude message MAY contain an optional channel ID
limiting the exclude message so that the excluded stream might be
sent using any other transport channel if available. If the channel
ID is missing in the exclude message this means that the exclude
concerns any channel between an endpoint and a sender.
Exclude = (COMMON-HEADER)
1*(FLOOR-ID)
(OPERATION)
1*(MEDIA-IDENTIFICATION)
1*(CHANNEL-IDENTIFICATION)
*[EXTENSION-ATTRIBUTE]
A receiver of an exclude message MUST respond with a
MediaSelectionAck containing the same transaction id.
5.3.4. Substitute
MESS Substitute messages are sent as BFCP messages with primitive
"Media Selection" and the OPERATION attribute set to "Substitute".
Grondal, et al. Expires April 26, 2012 [Page 15]
Internet-Draft MESS October 2011
Then follows a list of pairs of tuples called MEDIA-TUPLE. A MEDIA-
TUPLE contains a MEDIA-IDENTIFICATION and an optional CHANNEL-
IDENTIFICATION.
The following is a formal description of MEDIA-TUPLE.
MEDIA-TUPLE = (MEDIA IDENTIFICATION)
1*(CHANNEL-IDENTIFICATION)
The following is a formal description of the Substitute message.
Substitute = (COMMON-HEADER)
1*(FLOOR-ID)
(OPERATION)
1*(MEDIA-TUPLE MEDIA-TUPLE)
*[EXTENSION-ATTRIBUTE]
In the list of pairs of MEDIA-TUPLEs, the pair MUST be interpret as
follows. The first MEDIA-TUPLE defines the media stream, and
possibly a transport channel, that should be replaced and the second
MEDIA-TUPLE defines the media stream, and optionally a transport
channel, to use as a replacement for the first MEDIA-TUPLE.
Note that the included MEDIA-INDENTIFICATIONs typically need to be of
type USER-SUB-IDENTIFICATION, since they in general do not refer to
media from the same user, but other addressing MAY be sufficient.
Since CHANNEL-IDENTIFICATION is optional and might be missing for any
MEDIA-TUPLE in the above description, such a missing attribute should
be interpreted as follows.
No Channel ID in any tuple: All media occurrences should be replaced
using the already used channels. This is the same as an atomic
version of a message series containing an exclude message and an
include message without CHANNEL-IDENTIFICATION attributes.
Channel ID in the replaced media tuple: Replace the identified media
only on the identified channel. This is the same as an atomic
version of a message series containing an exclude message with a
CHANNEL-IDENTIFICATION attribute and an include message without
CHANNEL-IDENTIFICATION attribute.
Channel Id present in the replacing media tuple: Replace all
occurrences of an identified media with the replacing media stream
using the identified channel. This is the same as an atomic
version of an exclude message without CHANNEL-IDENTIFICATION
attribute followed by an include message with a CHANNEL-
IDENTIFICATION.
Grondal, et al. Expires April 26, 2012 [Page 16]
Internet-Draft MESS October 2011
Channel Id present in both media tuples: Replace the identified
media on the identified channel with the replacing media using the
identified channel. This is the same as an atomic version of an
exclude message followed by an include message, both holding a
CHANNEL-IDENTIFICATION attribute.
A receiver of a substitute message MUST respond with a
MediaSelectionAck containing the same transaction id.
5.3.5. Reset
MESS Reset messages are sent as BFCP messages with primitive "Media
Selection" and the OPERATION attribute set to "Reset". The message
carries a list of MEDIA-IDENTIFICATION to be reset. It does not
matter if the media described by MEDIA-IDENTIFICATION has been
excluded, included or neither of them before. The result at the
floor control is always the same, the media associated with the
received id will no longer be subject to explicit inclusion/
exclusion. Requests to Reset an already reset media SHALL be
ignored.
A receiver of a reset message MUST respond with a MediaSelectionAck
containing the same transaction id.
Reset = (COMMON-HEADER)
1*(FLOOR-ID)
(OPERATION)
1*(MEDIA-IDENTIFICATION)
*[EXTENSION-ATTRIBUTE]
5.3.6. Reset All
MESS Reset All messages are sent as BFCP messages with primitive
"Media Selection" and the OPERATION attribute set to "Reset All". It
has no attributes. The message is equivalent to a MESS Reset message
including MEDIA-IDENTIFICATION attributes of all streams that have
previously been specified in "Include", "Exclude" or as second MEDIA-
IDENTIFICATION attribute in "Substitute", effectively releasing all
existing media streams from being subject to inclusion/exclusion.
This operation can fully reset the inclusion/exclusion state even if
the requesting endpoint has lost track of what restrictions were
previously put.
Reset All = (COMMON-HEADER)
1*(FLOOR-ID)
(OPERATION)
*[EXTENSION-ATTRIBUTE]
Grondal, et al. Expires April 26, 2012 [Page 17]
Internet-Draft MESS October 2011
A receiver of a reset all message MUST respond with a
MediaSelectionAck containing the same transaction id.
6. MESS Responses
This document does define an acknowledge response (Section 5.3.1) as
well as an error message with several different error reasons.
BFCP [RFC4582] defines attributes for error handling. The BFCP Error
message in BFCP section 5.3.13 [RFC4582] SHALL be used also for error
reporting applicable to this RFC.
BFCP [RFC4582] Table 5 defines 9 error codes used in floor control.
This document defines the following additional error codes that MAY
be used in MESS responses:
+--------+-------------------------------------+
| Value | Meaning |
+--------+-------------------------------------+
| 16 | Media does not exist |
| 17 | Endpoint does not exist |
| 18 | Cannot include media |
| 20 | Cannot exclude media |
| 21 | Cannot substitute media |
+--------+-------------------------------------+
Table 5: Media Selection Error Codes
The exact reason for the failure MAY be included as UTF8 encoded text
in the field "Error specific details" of the BFCP ERROR-CODE
attribute. The ERROR-INFO attribute MAY also be used.
7. RTP Implications
RTP is a widely used protocol to transfer media. Usage of MESS when
media transport is handled using RTP might impact how RTCP reports
must be handled when excluding media. In the case where RTP
Translators [RFC5117] exists in between endpoints and if the RTP
Transport Translators are able to adjust their forwarding rules based
on the signalling defined in this document, RTCP reporting may become
inconsistent for excluded media content. How this should be handled
is out of scope for this document. The operations described in MESS
are consistent with the operation of RTP mixers or direct end-point
to end-point topologies.
Grondal, et al. Expires April 26, 2012 [Page 18]
Internet-Draft MESS October 2011
8. Examples
Note that the SDP in the examples below is not complete. Only
relevant parts have been included.
8.1. Client joins a conference
A clients joins a conference by sending an SDP according to the
following:
s=MESS Example Client
m=audio 49200 RTP/AVP 96
a=rtpmap:96 G719/48000/2
a=ssrc:521923924 cname:alice@foo.example.com
a=mid:1
m=video 49300 RTP/AVP 96
a=rtpmap:96 H264/90000
a=ssrc:834753488 cname:alice@foo.example.com
a=ssrc:834753488 information:"Alice cam"
a=label:main video
a=mid:2
a=content:main
m=application 50000 TCP/BFCP *
a=setup:passive
a=connection:new
In this SDP Alice explicitly names her video stream "Alice cam" by
using the new attribute defined in this document. This information
is associated with a specific SSRC.
A conferencing node in the network then sends the following SIP
NOTIFY sample body to subscribed clients.
Grondal, et al. Expires April 26, 2012 [Page 19]
Internet-Draft MESS October 2011
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="full" version="1">
<!-- OTHER CONFERENCE INFO -->
<users>
<!-- USER -->
<user entity="sip:alice@example.com" state="full">
<display-text>Alice</display-text>
<!-- ENDPOINTS -->
<endpoint
entity="sip:4kfk4j392jsu@example.com;grid=433kj4j3u">
<status>connected</status>
<!-- MORE INFORMATION -->
<!-- MEDIA -->
<media id="1">
<display-text>Alice cam</display-text>
<type>Video</type>
<label>main video</label>
<src-id>834753488</src-id>
<status>sendrecv</status>
</media>
<!- POSSIBLY ADDITIONAL MEDIA -->
</endpoint>
<!-- POSSIBLY ADDITIONAL ENDPOINTS -->
</user>
<!-- ADDITIONAL USERS -->
</users>
<!-- ADDITIONAL ELEMENTS -->
</conference-info>
Any subscribing endpoint that receives this information can now
actively request the "Alice cam" media from sip:alice@example.com to
be explicitly included in received media streams. This is done by
sending an Include message as defined in this document (some fields
not encoded for clarity):
Grondal, et al. Expires April 26, 2012 [Page 20]
Internet-Draft MESS October 2011
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1|0 0 0 0 0|0 0 1 0 0 0 0 0| Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 1|1|0 0 0 1 0 1 0 1|0 0 0 0 0 0 0 0| |
+-------------+-+---------------+---------------+ |
| |
/ sip:alice@example.com /
/ +--------------------+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 1|1| Length |0 0 0 0 0 0 0 1| |
+-------------+-+---------------+---------------+ |
| |
/ sip:4kfk4j392jsu@example.com;grid=433kj4j3u /
/ +--------------------+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 1|1| Length |0 0 0 0 0 0 1 1| |
+-------------+-+---------------+---------------+ |
| |
/ 1 /
/ +--------------------+
| | Padding |
+------------------------------------------+--------------------+
|0 1 0 0 0 1 0|1| Length | |
+-------------+-+---------------+ |
| Channel Id +--------------------+
| | Padding |
+------------------------------------------+--------------------+
The receiver of this message MUST send an acknowledgement using the
same transaction ID as soon as possible.
9. IANA Considerations
Following the guidelines in SDP [RFC4566], in SDP Grouping Framework
[RFC5888] and in RTP [RFC3550], the IANA is requested to register:
Grondal, et al. Expires April 26, 2012 [Page 21]
Internet-Draft MESS October 2011
A new source-specific attribute named "information" as defined in
Section 4.3.
Add the following entries to the BFCP [RFC4582] registry:
o Primitives from Table 1
o Attributes from Table 2
o Error Codes from Table 5
Start a new registry for this document with:
o Operations from Table 3
o Media Identification Types from Table 4
10. Security Considerations
When using MESS there is a potential risk of exposing client behavior
to other participants. Consider the case where multiple endpoints
participates in a conference. Also assume that media transport is
done using RTP. If the network between endpoints contains one (or
more) RTP translators and even if MESS communication is strictly
between floor server and floor participant, the RTCP traffic to/from
endpoints could expose information about endpoints excluding other
endpoints. Previously received RTCP traffic replaced with no traffic
could be leaking information about an endpoint excluding other
endpoints.
11. Acknowledgements
Jonanthan Lennox and Henning Schulzrinne for their proposal of a
source-specific information attribute in the expired Internet Draft
draft-lennox-mmusic-sdp-source-selection-02.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Grondal, et al. Expires April 26, 2012 [Page 22]
Internet-Draft MESS October 2011
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
12.2. Informative References
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams",
RFC 4583, November 2006.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
Grondal, et al. Expires April 26, 2012 [Page 23]
Internet-Draft MESS October 2011
Authors' Addresses
Daniel Grondal
Ericsson AB
Farogatan 6
SE - 164 80 Kista,
Sweden
Phone: +46107147505
Fax: +46107175550
Email: daniel.grondal@ericsson.com
URI: www.ericsson.com
Bo Burman
Ericsson AB
Farogatan 6
SE - 164 90 Kista,
Sweden
Phone: +46107141311
Fax: +46107175550
Email: bo.burman@ericsson.com
URI: www.ericsson.com
Magnus Westerlund
Ericsson AB
Farogatan 6
SE- Kista 164 90,
Sweden
Phone: +46107148287
Fax:
Email: magnus.westerlund@ericsson.com
URI: www.ericsson.com
Grondal, et al. Expires April 26, 2012 [Page 24]
