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 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 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 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 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 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 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]