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

[Paul Kyzivat <[e-mail]>]

The bridged line appearance case is an interesting one. It is definitely 
a feature that sip has trouble with.

There are proprietary solutions for shared line appearance that use sip 
for call set up, along with other protocols. (Or at least *can* use sip, 
even if they usually use something else proprietary.) But they are 
proprietary, so that you have to buy the whole solution from one vendor, 
generally including all the phones.

IIUC, with RTCWEB as Matthew is proposing it, you would be able to use 
anybody's phone that had a browser and supported RTCWEB. The limitation 
is that then all of the phones that want to be part of the shared line 
appearance group will need to share a server. IOW, you will need an 
RTCWEB capable web server representing the AOR.

That could be a big hurdle for retrofitting existing sip-based phone 
systems, though perhaps an attractive approach for up and coming 
competitors to those existing systems.

	Thanks,
	Paul

On 9/6/11 3:24 PM, Asveren, Tolga wrote:
> What about semantics (adding just a X-header won't help there) or how much SIP would be left anyhow if all semantical control is exposed through the API?
>
> I think bridged line appearance is a good test to run against different models.
>
> Thanks,
> Tolga
>
>
> -----Original Message-----
> From: [e-mail] on behalf of Olle E. Johansson
> Sent: Tue 9/6/2011 2:47 PM
> To: Matthew Kaufman
> Cc: [e-mail]
> Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as	SIPREC	session recordingclient]
>
>
> 6 sep 2011 kl. 20:40 skrev Matthew Kaufman:
>
>> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote:
>>> Matthew,
>>>
>>> Even in case of SIP, there is no need of standardization in case it is within single webserver(skype). SIP supports x-header or proprietary header to extend the way you want it for providing innovative functionality.
>>
>> Not if SIP is baked in to the browser it doesn't. If the browser implements a SIP phone in native code, I have no way of adding "x-header" or anything else. I live with the functionality provided by the browser.
> That's an implementation detail. One can easily add an API call to add headers on the outbound INVITE.
>
>>
>> If on the other hand, you want SIP implemented in Javascript then sure, if a developer wants to use it, great. If they want to extend it, that's fine too. And if they'd rather use another model, they are free to do that. Just as you would expect from a *platform*.
>>
>>> There is no extension barrier from SIP perspective but it ensure that basic call works across web servers. For example, skype browser user will able to talk to gmail real-time user even though all skype functionality are not supported.
>> See above.
>>>
>>>   In case you have the points why HTTP allows innovation but SIP will not, let us discuss in detail.
>>
>> See above. I want you to be free to use SIP, but not *required* to use SIP.
>>
>> And there's some security reasons that I'd rather you tunnel it over HTTP rather than opening up your ability to send UDP packets to port 5060.
> SIP runs on TCP and TLS ports too.
>
> I am not arguing for either side, just correcting some details...
>
> /O
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>