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

Roman Shpount <roman@telurix.com> Mon, 12 September 2011 03:25 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 812CE21F8A57 for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 20:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.791
X-Spam-Level:
X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 bgbQ3B7WUTIv for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 20:25:36 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40D4521F889A for <rtcweb@ietf.org>; Sun, 11 Sep 2011 20:25:36 -0700 (PDT)
Received: by pzk33 with SMTP id 33so21498980pzk.18 for <rtcweb@ietf.org>; Sun, 11 Sep 2011 20:27:38 -0700 (PDT)
Received: by 10.68.5.138 with SMTP id s10mr2950112pbs.238.1315798057214; Sun, 11 Sep 2011 20:27:37 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i1sm40202091pbe.1.2011.09.11.20.27.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Sep 2011 20:27:35 -0700 (PDT)
Received: by pzk33 with SMTP id 33so21498717pzk.18 for <rtcweb@ietf.org>; Sun, 11 Sep 2011 20:27:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.12.40 with SMTP id v8mr3557983pbb.322.1315798054329; Sun, 11 Sep 2011 20:27:34 -0700 (PDT)
Received: by 10.68.43.136 with HTTP; Sun, 11 Sep 2011 20:27:33 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F09EE@sonusinmail02.sonusnet.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> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> <CAD5OKxtaGMuzTsRV2YJ6-UDRM4zGUK6F1h5cpp6XNKc-eR=-3w@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F09EE@sonusinmail02.sonusnet.com>
Date: Sun, 11 Sep 2011 23:27:33 -0400
Message-ID: <CAD5OKxuujU6eA2jPV1iF4y4-dDBOQCuiNZoisLy6KWcBP3=nNg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary="bcaec51f90199fdeba04acb61b42"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
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 03:25:38 -0000

Partha,

What I was saying that even with the current web client infrastructure you
can implement everything you need to create a signaling channel. You can use
a hanging HTTP request technique to send notifications to the client. This
is less efficient then websocket, but this is available and is used by a lot
of applications that implement IM and other real time event notifications.

My main point is that communications using RFC 3261 SIP would be limited to
communications between two clients on the public internet or on the same
natted network. This is useless to a consumer oriented RTC application,
where each end point would be behind its own NAT. To communicate using SIP
from behind NAT you need some types of SIP extensions. The standard that
intends (and somewhat fails) to provide a generic solution for
communications between SIP end points behind NAT is RFC 5626. This is the
only solution that allows support for SIP over TCP and SIP over TLS
(security) from behind NAT. It essentially makes clients proxy all its SIP
requests through a persistent connection to a proxy located on the public
IP. The main downsides of this solution is that I do not know of the single
one actually implemented and available (to be honest we just built one) and
that it still has problems with things like connection reset in the middle
of a SIP transaction. As far as efficiency of this solution is concerned it
is no more network, CPU, or implementation efficient then building an HTTP
to SIP proxy doing the same thing. If web RTC becomes a reality I would see
that someone can take a month or two and implement  such HTTP to SIP proxy
using SIP servlets or a custom module to opensips. This is no more
complicated then that. Once again, this does not even need websockets, but
would certainly benefit from them.

If we go this route we do not need to add anything to HTTP. We do not need
to standardize this. This all falls within an already existing capabilities
of JavaScript and things like XMLHttpRequest. There is nothing for the
standard committee to do in regard to signaling. We will not add any value
by creating new standards here. We can try to adapt SIP for RTC, but in some
sense existing browser environment provides a signaling channel that is
better, more flexible, more robust, secure, and most importantly already
implemented.

As far as working with telephone companies, our best course of action is to
provide something that, with some application knowledge, can be mapped to
SIP. If we want to terminate to the existing telephone network this is the
only course of action. Everything else will result into something were media
would need to be proxied. It does not matter how good or robust protocol we
create here, it will take telephone companies 5-10 years to adopt and
implement it. This is not the time-frame that we can afford.
_____________
Roman Shpount


On Sun, Sep 11, 2011 at 5:06 PM, Ravindran Parthasarathi <
pravindran@sonusnet.com> wrote:

>  Hi Roman,****
>
> ** **
>
> IIUC, SIP 2.0 (RFC 3261) and its extensions are not flexible for public
> internet two-party communication and HTTP (websocket) + Javascript is a
> better known solution for this communication but less efficient. I tend to
> agree with you in case my understanding about your mail is correct. ****
>
> ** **
>
> My way of looking at this problem solving using websocket with no other its
> extension is that the time of market delivery of RTCWeb1.0 without looking
> for the future. I’m worried because these sort of deliverables creates chaos
> during RTCWeb2.0 wherein RTCweb2.0 will be restricted to RTCWeb 1.0 to meet
> backward compatibility. Very good example is not that folks are not
> interested in SIP 2.0 with its extensions or SIP 3.0 as you mentioned below
> J****
>
> ** **
>
> Please read inline.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> ** **
>
> *From:* Roman Shpount [mailto:roman@telurix.com]
> *Sent:* Thursday, September 08, 2011 9:06 PM
> *To:* Ravindran Parthasarathi
> *Cc:* Harald Alvestrand; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
> recording - RTC-Web client acting as SIPREC session recording client]****
>
>  ** **
>
> Partha,
>
> What I am failing to understand is what you plan to use SIP for. ****
>
> *[Partha] SIP for real-time communication using IETF standard.*
>
> SIP would be useful to call a SIP end point on the public IP or behind the
> same NAT. If you want to call another SIP end point behind NAT, especially
> if you need to use TCP to send ICE offers or security with TLS, you will
> need an assistance of some type of server on the public IP. In order for
> this to work both server and the client will need to implement something
> like RFC 5626. This will require building something fairly tricky to
> essentially proxy all the SIP requests from the client to all the other SIP
> points. Building this is no easier then implementing the same thing using an
> HTTP server application which works with a client JavaScript library. If our
> primary goal were implementation of Intranet SIP phones, that would be an
> acceptable solution. For consumer oriented RTC service this is completely
> useless.****
>
> *[Partha]. You are comparing RFC 5626 with
> websocket(draft-ietf-hybi-thewebsocketprotocol ). Please correct me here*
>
> On the other hand extending SIP based infrastructure to implement new
> functionality is a lot more complex. Adding new features will require
> standardization or navigating a large number of conflicting SIP related
> specifications which are currently in force. ****
>
> *[Partha] I hope that you are talking about backward-compatibility issue
> which I mentioned earlier. Any new protocol looks green for the basic call
> and the mentioned supplementary services. While keep adding more service,
> HTTP will land in the same place. So, I’m not fully convinced here. I really
> don’t know why do you think SIP based infrastructure is complex but I agree
> with you that SIP API design matters.*
>
> Also, keep in mind that compliance to a lot of more advanced SIP
> specifications does not necessarily imply easy interoperability with
> existing devices. Compliance to a lot of those standards require a custom
> SIP server or SBC which implements them using a much smaller subset
> supported by each different SIP device. Bottom line, adding new features in
> SIP based environment typically requires a lot of server development, which
> is pretty much what will be required for doing signaling via an HTTP
> connection.****
>
> *[Partha] I agree with you that SIP interop is not straight forward
> because legacy implementation issues but HTTP connection calls new gateway
> with new mapping of the protocol. Please note that SIP normalization in SBC
> is well established compare to creating new HTTP + XML metadata to SIP
> gateways.*
>
>
>
> I will concur that using HTTP with JavaScript is a lot less efficient then
> using SIP for both the client and the server, since client will need to
> implement more functionality using JavaScript and the server will need to
> maintain large number of connections and proxy all the requests, but this is
> a drawback of any AJAX based solution. This is something that seems to be
> acceptable to the industry and should not be a decisive factor.****
>
> *[Partha] The industry tries to re-use  existing infrastructure for easy
> interop but does not mean that it is the best solution and IETF has to be
> adopt the same. IETF shall provide the better protocol. The industry adopts
> if the right protocol is designed or selected.*
>
>
> _____________
> Roman Shpount
>
> **
>
> On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi <
> pravindran@sonusnet.com> wrote:****
>
> Harald,****
>
>  ****
>
> I’m proposing for “SIP UA framework for RTCWeb browser”, the framework
> provides Javascript API. In case you mean the same as “SIP lite”. I’m fine
> with it. SIP UA framework helps to support two-party communication from
> RTCWeb browser and uses HTTP as presence or configuration interface. ****
>
>  ****
>
> As I mentioned in the another mail, I’m talking about INVITE subset of RFC
> 3261 in browser.  ****
>
>  ****
>
> Thanks****
>
> Partha****
>
>  ****
>
> *From:* Harald Alvestrand [mailto:harald@alvestrand.no]
> *Sent:* Thursday, September 08, 2011 12:23 PM****
>
>
> *To:* Ravindran Parthasarathi
> *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
> recording - RTC-Web client acting as SIPREC session recording client]****
>
>     ****
>
> On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: ****
>
> Harald,****
>
>  ****
>
> For browser as a SIP UA application, browser has to no need to compliant
> with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree
> with you that browser-to-browser communication, I could not see the strong
> reason for supporting S/MIME. As part of the RTCWeb architecture & solution,
> we will able to explore the SIP UA requirement for making browser SIP
> compliant.****
>
> So you're advocating for creating a "SIP lite" subset that RTCWEB browsers
> implement.
> I think we have been down this road before, and it's not a happy one.
> But sure - if you want us to implement some part of SIP, *please start
> stating what part* rather than making wooly statements.
>
> Subsets are Real Hard Work.****
>
> Say for example, forking does not make sense in case of browser as SIP UA
> application, forked response will be rejected with CANCEL in browser without
> Javascript intervention. The main requirement is to build the right SIP UA
> framework in browser by which Javascript developer will be able to use to
> the maximum extent without impacting the basic 2 two party communication in
> the internet.  ****
>
>  ****
>
> As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a
> modern exchange in web world (Plain Old Telephony System phone with exchange
> architecture). I think so because POTS phones are dumb which does not know
> its identity and every event like offhook, onhook has to passed to exchange
> (webserver) whereas RTCWeb client (browser) has to pass every event to
> webserver and webserver has whole intelligence to make it work.****
>
> Don't forget that the RTCWEB client (the browser) contains an open, fully
> programmable application platform - the Javascript engine. That's a HUGE
> difference to the POTS phone.****
>
> I got this feel more when someone is talking about MEGACO or MGCP between
> RTCWEB client & webserver. My understanding is that SIP does not fit well to
> legacy telephone-based paradigm by any means but MEGACO or MGCP are the
> better choice which maps to SS7 architecture well. I’m interested in seeing
> RTCWeb client perform the basic routing rather than webserver does the
> routing on behalf of RTCWEb client.****
>
>  ****
>
> I agree with you that in case it is local exchange (same site like skype or
> Google hangout) communication, there will be no need of signaling but I’m
> interested in communication with one of the Google real-time user in
> internet without having any Google id.  I believe that SIP will make it
> work.****
>
> If by saying "the Google real time user in Internet", you mean a Google
> Talk user, you have that already. It's called Google Voice. It uses SIP, but
> not in the browser.
>
> Talking to someone who doesn't want to talk to you is an use case we don't
> intend to support.****
>
>  ****
>
> Thanks****
>
> Partha****
>
>  ****
>
> *From:* Harald Alvestrand [mailto:harald@alvestrand.no<harald@alvestrand.no>]
>
> *Sent:* Wednesday, September 07, 2011 11:13 PM
> *To:* Ravindran Parthasarathi
> *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
> recording - RTC-Web client acting as SIPREC session recording client]
> ****
>
>   ****
>
> On 09/07/11 19:29, Ravindran Parthasarathi wrote: ****
>
> Matthew,****
>
>  ****
>
> When I asked for SIP, I have meant RFC 3261 only.****
>
> This is 269 pages, and has 26 normative dependencies including S/MIME. It's
> not a small dependency.****
>
>
>
> ****
>
> The basic reason for asking SIP is to make the basic call works between
> browser to browser across web servers. Without SIP in browser, it is not
> going happen. Innovative application is going to be proprietary whether it
> is HTTP or SIP or any other protocol for that matter.****
>
>  ****
>
> My reasoning are as follows:****
>
> SIP makes browser more intelligence compare to dump signaling mechanism
> like MEGACO and browser acts as MG. ****
>
> Why does that "intelligence" need to be in the browser, rather than in the
> Javascript?
>
> ****
>
> The importance of basic call interop is that there is no need of many
> individual id like skype id, Google id  and yahoo id by everyone in the
> world to communicate others. I wish to have single id like e-mail id to be
> maintained by browser-to-browser users to communicate with others. ****
>
> This only makes sense for applications that fit the "call an identified
> party" paradigm.
>
> ****
>
> SIP helps to interop for basic call with other existing realtime
> application in Enterprise & Telecom provider.****
>
> There is no need to build two different signaling logic in VoIP servers for
> each service. Your own example of Bridge line appearance will need two
> implementation by the single vendor because desktop application or hardphone
> implementation based on SIP and browser based implementation is depend on
> HTTP metadata. It is possible to avoided by having one signaling protocol.
> ****
>
> One protocol can be achieved by multiple applications choosing to implement
> one protocol.
> It doesn't have to be enforced by the prtoocol being embedded in the
> browser.
>
> ****
>
>  ****
>
> In RTCWEB does not standardize the signaling protocol interface between
> browsers, the interop across webservers is next to impossible and it will be
> restricted to single webserver (company) only. Please let  me know in case
> I’m missing something here.****
>
>
> I think the main thing you are missing is that there are many applications
> that people want to build on top of RTCWEB that are not telephones, and will
> not fit with telephone-based paradigms.****
>
>  ****
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>