1 / 17

CLUE

CLUE. Signaling Requirements for implementing the Framework CLUE interim Feb 15, 16, 2012. Allyn Romanow (allyn@cisco.com) Stephen Botzko (stephen.botzko@gmail.com) Robert Hansen (rohanse2@cisco.com ). Data Flow. Provider. Consumer. Consumer capabilities.

willem
Download Presentation

CLUE

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. CLUE Signaling Requirements for implementing the Framework CLUE interim Feb 15, 16, 2012 Allyn Romanow (allyn@cisco.com) Stephen Botzko (stephen.botzko@gmail.com) Robert Hansen (rohanse2@cisco.com)

  2. Data Flow Provider Consumer Consumer capabilities Advertisement-- Captures and Potential Streams Selection Media …

  3. Parameters • Capture attributes – spatial relations, purpose, switched/composed, layout/policies, audio channel, encoding group id • Encoding attributes – max width, max height, max FPS, max macroblocks per second, max bitrate

  4. Dynamic messages • Advertisement and selection happen throughout call

  5. Using SDP for signaling CLUE- for discussion • SDP for what? • Session-level and media-level media parameters • CLUE encodings, encoding groups • CLUE capture attributes • CLUE selection • Latency requirements? • if too stringent SDP would not work •   What do intermediaries need to know about CLUE info?  • SDP would be an advantageous way to carry that subset of the information.

  6. SDP questions • Is there a concern about SDP bloat and the need to preserve backward capability – large number of advertisements and selections • CLUE doesn’t fit within offer/answer.. So if we’re using SDP, it will be interesting

  7. Goal We need to agree on the requirements for signaling protocols to implement the framework

  8. Requirements for each • Consumer advertisements - skip for now • Capture advertisements • Encoding advertisements • Selection • Media

  9. Timing Requirements -advertisements of capture attributes • Switched/composed – changes are frequent • Spatial attributes change as current participant changes, speaker changes • Need spatial info before media is received in order to render (Need to sync with media) • Advertisement needs to be fast. On par with the speed of the media. Order of 100s ms to 300ms • A slow signaling channel wouldn’t work • Want delivery status to be known by provider, to manage latency - reliability

  10. Requirements for capture attribs advertisement continued • Advertisements also change when new sites join - less frequently than speaker changes. • Advertisements might change in response to network conditions • In these cases advertisement can be slower. Latencies on the order of 1-2 seconds seem acceptable

  11. Timing Requirements –Advertisements of encodings & encoding groups • Media parameters (bandwidth, resolution, etc) are maximums • No need to change with voice switching • Hence more static than spatial • Scale of 1-2 seconds • Encodings and the enc group might change due to network conditions, local resources usage. Infrequent and longer time scale.

  12. Timing Requirements for consumer selection • Consumer selection often automatic • done by machine agents per policy • Latency requirements might need more analysis • User selection will be included in most UIs • Needs to be responsive to human speed • Latency of 1-2 seconds seems sufficient

  13. Signalling bandwidth • Requires investigation

  14. Requirements for media • Multiplex RTP streams on single session • Hard limit on the number of streams • How to do mapping of source to output is the issue • Different approaches: • draft-lennox-clue-rtp-usage-02 - RTP extension • draft-westerlund-clue-multistream-conference-00 - SSRC

  15. Requirements for intermediaries • Intermediaries need to know (and change) some parameters so they can enforce administrator policies • Bandwidths (overall, per stream) • Security • Other media encoding parameters • In SIP calls this is traditionally solved by intermediaries monitoring/rewriting SDPs

  16. Use of SDP • SDP is the primary location for media parameters – seems a good fit for encoding group parameters • Allows policy monitoring by intermediary devices • Can be used to negotiate a CLUE protocol for fast end-to-end messages

  17. SDP Challenges • Latency bounds and media synchronization requirements for some messaging not met by SIP/SDP • Encoding Group advertisement challenging to fit into SDP • Don’t know how to use offer without answer for the encoding advertisement • Two one-way communications – not the O/A model • Potential interop issues if SDP size is significantly expanded

More Related