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

"Ravindran Parthasarathi" <> Thu, 08 September 2011 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE30221F85EC for <>; Thu, 8 Sep 2011 08:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3BpOiFdFw7SW for <>; Thu, 8 Sep 2011 08:12:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B993C21F85AE for <>; Thu, 8 Sep 2011 08:12:28 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p88FEk8R019545; Thu, 8 Sep 2011 11:14:46 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 11:13:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6E39.E35B7242"
Date: Thu, 8 Sep 2011 20:43:32 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
Thread-Index: Acxt9AbN3JhWXoAGQEWrQ9SN744t+wARGUtg
References: <> <> <> <><> <> <> <> <> <> <> <> <> <>
From: "Ravindran Parthasarathi" <>
To: "Harald Alvestrand" <>
X-OriginalArrivalTime: 08 Sep 2011 15:13:43.0904 (UTC) FILETIME=[E6121E00:01CC6E39]
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2011 15:12:33 -0000



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


As I mentioned in the another mail, I'm talking about INVITE subset of
RFC 3261 in browser.  





From: Harald Alvestrand [] 
Sent: Thursday, September 08, 2011 12:23 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman;;
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: 



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

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.





From: Harald Alvestrand [] 
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman;;
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: 



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


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.