Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

Iñaki Baz Castillo <ibc@aliax.net> Fri, 07 October 2011 01:54 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 2C81A21F8B98 for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 18:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, 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 1JVPCRlsWtvb for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 18:54:18 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA3221F8B95 for <rtcweb@ietf.org>; Thu, 6 Oct 2011 18:54:18 -0700 (PDT)
Received: by vws5 with SMTP id 5so3451541vws.31 for <rtcweb@ietf.org>; Thu, 06 Oct 2011 18:57:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.184.103 with SMTP id et7mr570836vdc.35.1317952650465; Thu, 06 Oct 2011 18:57:30 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Thu, 6 Oct 2011 18:57:30 -0700 (PDT)
In-Reply-To: <4E8D6507.8000707@ericsson.com>
References: <CA+9kkMBi9BzDu=WOq3RG-o5nbfnUTftDg3LRBU3DFh=Kc4W5ZQ@mail.gmail.com> <CALiegfmYgQ+yb=pDp1J2_PVa1SkxTOuaUCM02Vt6-iGabwif1g@mail.gmail.com> <CA+9kkMCUTiPO3eASjn0mbRA9YCF6TMmGGOjQ4NkVkvzVMN39Gg@mail.gmail.com> <CALiegfnx=qoS_pqyC45WVEYEFqj-3eP9g_kyhAUaOO6He_UEfw@mail.gmail.com> <CA+9kkMCibnPLrEq1234bUMXpiKBK0+22mqwYOM__CpcO2nOayg@mail.gmail.com> <CALiegfms2bt-WPtMeosFQz3-aSf2L6mfX+i68tw45sSgix561Q@mail.gmail.com> <4E8D6507.8000707@ericsson.com>
Date: Fri, 7 Oct 2011 03:57:30 +0200
Message-ID: <CALiegf=VyViX2arp0gr0dK4WN_jv=bjwP0LUAxRf=quTxrYrUQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)
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: Fri, 07 Oct 2011 01:54:19 -0000

2011/10/6 Magnus Westerlund <magnus.westerlund@ericsson.com>;:
> My interpretation of your draft is that it is a description of how you
> can deploy SIP implemented in JS over websocket.

Yes.


> Thus enabling SIP
> interworking when needed by having the JS SIP stack convert regular SIP
> with SDP into interactions with the WEBRTC API.

Yes.


> Thus your proposal
> really is primarily an argument that you don't need SIP implemented in
> the browser,

Of course, I don't want a SIP native stack in the browser, never.


> as long as the API allows the JS to create SIP with SDP
> messages.

Not exactly. We generate the SIP messages in JS (without using a
RTCweb API at all). We just need a RTCweb API to create a SDP object
(maybe a JS object) so then I can generate the plain SDP using
JavaScript (and XMPP/Jingle folks would generate a XML SDP).
And we just need some way to tell the RTCweb stack from JS: "hey, I've
received this SDP and I need you to tell me what do you think about
it, parse it please, or ask me to previously convert it into a
specific JS object and then I pass it to you".



> Thus I would interpret this as something that could work both
> over something similar to the current PeerConnection API proposals and a
> more low level API. Where PeerConnection likely is less work as it does
> provide the SDP that in most cases don't need modifications.

Right. But this could occur regardless the signaling protocol chosen
by each web application. At the end, Alice will receive (via
HTTP/WebSocket) something like a SDP from Bob, and Alice must deal
with that with the help of a JS RTCweb API.



> Is this a correct interpretation and thus your draft is an extension
> that simplifies life for the people who like SIP interworking by getting
> the SIP functionality into the end-point rather than a gateway?

Sure :)



> Or is it something else?

No, it's exactly that.


> If it is the first I don't see your proposal as complete proposal for
> how signaling for RTCWEB, as you still need APIs to something in some
> form and with possibly certain semantics that interact with the SIP in
> JS implementation.

You are right. It's just a signaling proposal (not to make a standard
signaling, not at all, but just a signaling example, in this case pure
SIP).



> To clarify, what I see the question for the WG is how the signalling
> model for RTCWEB session establishment is intended to work. Thus the
> drafts intended for answering this needs to be focused on describing a
> signalling model.

Yes, agreed.


Regards.


PS: SIP over WebSocket just works fine. A demonstration next week.



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