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

Harald Alvestrand <> Wed, 07 September 2011 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3283A21F8C95 for <>; Wed, 7 Sep 2011 10:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.776
X-Spam-Status: No, score=-107.776 tagged_above=-999 required=5 tests=[AWL=2.822, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RdgOOcfZEdf7 for <>; Wed, 7 Sep 2011 10:41:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5F12A21F8C93 for <>; Wed, 7 Sep 2011 10:41:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D88A839E112; Wed, 7 Sep 2011 19:43:26 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k83rRXCyu0Qb; Wed, 7 Sep 2011 19:43:25 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id 86D5539E072; Wed, 7 Sep 2011 19:43:25 +0200 (CEST)
Message-ID: <>
Date: Wed, 07 Sep 2011 19:43:25 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ravindran Parthasarathi <>
References: <> <> <> <><> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080305010903000801030803"
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: Wed, 07 Sep 2011 17:41:39 -0000

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:
> 1)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?
> 2)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.
> 3)SIP helps to interop for basic call with other existing realtime 
> application in Enterprise & Telecom provider.
> 4)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.