Network Working Group S. Cazeaux Internet-Draft E. Bertin Intended status: Informational France Telecom Orange Expires: September 6, 2012 March 5, 2012 Requirements for ControLling mUltiple streams for tElepresence (CLUE) signaling. draft-cazeaux-clue-sip-signaling-00 Abstract This document defines requirements relating to the design of CLUE signaling. This document also proposes two alternative design approaches the 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 6, 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 & Bertin Expires September 6, 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 . . . 5 4.1.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Transport and encoding choice . . . . . . . . . . . . 6 4.2. Option B: media capture selection in a separate protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Transport and encoding choice . . . . . . . . . . . . 8 4.3. Interoperability with legacy endpoints . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 8.2. Informative references . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Cazeaux & Bertin Expires September 6, 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 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 possible 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 & Bertin Expires September 6, 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 enable to exchange data related to media capture (description, spatial relations, etc.) and to select media capture without dependency or impact on the negotiated media streams (except that a media capture MUST refer to a negotiated media stream). REQ-9 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-10 The solution MUST NOT add new requirements regarding NAT traversal compared to legacy video systems (NOTE : lesson learned from BFCP over TCP). REQ-11 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 Cazeaux & Bertin Expires September 6, 2012 [Page 4] Internet-Draft CLUE signaling requirements March 2012 4.1. Option A: CLUE signaling based on SIP-SDP signaling This option proposes an approach where the exchange of CLUE messages between the provider and the consumer is based on the SDP O/A model as specified in [RFC3264]. The SDP is used for the exchange of media stream and media capture data. 4.1.1. Signaling CLUE session establishment A B | | |OPTIONS | |----------------------------------->| | 200 OK (SDP:cons-capB)| |<-----------------------------------| |INVITE (SDP-O1:ann-capA) | |----------------------------------->| | 200 OK (SDP-A1:conf-capB)| |<-----------------------------------| |ACK | |----------------------------------->| | | | OPTIONS| |<-----------------------------------| |200 OK (SDP:cons-capA) | |----------------------------------->| | INVITE (SDP-O1:ann-capB+conf-capB)| |<-----------------------------------| |200 OK (SDP-A1:conf-capA+conf-capB) | |----------------------------------->| | ACK| |<-----------------------------------| Figure 1 cons-capX includes the capabilities of the consumer X. ann-capX includes the capabilities announced by the provider X. conf-capX includes the capabilities configured by the consumer X. 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 Cazeaux & Bertin Expires September 6, 2012 [Page 5] Internet-Draft CLUE signaling requirements March 2012 it can safely replace it. It is worth noting that this option will not satisfy the requirements 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 cannot wait for a user action more than what a SIP transaction timer allows. 4.1.2. Transport and encoding choice 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 encoding of CLUE messages is SDP. 4.2. Option B: 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 (named futher the CLUE channel). Cazeaux & Bertin Expires September 6, 2012 [Page 6] Internet-Draft CLUE signaling requirements March 2012 4.2.1. Signaling CLUE session establishment A B | | |INVITE (SDP-offer1) | |------------------------------>| | 200 OK (SDP-answer1)| |<------------------------------| |ACK | |------------------------------>| | | | CLUE channel | |<=============================>| | | |re-INVITE (SDP-offer2) | |------------------------------>| | 200 OK (SDP-Answer2)| |<------------------------------| |ACK | |------------------------------>| | | Figure 2 SDP-offer1: This SDP provides the capabilities of A acting as a consumer (what A can receive) under the form of the number and characteristics of media streams that A is able to receive. This SDP also provides the capabilities of A acting as a provider (what A can send) which describe the characteristics A's media streams . The characteristics of the media streams that A can send include, among other: spatial relations, available media captures. At this stage: A can receive and can send. SDP-answer1: This SDP provides the capabilities of B as consumer. B builds his SDP in response to the capabilities of A, meaning that B will here define what it will receive according to A's capabilities as provider. This SDP also provides the capabilities of B as provider, here also in response to the capabilities of A, meaning that B will define what it will send to A. 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. However, no Cazeaux & Bertin Expires September 6, 2012 [Page 7] Internet-Draft CLUE signaling requirements March 2012 media capture selection has been yet performed. CLUE channel: The CLUE channel enables each consumer to perform media content selection according to provider capabilities. It is worth noting that any operation performed on this channel is done in the context of the previous SDP offer-answer. The use of this channel is optional. Without it, a consumer cannot perform selection, thus the provider will adopt a default behavior in terms of media content. SDP-offer2 and SDP-answer2: Subsequent SDP offer/answer cycles may occur, when A or B wishes to update his capabilities (add or remove a media stream for instance). This option should satisfy all requirements. 4.2.2. Transport and encoding choice In this option, the solution is constituted of at least two protocol elements. The first protocol element aims to handle 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 encoding is SDP. 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. 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 Cazeaux & Bertin Expires September 6, 2012 [Page 8] Internet-Draft CLUE signaling requirements March 2012 provider to determine whether the consumer is CLUE-enabled or not. 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). The option A as defined in Section 4.1 relies on the solution 1, and the option B as defined Section 4.2 relies the solution 2. However it is worth noting that the the design of the solution to enable interoperability with legacy is actually independent from the choice of introducing a CLUE channel or not. In other terms, the option A could also rely on the solution 2, and the option B on the solution 1. 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. Cazeaux & Bertin Expires September 6, 2012 [Page 9] Internet-Draft CLUE signaling requirements March 2012 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [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 Cazeaux & Bertin Expires September 6, 2012 [Page 10]