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

Roman Shpount <roman@telurix.com> Mon, 12 September 2011 21:30 UTC

Return-Path: <roman@telurix.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 1D53621F8E27 for <rtcweb@ietfa.amsl.com>; Mon, 12 Sep 2011 14:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.582
X-Spam-Level:
X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, 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 iejyppjYInqx for <rtcweb@ietfa.amsl.com>; Mon, 12 Sep 2011 14:30:29 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D263321F8E22 for <rtcweb@ietf.org>; Mon, 12 Sep 2011 14:30:28 -0700 (PDT)
Received: by gwb20 with SMTP id 20so3282417gwb.31 for <rtcweb@ietf.org>; Mon, 12 Sep 2011 14:32:30 -0700 (PDT)
Received: by 10.151.87.13 with SMTP id p13mr1268230ybl.332.1315863150120; Mon, 12 Sep 2011 14:32:30 -0700 (PDT)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx.google.com with ESMTPS id h1sm807198ybi.29.2011.09.12.14.32.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Sep 2011 14:32:29 -0700 (PDT)
Received: by gxk28 with SMTP id 28so4189770gxk.27 for <rtcweb@ietf.org>; Mon, 12 Sep 2011 14:32:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.8.66 with SMTP id p2mr3075918pba.442.1315863148401; Mon, 12 Sep 2011 14:32:28 -0700 (PDT)
Received: by 10.68.46.227 with HTTP; Mon, 12 Sep 2011 14:32:28 -0700 (PDT)
In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A50DF699@nambx03.corp.adobe.com>
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> <0FEA137C08A9DF4781EEF745038C969430A50DF699@nambx03.corp.adobe.com>
Date: Mon, 12 Sep 2011 17:32:28 -0400
Message-ID: <CAD5OKxsTPO8LHDH-QC_dBOhPuc6nvKUS0isMDtnrcgi4_urWzQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Jozsef Vass <jovass@adobe.com>
Content-Type: multipart/alternative; boundary=bcaec53ae87888960e04acc543df
Cc: "rtcweb@ietf.org" <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: Mon, 12 Sep 2011 21:30:30 -0000

Neither do they websockets (they use BOSH
http://xmpp.org/about-xmpp/technology-overview/bosh/) or SIP (at least not
for client to server communications).
_____________
Roman Shpount


On Mon, Sep 12, 2011 at 5:10 PM, Jozsef Vass <jovass@adobe.com> wrote:

> Neither the website nor the documents mention the use of Flash, which is
> evident if you try the app. They also make use of the acoustic echo
> cancellation capability available in Flash.
>
> Jozsef
>
> -----Original Message-----
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
> Sent: Wednesday, September 07, 2011 6:16 PM
> To: Matthew Kaufman
> 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]
>
> 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.
>
> 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
>