1 / 22

RTP Usage for CLUE IETF 82 – 14 November 2011

RTP Usage for CLUE IETF 82 – 14 November 2011. Jonathan Lennox jonathan@vidyo.com Allyn Romanow allyn@cisco.com Paul Witty pauwitty@cisco.com. Source Multiplexing: Motivation. A telepresence session has lots of sources Dozens at a time e.g. for a continuous presence screen

joan-maldonado
Download Presentation

RTP Usage for CLUE IETF 82 – 14 November 2011

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. RTP Usage for CLUEIETF 82 – 14 November 2011 Jonathan Lennox jonathan@vidyo.com Allyn Romanow allyn@cisco.com Paul Witty pauwitty@cisco.com

  2. Source Multiplexing: Motivation • A telepresence session has lots of sources • Dozens at a time • e.g. for a continuous presence screen • Out of a pool of hundreds possible • Sessions have asymmetric numbers of sources • So the usual SIP model (a single media source per session) doesn’t scale, and is needlessly complex.

  3. Source multiplexing • Send all sources (of the same media type) over a single RTP session, single transport flow. • Protocol behavior is straightforward • NAT traversal is fast, port consumption is low. • SDP is small, and looks “normal” to middleboxes. • This was always part of RFC 3550 (RTP), but not widely used until recently.

  4. Source multiplexing: exceptions • There may be cases where we still need to use multiple RTP sessions • Most obviously, if sources should have different transport characteristics, e.g. different QoS. • This doesn’t preclude having those sessions themselves carry multiple sources!

  5. Source multiplexing: complications • Some things get complicated • One-source-per-session was a fairly pervasive assumption. • Even though RTP always supported source multiplex. • Details of RTCP behavior. • Backward compatibility. • Not in scope for CLUE – general IETF architecture. • See: • draft-westerlund-avtcore-multiplex-architecture-00 • draft-lennox-rtcweb-rtp-media-type-mux-00 • The AVTCORE WG, and probably other groups too.

  6. CLUE-specific Complications • When you receive a source, you need to know why you’re receiving it. • Which requested capture it corresponds to. • This can change dynamically • Source collision / restart. • Switched captures. • Source moving between switched captures. • Three camera to two screen: LC → LR → CR → LR • This is needed before stream decoding starts. • Many systems: which screen to display on → which decoder hardware to use.

  7. Demultiplexing RTP Streams in Same Session

  8. Case to Consider: Infinite Sources EndPoint EndPoint MCU EndPoint EndPoint

  9. How to Demultiplex • SSRC • MuxID • Hybrid

  10. SSRCs Pros • Already in RTP packet • Unique number

  11. The issue with SSRC: 3 streams sent SSRC 1 VC1 SSRC 2 VC2 SSRC 3 VC3

  12. 2 of 3 streams stop SSRC 1 VC1 SSRC 2 VC2 SSRC 3 VC3

  13. VC2 and VC3 continue with different SSRC SSRC 5 VC3 SSRC 4 VC2 SSRC 1 VC1

  14. Timeline A B SSRCS 1, 2, 3 A decides to Change VC2 & VC3 Aim is to minimise this time VC2 = SSRC 4; VC3 = SSRC 5 SSRCS 1, 4, 5

  15. SSRCs Challenges • SSRC changes • Requires metadata to link SSRC to CLUE capture • Requires storage for lookup tables • Timing requirements for codec when SSRC changes

  16. Where to put metadata • CLUE message • Advantage – reliable • Disadvantage – reliability can cause large delays, esp. when lots of conference participants. Switching latency • RTCP, e. g., new SDES • Advantage – in data path, can arrive early • Disadvantage – RTCP lossy, receiver won’t know how to route media • Can use acks and retrans, but can cause high latency

  17. Sending metadata A B SSRCS 1, 2, 3 A decides to Change VC2 & VC3 VC2 = SSRC 4; VC3 = SSRC 5 High Latency Acknowledge updated mapping SSRCS 1, 4, 5

  18. Multiplex ID Advantages • Tag media packet with muxID • Header extension • Advantage – no lag time when SSRC changes • When stream changes, muxID can remain • Receiver can add useful info to muxID

  19. Multiplex ID Cons • Disadvantage – high processing costs • Scoped only within one hop • Adding, modifying expensive due to SRTP auth • requires re-auth of whole packet, could limit throughput • Might need to re-auth due to SDP anyway

  20. Sending Multiplex IDs A B SSRCS 1, 2, 3 A decides to Change VC2 & VC3 Low Latency SSRCS 1, 4, 5 with updated Multiplex IDs

  21. Hybrid Scheme, Pros and Cons • MuxID only in packet of the first frame of media (typically an IDR/GDR). • All other packets demux using only the SSRC • Advantage - Mitigates high switching latency and high processing cost • Can’t send without IDR so must wait anyway

  22. Hybrid Challenges • Additional complexity in demuxing – check if muxID, if not use SSRC • Needs more investigation

More Related