CLUE Working Group R. Presta Internet-Draft S. Romano Intended status: Standards Track University of Napoli Expires: August 9, 2015 February 5, 2015 CLUE protocol draft-ietf-clue-protocol-03 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.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow across 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 August 9, 2015. Copyright Notice Copyright (c) 2015 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 Presta & Romano Expires August 9, 2015 [Page 1] Internet-Draft draft-ietf-clue-protocol-03 February 2015 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. Presta & Romano Expires August 9, 2015 [Page 2] Internet-Draft draft-ietf-clue-protocol-03 February 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 5 4. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 7 4.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. OPTIONS RESPONSE . . . . . . . . . . . . . . . . . . . . . 11 4.3. ADVERTISEMENT . . . . . . . . . . . . . . . . . . . . . . 12 4.4. ADVERTISEMENT ACKNOWLEDGEMENT . . . . . . . . . . . . . . 13 4.5. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. CONFIGURE RESPONSE . . . . . . . . . . . . . . . . . . . . 14 4.7. Response codes and reason strings . . . . . . . . . . . . 15 5. Protocol state machines . . . . . . . . . . . . . . . . . . . 16 6. CLUE Participant's state machine . . . . . . . . . . . . . . . 17 6.1. Media Provider's state machine . . . . . . . . . . . . . . 19 6.2. Media Consumer's state machine . . . . . . . . . . . . . . 22 7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Extensions and options . . . . . . . . . . . . . . . . . . . . 26 9. Details on CLUE Protocol Enhancement . . . . . . . . . . . . . 27 9.1. CLUE OPTION registration . . . . . . . . . . . . . . . . . 28 9.1.1. Attribute / Attribute Value related OPTIONs . . . . . 28 9.1.2. Syntax / Response code related OPTIONs . . . . . . . . 30 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.1. Simple ADV . . . . . . . . . . . . . . . . . . . . . . . . 35 11.2. ADV with MCCs . . . . . . . . . . . . . . . . . . . . . . 40 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47 12.2. XML Schema registration . . . . . . . . . . . . . . . . . 48 12.3. MIME Media Type Registration for 'application/clue+xml' . 48 12.4. DNS Registrations . . . . . . . . . . . . . . . . . . . . 49 12.4.1. Application Service tag . . . . . . . . . . . . . . . 50 12.4.2. Application Protocol tag . . . . . . . . . . . . . . . 50 12.5. CLUE Protocol Registry . . . . . . . . . . . . . . . . . . 50 12.5.1. CLUE Message Types . . . . . . . . . . . . . . . . . . 50 12.5.2. CLUE Response Codes . . . . . . . . . . . . . . . . . 51 13. Diff with draft-ietf-clue-protocol-02 . . . . . . . . . . . . 51 14. Diff with draft-ietf-clue-protocol-01 . . . . . . . . . . . . 52 15. Diff with draft-ietf-clue-protocol-00 . . . . . . . . . . . . 52 16. Diff with draft-presta-clue-protocol-04 . . . . . . . . . . . 52 17. Diff with draft-presta-clue-protocol-03 . . . . . . . . . . . 53 18. Diff with draft-presta-clue-protocol-02 . . . . . . . . . . . 53 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 20.1. Normative References . . . . . . . . . . . . . . . . . . . 53 20.2. Informative References . . . . . . . . . . . . . . . . . . 55 Presta & Romano Expires August 9, 2015 [Page 3] Internet-Draft draft-ietf-clue-protocol-03 February 2015 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 properly 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 in [I-D.ietf-clue-signaling] and [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing across such a channel are detailed in this document, 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 10. 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 used in the document. The definition of "CLUE Participant" herein proposed is not imported from any of the above documents. CLUE Participant: An entity able to use the CLUE protocol within a telepresence session. It can be either an endpoint or an 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 August 9, 2015 [Page 4] Internet-Draft draft-ietf-clue-protocol-03 February 2015 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 an MCU) able to send Media Streams. Media Consumer: A CLUE Participant (i.e., an Endpoint or an MCU) able to receive Media Streams. 3. Overview of the CLUE protocol The CLUE protocol is conceived to enable CLUE telepresence sessions. It is designed in order to address SDP limitations in terms of the description of some 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 information about the features of the flowing multimedia streams that are needed to enable a "being there" rendering experience. 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 for 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 a realiable and ordered SCTP over DTLS transport channel connecting two CLUE Participants. Messages carry 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 completes successfully, Presta & Romano Expires August 9, 2015 [Page 5] Internet-Draft draft-ietf-clue-protocol-03 February 2015 the 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 this 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 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 integers, separated by a dot. While minor version numbers denote backward 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 a 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 August 9, 2015 [Page 6] Internet-Draft draft-ietf-clue-protocol-03 February 2015 CLUE messages for the media session description and negotiation are 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 conveying 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 MP streams 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. Such messages 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 at the end of this document (Section 10). 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 and the CONFIGURE messages), in order to use the concepts defined in [I-D.ietf-clue-framework]. The CLUE protocol messages are the following: o OPTIONS o OPTIONS RESPONSE o ADVERTISEMENT (ADV) o ADVERTISEMENT ACKNOWLEDGEMENT (ACK) Presta & Romano Expires August 9, 2015 [Page 7] Internet-Draft draft-ietf-clue-protocol-03 February 2015 o CONFIGURE (CONF) o CONFIGURE RESPONSE (CONF 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 excerpt: The basic structure determines the mandatory information that is carried within each CLUE message. This information is composed of: 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 of 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", etc. Presta & Romano Expires August 9, 2015 [Page 8] Internet-Draft draft-ietf-clue-protocol-03 February 2015 Each CP should manage up 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. 4.1. OPTIONS The OPTIONS message is sent from 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 August 9, 2015 [Page 9] Internet-Draft draft-ietf-clue-protocol-03 February 2015 Presta & Romano Expires August 9, 2015 [Page 10] Internet-Draft draft-ietf-clue-protocol-03 February 2015 contains the list of the versions that are supported by the CI, each 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 and all the versions having the same major version number and lower minor version number. For example, if the "v" attribute has a value of "3.4" and there is no tag in the OPTIONS message, it means the CI supports only major version 3 with all the minor versions comprised between 3.0 and 3.4, with version 3.4 included. If a is provided, at least one tag MUST be included. The element specifies the list of options supported by the CI. If there is no in the OPTIONS message, the CI does not support anything other than what is envisioned in the versions it supports. For each option, an