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

Igor Faynberg <> Wed, 24 August 2011 04:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBAF921F8B02 for <>; Tue, 23 Aug 2011 21:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.607
X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gdh2xrkvsWl4 for <>; Tue, 23 Aug 2011 21:38:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0850821F8AFC for <>; Tue, 23 Aug 2011 21:38:37 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id p7O4dkVZ004565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2011 23:39:46 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id p7O4djXk008321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Aug 2011 23:39:46 -0500
Received: from [] ( []) by (8.13.8/TPES) with ESMTP id p7O4dhks024288; Tue, 23 Aug 2011 23:39:44 -0500 (CDT)
Message-ID: <>
Date: Wed, 24 Aug 2011 00:39:43 -0400
From: Igor Faynberg <>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ravindran Parthasarathi <>
References: <> <> <> <><> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060201090000090906030102"
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
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, 24 Aug 2011 04:38:40 -0000

Actually, I don't think that the "must not" decision has ever been made 
by the WG. In fact, two implementation reports from the last meeting 
cited SIP implementation...

I actually thought that the need for supporting SIP in the browser was 
well articulated in Quebec...


On 8/23/2011 8:57 PM, Ravindran Parthasarathi wrote:
> I agree with Igor.  It will be good in case the discussion in the line 
> why SIP MUST NOT be used for browser. I guess that the following are 
> not the reason for not selecting SIP:
> 1) Memory usage in browser is not the limiting factor for SIP. I know 
> of the SIP application which works well in embedded device with 16MB RAM.
> 2)In case the idea is to use the simple alternative protocol for the 
> basic dialog between browser to browser. It is possible for the same 
> protocol to become as complex as SIP in 5-10 years while adding more 
> feature or services.  We end-up with two protocol for real-time 
> communication from IETF and interact through gateways.
> 3)As per IETF recommendation,  standalone application in endpoint has 
> to use SIP for real-time communication whereas the same application 
> running in browser has to use RTCWeb recommended protocol. It is tough 
> for each application to support both protocols or its related 
> infrastructure to make it work. Or the intention is not to use SIP 
> anywhere in endpoint?
> I'm interested in hearing the reasons for why SIP MUST NOT be used in 
> browser.
> Thanks
> Partha
> *From:* [] *On 
> Behalf Of *Igor Faynberg
> *Sent:* Wednesday, August 24, 2011 2:09 AM
> *To:*
> *Subject:* Re: [rtcweb] Remote recording - RTC-Web client acting as 
> SIPREC session recording client
> On 8/23/2011 1:50 PM, Hutton, Andrew wrote:
> ...
> What I heard a number of times at IETF81 is that what people want is 
> to build innovative new applications with a real time media enabled 
> browser and to it seems clear to me we need a browser API which is 
> flexible and enables applications to do clever things with media 
> streams. So exploring some use cases which require the browser to 
> duplicate and copy media streams is a good idea.
> Indeed the browser API must be flexible and it must enable 
> applications.  Strong ++ on that.
> Inasmuch as we, in the IETF, are not really in control of API, to 
> ensure its flexibility we can only make the right protocol 
> selection.   To this end, the worst thing would be trying to reinvent 
> the wheel.  People have been working on SIPREC for more than a year 
> now--would it be not wise on our part to take the output of that work?
> Overall, even if the browser does not support the full-blown SIP, I 
> think it must support some parts of it (REFER and SUBSCRIBE/NOTIFY, 
> for one thing) in order to enable flexibility.
> A few thousand messages ago, I asked how (asynchronous) notifications 
> could be implemented without having SIP in the browser, and I don't 
> think we had a sufficient discussion.
> Igor