1 / 11

About the I-D draft-cazeaux-clue-sip-signaling

About the I-D draft-cazeaux-clue-sip-signaling. The framework defined for Telepresence Multi-Streams introduces the need to exchange CLUE messages between Telepresence endpoints.

graiden-kim
Download Presentation

About the I-D draft-cazeaux-clue-sip-signaling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. About the I-Ddraft-cazeaux-clue-sip-signaling • The framework defined for Telepresence Multi-Streams introduces the need to exchange CLUE messages between Telepresence endpoints. • It is necessary to agree upon a signaling protocol enabling these CLUE messages to be exchanged, taking into account what SIP and SDP can already provide. • This I-D outlines signaling requirements to be met by the CLUE protocol. • This I-D proposes possible approaches for the design of this protocol.

  2. Signalling Requirements 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). REQ-4 The solution MUST enable interoperability with SIP legacy endpoints, with a minimum number of offer-answer cycles. 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-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. and other pretty obvious ones that can be found in the I-D…

  3. Mapping media captures and selection to SDP • Solution A • SDP is used for provider advertisement of available media captures and supported encoding options. • SDP is used for consumer selection of the media captures it wants to receive from the provider and configuration the encoding options to be applied by the provider to the media streams. • A change in media capture selection requires a new SDP Offer/Answer cycle. • Solution B • SDP is used for provider advertisement of available media captures and supported encoding options. (Same as Solution A). • SDP is used for consumer configuration of the encoding options to be applied by the provider to the media streams • A dedicated CLUE channel is used for the consumer selection of the media captures to receive from the provider. • A change of media capture selection does not require new SDP Offer/Answer cycle. • Two variants of solution B • Solution B-1: as for Solution A, multiple SDP offer/answer cycles are used • Solution B-2: a single SDP offer/answer cycle is used for initial negotiation

  4. Solution A • Media descriptions in a Provider announcement include the a=sendonly attribute. Encoding options are represented by the <fmt> 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. • Variants A-1) Media captures 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 named “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. A-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.

  5. Solution A (variant 1) m=video … a=sendonly a=content: main a=clue-capture{1:camera-left,2:full-scene,3:composed-scene,4:speaker} a= codec attributes a= … m=video … a=sendonly a=content: presentation a= … m=audio … … Alice Bob INVITE (SDP-Off = A-adv) provider Role 200 OK (SDP-Ans = B-conf) Consumer Role m=video … a=recvonly a=content: main a=clue-capture{1:camera-left} a= selected codec attributes a= … m=audio … … ACK Re-INVITE (SDP-Off = B-adv+B-conf) provider Role Consumer Role 200 OK (SDP-Ans = A-conf +B-conf) Captures (and associated encodings) Alice will send and want to receive ACK Bob’s capture (and associated encodings) announcements Media Streams

  6. Solution B-1 • As for Solution A: • Media descriptions in a Provider announcement include the a=sendonly attribute with encoding options represented by the <fmt> sub-field. • 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 named “clue-capture”) provides the list of media captures. • Media descriptions associated to selected media streams (selected by a Consumer) have the a=recvonly attribute. • Difference with Solution A: Solution B1 relies on a CLUE channel for the media capture selection • The “clue-capture” attribute is not used for capture selection • The media capture identifier provided by the specific CLUE attribute of the m= line and the media id provided by the <mid> sub-field of the same m= line to perform the media capture selection by the Consumer through the CLUE channel. • The CLUE channel allows each consumer to select media captures that the provider will send. Unless encoding options need not to be changed, media capture selection don’t require new SDP offer/answer cycles.

  7. Solution B-1 m=video … a=sendonly a=content: main a=clue-capture{1:camera-left,2:full-scene,3:composed-scene,4:speaker} a= codec attributes a= … m=video … a=sendonly a=content: presentation a= … m=audio … … m=application CLUE … … Alice m=video … a=recvonly a=content: main a=clue-capture{1:camera-left,2:full-scene,3:composed-scene,4:speaker} a= selected codec attributes a= … m=audio … … m=application CLUE … … Bob INVITE (SDP-Off = A-adv) provider Role 200 OK (SDP-Ans = B-conf) Consumer Role ACK Re-INVITE (SDP-Off = B-adv+B-conf) Selected encoding options associated to media streams Alice will send and want to receive provider Role Consumer Role Bob’s capture (and associated encodings) announcements 200 OK (SDP-Ans = A-conf +B-conf) ACK CLUE Channel Media capture selection Bob wants to receive from Alice Media capture selection Alice wants to receive from Bob Media Streams

  8. Solution B-2 • A single initial SDP offer/answer cycle is used to establish unidirectional streams between the parties. • The Offerer sends • As a provider, its advertisement (streams with a=sendonly attributes) • As a consumer, its capabilities (streams with a=recvonly attributes) • The Answerer sends • As consumer, a configuration of the received advertisement (streams with a=recvonly attribute) • A consumer configuration on behalf of the Offerer, based on received capabilities. This configuration is completed with information about its capabilities as Provider. • After the initial SDP offer/answer cycle, each party acting as consumer know the capabilities of the remote provider. Subsequent SDP offer/answer cycles may occur to allow each party to update its consumer configuration. • All other aspects are identical with solution B1 (including the use of a CLUE channel is used for the media capture selection).

  9. Solution B-2 m=video … a=recvonly a= selected codec attributes a=content: main a=clue-capture{1:camera-left,2:full-scene,3:composed-scene,4:speaker} a= … m=video … a=sendonly a= selected codec attributes a=content: main a= clue-capture{1:main-camera,2:secondary-camera} m=audio … … m=application CLUE … … m=video … a=sendonly a=content: main a=clue-capture{1:camera-left,2:full-scene,3:composed-scene,4:speaker} a= codec attributes a= … m=video … a=recvonly a=content: main a= codec attributes m=audio … … m=application CLUE … … Alice Bob INVITE (SDP-Off = A-Adv + A-Cap ) 200 OK (SDP-Ans = {B-adv + A-Conf} + B-Conf) ACK CLUE Channel Alice selects media captures Media Streams Bob selects media captures INVITE (SDP-Off = A-Adv + A-Conf) Optional. Alice wants to change encoding configuration. Alice provides its provider advertisement and its new consumer configuration. 200 OK (SDP-Ans = B-conf + A-Conf) ACK

  10. Interworking with Legacy Endpoints • Use of SIP OPTIONS: 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. • 200 OK response maps to the “Consumer Capability » information flows identified in clause 9.4 of the CLUE framework document • Use of RFC5939: 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).

  11. Analysis • Solution A-1 vs. A-2 • A-1 makes SDP more compact • A-2 enables using RFC5888 for LIP synch • Solution B-1 vs. B-2 • B-2 uses an initial single SDP offer/answer but does not enable the Offerer to perform encoding configuration as a consumer. • Solution A vs. B • Drawbacks of solution A: • 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. • Drawbacks of solution B: • Requires a new CLUE channel

More Related