Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[José Luis Millán <[e-mail]>]

Hi,


2011/9/19 Randell Jesup <[e-mail]>

> +1 (comments below in-line)
>
> On 9/16/2011 4:43 PM, Ted Hardie wrote:
>
>  On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <[e-mail]<mailto:
>> jim.mceachern@genband.**com <[e-mail]>>> wrote:
>>
>>    Hadriel,
>>    Well said.
>>
>>    Your closing paragraph sums it up nicely in my mind.
>>
>>    <snip>
>>    The only thing we need to do for rtcweb is make sure the RTP
>>    library built into the browser supports media in such a way that
>>    it can communicate with other RTP peers at a media plane,
>>    regardless of what signaling protocol those peers might be using,
>>    preferably without going through media gateways.  And ... we need
>>    to make sure it's possible to use SIP on the rtcweb server....
>>    </snip>
>>
>>
>> I think there is more to it than this for it to be a success.  We have to
>> make sure that it is relatively easy to adopt  rtcweb in javascript
>> applications.  The way we've discussed that in the past was "2 party video
>> chat in 20 lines of javascript".   If a novel signalling protocol is created
>> every time, that won't be a practical choice.  Even if the signalling is
>> segmented into libraries, the app will have to download the one in use by a
>> particular website, potentially every time.  This is better than a plugin in
>> some ways and potentially actually worse in others.
>>
>
> I agree whole-heartedly.  My (and I'll say Mozilla's) position is that we
> believe that while enabling unique new signalling and negotiation makes
> interesting new applications possible, we also must make sure that this
> ability is equally available to a (say) games developer who wants to add
> voice or video chat to their game without having to learn or understand 20
> years of discussions and experience with signalling and media protocols.
>
> As far as I know, this is achieved by a user level API regardless of the
signalling controller nature; browser built-in or JS stack, which serves as
an abstraction of the library underlying ins and outs.



> The point was made repeatedly when I explained this primary area of
> contention that we want it to be easy to use by the "little guys", and that
> even if signalling was a downloaded JS library, you'd end up with a wild
> mixture of old versions in use, which may complicate interop/federation
> (plus the overhead to pull them down, and some possible security issues).


 I would say that Mixture of old versions and the possible security issues
are problems to face in any case.



>> We also have to make sure that the resulting application does not flood or
>> fry the network. That means it will have to have real congestion control
>> mechanisms.   Trusting the javascript application for that has some real
>> issues which we've already discussed.   Splitting signaling and congestion
>> control isn't a lot better.  If congestion control at the network level is
>> managed by the browser but signalling is in the javascript, then information
>> about that state has to pass into the JS application, so it can manage the
>> signalling.  That makes the APIs more complex and runs the risk that a naive
>> javascript application will not adjust to the congestion control
>> requirements at all.
>>
>
> I think we do want to optionally include the JS application in the
> decisions about bit allocation, but handle it automatically for most cases.
>  A class of complex WebRTC apps will want to be able to allocate the bits
> themselves, and in some cases drop or add streams (or switch operation
> modes) in response to bandwidth changes.  Details to be determined; I plan
> to make a proposal on this.  However, unless you go out of your way none of
> this will impinge on your straightforward WebRTC app.
>
>
>
>> The early web took off in part because of the ease of embedding things
>> like images (compared to gopher, for example) into rich content.  We have
>> the opportunity to create native web applications with much richer and more
>> interactive experiences with rtcweb, but if it is not easy to do, it won't
>> have the same impact.  If this is something that can be done only by folks
>> who can roll their own signalling protocol, it's dead, because the number of
>> content authors is too small.  If it even requires selecting among an
>> unbounded set of variously maintained libraries , it will be frustrating for
>> the developer of simple applications.   At that level, the existing plugins
>> will simply be more stable and better known.
>>
>
> +1
>
>
>
>> Providing baseline APIs into a well-known signaling capability seems to me
>> far more likely to result in a real flowering of rtcweb content.  That's why
>> I want it.
>>
>> Just my two cents, not taken from any hat,
>>
>> Ted
>>
>>
Regards,


>
> --
> Randell Jesup
> [e-mail]
>
>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>