1 / 8

Adam’s m = line Musings

Adam’s m = line Musings. draft-roach-mmusic-mlines-00 RTCWEB Interim Boston, MA February 5 th , 2013. Three Proposed Approaches. Approach 1a: One m= section per media type, regardless of how many streams of that type in the session Approach 1b: One m= section per session (MMT)

darrin
Download Presentation

Adam’s m = line Musings

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. Adam’s m= line Musings draft-roach-mmusic-mlines-00 RTCWEB Interim Boston, MA February 5th, 2013

  2. Three Proposed Approaches • Approach 1a: One m= section per media type, regardless of how many streams of that type in the session • Approach 1b: One m= section per session (MMT) • Approach 2: One m= section per media stream

  3. Codec Selection • Handling of preferences in RFC3264 currently assumes one-stream-per-m-section model • This requires fix-up for approaches 1a and 1b (or ambiguity and loss of control) • Favors approach 2

  4. Port Number Handling • SDP syntax does not natively support bundling more than one m= section into a single session (port # is mandatory). • For solutions 1a and 2, we need to choose “the lesser of two evils”: • Indicating the same port in all lines trips up legacy use • Indicating different ports (some bogus) in each line trips up some SBCs • Favors approach 1b

  5. Attribute Handling • Since attributes can roughly apply to either sessions or to streams, creating a distinction requires updates to attribute handling • Approaches 1a and 1b can use RFC5576 for stream-level attributes • Approaches 1a and 2 can indicate transport-level attributes in all relevant m= sections • Because 1a must address both situations, it is more complicated than the either two.

  6. Unknown Unknowns • Problems such as the codec selection problem are yet to be identified for the general case. • Addressing these issues in the future is easiest if we have the most granular control surface possible. • This also makes future extensions more compatible with non-RTCWEB SDP use • This supports selection of the most granular control surface, which is alternative 2.

  7. Problems with all solutions • Offerer and answerer needing different number of streams • Attribute bidirectionality • Implementation complexity

  8. Approach Summary

More Related