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

["Ravindran Parthasarathi" <[e-mail]>]

Matthew,

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

In case one port opening (80) will not create security issue but how
opening two ports (80 & 5060) will cause security issue? Could you
please explain the security reason between port 80 for HTTP and 5060 for
SIP

Please read inline for further comments.

Thanks
Partha

>-----Original Message-----
>From: Olle E. Johansson [mailto:[e-mail]]
>Sent: Wednesday, September 07, 2011 12:17 AM
>To: Matthew Kaufman
>Cc: Ravindran Parthasarathi; [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]
>
>
>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.
[Partha] My understanding is same as olle. Javascript API MUST provide
the mechanism to add proprietary SIP headers or else I agree with you
that solution is useless.

>
>>
>> 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.
[Partha] In case Javascript API supports for adding new headers, there
is no difference right?

>>
>> 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.
[Partha] 
>
>I am not arguing for either side, just correcting some details...
>
>/O