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

José Luis Millán <jmillan@aliax.net> Mon, 19 September 2011 10:15 UTC

Return-Path: <jmillan@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AB721F8B7F for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 03:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.825
X-Spam-Level:
X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRsqmkZuNK-X for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 03:15:15 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7199021F8B7A for <rtcweb@ietf.org>; Mon, 19 Sep 2011 03:15:15 -0700 (PDT)
Received: by iaby26 with SMTP id y26so6540477iab.31 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 03:17:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.66.14 with SMTP id l14mr3827459ibi.69.1316427457949; Mon, 19 Sep 2011 03:17:37 -0700 (PDT)
Received: by 10.231.36.201 with HTTP; Mon, 19 Sep 2011 03:17:37 -0700 (PDT)
In-Reply-To: <4E76E078.5020708@jesup.org>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com> <4E76E078.5020708@jesup.org>
Date: Mon, 19 Sep 2011 12:17:37 +0200
Message-ID: <CABw3bnMOzUTC8yfdmtkeZp7NMWkpNP6FWwcHTJ=EE+u8UgG-kw@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= <jmillan@aliax.net>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary=00151773e02800ef6804ad48a71c
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 10:15:16 -0000

Hi,


2011/9/19 Randell Jesup <randell-ietf@jesup.org>;

> +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 <jim.mceachern@genband.com<mailto:
>> jim.mceachern@genband.**com <jim.mceachern@genband.com>>>; 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
> randell-ietf@jesup.org
>
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>