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

[Harald Alvestrand <[e-mail]>]

On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:
>
> Harald,
>
> For browser as a SIP UA application, browser has to no need to 
> compliant with 269 pages of RFC 3261 as proxy core is irrelevant to 
> it. I also agree with you that browser-to-browser communication, I 
> could not see the strong reason for supporting S/MIME. As part of the 
> RTCWeb architecture & solution, we will able to explore the SIP UA 
> requirement for making browser SIP compliant.
>
So you're advocating for creating a "SIP lite" subset that RTCWEB 
browsers implement.
I think we have been down this road before, and it's not a happy one.
But sure - if you want us to implement some part of SIP, *please start 
stating what part* rather than making wooly statements.

Subsets are Real Hard Work.
>
> Say for example, forking does not make sense in case of browser as SIP 
> UA application, forked response will be rejected with CANCEL in 
> browser without Javascript intervention. The main requirement is to 
> build the right SIP UA framework in browser by which Javascript 
> developer will be able to use to the maximum extent without impacting 
> the basic 2 two party communication in the internet.
>
> As mailed in another thread, RTCWEB client + RTCWeb server makes to 
> feel a modern exchange in web world (Plain Old Telephony System phone 
> with exchange architecture). I think so because POTS phones are dumb 
> which does not know its identity and every event like offhook, onhook 
> has to passed to exchange (webserver) whereas RTCWeb client (browser) 
> has to pass every event to webserver and webserver has whole 
> intelligence to make it work.
>
Don't forget that the RTCWEB client (the browser) contains an open, 
fully programmable application platform - the Javascript engine. That's 
a HUGE difference to the POTS phone.
>
> I got this feel more when someone is talking about MEGACO or MGCP 
> between RTCWEB client & webserver. My understanding is that SIP does 
> not fit well to legacy telephone-based paradigm by any means but 
> MEGACO or MGCP are the better choice which maps to SS7 architecture 
> well. I'm interested in seeing RTCWeb client perform the basic routing 
> rather than webserver does the routing on behalf of RTCWEb client.
>
> I agree with you that in case it is local exchange (same site like 
> skype or Google hangout) communication, there will be no need of 
> signaling but I'm interested in communication with one of the Google 
> real-time user in internet without having any Google id.  I believe 
> that SIP will make it work.
>
If by saying "the Google real time user in Internet", you mean a Google 
Talk user, you have that already. It's called Google Voice. It uses SIP, 
but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we 
don't intend to support.
>
> Thanks
>
> Partha
>
> *From:*Harald Alvestrand [mailto:[e-mail]]
> *Sent:* Wednesday, September 07, 2011 11:13 PM
> *To:* Ravindran Parthasarathi
> *Cc:* Matthew Kaufman; [e-mail]; [e-mail]
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: 
> Remote recording - RTC-Web client acting as SIPREC session recording 
> client]
>
> On 09/07/11 19:29, Ravindran Parthasarathi wrote:
>
> Matthew,
>
> When I asked for SIP, I have meant RFC 3261 only.
>
> This is 269 pages, and has 26 normative dependencies including S/MIME. 
> It's not a small dependency.
>
>
>
> 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:
>
> SIP makes browser more intelligence compare to dump signaling 
> mechanism like MEGACO and browser acts as MG.
>
> Why does that "intelligence" need to be in the browser, rather than in 
> the Javascript?
>
> 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.
>
> This only makes sense for applications that fit the "call an 
> identified party" paradigm.
>
> SIP helps to interop for basic call with other existing realtime 
> application in Enterprise & Telecom provider.
>
> 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.
>
> One protocol can be achieved by multiple applications choosing to 
> implement one protocol.
> It doesn't have to be enforced by the prtoocol being embedded in the 
> browser.
>
> 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.
>
>
> I think the main thing you are missing is that there are many 
> applications that people want to build on top of RTCWEB that are not 
> telephones, and will not fit with telephone-based paradigms.
>