Internet DRAFT - draft-cazeaux-clue-sip-signaling
draft-cazeaux-clue-sip-signaling
Network Working Group S. Cazeaux
Internet-Draft E. Bertin
Intended status: Informational B. Chatras
Expires: September 28, 2012 France Telecom Orange
March 27, 2012
Requirements for ControLling mUltiple streams for tElepresence (CLUE)
signaling.
draft-cazeaux-clue-sip-signaling-01
Abstract
This document defines requirements relating to the design of CLUE
signaling. This document also proposes two alternative design
approaches to CLUE signaling.
Status of this Memo
This Internet-Draft is submitted to IETF 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 September 28, 2012.
Copyright Notice
Copyright (c) 2012 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
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.
Cazeaux, et al. Expires September 28, 2012 [Page 1]
Internet-Draft CLUE signaling requirements March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. CLUE signaling options . . . . . . . . . . . . . . . . . . . . 4
4.1. Option A: CLUE signaling based on SIP-SDP signaling
only . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Use of SDP fields . . . . . . . . . . . . . . . . . . 6
4.1.3. Examples of SDP . . . . . . . . . . . . . . . . . . . 7
4.1.4. Transport and format . . . . . . . . . . . . . . . . . 9
4.2. Option B1: media capture selection in a separate
protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Use of SDP fields . . . . . . . . . . . . . . . . . . 11
4.2.3. Examples of SDP . . . . . . . . . . . . . . . . . . . 11
4.2.4. Transport and format . . . . . . . . . . . . . . . . . 15
4.3. Option B2: media capture selection in a separate
protocol . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2. Use of SDP fields . . . . . . . . . . . . . . . . . . 17
4.3.3. Examples of SDP . . . . . . . . . . . . . . . . . . . 18
4.3.4. Transport and format . . . . . . . . . . . . . . . . . 22
4.4. Interoperability with legacy endpoints . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative references . . . . . . . . . . . . . . . . . . . 23
8.2. Informative references . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Cazeaux, et al. Expires September 28, 2012 [Page 2]
Internet-Draft CLUE signaling requirements March 2012
1. Introduction
The framework defined for Telepresence Multi-Streams
[I-D.ietf-clue-framework] in the context of CLUE introduces the need
to have CLUE messages, conveying CLUE data, exchanged between
telepresence endpoints. It is necessary to agree upon a signaling
protocol enabling these CLUE messages to be exchanged, taking into
account the existing SIP-SDP ecosystem.
This document first outlines signaling requirements to be met by the
CLUE protocol. Then the document proposes two approaches for the
design of this protocol.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119].
3. Requirements
The term of "solution" designates here the set of mechanisms that
allows endpoints to exchange CLUE-related information.
REQ-1 The solution MUST enable the implementation of the CLUE
framework described in [I-D.ietf-clue-framework], in
particular : CLUE data model, provider/consumer exchange.
REQ-2 The solution MUST allow session establishment between two
Telepresence endpoints, and between a Telepresence endpoint
and a Multipoint Control Unit (MCU). The solution MUST
support the establishment of symmetrical or asymmetrical
media streams between the Telepresence endpoints (or MCU).
REQ-3 The solution MUST enable interoperability with SIP legacy
endpoints, without requiring intermediary protocol
translation systems. At a minimum, the solution MUST enable
interoperability with legacy SIP audio endpoints (one audio
media stream) and SIP video endpoints (one audio media
stream, zero or one main video media stream, zero or one
presentation video media stream, zero or one BFCP stream).
Cazeaux, et al. Expires September 28, 2012 [Page 3]
Internet-Draft CLUE signaling requirements March 2012
REQ-4 The solution MUST enable interoperability with SIP legacy
endpoints, with a minimum number of offer-answer cycles.
REQ-5 The solution MUST NOT make any assumptions on the SIP
implementation level (besides [RFC3261]) of intermediary
systems that could be in the signaling path of a Telepresence
session (e.g. a Session Border Controller, SBC).
REQ-6 The solution MUST enable to discover whether a remote party
is CLUE-enabled or not.
REQ-7 The solution MUST rely on the SDP offer/answer model for any
CLUE data related to the definition of media streams. This
requirement in particular aims to enable intermediaries (such
as SBCs) to apply appropriate policies (e.g. QoS marking,
Bandwidth control ...), which require that SDP offers and
answers provide and accurate description of the actual media
streams.
REQ-8 The solution MUST take into account that a media capture
selection could result from the interaction with an end-user,
at any time during a session. The user interaction can
indeed occur between the provider capability advertisement
and the consumer selection, but also at any moment during the
established session.
REQ-9 The solution MUST NOT add new requirements regarding NAT
traversal compared to legacy video systems (NOTE : lesson
learned from BFCP over TCP).
REQ-10 The solution MUST be extensible in order to support future
evolution in a backward compatible manner.
Note that no requirement is placed regarding to the latency of the
CLUE messages exchanged between the provider and the consumer.
4. CLUE signaling options
4.1. Option A: CLUE signaling based on SIP-SDP signaling only
This option proposes an approach where the exchange of CLUE messages
(including all CLUE parameters) between the provider and the consumer
is solely based on the SDP O/A model as specified in [RFC3264]. The
SDP is used for the exchange of media stream descriptions and media
capture descriptions and selection.
Cazeaux, et al. Expires September 28, 2012 [Page 4]
Internet-Draft CLUE signaling requirements March 2012
4.1.1. Overview
An example message flow for CLUE session establishment is illustrated
below.
A B
| |
{A as provider} {B as consumer}
| |
|INVITE (SDP-O1:A-adv) |
|----------------------------------->|
| 200 OK (SDP-A1:B-conf)|
|<-----------------------------------|
|ACK |
|----------------------------------->|
| |
| |
{A as consumer} {B as provider}
| |
| INVITE (SDP-O2:B-adv+B-conf)|
|<-----------------------------------|
|200 OK (SDP-A2:A-conf+B-conf) |
|----------------------------------->|
| ACK|
|<-----------------------------------|
Figure 1
A-adv: A as a Provider advertises available media captures and
supported encoding options.
B-conf: B as a Consumer selects the media captures it wants to
receive from A and configure the encoding options to be applied by A
to the media streams
B-adv: B as a Provider advertises available media captures and
supported encoding options.
A-conf: A as a Consumer selects the media captures it wants to
receive from B and configure the encoding options to be applied by B
to the media streams
SDP is used for provider advertisement of available media captures
and supported encoding options. SDP is also used for consumer
selection of the media captures it wants to receive from the provider
and configure the encoding options to be applied by the provider to
the media streams. A change in media capture selection requires a
Cazeaux, et al. Expires September 28, 2012 [Page 5]
Internet-Draft CLUE signaling requirements March 2012
new SDP Offer/Answer cycle
The first SDP offer/answer cycle enables the CLUE exchange between A
as provider and B as consumer. The second SDP offer/answer cycle
enables the CLUE exchange between A as consumer and B as provider.
This second SDP offer/answer cycle completes the first one, so that
it can safely replace it.
It is worth noting that this option will not satisfy the following
requirements:
REQ-8: this option requires a complete SDP offer/answer cycle to
change media capture selection, thus requires to re-negotiate
(even if not actually required) the media streams.
REQ-9: the transmission of a SDP answer conveying a capture
selection cannot wait for a user action more than what a SIP
transaction timer allows.
4.1.2. Use of SDP fields
Media descriptions in a Provider announcement include the a=sendonly
attribute. Encoding options are represented by the <fmt> sub-fields
of the m= line and associated SDP attributes.
Media descriptions associated to selected media captures have the
a=recvonly attribute. Media descriptions associated to other media
captures are either omitted or included with the a=inactive
attribute. Encoding options are selected using regular SDP Offer/
Answer procedures.
There are two variants regarding media capture description and
selection:
1) Media capture of the same media type representing alternative
captures of the same CLUE type are represented by an m= line and
associated attributes (regular SDP attributes and CLUE-specific
attributes). One specific CLUE attribute tentatively called "clue-
capture" provides the list of media captures. Media capture
selection is performed by the Consumer through updating the value of
this specific CLUE attribute.
2) A media capture is represented by an m= line and associated
attributes (regular SDP attributes and CLUE-specific attributes).
Because of the one-to-one mapping between media captures and media
streams, the presence of the a=recvonly attribute is sufficient to
imply selection of the media capture.
Cazeaux, et al. Expires September 28, 2012 [Page 6]
Internet-Draft CLUE signaling requirements March 2012
4.1.3. Examples of SDP
The examples below show a negotiation between a typical 3-camera/
screen/microphone telepresence endpoint (acting as Provider below),
and a typical 1-camera/screen/microphone telepresence endpoint
(acting as Consumer below), based on the option 1) described in the
Section 4.1.2
An example of SDP for a Provider announcement illustrated below.
a=group:LS 1 6
a=group:LS 2 7
a=group:LS 3 8
m=video 10002 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:1
a=clue-attributes:
a=clue-capture{1:camera-left,2:full-scene,
3:composed-scene,4:speaker}
m=video 10003 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:2
a=clue-attributes:
a=clue-capture{1:camera-center,2:full-scene,
3:composed-scene,4:speaker}
m=video 10004 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:3
a=clue-attributes:
a=clue-capture{1:camera-right,2:full-scene,
3:composed-scene,4:speaker}
m=video 10006 RTP/AVP 96
a=sendonly
a=rtpmap:96 H264
Cazeaux, et al. Expires September 28, 2012 [Page 7]
Internet-Draft CLUE signaling requirements March 2012
a=content: slides
a=mid:5
a=clue-attributes
m=audio 10000 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:6
a=clue-attributes:
a=clue-capture{1:mic-left,2:speaker}
m=audio 10001 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:7
a=clue-attributes:
a=clue-capture{1:mic-center,2:speaker}
m=audio 10002 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:8
a=clue-attributes:
a=clue-capture{1:mic-right,2:speaker}
Cazeaux, et al. Expires September 28, 2012 [Page 8]
Internet-Draft CLUE signaling requirements March 2012
An example of SDP for a Consumer configuration is illustrated below.
a=group:LS 1 6
m=video 10002 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: main
a=mid:1
a=clue-attributes:
a=clue-capture{1:full-scene}
m=video 10006 RTP/AVP 96
a=inactive
a=rtpmap:96 H264
a=content: slides
a=mid:5
a=clue-attributes
m=audio 10000 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:6
a=clue-attributes:
a=clue-capture{1:speaker}
4.1.4. Transport and format
In this option, the CLUE protocol is entirely based on the SDP offer/
answer model as described in [RFC3264]. Thus the transport protocol
for CLUE messages is SIP, and the format of CLUE messages follows SDP
specifications.
4.2. Option B1: media capture selection in a separate protocol
This option proposes an approach where the exchange of CLUE messages
between the provider and the consumer related to media stream is
based on the SDP offer/answer model as described in [RFC3264], and
the exchange of CLUE messages related to media captures is based on a
dedicated channel (futher referred to as the CLUE channel).
Cazeaux, et al. Expires September 28, 2012 [Page 9]
Internet-Draft CLUE signaling requirements March 2012
4.2.1. Overview
An example message flow for a CLUE session establishment is
illustrated below.
A B
| |
{A as provider} {B as consumer}
| |
|INVITE (SDP-O1:A-adv) |
|----------------------------------->|
| 200 OK (SDP-A1:B-conf)|
|<-----------------------------------|
|ACK |
|----------------------------------->|
| |
| |
{A as consumer} {B as provider}
| |
| INVITE (SDP-O2:B-adv+B-conf)|
|<-----------------------------------|
|200 OK (SDP-A2:A-conf+B-conf) |
|----------------------------------->|
| ACK|
|<-----------------------------------|
| CLUE channel |
|<==================================>|
| |
Figure 4
A-adv: A as a Provider advertises available media captures and
supported encoding options.
B-conf: B as a Consumer configures the encoding options to be applied
by A to the media streams
B-adv: B as a Provider advertises available media captures and
supported encoding options.
A-conf: A as a Consumer configures the encoding options to be applied
by B to the media streams
The model of multiple SDP O/A cycles is the same than in option B.
The difference resides in the fact that the SDP B-conf and A-conf
don't enable media captures selection, they are just used for
encoding configuration . The media capture selection is performed
Cazeaux, et al. Expires September 28, 2012 [Page 10]
Internet-Draft CLUE signaling requirements March 2012
through a dedicated CLUE channel.
The CLUE channel enables each consumer to select what media capture
will be sent by the remote provider. A media capture selection does
not require making a SDP O/A cycle, unless a consumer whishes to
change an encoding option.
This option should satisfy all requirements.
4.2.2. Use of SDP fields
As for option A, media descriptions in a Provider announcement
include the a=sendonly attribute. Encoding options are represented
by the <fmt> sub-fields of the m= line and associated SDP attributes.
Media capture of the same media type representing alternative
captures of the same CLUE type are represented by an m= line and
associated attributes (regular SDP attributes and CLUE-specific
attributes). One specific CLUE attribute provides the list of media
captures.
This option B1 relies on the media capture identifier provided by the
specific CLUE attribute of the m= line and the media id provided by
the <mid> sub-field of the same m= line to perform the media capture
selection by the Consumer through the CLUE channel.
Media descriptions associated to selected media streams (selected by
a Consumer) have the a=recvonly attribute. Media descriptions
associated to other media captures are either omitted or included
with the a=inactive attribute. Encoding options are selected using
regular SDP Offer/Answer procedures.
4.2.3. Examples of SDP
The examples below show a negotiation between a typical 3-camera/
screen/microphone telepresence endpoint (acting as Provider below),
and a typical 1-camera/screen/microphone telepresence endpoint
(acting as Consumer below).
An example of SDP for a Provider announcement illustrated below.
m=video 10002 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:1
Cazeaux, et al. Expires September 28, 2012 [Page 11]
Internet-Draft CLUE signaling requirements March 2012
a=clue-attributes:
a=clue-capture{1:camera-left,2:full-scene,
3:composed-scene,4:speaker}
m=video 10003 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:2
a=clue-attributes:
a=clue-capture{1:camera-center,2:full-scene,
3:composed-scene,4:speaker}
m=video 10004 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:3
a=clue-attributes:
a=clue-capture{1:camera-right,2:full-scene,
3:composed-scene,4:speaker}
m=video 10006 RTP/AVP 96
a=sendonly
a=rtpmap:96 H264
a=content: slides
a=mid:5
a=clue-attributes
m=audio 10000 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:6
a=clue-attributes:
a=clue-capture{1:mic-left,2:speaker}
m=audio 10001 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:7
a=clue-attributes:
a=clue-capture{1:mic-center,2:speaker}
m=audio 10002 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
Cazeaux, et al. Expires September 28, 2012 [Page 12]
Internet-Draft CLUE signaling requirements March 2012
a=mid:8
a=clue-attributes:
a=clue-capture{1:mic-right,2:speaker}
An example of SDP for a Consumer configuration is illustrated below.
Cazeaux, et al. Expires September 28, 2012 [Page 13]
Internet-Draft CLUE signaling requirements March 2012
m=video 10002 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: main
a=mid:1
a=clue-attributes:
m=video 10003 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: main
a=mid:2
a=clue-attributes:
m=video 10004 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: main
a=mid:3
a=clue-attributes:
m=video 10006 RTP/AVP 96
a=inactive
a=rtpmap:96 H264
a=content: slides
a=mid:5
a=clue-attributes
m=audio 10000 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:6
a=clue-attributes:
m=audio 10001 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:7
a=clue-attributes:
m=audio 10002 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:8
a=clue-attributes:
Cazeaux, et al. Expires September 28, 2012 [Page 14]
Internet-Draft CLUE signaling requirements March 2012
4.2.4. Transport and format
In this option, the solution uses at least two protocol elements.
The first protocol element aims at handling the CLUE media streams
and the advertisement of the CLUE media captures. For this part, the
transport protocol of CLUE messages is SIP, and the format follows
SDP specifications.
The second protocol element (named hereafter the CLUE channel), aims
to handle the CLUE media capture configuration and selection. The
CLUE channel most likely relies on a separate protocol.
A possible design of the CLUE channel is to rely on the BFCP protocol
([RFC4582]) extended as defined in
[I-D.westerlund-dispatch-stream-selection].
4.3. Option B2: media capture selection in a separate protocol
This option is a variant of the previous one. With the use of a CLUE
channel to enable each consumer to make the media capture selection,
it is possible to consider a solution where a single SDP O/A cyle is
used for the initial negotiation of the media streams between the
parties. It enables to be again closer to regular SDP O/A cycle,
where the answerer will make the final choice of the encoding
options. This is also the main drawback of this solution, since
subsequent SDP O/A cycles will be necessary to enable the initial
offerer to make its own configuration of the encoding. However, the
usage of a single SDP O/A cycle may be sufficient for simple
configuration, for instance where only one encoding option is
advertised by a provider.
Cazeaux, et al. Expires September 28, 2012 [Page 15]
Internet-Draft CLUE signaling requirements March 2012
4.3.1. Signaling
An example message flow for a CLUE session establishment is
illustrated below.
A B
| |
| |
|INVITE (SDP-O1:A-adv + A-cap) |
|---------------------------------------->|
|200 OK (SDP-A1:{B-adv + A-conf} + B-conf)|
|<----------------------------------------|
|ACK |
|---------------------------------------->|
| |
| CLUE channel |
|<=======================================>|
| |
Figure 7
SDP-O1: This SDP provides the capabilities of A acting as a consumer
(A-cap, what A can receive) under the form of the number and
characteristics of media streams that A is able to receive. This
SDP also advertises the capabilities of A acting as a provider
(A-adv, what A can send). At this stage: A can receive and can
send.
SDP-A1: This SDP provides the configuration of A's capabilities,
corresponding to what B acting as consumer wants to receive from
A (B-conf, what B will receive). This SDP also provides the
configuration of B's capabilities acting as provider, on behalf
of A (A-conf, what A will receive). The A-conf is completed with
information that provide hints to A about B's capabilities as
providers (represented as {B-adv + A-conf} in the figure above).
More precisely, {B-adv + A-conf} is built as the configuration B
according to A's capabilities, and completed (under the form of
sdp attributes) with information about B's capabilities as
Provider (such as list of media capture B can send, for
instance).
At this stage : B will receive and send, A will receive and send.
After this SDP offer/answer cycle, A and B are able to send and
receive media through the media streams that have been
negotiated. Additionally, each entity (as consumer) know what
media captures can be sent by the remote provider (A-adv and
B-adv have been exchanged). However, no media capture selection
Cazeaux, et al. Expires September 28, 2012 [Page 16]
Internet-Draft CLUE signaling requirements March 2012
has been yet performed.
CLUE channel: The CLUE channel enables each consumer to perform
media content selection according to provider capabilities. The
use of this channel may be defined as optional. Indeed, without
exchange on CLUE channel, a provider will select a default media
capture for each negotiated media stream.
Subsequent SDP O/A cycles are not required, but may occur to enable A
or B wishes to update their respective capabilities (add or remove a
media stream for instance) or change their respective configuration.
In the sample below, A initiates a new SDP O/A cycle by sending a SDP
offer (SDP-O2) which repeats or updates its capabilities as provider
(A-adv) and provides its configuration of B's capabilities (based on
the B's provider capabilities advertised in SDP-A1) corresponding to
what A wants to receive from B. B responds with with a SDP answer
which repeats the configuration sent by A (A-conf) and repeats or
updates its configuration of what A will send based (B-conf) on the
advertisement provided by A (A-adv)
An example message flow to update an established session is
illustrated below.
A B
| ... |
| {established session} |
| |
|re-INVITE (SDP-O2:A-adv + A-conf) |
|---------------------------------------->|
|200 OK (SDP-A2:{B-adv + A-conf} + A-conf)|
|<----------------------------------------|
|ACK |
|---------------------------------------->|
| |
Figure 8
4.3.2. Use of SDP fields
Media descriptions in a Provider announcement include the a=sendonly
attribute. Encoding options are represented by the <fmt> sub-fields
of the m= line and associated SDP attributes. Media capture of the
same media type representing alternative captures of the same CLUE
type are represented by an m= line and associated attributes (regular
SDP attributes and CLUE-specific attributes). One specific CLUE
Cazeaux, et al. Expires September 28, 2012 [Page 17]
Internet-Draft CLUE signaling requirements March 2012
attribute provides the list of media captures. The media capture
identifier provided by the specific CLUE attribute of the m= line and
the media id provided by the <mid> sub-field of the same m= line are
used to perform the media capture selection by the Consumer through
the CLUE channel.
Media descriptions in a Consumer capability announcement include the
a=recvonly attribute. Encoding options are represented by the <fmt>
sub-fields of the m= line and associated SDP attributes. These media
descriptions don't include descriptions of media captures
Media descriptions associated to selected media streams (selected by
a Consumer) have the a=recvonly attribute. Media descriptions
associated to other media captures are either omitted or included
with the a=inactive attribute. Encoding options are selected using
regular SDP Offer/Answer procedures.
4.3.3. Examples of SDP
The examples below show a negotiation between a typical 3-camera/
screen/microphone telepresence endpoint (acting as Offerer below),
and a typical 1-camera/1-screen/1-microphone telepresence endpoint
(acting as Answerer below). The answerer is actually equipped with
two cameras (main and secondary cameras), but is able to use only one
simultaneously.
An example of initial SDP offer including Provider announcement and
Consumer capability is illustrated below.
; Provider announcement
m=video 10002 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:1
a=clue-attributes
a=clue-capture{1:camera-left,2:full-scene,
3:composed-scene,4:speaker}
m=video 10003 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:2
Cazeaux, et al. Expires September 28, 2012 [Page 18]
Internet-Draft CLUE signaling requirements March 2012
a=clue-attributes:
a=clue-capture{1:camera-center,2:full-scene,
3:composed-scene,4:speaker}
m=video 10004 RTP/AVP 96 97
a=sendonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:3
a=clue-attributes:
a=clue-capture{1:camera-right,2:full-scene,
3:composed-scene,4:speaker}
m=video 10006 RTP/AVP 96
a=sendonly
a=rtpmap:96 H264
a=content: slides
a=mid:4
a=clue-attributes
a=clue-capture{1:slides,2:presentation-camera,
3:dvd}
m=audio 10000 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:5
a=clue-attributes:
a=clue-capture{1:mic-left,2:speaker}
m=audio 10001 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:6
a=clue-attributes:
a=clue-capture{1:mic-center,2:speaker}
m=audio 10002 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:7
a=clue-attributes:
a=clue-capture{1:mic-right,2:speaker}
; Consumer capability
m=video 20002 RTP/AVP 96 97
a=recvonly
Cazeaux, et al. Expires September 28, 2012 [Page 19]
Internet-Draft CLUE signaling requirements March 2012
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:8
a=clue-attributes:
m=video 20003 RTP/AVP 96 97
a=recvonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:9
a=clue-attributes:
m=video 20004 RTP/AVP 96 97
a=recvonly
a=rtpmap:96 H264
a=rtpmap:97 H265
a=content: main
a=mid:10
a=clue-attributes:
m=video 20006 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: slides
a=mid:11
a=clue-attributes
m=audio 20000 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:12
a=clue-attributes:
m=audio 20001 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:13
a=clue-attributes:
m=audio 20002 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:14
a=clue-attributes:
; CLUE Channel
Cazeaux, et al. Expires September 28, 2012 [Page 20]
Internet-Draft CLUE signaling requirements March 2012
m=application 30000 CLUE
a=sendrcv
An example of initial SDP answer including Provider announcement and
Consumer configuration is illustrated below.
; Consumer configuration
m=video 10002 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: main
a=mid:1
a=clue-attributes:
m=video 10003 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: main
a=mid:2
a=clue-attributes:
m=video 10006 RTP/AVP 96
a=recvonly
a=rtpmap:96 H264
a=content: slides
a=mid:4
a=clue-attributes
m=audio 10000 RTP/AVP 96
a=recvonly
a=rtpmap:96 PCMU
a=mid:6
a=clue-attributes:
; Remote consumer configuration and
Provider announcement
m=video 20002 RTP/AVP 96
a=sendonly
a=rtpmap:96 H264
a=content: main
a=mid:8
a=clue-attributes:
a=clue-capture{1:main-camera,2:secondary-camera}
Cazeaux, et al. Expires September 28, 2012 [Page 21]
Internet-Draft CLUE signaling requirements March 2012
m=video 20006 RTP/AVP 96
a=sendonly
a=rtpmap:96 H264
a=content: slides
a=mid:11
a=clue-attributes
a=clue-capture{1:slides,2:presentation-camera}
m=audio 20000 RTP/AVP 96
a=sendonly
a=rtpmap:96 PCMU
a=mid:12
a=clue-attributes:
a=clue-capture{1:main-mic}
; CLUE Channel
m=application 30000 CLUE
a=sendrcv
4.3.4. Transport and format
Same as option B1.
4.4. Interoperability with legacy endpoints
To enable the interoperability with legacy endpoints, a CLUE-enabled
endpoint must be able to discover whether the remote endpoint is
CLUE-enabled or not. When the remote endpoint is not CLUE-enabled,
the telepresence endpoints must establish a session without using
CLUE extensions.
Two solutions are possible:
Solution 1: OPTIONS procedures are invoked before the first offer/
answer cycle between a consumer and a provider. The OPTIONS
procedure enables the provider to retrieve consumer capabilities
so as to be able to build an SDP Offer that is meaningful for the
consumer. This procedure is particularly useful to enable the
provider to determine whether the consumer is CLUE-enabled or
not.
Cazeaux, et al. Expires September 28, 2012 [Page 22]
Internet-Draft CLUE signaling requirements March 2012
Solution 2: RFC5939 ([RFC5939]) is used. The SDP Offer sent by the
provider includes an "Actual Configuration" and one or more
"Potential Configurations". The "Actual Configuration"
corresponds to a basic mono-stream video call and can be
understood by any endpoint. One of the "Potential
Configurations" corresponds to a fully CLUE-compliant endpoint.
Other "Potential Configurations" may correspond to partially
compliant endpoint (e.g. multistream video without clue-specific
data).
These solutions are intended to fulfil requirements 3,4 and 6.
The options A, B1 and B2 described previously in the document do not
include the usage of any of these solutions. But they may rely on
any of these solutions to enable the interoperability with legacy
endpoints.
5. Security Considerations
6. IANA Considerations
None.
7. Acknowledgements
8. References
8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006.
Cazeaux, et al. Expires September 28, 2012 [Page 23]
Internet-Draft CLUE signaling requirements March 2012
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010.
8.2. Informative references
[I-D.ietf-clue-framework]
Romanow, A., Pepperell, A., Baldino, B., and M. Duckworth,
"Framework for Telepresence Multi-Streams",
draft-ietf-clue-framework-03 (work in progress),
February 2012.
[I-D.westerlund-dispatch-stream-selection]
Grondal, D., Burman, B., and M. Westerlund, "Media Stream
Selection (MESS)",
draft-westerlund-dispatch-stream-selection-00 (work in
progress), October 2011.
Authors' Addresses
Stephane Cazeaux
France Telecom Orange
42 rue des Coutures
Caen 14000
France
Email: stephane.cazeaux@orange.com
Emmanuel Bertin
France Telecom Orange
42 rue des Coutures
Caen 14000
France
Email: emmanuel.bertin@orange.com
Bruno Chatras
France Telecom Orange
38 rue du General Leclerc
Issy-Les-Moulineaux 92794
France
Email: bruno.chatras@orange.com
Cazeaux, et al. Expires September 28, 2012 [Page 24]
