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" <[e-mail]>]

7 sep 2011 kl. 19:29 skrev Ravindran Parthasarathi:

> 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.
> 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.
> 3)      SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.
> 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.
>  
> 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.

Ravindran,
I don't follow the logic here. If you have SIP in the browser, the web server will only be involved when loading the web page. SIP will take care of the rest.

In order to explain my current view (which might change): Try to divide a sip phone in two parts. One part handles the multimedia - codecs, encryption, qos (RTCP). The other part handles sessions - setup, teardown, transfers etc. The way I see it (which is my personal view, not this lists) is that rtcweb is the media handler. We can build various controlling applications on client and server side, using the protocol we like - it could be SIP but also a range of other protocols, including proprietary protocols. I do hope that SIP wins here of course. I don't think we should fight another round of session management protocol wars in rtcweb - but that opinion is based on the architecture I described here.

Getting what we need to be able to set up media sessions in a web browser from applications like Asterisk is a great win. We have what we need to handle the session management part :-)

I hope this helps you to understand my view that SIP should not be part of the rtcweb set of standards. It is not about whether SIP can be in the browser or not, it's just about putting some sort of scope limit on this IETF project. SIP can still be implemented - and will propably be - in the browser. At my first SIPit in Stockholm many years ago, I tested with someone who already at that time had a SIP client in the browser.

Cheers,
/O