CLUE Working Group R. Presta Internet-Draft S. Romano Intended status: Standards Track University of Napoli Expires: December 26, 2014 June 24, 2014 CLUE protocol draft-ietf-clue-protocol-01 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 December 26, 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 December 26, 2014 [Page 1] Internet-Draft draft-ietf-clue-protocol-01 June 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. ADVERTISEMENT examples . . . . . . . . . . . . . . . . . . . . 33 10.1. Simple ADV . . . . . . . . . . . . . . . . . . . . . . . . 34 10.2. ADV with MCCs . . . . . . . . . . . . . . . . . . . . . . 39 11. Diff with draft-ietf-clue-protocol-00 . . . . . . . . . . . . 46 12. Diff with draft-presta-clue-protocol-04 . . . . . . . . . . . 47 13. Diff with draft-presta-clue-protocol-03 . . . . . . . . . . . 47 14. Diff with draft-presta-clue-protocol-02 . . . . . . . . . . . 47 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 16. Informative References . . . . . . . . . . . . . . . . . . . . 48 Presta & Romano Expires December 26, 2014 [Page 2] Internet-Draft draft-ietf-clue-protocol-01 June 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 December 26, 2014 [Page 3] Internet-Draft draft-ietf-clue-protocol-01 June 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 December 26, 2014 [Page 4] Internet-Draft draft-ietf-clue-protocol-01 June 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 December 26, 2014 [Page 5] Internet-Draft draft-ietf-clue-protocol-01 June 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 December 26, 2014 [Page 6] Internet-Draft draft-ietf-clue-protocol-01 June 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. The content of the "v" attribute is composed by the major version number followed by a dot and then by the minor version number of the CLUE protocol in use. Allowed values are of this kind: "1.3", "2.45", and the like. Each CP should manage uo to three streams of sequence numbers: (i) one for the messages exchanged in the initiation phase, (ii) one for Presta & Romano Expires December 26, 2014 [Page 7] Internet-Draft draft-ietf-clue-protocol-01 June 2014 the messages exchanged as MP, and (iii) one for the messages exchanged as MC. 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 December 26, 2014 [Page 8] Internet-Draft draft-ietf-clue-protocol-01 June 2014 Presta & Romano Expires December 26, 2014 [Page 9] Internet-Draft draft-ietf-clue-protocol-01 June 2014 contains the list of the versions that are supported by the CI, each one represented in a child element. The content of each element is a string made by the major version number followed by a dot and then by the minor version number (e.g., 1.3 or 2.43). 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