Re: [rtcweb] No Plan - but what's the proposal

[Emil Ivov <[e-mail]>]

Hey Cullen,

On 30.05.13, 20:07, Cullen Jennings wrote:
> Interesting draft but it seemed to have more questions about how
> things would wok than answers. Let me try and ask you some specifics
> to help flesh out what this plan is and offer a few comments.
>
> Of the actual recommendations in the draft that relate to the problem
> I would summarize that draft as
>
> 1) demux RTP based on PT but let the application know the SSRC in
> case it wants to do something more
>
> 2) the way the applications interacts with the browser for set up of
> the media stack is via SDP
>
> 3) Other session control not related to the media stack is left up to
> the application to do how it wants
>
> 4) Things like conference control and clue control  and call control
> should be handled by the application
>
> 5) you have a few avenues we might pursue for making FEC, RTC, etc
> work
>
> 6) you have some API requirements

Yes, the above seem like an accurate summary.

> which, with the exception of 4
> about exposing the max number of incoming streams that can be
> decoded, I think are pretty much agreed to be put put in W3C API
> already.
> On the topic of #4, it's a big unclear what is really needed
> and ongoing discussion is happening around how do indicate what can
> be received but thats a webrtc issue

Then I suppose this is a good time for us to agree here on what we need 
the API to expose so that the underlying protocols would work.

> This is very close to Plan A.

I'd say it's actually closer to Plan B but Plan-A-style signalling 
should certainly be possible to implement by the app or a signalling 
gateway.

> So I read the whole draft and asked
> myself how is this different than plan A. What parts of this draft
> would not be abel to do if we did Plan A.

The part where one doesn't have to redo (and propagate) an Offer/Answer 
exchange every time a source is added or removed.

> The only real topic I could
> come up with was the port music here is PT only instead of PT + SSRC.
> I'l start a separate thread on that.

This is another difference indeed.

> But lets ask what the proposal is for the question Plan A and Plan B
> are trying to resolve.
>
> Let's say browse A wants to say it can send two streams of video and
> here are the parameters for the video codecs for each to the streams.
> What does the SDP that createOffer generates look like?

There's an example in the draft. I assume the "parameters" you mention 
are not in there, so could you please be more specific?

> I see the
> draft says "strongly advises against the use of multiple m= lines for
> a single media type. " but I don't really know what you mean by that.

It means a browser should generate and offer that looks like this:

m=audio
m=video

rather than an offer that looks like this

m=audio
m=video
m=video
m=video

Also if one bundle is not enough to fit all payload types in the two 
media lines, then we split them in two.

> Can you explain what you are actually proposing we do do instead of
> just saying what not to do ?

We create an offer that would describe the media types and the bundle. 
We use that offer to also describe capabilities in terms of maximum 
resolutions, supported header extensions, potentially max-ssrc-s, etc.

It is up to the application how to handle the rest. If it needs to 
transmit additional signalling: let it. If it wants to encode that in 
SDP, great. If it wants to attach it in JSON next to the browser 
generated SDP, that also works.

> The above paragraph is the most important part of my email. Please,
> what is the proposal for what the SDP in the offer looks like.

You started another thread for this, so I'll respond there.

> The idea of exposing a low level API to the media stack and having
> the all proposing to do FEC, RTX, SDP processing ect has been
> discussed many times across the various working groups. It' jokingly
> refereed to as comment 22 at this point.

I appreciate you are trying to turn this into a joke (which I think is a 
pity provide your chairing role in this working group), but abandoning 
SDP really isn't what this is about. You might have noticed text about 
this as early as the abstract:

   This document does not question the use of SDP and the Offer/Answer
   model or the value they have in terms of interoperability with legacy
   or other non-WebRTC devices.

Emil

> It's not that it does not
> have merits, but many people myself included see it as a much longer
> road to get done, a lot more work, and no clear gain. One of the
> other issues is we are trying to make this so you don't have to be a
> telephone expert to use it and that lots of developers can use it.
> I'm not going to try and summarize the low level API augments here
> but if you want to discus it webrtc is the right WG.
>
> I'll note there are many points in the draft that I disagree
> with but
> I'd rather try and sort through what the actually proposal is here
> before addressing any of them.
>
> There is one point I would like to make that is the confusion
> introduced by "legacy endpoint". When I talk about legacy endpoints,
> I am talking about endpoints that use SIP or Jingle and both past
> ones and future endpoints. SIP will continue to evolve  and I expect
> WebRTC to continue being able to negotiate new features. For example,
> if a SIP phone added VP9 and a browser supported VP9, I would expect
> to be able to use it. The legacy refers to an older protocol, SIP,
> and not to the age of the endpoint. We do know that things can't work
> with all deployed endpoints and long ago we made the decision to give
> up on endpoints that don't do ICE. But we do try and have a
> reasonable experience with old and future endpoints.
>
>
> On May 29, 2013, at 12:59 PM, Emil Ivov <[e-mail]> wrote:
>
>> Hey all,
>>
>> Based on many of the discussions that we've had here, as well as
>> many others that we've had offlist, it seemed like a good idea to
>> investigate a negotiation alternative that relies on SDP and
>> Offer/Answer just a little bit less.
>>
>> The following "no plan" draft attempts to present one such
>> approach:
>>
>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>
>> The draft relies on conventional use of SDP O/A but leaves the
>> intricacies of multi-source scenarios to application-specific
>> signalling, with potentially a little help from RTP.
>>
>> Hopefully, proponents of Plans A and B would find that the
>> interoperability requirements that concerned them can still be met
>> with "no plan". Of course they would have to be addressed by
>> application-specific signalling and/or signalling gateways.
>>
>> Comments are welcome!
>>
>> Cheers, Emil
>>
>> -- https://jitsi.org
>> _______________________________________________ rtcweb mailing
>> list [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
https://jitsi.org