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

[Harald Alvestrand <[e-mail]>]

On 05/07/2013 02:08 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.
> - Assume I have two cameras, one which can handle codec X, and one which can handle codec Y.
>
> - I send you an offer with a video m- line, offering X, Y and a ssrc for each camera
>
> - You only want one of my camera streams, AND you only support codec X. Now, how do you know which ssrc to choose? You don't know which uses codec X.

Right. That's the part that goes all artificial on me. Two cameras, and 
I'm going to choose blindly between them if I support both codecs, but I 
can't accept both and let you deal with sending me only the one I can 
handle?

You can, if you want to, send me two M-lines: "a=content:codec-x" and 
"a=content:codec-y". This is an example of "the application is dependent 
on segregating the codecs".

>
> Now, maybe this is a theoretical problem, but I think the draft needs to describe that codecs, and codec configurations, apply to all ssrcs associated with an m- line.
>
> And, IF there is a need to apply codecs to a specific ssrc only, you need to use a separate m- line for that ssrc.

Agreed.

>
>>> 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.
> Fair enough, but that needs to be clearly described.
>
>
>>> 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.
> I wasn't referring to the MSID identifier, but more to the fact that you don't indicate the ssrc value for the "main" flow. I thought we were going to mandate the indication of the ssrc value for each flow, but maybe I remember wrong.

I was trying to locate the flows in the example in section 5.2, and I 
couldn't find them anywhere but in the MSID attribute. So I couldn't 
parse your comment.

The way I read the document, the first m=audio line is the main audio; 
it has 3 audio flows.
The first m=video line is the main video; it has 3 video flows.
The third m=video line is the slides video; it has 2 SSRCs, one for the 
main flow and one for the repair flow.

So - the issue seems to be that the word "main" as in "main audio" is 
easy to mistake for "a single main flow". It isn't intended to be that 
way. I guess the text could be clearer.



>
>
>>> 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.
> Fair enough. My mistake.
>
> Regards,
>
> Christer
>
> 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.
>
>   
>   
>   
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Harald Alvestrand
> Sent: 6. toukokuuta 2013 17:20
> To: Justin Uberti
> Cc: [e-mail]; [e-mail]
> 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: <[e-mail]>
> Date: Thu, May 2, 2013 at 10:46 PM
> Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
> To: Justin Uberti <[e-mail]>
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>   
>