Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]

Silvia Pfeiffer <silviapfeiffer1@gmail.com> Thu, 08 September 2011 06:18 UTC

Return-Path: <silviapfeiffer1@gmail.com>
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 AF88F21F8C00 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 23:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 i15PqVAYe0Yt for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 23:18:01 -0700 (PDT)
Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEBD21F8BC3 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 23:18:01 -0700 (PDT)
Received: by gxk9 with SMTP id 9so689014gxk.40 for <rtcweb@ietf.org>; Wed, 07 Sep 2011 23:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=J4MRLXWHHiPBQnXkR6TIAnPYdzGeZuKYmrKNugAZ60o=; b=SkcSeeb0tKaj9TNHnKsaFibdpEFtmlnXXrFlgT45oknXisUSzwhOAUACGCTD+H+JOf lT7ls85zH4JUbuV/aBnzUCu4EQ25azv00JvLha3Bc6JLK778KfzT/mP50Gyr2KKRbNV/ ifxkoO4nNR2hyRW+rYQ4ICPkc2ga+zpE2DfbU=
Received: by 10.236.76.225 with SMTP id b61mr1613457yhe.92.1315462792149; Wed, 07 Sep 2011 23:19:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.236.203.5 with HTTP; Wed, 7 Sep 2011 23:19:32 -0700 (PDT)
In-Reply-To: <F5C58E92-F73F-4587-840C-4389C9882305@edvina.net>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> <CAHp8n2=Q9a14pnAojAUmdGcpuEN-QXF2DVmfckEzt4R-Ngbb8g@mail.gmail.com> <F5C58E92-F73F-4587-840C-4389C9882305@edvina.net>
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 8 Sep 2011 16:19:32 +1000
Message-ID: <CAHp8n2=sZLuwPG8Ri27oArxgfxV+iWcHTV=-x2jcQsOCbUK_hg@mail.gmail.com>
To: "Olle E. Johansson" <oej@edvina.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]
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: Thu, 08 Sep 2011 06:18:02 -0000

I'm arguing for leaving it out, since obviously it's already possible
to support it in the browser through web sockets. We wouldn't put
SMPTE support into browsers either just to be able to read email in
browsers.

I wonder: if you are arguing for it, what is it that is not possible
with such a JS implementation that would require introduction of a
totally new technology into the browser (with all associated security
risks)?

Silvia.


On Thu, Sep 8, 2011 at 3:51 PM, Olle E. Johansson <oej@edvina.net> wrote:
>
> 8 sep 2011 kl. 03:15 skrev Silvia Pfeiffer:
>
> If implementations count for anything, check out:
>
> http://phono.com/
> and
> https://docs.google.com/present/view?id=0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl=en&pli=1
>
> They use SIP with web sockets.
>
> Nice. That will make it easy to hook in the rtcweb/webrtc media layer.
> Now, I don't see clearly if you want to argue for or against SIP as part of
> rtcweb standards with these examples, but that may be my biased eyes
> reading... ;-)
> /O
>
> Cheers,
> Silvia.
>
>
> On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman
> <matthew.kaufman@skype.net> wrote:
>
> On 9/7/11 12:20 PM, Randell Jesup wrote:
>
> I also started from the same point - assume SIP.  SIP gives you all the
>
> things that the zillions of hours and emails to define it and define
>
> extensions and secure it provides, without having to reinvent all those
>
> wheels (or ask app developers to reinvent them).  Why go through the
>
> horrible pain of choosing something else, or why throw the app developers to
>
> the wolves to fend for themselves?
>
> However...
>
> Two things have swayed me.  The primary one is the suggestion of
>
> Offer/Answer in the browser.  This breaks out the important negotiation
>
> piece that almost any application would need, and while not perfect, SDP O/A
>
> is a zillion times simpler than SIP with all the extensions one could use.
>
> I agree with this. While I am also opposed to SDP O/A, these are two
>
> unrelated arguments to have... and not baking a SIP phone into the browser
>
> is *more* important than avoiding a repeat of the offer/answer problems.
>
>
> The other thing that swayed me was thinking about federation and the apps
>
> that will be built with this.  A webrtc app talks to its (web)server, other
>
> webrtc clients running the app that talk to the server, and to other webrtc
>
> applications/networks that federate with it (and their clients).
>
> Federation is in the same hands as the person who provides/wrote the app.
>
>  If they have no interest in federation you can't force it, and they may
>
> have no use for all the fancy SIP standards.
>
> And for numerous types of apps (think: server-based augmented reality
>
> systems), "federation" doesn't even make sense.
>
>
> On the other hand, if they *want* to either provide access to the wider
>
> communication net that is the PSTN network, now or in the future, or they
>
> want easy federation with other networks, it behooves them to use SIP or
>
> something very close to it or equivalent/convertible (at a basic level at
>
> least) to it.
>
> So what conclusions do I draw from this?
>
> 1) O/A via SDP in the browser simplifies a lot of things (including
>
> handling new codecs, etc).  It doesn't extremely limit an application,
>
> though we should think about how an application can interact with the
>
> fmtp/etc parameters used.
>
> I agree that it would simplify some interop cases, but at an unfortunate
>
> cost in lack of flexibility and functionality. Still not nearly as bad as if
>
> we put a full SIP stack in there though.
>
>
> 2) SIP as a *separate* item that can be cleanly and easily *added* to a
>
> webrtc app to handle the call setup/etc is a good idea.
>
> I would be open to looking at this again, *after* RTC is already in browsers
>
> and successful, to see if it actually solves a real use case.
>
> Matthew Kaufman
>
> _______________________________________________
>
> rtcweb mailing list
>
> rtcweb@ietf.org
>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> ---
> * Olle E Johansson - oej@edvina.net
> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
>
>
>