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

[Matthew Kaufman <[e-mail]>]

On 9/7/11 10:29 AM, Ravindran Parthasarathi wrote:
>
> Matthew,
>
> When I asked for SIP, I have meant RFC 3261 only.
>

As I pointed out earlier, this is the top of a very slippery slope.

Certainly you must have meant 3261 + early media + PRACK (for instance), 
yes?

> The basic reason for asking SIP is to make the basic call works 
> between browser to browser across web servers.
>

SIP is in no way required to make this happen.

> Without SIP in browser, it is not going happen.
>

Totally disagree.
>
> Innovative application is going to be proprietary whether it is HTTP 
> or SIP or any other protocol for that matter.
>

True. But having to reverse-engineer out the phone part is really 
painful for the application developer who is trying to build something else.

> My reasoning are as follows:
>
> 1)SIP makes browser more intelligence compare to dump signaling 
> mechanism like MEGACO and browser acts as MG.
>

SIP in the browser makes the browser less *flexible* than an API with 
more direct control over the internal objects (camera, codec, network 
connection) and yet no more intelligent, as the browser has a runtime 
that can be programmed to do anything you want at the client side.

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

This isn't going to happen, and is even closer to my fears about "IMAP 
in the browser" expressed earlier.

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

So what? I hope people understand that RTCWEB could be about so much 
more than enterprise and telecom providers doing two-party phone calls.

Among other things, you can build augmented reality systems out of it 
(see how Flash streaming has been used similarly), multi-party 
experiences that aren't calls (Google hangouts), and many other 
applications we haven't even thought of yet... as long as we don't 
cripple the APIs.
>
> 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.
>

It doesn't even work over that "one signaling protocol", so that doesn't 
help. And again, there is no reason that a web site providing RTC 
applications to/from a browser need necessarily be serving "SIP phones" 
as clients as well. Maybe that just isn't the business they're in.
>
> In RTCWEB does not standardize the signaling protocol interface 
> between browsers, the interop across webservers is next to impossible
>

Totally disagree. We need to standardize the *media transport* between 
the browsers, and W3C needs to standardize the *API* by which we can 
send Javascript to the browser that executes the same way on every 
browser, but that doesn't mean the signaling protocol needs to be 
specified any more than IETF needed to intervene to ensure that the XML 
or JSON data that goes between your browser and Gmail is the same as the 
data that goes between your browser and Yahoo mail when you're using 
each to compose email messages.

> and it will be restricted to single webserver (company) only.
>

Disagree. Just like Gmail and Yahoo mail can send messages to each 
other's users over a standard protocol for federation, so can RTCWEB. In 
fact, SIP is probably a great choice for inter-provider trunking. And 
conveniently, we plan to support the same *media transport* that other 
SIP devices use (RTP), so there'll be even more interoperability than 
just browser-to-browser federated between providers.

> Please let  me know in case I'm missing something here.
>

See above.

Matthew Kaufman