Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Iñaki Baz Castillo <ibc@aliax.net> Sat, 15 October 2011 08:43 UTC

Return-Path: <ibc@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 330C421F8B30 for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 01:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level:
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 zRIZLao3td+9 for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 01:43:38 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7469421F8ACE for <rtcweb@ietf.org>; Sat, 15 Oct 2011 01:43:38 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1890016vcb.31 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 01:43:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.184.11 with SMTP id ci11mr964817vcb.76.1318668217880; Sat, 15 Oct 2011 01:43:37 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Sat, 15 Oct 2011 01:43:37 -0700 (PDT)
In-Reply-To: <CA+9kkMDsWyKdvXSRMV0OGEeEYbSENFHSOovNJDUGK30N_pGrnQ@mail.gmail.com>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com> <ABB0E87F-DEEF-4386-A718-D48E00F5961A@acmepacket.com> <CALiegfnHuYJnX3rnuDGbZPB4NvK=dCTJ=iLcu+zguP5wo_uPqQ@mail.gmail.com> <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <CALiegfn6nv1D2HjeMo-jPDh9Acph7JdH1DT1xZXUtHqzqxya3Q@mail.gmail.com> <CA+9kkMB3p1u7hRX_vO1bQbQ2z-V+0rLiJmi+ZqkEA0mqc66keQ@mail.gmail.com> <CALiegf=26_6r_YjBCmO+6_GnrAzi=KcLoPFqUi-y1E8m_gWreQ@mail.gmail.com> <CA+9kkMDsWyKdvXSRMV0OGEeEYbSENFHSOovNJDUGK30N_pGrnQ@mail.gmail.com>
Date: Sat, 15 Oct 2011 10:43:37 +0200
Message-ID: <CALiegfkNapr9rB29xDa2H5Ap0P6PJzQrzpkshBAURg6hwcRRHA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Sat, 15 Oct 2011 08:43:39 -0000

2011/10/15 Ted Hardie <ted.ietf@gmail.com>;:
> On Fri, Oct 14, 2011 at 2:41 PM, Iñaki Baz Castillo
>>
>> IMHO RTCweb (specially the JS API for managing media sessions) must be
>> designed in a way that it's possible for a developer to implement a
>> SIP client in JavaScript or another custom signaling protocol having a
>> gateway that maps it to/from SIP. This means that SIP features as
>> parallel forking, early media, conference... should be possible using
>> the RTCweb JavaScript API.
>
> Do you think you could support SIP identity with a javascript client?

Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to
have a list of CA's and verify the retrieved certificate by itself. A
JavaScript client receiving an incoming INVITE with Identity and
Identity-Info header could make a webservice call (i.e. using AJAX)
and ask its web server to retrieve it and verify it in behalf of the
client. And still that is SIP.

So yes, I could support SIP Indentity with a JavaScript client.


>> So, assuming that there MUST NOT exist a *standard* signaling protocol
>> for federation in RTCweb, what is the purpose of speaking about
>> "federation"?
>
> I don't think RFC 2119 MUST NOTs belong here.
>
> Understanding federation as a use case does not mandate a "one ring to rule
> them all" approach to federation.  We could define one (as XMPP defines how
> different XMPP servers pass traffic among themselves).  That would not
> mandate that all servers use it.  We could also choose not to define one,
> but if we support the use case, we would have to understand what the minimal
> set of data that had to be pass over the protocols implementing the
> federation would be, what security is required, and so on.

So just imagine that SIP is used for federation and make the
requirements assuming that.


>> Probably we all are speaking about the same concept, but
>> for me "federation" means a RTCweb server communicating with other
>> RTCweb server. If Hadriel and you meant "RTCweb server communicating
>> with a SIP network" then I repeat my first paragraph :)
>>
>> So in order to accomplish with requirements of Hadriel we need to make
>> the RTCweb client stack and the RTCweb JavaScript API flexible enough
>> so all (or most of) the SIP features can be implemented in JavaScript
>> (I mean "audio/video features" since all the signaling can already be
>> coded in different ways).
>>
>> Hope it's more clear now.
>>
>
> Well, given that you don't believe in the need for a protocol here at all,

A protocol is needed, of course. But not a *specific* protocol.


> but only an incredibly flexible API, it seems a bit unclear why you're not
> making these points on the W3C public mailing list for this activity.

I expect such work must come once the requirements for such API are
done in this WG.


> A truly well structured API here will imply, at least in my view, at least a
> common model for negotiation and a common set of structured data to be
> passed via this javascript-implemented protocol.  Doing that without
> defining a standard protocol is actually harder than doing it while defining
> a protocol.
>
> I've heard the various arguments against defining one, but none of them
> seems to stand up against the base fact that you can have a standard
> protocol--known to be available--without restricting the ability to create
> proprietary protocols using the same API.

There have been lot of arguments contrary to defining a "default
signaling protocol". I don't want to repeat them again, but neither
answer as if they don't exist.


Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>;