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

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Thu, 08 September 2011 13:53 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 2355421F8B87 for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 06:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.603
X-Spam-Level:
X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 JTID426pvQeB for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 06:53:12 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F221F844F for <rtcweb@ietf.org>; Thu, 8 Sep 2011 06:53:11 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p88Dt3sR021272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Thu, 8 Sep 2011 08:55:04 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88Dt3Ph030918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Thu, 8 Sep 2011 08:55:03 -0500
Received: from [135.244.18.36] (faynberg.lra.lucent.com [135.244.18.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p88Dt2gA019207; Thu, 8 Sep 2011 08:55:03 -0500 (CDT)
Message-ID: <4E68C935.2090607@alcatel-lucent.com>
Date: Thu, 08 Sep 2011 09:55:01 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
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>
In-Reply-To: <CAHp8n2=Q9a14pnAojAUmdGcpuEN-QXF2DVmfckEzt4R-Ngbb8g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010704070200050806060500"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
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
Reply-To: igor.faynberg@alcatel-lucent.com
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 13:53:14 -0000

Finally, I am getting an answer to my question!  Thanks, Silvia!

One question: Is it possible to get the full library source code?  (I 
cannot find the this.phone.dial code, but this is the one that sends the 
INVITE as far as I figured out.  Most important, I cannot find how 
notifications are handled.)

Igor

|
|



On 9/7/2011 9:15 PM, Silvia Pfeiffer wrote:
> 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