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

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Wed, 24 August 2011 00:56 UTC

Return-Path: <pravindran@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DBB5C21F8564 for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 17:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xvjTIVGY5e1W for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 17:56:52 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8A08121F8556 for <rtcweb@ietf.org>; Tue, 23 Aug 2011 17:56:52 -0700 (PDT)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com []) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7O0wQWr007016; Tue, 23 Aug 2011 20:58:26 -0400
Received: from sonusinmail02.sonusnet.com ([]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 20:57:40 -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_01CC61F8.D11DA778"
Date: Wed, 24 Aug 2011 06:27:36 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com>
In-Reply-To: <4E540FE2.7020605@alcatel-lucent.com>
Thread-Topic: SIP MUST NOT be used in browser?[was RE: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client]
Thread-Index: Acxh1LWUFpa7XMlsS2mtpG9K96WB+QAH+HxA
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: <igor.faynberg@alcatel-lucent.com>, <rtcweb@ietf.org>
X-OriginalArrivalTime: 24 Aug 2011 00:57:40.0358 (UTC) FILETIME=[D2D0BA60:01CC61F8]
Subject: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 00:56:55 -0000

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

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





From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
Of Igor Faynberg
Sent: Wednesday, August 24, 2011 2:09 AM
To: rtcweb@ietf.org
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.