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

["Ravindran Parthasarathi" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Igor Faynberg
Sent: Wednesday, August 24, 2011 2:09 AM
To: [e-mail]
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