CLUE Working Group R. Presta
Internet-Draft S. Romano
Intended status: Standards Track University of Napoli
Expires: November 10, 2014 May 9, 2014
CLUE protocol
draft-presta-clue-protocol-04
Abstract
The CLUE protocol is an application protocol conceived for the
description and negotiation of a CLUE telepresence session. The
design of the CLUE protocol takes into account the requirements and
the framework defined, respectively, in [I-D.ietf-clue-framework] and
[I-D.ietf-clue-telepresence-requirements]. The companion document
[I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as
well as on the SIP/SDP session establishment phase. CLUE messages
flow upon the CLUE data channel, based on reliable and ordered SCTP
over DTLS transport, as described in [I-D.ietf-clue-datachannel].
Message details, together with the behavior of CLUE Participants
acting as Media Providers and/or Media Consumers, are herein
discussed.
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 November 10, 2014.
Copyright Notice
Copyright (c) 2014 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
Presta & Romano Expires November 10, 2014 [Page 1]
Internet-Draft draft-presta-clue-protocol-04 May 2014
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 4
4. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 6
4.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. OPTIONS RESPONSE . . . . . . . . . . . . . . . . . . . . . 10
4.3. ADVERTISEMENT . . . . . . . . . . . . . . . . . . . . . . 11
4.4. ADVERTISEMENT ACKNOWLEDGEMENT . . . . . . . . . . . . . . 12
4.5. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. CONFIGURE RESPONSE . . . . . . . . . . . . . . . . . . . . 14
4.7. READV . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. READV RESPONSE . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Response codes and reason strings . . . . . . . . . . . . 16
5. Protocol state machines . . . . . . . . . . . . . . . . . . . 18
6. CLUE Participant's state machine . . . . . . . . . . . . . . . 18
6.1. Media Consumer's state machine . . . . . . . . . . . . . . 21
6.2. Media Provider's state machine . . . . . . . . . . . . . . 23
7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Extensions and options . . . . . . . . . . . . . . . . . . . . 26
9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Diff with the -03 version . . . . . . . . . . . . . . . . . . 33
11. Diff with the -02 version . . . . . . . . . . . . . . . . . . 34
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. Informative References . . . . . . . . . . . . . . . . . . . . 34
Presta & Romano Expires November 10, 2014 [Page 2]
Internet-Draft draft-presta-clue-protocol-04 May 2014
1. Introduction
The CLUE protocol is an application protocol used by two CLUE
Participants to enhance the experience of a multimedia telepresence
session. The main goals of the CLUE protocol are:
1. enabling a MP to fully announce its current telepresence
capabilities to a MC in terms of available media captures, groups
of encodings, simultaneity constraints and other information
envisioned in [I-D.ietf-clue-framework];
2. enabling a MC to request the desired multimedia streams to the
offering MP.
CLUE-capable endpoints are connected by means of the CLUE data
channel, an SCTP over DTLS channel which is opened and established as
depicted respectively in [I-D.kyzivat-clue-signaling] and
[I-D.kyzivat-clue-signaling]. CLUE protocol messages flowing upon
such channel are detailed in the following, both syntactically and
semantically.
In Section 3 we provide a general overview of the CLUE protocol.
CLUE protocol messages are detailed in Section 4 The CLUE Participant
state machine is introduced in Section 5. Versioning and extensions
are discussed in Section 7 and Section 8, respectively. The XML
schema defining the CLUE messages is reported in Section 9.
2. Terminology
This document refers to the same terminology used in
[I-D.ietf-clue-framework] and in
[I-D.ietf-clue-telepresence-requirements]. We briefly recall herein
some of the main terms exploited in the document. We further
introduce the definition of CLUE Participant.
CLUE Participant An entity able to use the CLUE protocol within a
telepresence session. It can be an endpoint or a MCU able to use
the CLUE protocol.
Endpoint The logical point of final termination through receiving,
decoding and rendering, and/or initiation through capturing,
encoding, and sending of media streams. An endpoint consists of
one or more physical devices which source and sink media streams,
and exactly one [RFC4353] Participant (which, in turn, includes
exactly one SIP User Agent). Endpoints can be anything from
multiscreen/multicamera room controllers to handheld devices.
Presta & Romano Expires November 10, 2014 [Page 3]
Internet-Draft draft-presta-clue-protocol-04 May 2014
MCU Multipoint Control Unit (MCU) - a device that connects two or
more endpoints together into one single multimedia conference
[RFC5117]. An MCU may include a Mixer [RFC4353].
Media Any data that, after suitable encoding, can be conveyed over
RTP, including audio, video or timed text.
Media Capture A "Media Capture", or simply "Capture", is a source of
Media.
Capture Encoding A specific encoding of a Media Capture, to be sent
via RTP [RFC3550].
Media Stream The term "Media Stream", or simply "Stream", is used as
a synonymous of Capture Encoding.
Media Provider A CLUE Participant (i.e., an Endpoint or a MCU) able
to send Media Streams.
Media Consumer A CLUE Participant (i.e., an Endpoint or a MCU) able
to receive Media Streams.
3. Overview of the CLUE protocol
The CLUE protocol has been conceived to enable CLUE telepresence
session. It is designed in order to address SDP limitations in terms
of the description of several information about the multimedia
streams that are involved in a real-time multimedia conference.
Indeed, by simply using SDP we are not able to convey the information
about the features of the flowing multimedia streams that is needed
to enable a "being there" rendering. Such information is designed in
the CLUE framework document and formally defined and described in the
CLUE data model document. The CLUE protocol represents the mechanism
that enables the exchange of CLUE information between CLUE
Participants. It mainly provides the messages to enable a Media
Provider to advertise its telepresence capabilities and to enable a
Media Consumer to select the desired telepresence options.
The CLUE protocol, as defined in the following, is a stateful,
client-server, XML-based application protocol. CLUE protocol
messages flow on realiable and ordered SCTP over DTLS transport
channel connecting two CLUE Participants. Messages carries
information taken from the XML-based CLUE data model
([I-D.ietf-clue-data-model-schema]). Three main communication layers
can be identified:
1. Establishment of the CLUE data channel: in this phase, the CLUE
data channel setup takes place. If it ends up successfully, the
Presta & Romano Expires November 10, 2014 [Page 4]
Internet-Draft draft-presta-clue-protocol-04 May 2014
CPs are able to communicate and start the initiation phase.
2. Negotiation of the CLUE protocol version and options (initiation
phase): the CPs connected via the CLUE data channel agree on the
version and on the options to be used during the telepresence
session. Special CLUE messages are used for such a task. At the
end of that basic negotiation, each CP starts its activity as a
CLUE MP and/or CLUE MC.
3. CLUE telepresence capabilities description and negotiation: in
this phase, the MP-MC offer-answer dialogues take place on the
data channel by means of the CLUE protocol messages.
As soon as the channel is ready, the CLUE Participants must agree on
the protocol version and extensions to be used within the
telepresence session. CLUE protocol version numbers are
characterized by a major version number and a minor version number,
both unsigned integer, separated by a dot. While minor version
numbers denote backword compatible changes in the context of a given
major version, different major version numbers generally indicate a
lack of interoperability between the protocol implementations. In
order to correctly establish a CLUE dialogue, the involved CPs MUST
have in common a major version number (see Section 7 for further
details). The subset of the protocol options and extensions that are
allowed within the CLUE session is also determined in the initiation
phase, such subset being the one including only the options that are
supported by both parties. A mechanism for the negotiation of the
CLUE protocol version and extensions is envisioned in the initiation
phase. According to such solution, the CP which is the CLUE Channel
initiator (CI) issues a proper CLUE message (OPTIONS) to the CP which
is the Channel Receiver (CR) specifying the supported version and
extensions. The CR then answers by selecting the subset of the CI
extensions that it is able to support and determines the protocol
version to be used.
After that negotiation phase is completed, CLUE Participants describe
and agree on the media flows to be exchanged. Indeed, being CPs A
and B both transmitting and receiving, it is possible to distinguish
between two dialogues:
1. the one needed to describe and set up the media streams sent from
A to B, i.e., the dialogue between A's Media Provider side and
B's Media Consumer side
2. the one needed to describe and set up the media streams sent from
B to A, i.e., the dialogue between B's Media Provider side and
A's Media Consumer side
Presta & Romano Expires November 10, 2014 [Page 5]
Internet-Draft draft-presta-clue-protocol-04 May 2014
CLUE messages for the media session description and negotiation is
designed by considering the MP side as the server side of the
protocol, since it produces and provides media streams, and the MC
side as the client side of the protocol, since it requests and
receives media streams. The messages that are exchanged to set up
the telepresence media session are described by focusing on a single
MP-MC dialogue.
The MP first advertises its available media captures and encoding
capabilities to the MC, as well as its simultaneity constraints,
according to the information model defined in
[I-D.ietf-clue-framework]. The CLUE message conveing the MP's
multimedia offer is the ADVERTISEMENT message. Such message
leverages the XML data model definitions provided in
[I-D.ietf-clue-data-model-schema].
The MC selects the desired streams of the MP by using the CONFIGURE
message, which makes reference to the information carried in the
previously received ADVERTISEMENT.
Besides ADVERTISEMENT and CONFIGURE, other messages have been
conceived in order to provide all the needed mechanisms and
operations and will be detailed in the following sections.
4. Protocol messages
CLUE protocol messages are textual, XML-based messages that enable
the configuration of the telepresence session. The formal definition
of such messages is provided in the XML Schema provided at the end of
this document (Section 9).
The XML definitions of the CLUE information provided in
[I-D.ietf-clue-data-model-schema] are included within some CLUE
protocol messages (namely the ADVERTISEMENT, the CONFIGURE, and the
READV RESPONSE messages), in order to use the concept defined in
[I-D.ietf-clue-framework].
The CLUE protocol messages that have been defined up to now are the
following:
o OPTIONS
o OPTIONS RESPONSE
o ADVERTISEMENT (ADV)
o ADVERTISEMENT ACKNOWLEDGE (ACK)
Presta & Romano Expires November 10, 2014 [Page 6]
Internet-Draft draft-presta-clue-protocol-04 May 2014
o CONFIGURE (CONF)
o CONFIGURE RESPONSE
o READV
o READV RESPONSE
While the OPTIONS and OPTIONS RESPONSE messages are exchanged in the
initiation phase between the CPs, the other messages are involved in
MP-MC dialogues.
Each CLUE message inherits a basic structure depicted in the
following figure:
The basic structure determines the mandatory information that is
carried within each CLUE message. Such an information is made by:
o clueId: an XML element containing the identifier of the CP within
the telepresence system;
o sequenceNr: an XML element containing the local message sequence
number;
o protocol: a mandatory attribute set to "CLUE" identifying the
procotol the messages refer to;
o v: a mandatory attribute carrying the version of the protocol
Each CP should manage uo to three streams of sequence numbers: (i)
one for the messages exchanged in the initiation phase, (ii) one for
the messages exchanged as MP, and (iii) one for the messages
exchanged as MC.
Presta & Romano Expires November 10, 2014 [Page 7]
Internet-Draft draft-presta-clue-protocol-04 May 2014
4.1. OPTIONS
The OPTIONS message is sent by the CP which is the CI to the CP which
is the CR as soon as the CLUE data channel is ready. Besides the
information envisioned in the basic structure, it specifies:
o mediaProvider: a mandatory boolean field set to "true" if the CP
is able to act as a MP
o mediaConsumer: a mandatory boolean field set to "true" if the CP
is able to act as a MC
o supportedVersions: the list of the supported versions
o supportedOptions: the list of the supported options
The XML Schema of such a message is reported below:
Presta & Romano Expires November 10, 2014 [Page 8]
Internet-Draft draft-presta-clue-protocol-04 May 2014
Presta & Romano Expires November 10, 2014 [Page 9]
Internet-Draft draft-presta-clue-protocol-04 May 2014
contains the list of the versions that are
supported by the CI. Only one element SHOULD be provided
for each major version supported, containing the maximum minor
version number of such a version, since all minor versions are
backward compatible. If no is carried whithin
the OPTIONS message, the CI supports only the version declared in the
"v" attribute. For example, if the "v" attribute has a value of
"3.4" and there is not a tag in the OPTIONS
message, it means the CI supports only major version 3 with all the
minor versions comprised between 3.0 the 3.4 included. If a
is provided, at least one tag MUST be
included.
The element specifies the list of the options
supported by the CI. If there is no in the
OPTIONS message, the CI does not support anything more than what is
envisioned in the versions it supports. For each option, an