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

"Olle E. Johansson" <> Thu, 08 September 2011 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6B3021F8B08 for <>; Thu, 8 Sep 2011 02:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.381
X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JFRZNeNnmyd4 for <>; Thu, 8 Sep 2011 02:43:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF33221F8AF7 for <>; Thu, 8 Sep 2011 02:43:38 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPA id D5EF9754BCE4; Thu, 8 Sep 2011 09:45:27 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: "Olle E. Johansson" <>
In-Reply-To: <>
Date: Thu, 8 Sep 2011 11:45:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <><> <> <> <> <> <> <> <>
To: Tim Panton <>
X-Mailer: Apple Mail (2.1244.3)
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 09:43:39 -0000

8 sep 2011 kl. 11:38 skrev Tim Panton:

> On 7 Sep 2011, at 18:29, Ravindran Parthasarathi wrote:
>> Matthew,
>> When I asked for SIP, I have meant RFC 3261 only. 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.
> You'd be astonished what you can implement in javascript, just because it isn't baked into the browser,
> it doesn't mean the protocol will be dumb. Take a look at how does XMPP for a proof by example.
>> 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.
> Be very careful what you wish for. You really don't want the users of a virtual video phone in Habbo Hotel to be able to accidentally call an adult Chatroulette service just by typing the right SIP address. Web services represent 
> communities with rules, any interop between those services needs to be centrally authorised.
..or not authorised. Regardless, the decision about that is not in scope for rtcweb in my opinion.

>> 3)      SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.
> It really doesn't . I'd guess a very small % of SIP endpoints are directly exposed to the internet, almost all are behind some sort of SBC, adding a permissioning and auth filter layer.
We can discuss for along time why SIP isn't used on the open Internet - but that's just a good example on why we need to follow Skype and secure all media streams. Hopefully we can build an open federation of SIP services somewhere down the road, like the existing open XMPP federation. That's in my opinion also out of scope of rtcweb.

>> 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.
> The classic VoIP use-case is only a small (and diminishing) part of the ways that rtcweb will be used. 
> Rtcweb will typically provide additional features to a community, not be the focus itself. Look at audio in second-life
> as an example, it adds to the experience, but SL existed and works without it. (And that's salient, SL is still one of
> the biggest providers of wideband calls!)
>> 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.
> Sites who's users wish to interop will do so via XMPP, SIP or SS7 or IMS or whatever is appropriate.
> (A small GSM cell operator providing a portal app might choose to interop at the SS7 level to gain billing etc)
> Sites that don't wish to interop won't and it should not be forced on them. I don't want my bank calling my second life avatar.

Hmm. Do you have a trust problem with the bank or the avatar? ;-)

Agree that we need to keep rtcweb focused on the media handling and let the application developers decide on signalling model. Personally, I need it to interface with SIP and XMPP platforms so selecting either one for inclusion in rtcweb would mean that I have to add gateways, which is never a good solution.  Let's try to keep signalling out of scope for the rtcweb project.