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: Iñaki 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>
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- [rtcweb] Signalling, SDP, and the way we think ab… BeckW
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Hadriel Kaplan
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Hadriel Kaplan
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Ted Hardie
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Hadriel Kaplan
- Re: [rtcweb] Signalling, SDP, and the way we thin… Ted Hardie
- Re: [rtcweb] Signalling, SDP, and the way we thin… Dzonatas Sol
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Neil Stratford
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Harald Alvestrand
- Re: [rtcweb] Signalling, SDP, and the way we thin… Neil Stratford
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Harald Alvestrand
- Re: [rtcweb] Signalling, SDP, and the way we thin… Neil Stratford
- Re: [rtcweb] Signalling, SDP, and the way we thin… Roy, Radhika R USA CIV (US)
- Re: [rtcweb] Signalling, SDP, and the way we thin… Stephan Wenger
- [rtcweb] VP8 and parameters (Re: Signalling, SDP,… Harald Alvestrand
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Dzonatas Sol
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang Beck
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Ted Hardie
- Re: [rtcweb] Signalling, SDP, and the way we thin… Dzonatas Sol
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang Beck
- Re: [rtcweb] Signalling, SDP, and the way we thin… Cullen Jennings