CLUE Working Group R. Presta Internet-Draft S. Romano Intended status: Standards Track University of Napoli Expires: February 14, 2017 August 13, 2016 CLUE protocol draft-ietf-clue-protocol-09 Abstract The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document 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. 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 February 14, 2017. Copyright Notice Copyright (c) 2016 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 Presta & Romano Expires February 14, 2017 [Page 1] Internet-Draft draft-ietf-clue-protocol-09 August 2016 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 February 14, 2017 [Page 2] Internet-Draft draft-ietf-clue-protocol-09 August 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 5 5. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 7 5.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. OPTIONS RESPONSE . . . . . . . . . . . . . . . . . . . . . 11 5.3. ADVERTISEMENT . . . . . . . . . . . . . . . . . . . . . . 12 5.4. ADVERTISEMENT ACKNOWLEDGEMENT . . . . . . . . . . . . . . 13 5.5. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. CONFIGURE RESPONSE . . . . . . . . . . . . . . . . . . . . 14 5.7. Response codes and reason strings . . . . . . . . . . . . 15 6. Protocol state machines . . . . . . . . . . . . . . . . . . . 17 6.1. Media Provider's state machine . . . . . . . . . . . . . . 19 6.2. Media Consumer's state machine . . . . . . . . . . . . . . 22 7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Extensions and options . . . . . . . . . . . . . . . . . . . . 25 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Simple ADV . . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. ADV with MCCs . . . . . . . . . . . . . . . . . . . . . . 37 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 46 12.2. XML Schema registration . . . . . . . . . . . . . . . . . 47 12.3. MIME Media Type Registration for 'application/clue+xml' . 47 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . . 48 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 48 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . . 50 13. Diff with draft-ietf-clue-protocol-06 . . . . . . . . . . . . 51 14. Diff with draft-ietf-clue-protocol-05 . . . . . . . . . . . . 51 15. Diff with draft-ietf-clue-protocol-04 . . . . . . . . . . . . 51 16. Diff with draft-ietf-clue-protocol-03 . . . . . . . . . . . . 51 17. Diff with draft-ietf-clue-protocol-02 . . . . . . . . . . . . 51 18. Diff with draft-ietf-clue-protocol-01 . . . . . . . . . . . . 52 19. Diff with draft-ietf-clue-protocol-00 . . . . . . . . . . . . 52 20. Diff with draft-presta-clue-protocol-04 . . . . . . . . . . . 53 21. Diff with draft-presta-clue-protocol-03 . . . . . . . . . . . 53 22. Diff with draft-presta-clue-protocol-02 . . . . . . . . . . . 53 23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 24.1. Normative References . . . . . . . . . . . . . . . . . . . 53 24.2. Informative References . . . . . . . . . . . . . . . . . . 55 Presta & Romano Expires February 14, 2017 [Page 3] Internet-Draft draft-ietf-clue-protocol-09 August 2016 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 Media Provider (MP) to properly announce its current telepresence capabilities to a Media Consumer (MC) in terms of available media captures, groups of encodings, simultaneity constraints and other information envisioned in [I-D.ietf-clue-framework]; 2. enabling an MC to request the desired multimedia streams from 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 described in [I-D.ietf-clue-signaling] and [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing upon such a channel are detailed in this document, both syntactically and semantically. In Section 4 we provide a general overview of the CLUE protocol. CLUE protocol messages are detailed in Section 5. The CLUE Participant state machines are introduced in Section 6. 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 [RFC7262]. 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 (CP): An entity able to use the CLUE protocol within a telepresence session. It can be an endpoint or an MCU able to use the CLUE protocol. CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol and the principles of CLUE negotiation, and seeks CLUE-enabled calls. Presta & Romano Expires February 14, 2017 [Page 4] Internet-Draft draft-ietf-clue-protocol-09 August 2016 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. MCU: Multipoint Control Unit (MCU) - a device that connects two or more endpoints together into one single multimedia conference [RFC7667]. 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. Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an MCU) able to receive Media Streams. Capture Encoding: A specific encoding of a Media Capture, to be sent via RTP [RFC3550]. Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an MCU) able to send Media Streams. Media Stream: The term "Media Stream", or simply "Stream", is used as a synonym of Capture Encoding. 3. Conventions 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 BCP 14, RFC 2119 [RFC2119]. 4. 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 Presta & Romano Expires February 14, 2017 [Page 5] Internet-Draft draft-ietf-clue-protocol-09 August 2016 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 reliable 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, 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 (OPTIONS and OPTIONS RESPONSE). The version and options negotiation can be performed once and only at this stage. 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 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 (single digit) and a minor version number (single digit), 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 is part of the initial 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 Presta & Romano Expires February 14, 2017 [Page 6] Internet-Draft draft-ietf-clue-protocol-09 August 2016 (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. In many cases CPs will seek to both transmit and receive media. Hence in a call between two CPs, A and B, there would be two separate dialogs, as follows: 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 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 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. Such messages will be detailed in the following sections. 5. 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). Presta & Romano Expires February 14, 2017 [Page 7] Internet-Draft draft-ietf-clue-protocol-09 August 2016 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) 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: Presta & Romano Expires February 14, 2017 [Page 8] Internet-Draft draft-ietf-clue-protocol-09 August 2016 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 (in the form of a generic string) of the CP within the telepresence system; o sequenceNr: an XML element containing the local message sequence number. The sender must increment the sequence numbers by one for each new message sent, the receiver must remember the most recent sequence number received and send back a 401 error if it receives a message with an unexpected sequence number. The initial sequence number can be chosen randomly by each party; 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.4", etc. Each CP MUST be able to manage up to three (independent) 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. 5.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 February 14, 2017 [Page 9] Internet-Draft draft-ietf-clue-protocol-09 August 2016 Presta & Romano Expires February 14, 2017 [Page 10] Internet-Draft draft-ietf-clue-protocol-09 August 2016 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.4). Exactly one element MUST 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 within 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