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

["Olle E. Johansson" <[e-mail]>]

6 sep 2011 kl. 21:24 skrev Asveren, Tolga:

> 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.
> 
Well, I tried to stay neutral but examples likes this makes me not want SIP in the browser. DTMF, Early Media, bridge line apperances and other PSTN legacy will make the implementation too focused on classical telephony and we'll spend too much time implementing features that are application specific and we can implement in controlling applications, client or server-side. 

Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but it will be hard to protect that from the myriad of extensions that add PSTN functionality that's not really needed to set up multimedia calls between two browser users. It may be needed for gatewaying to legacy systems, but if we don't "stop Olle in the gate" - verbatim translation of a Swedish saying that propably doesn't mean much to most people on the list - I think we will never be done.

Of course, being a SIP developer, I started off with thinking that SIP in the browser was the default route. I am beginning to understand that the browser is the user interface part we all need, the media handler. We all have different requirements on how to control that media GUI and to get anywhere I am beginning to think the logic for signalling to set up rendevouz points and manage sessions has to move "somewhere else" where we can implement SIP, XMPP or some other protocol that fulfills the need of our respective application.

To fearlessly  jump into another can of worms, I still think we should have confidentiality - SRTP - by default. We know that these applications will run on a myriad of devices on a myriad of networks and it will not work to let users have to decided whether or not they want confidentiality. If Skype did not have confidentiality by default, there would be articles every summer and xmas in the evening taboloids about how easy it is to listen in to your neighbours calls and that would have hurted Skype badly. 

/O


> 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

---
* Olle E Johansson - [e-mail]
* Cell phone [phone], Office [phone], Sweden