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

[Tim Panton <[e-mail]>]

On 7 Sep 2011, at 18:29, Ravindran Parthasarathi wrote:

> 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.

You'd be astonished what you can implement in javascript, just because it isn't baked into the browser,
it doesn't mean the protocol will be dumb. Take a look at how phono.com does XMPP for a proof by example.

> 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.

Be very careful what you wish for. You really don't want the users of a virtual video phone in Habbo Hotel to be able to accidentally call an adult Chatroulette service just by typing the right SIP address. Web services represent 
communities with rules, any interop between those services needs to be centrally authorised.


> 3)      SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.

It really doesn't . I'd guess a very small % of SIP endpoints are directly exposed to the internet, almost all are behind some sort of SBC, adding a permissioning and auth filter layer.

> 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.

The classic VoIP use-case is only a small (and diminishing) part of the ways that rtcweb will be used. 
Rtcweb will typically provide additional features to a community, not be the focus itself. Look at audio in second-life
as an example, it adds to the experience, but SL existed and works without it. (And that's salient, SL is still one of
the biggest providers of wideband calls!)

>  
> 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.

Sites who's users wish to interop will do so via XMPP, SIP or SS7 or IMS or whatever is appropriate.
(A small GSM cell operator providing a portal app might choose to interop at the SS7 level to gain billing etc)

Sites that don't wish to interop won't and it should not be forced on them. I don't want my bank calling my second life avatar.

Tim.
>  
> Thanks
> Partha
> _______________________________________________
>  
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb