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

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

3. 3  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. 4  Advertisement and selection happen throughout call

5. 5  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. 6  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. 7 We need to agree on the requirements for signaling protocols to implement the framework

8. 8  Consumer advertisements - skip for now  Capture advertisements  Encoding advertisements  Selection  Media

9. 9  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. 10  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. 11  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. 12  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. 13  Requires investigation

14. 14  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. 15  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. 16  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. 17  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