1 / 10

RTP Session multiplexing

RTP Session multiplexing. draft-rosenberg-rtcweb-rtpmux-00 draft-perkins-rtcweb-rtp-usage-02. Outline. The Basic Issue Current Situation Proposals and their issues Consensus Questions. The Basic Issue. RTP requires a lower transport layer to separate RTP sessions

banyan
Download Presentation

RTP Session multiplexing

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 Session multiplexing draft-rosenberg-rtcweb-rtpmux-00 draft-perkins-rtcweb-rtp-usage-02 AVTCORE WG IETF81

  2. Outline • The Basic Issue • Current Situation • Proposals and their issues • Consensus Questions AVTCORE WG IETF81

  3. The Basic Issue • RTP requires a lower transport layer to separate RTP sessions • NATs and Firewalls are everywhere • Traversal solutions incur costs • Opening additional pinholes: • Takes some small amount of time 1*RTT + N*Ta • May fail and cause communication failures • As IPv4 address gets scarce the deployment of ISP NATs will become more common. • Preserving port space becomes more important • Desired to only open a single pinhole AVTCORE WG IETF81

  4. RTCWEB Interactions • RTCWEB has very tight schedule • Desire to have only one transport layer flow for RTP sessions • In an side meeting the draft authors and chairs for both AVTCORE and RTCWEB meet and discussed the issues AVTCORE WG IETF81

  5. RTCWEB Side Agreement • RTCWEB will use a short term solution which is not a generic capability for muxingmultiple RTP sessions into one transport. • Use one RTP session to allow audio to be added as an additional stream in a session along with video, differentiated by SSRC. • This usage of such multiplexing will be signaled • The required signaling could be specified at a slower pace. • The rtcweb solution will also allow fallback to separate session for audio and video • For FEC, for example, if used by rtcweb • For interop purposes • We'd have a longer term solution which provides a generic muxing solution of multiple RTP sessions by adding an explicit RTP session identifier somewhere. AVTCORE WG IETF81

  6. Requirements from Meeting • The primary aim is to reduce the number of transport flows. • The solution must be seen as valid RTP by middle boxes. • The solution must be explicitly signaled • The solution should avoid RTP/RTCP side affects, like very high RTCP bandwidths for audio • The solution should enable reuse as much code as possible. AVTCORE WG IETF81

  7. Ideas • A Number of Idea for Solution has been thrown around: • Shim Layer • Rosenberg et al. • A Single RTP session (Jonathan Lennox) • Use the Padding Field • Define a new Profile • Do a Header Extension • Note: • All solutions requires explicit signaling and all participating RTP devices MUST agree to its use AVTCORE WG IETF81

  8. Question 1 • There is a request for being able to multiplex multiple RTP Sessions on the same lower layer without additional layers • Is this a problem the WG is interested in solving long term? • NOTE: RTCWEB is going to do a single session with multiple media types now! • They expect a better solution on long term AVTCORE WG IETF81

  9. Question 2 • If we aim at developing a solution, how important is compatibility with current RTP? • Do people prefer: • Not modifying RTP at all and use a shim layer • Find a solution that requires signaling but doesn’t break any RTP functions when signaled • That it should be compatible with RFC3550 but may break some extensions • Be similar to current RTP but we can break some part of RFC3550 • That we do RTP version 3 AVTCORE WG IETF81

  10. Way Forwards? • Actions for AVTCORE: • Do Nothing • Define Requirements for an RTP internal solution • Develop solution to meet requirements AVTCORE WG IETF81

More Related