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

[Justin Uberti <[e-mail]>]

Notifications can be received over WebSockets, or any of the existing
mechanisms web applications use for server->client notifications.

On Tue, Sep 6, 2011 at 3:46 PM, Igor Faynberg <
[e-mail]> wrote:

> The key question is:  What MUST the browser provide to support a SIP
> implementation in an application? (I asked this question a few thousand
> messages back, but the thread was inconclusive.)
>
> HTTP alone cannot do the job. How will the user agent receive
> notifications, for example?
>
> Igor
>
>
> On 9/6/2011 2:47 PM, Olle E. Johansson wrote:
>
>> 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<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>