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

Matthew Kaufman <> Wed, 07 September 2011 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86D8721F8BAC for <>; Wed, 7 Sep 2011 15:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.544
X-Spam-Status: No, score=-5.544 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IR8RCUz2vAqs for <>; Wed, 7 Sep 2011 15:21:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0233821F8B4F for <>; Wed, 7 Sep 2011 15:21:32 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id C94C47FD; Thu, 8 Sep 2011 00:23:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=mx; bh=30JvQbc4OQdm3UMdWM9YauMOEeg=; b=qC/10HZXL vTMcgr82Sb8+Zc7VE5RDr6NvCtOtecozJofPOECcS3kkjBnz5yVxHMjp75ECYJNW ZHxc2KSZDpWQ9PpXVi1w6EZ2p1lKlXK8fLnGw0iaGQeD9nu0GcIn678pO9yNRKl0 7pviqjh2IEVJ3nsuXbPpzmzUGqi43VR6qU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; q=dns; s=mx; b=cQHETtxM6Dtalnt6Xt0Rn2GjwmvjOAbnoTFZ6POp7LDPDw7g rTs1ACfQrGN1QJedMnLt1t+VrDjDq3OLu385d3qOWop7pxQOY0pxQKDK0ESYLEYw 9FZgrfbRQc7PJXsVddEYapJ008p1G6owA8Hn46PZsEForxJj3SuXH+hpdyc=
Received: from ( []) by (Postfix) with ESMTP id C706C7F6; Thu, 8 Sep 2011 00:23:21 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91E7335081E5; Thu, 8 Sep 2011 00:23:21 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g1gmbbdxlcPi; Thu, 8 Sep 2011 00:23:17 +0200 (CEST)
Received: from Matthew-Kaufman-Air.local ( []) by (Postfix) with ESMTPSA id A627935081CC; Thu, 8 Sep 2011 00:23:16 +0200 (CEST)
Message-ID: <>
Date: Wed, 07 Sep 2011 15:23:14 -0700
From: Matthew Kaufman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Ravindran Parthasarathi <>
References: <> <> <> <><> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050600040003040407050503"
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 22:21:35 -0000

On 9/7/11 10:29 AM, Ravindran Parthasarathi wrote:
> Matthew,
> When I asked for SIP, I have meant RFC 3261 only.

As I pointed out earlier, this is the top of a very slippery slope.

Certainly you must have meant 3261 + early media + PRACK (for instance), 

> The basic reason for asking SIP is to make the basic call works 
> between browser to browser across web servers.

SIP is in no way required to make this happen.

> Without SIP in browser, it is not going happen.

Totally disagree.
> Innovative application is going to be proprietary whether it is HTTP 
> or SIP or any other protocol for that matter.

True. But having to reverse-engineer out the phone part is really 
painful for the application developer who is trying to build something else.

> My reasoning are as follows:
> 1)SIP makes browser more intelligence compare to dump signaling 
> mechanism like MEGACO and browser acts as MG.

SIP in the browser makes the browser less *flexible* than an API with 
more direct control over the internal objects (camera, codec, network 
connection) and yet no more intelligent, as the browser has a runtime 
that can be programmed to do anything you want at the client side.

> 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 isn't going to happen, and is even closer to my fears about "IMAP 
in the browser" expressed earlier.

> 3)SIP helps to interop for basic call with other existing realtime 
> application in Enterprise & Telecom provider.

So what? I hope people understand that RTCWEB could be about so much 
more than enterprise and telecom providers doing two-party phone calls.

Among other things, you can build augmented reality systems out of it 
(see how Flash streaming has been used similarly), multi-party 
experiences that aren't calls (Google hangouts), and many other 
applications we haven't even thought of yet... as long as we don't 
cripple the APIs.
> 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.

It doesn't even work over that "one signaling protocol", so that doesn't 
help. And again, there is no reason that a web site providing RTC 
applications to/from a browser need necessarily be serving "SIP phones" 
as clients as well. Maybe that just isn't the business they're in.
> In RTCWEB does not standardize the signaling protocol interface 
> between browsers, the interop across webservers is next to impossible

Totally disagree. We need to standardize the *media transport* between 
the browsers, and W3C needs to standardize the *API* by which we can 
send Javascript to the browser that executes the same way on every 
browser, but that doesn't mean the signaling protocol needs to be 
specified any more than IETF needed to intervene to ensure that the XML 
or JSON data that goes between your browser and Gmail is the same as the 
data that goes between your browser and Yahoo mail when you're using 
each to compose email messages.

> and it will be restricted to single webserver (company) only.

Disagree. Just like Gmail and Yahoo mail can send messages to each 
other's users over a standard protocol for federation, so can RTCWEB. In 
fact, SIP is probably a great choice for inter-provider trunking. And 
conveniently, we plan to support the same *media transport* that other 
SIP devices use (RTP), so there'll be even more interoperability than 
just browser-to-browser federated between providers.

> Please let  me know in case I'm missing something here.

See above.

Matthew Kaufman