Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

On 05/07/2013 12:11 PM, Christer Holmberg wrote:
>
> Hi,
>
> A few questions on the draft:
>
> Q1_CODEC/CODEC CONFIGURATION:
>
> The examples only show one PT per m- line, and the draft seem to 
> assume that all PTs (ie codecs and/or codec configurations) apply to 
> all SSRCs within an m- line. I think that is very important to point 
> out, because at least in my opinion it is an important factor that we 
> need to discuss.
>
> Example: I think Cullen often talks about using a camera with built in 
> codec X. But, Plan B does not allow to (or, at least does not describe 
> how to) explicitly offer codec X for the track/ssrc associated with 
> the camera. Codec X is offered for ALL tracks/ssrcs associated with 
> the m- line.
>

My read: This is a very special use case. The sender always chooses the 
codec from the available codecs that the recipient can understand - and 
it's then free to choose the built in codec X if supported by the recipient.

If, for some reason, the application is dependent on segregating the 
codecs, it can use the "a=content" mechanism to segregate the streams 
onto different M-lines.

> Q2_1_LEGACY:
>
> The text says that things must work with legacy devices, and that an 
> endpoint can choose a single source when communicating with a legacy 
> device. But, there is really no text about how the legacy device will 
> know which source to use, etc.
>

The application that drives the API will have to decide that it can send 
only one source. The browser cannot (in my opinion) sensibly make that 
choice on behalf of the application.

> Q2_2_LEGACY:
>
> The example in section 5.2 (and sub sections) confuses me a little. 
> You indicate that the m- line itself represents "main", while ssrc 
> attributes are used to describe the left/center/right mic sources. Why 
> is there no ssrc attribute for the main flow?
>

The MSID identifier is, by definition, meaningless. The association 
between the MSID and the function of the stream is not carried in the 
MSID attribute. The example is a bit unfortunate in that it uses MSIDs 
that look as if they're human-readable strings that carry semantics.

> Q3_NUMBER_OF_M_LINES:
>
> The draft does not explicitly forbid the usage of multiple m- lines 
> for a given media type (e.g. audio). It would probably be good to 
> point that out also.
>

In fact the a=content mechanism (see section 3.1) depends on the ability 
to use multiple m- lines for a given media type, so it would be really 
hard to interpret the draft as forbidding this.

There's an issue with representing the semantics of an incoming call 
that uses multiple m- lines for a given media type and doesn't give 
differing a=content attributes for those media types.
I don't know if such a scenario ever occurs in practice.
>
> Regards,
>
> Christer
>
> *From:*rtcweb-bounces@ietf.org <mailto:rtcweb-bounces@ietf.org> 
> [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Harald Alvestrand
> *Sent:* 6. toukokuuta 2013 17:20
> *To:* Justin Uberti
> *Cc:* rtcweb@ietf.org <mailto:rtcweb@ietf.org>; mmusic@ietf.org 
> <mailto:mmusic@ietf.org>
> *Subject:* Re: [rtcweb] Fwd: New Version Notification for 
> draft-uberti-rtcweb-plan-00.txt
>
> Note - I regard the Plan A / Plan B conflict as the "long end of the 
> pole" with regards to resolving issues regarding SDP signalling in 
> RTCWEB - and as such, I regard it as very important to get it resolved.
>
> The silence on this issue is disquieting.
>
>            Harald
>
>
> On 05/03/2013 08:08 AM, Justin Uberti wrote:
>
>     Scribbled down the basic concepts of what I have been referring to
>     as "Plan B" - a way to signal multiple MediaStreamTracks in SDP
>     without needing a separate m= line for each.
>
>     Hopefully this will make discussion of this topic easier.
>
>     ---------- Forwarded message ----------
>     From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>     Date: Thu, May 2, 2013 at 10:46 PM
>     Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
>     To: Justin Uberti <justin@uberti.name <mailto:justin@uberti.name>>
>
>
>
>     A new version of I-D, draft-uberti-rtcweb-plan-00.txt
>     has been successfully submitted by Justin Uberti and posted to the
>     IETF repository.
>
>     Filename:        draft-uberti-rtcweb-plan
>     Revision:        00
>     Title:           Plan B: a proposal for signaling multiple media
>     sources in WebRTC.
>     Creation date:   2013-05-03
>     Group:           Individual Submission
>     Number of pages: 15
>     URL:
>     http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
>     Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
>     Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00
>
>
>     Abstract:
>        This document explains how multiple media sources can be
>     signaled in
>        WebRTC using SDP, in a fashion that avoids many common problems and
>        provides a simple control surface to the receiver.
>
>
>
>
>     The IETF Secretariat
>
>
>
>
>     _______________________________________________
>
>     rtcweb mailing list
>
>     rtcweb@ietf.org  <mailto:rtcweb@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>