[rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)

[José Luis Millán <[e-mail]>]

On Tue, Sep 13, 2011 at 9:25 PM,  <[e-mail]> wrote:
> Hi Inaki,
>
> Fully agree about everything you say below.

Hi,

Sorry if this mail arrives out of the original mail thread.

>
> It would be interesting to understand the performance differences of the
native vs. Javascript SIP stack, if there is anything we should be worried
about. This is my only concern when (perhaps one day) applying RTCWeb in
devices like smartphones. If the JS stack works in (any of) today's high end
smartphones without problems, we should be fine.

The are no meaningful performance penalties at all using the JavaScript SIP
stack in our prototype. In fact, multiple SIP stack instances can run in a
single Web browser freshly.  BTW, is there any WebSocket capable web browser
for smartphones?

>
> Markus
>
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>Of ext Iñaki Baz Castillo
>>Sent: 13 September, 2011 21:23
>>To: Ravindran Parthasarathi
>>Cc: [e-mail]
>>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket
Transport
>>for Session Initiation Protocol (SIP)
>>
>>2011/9/13 Ravindran Parthasarathi <[e-mail]>:
>>> Hi Inaki,
>>>
>>> I like the idea of using SIP between browser & server.
>>>
>>> I really don't know the strong reason for tunneling SIP message within
>>websocket. In fact, we are discussing SIP vs websocket in
>>http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail
>>thread as signaling protocol for RTCweb. Could you please mention the
>>technical advantage in going in the path of SIP over websocket rather than
>>having plain SIP connection over TCP or TLS or (UDP or DTLS).
>>
>>Hi Ravindran,
>>
>>SIP is a complex protocol and there are numerous extensions and features
in
>>many RFC's extending the SIP protocol. Having to rely on the features
>>implemented in a native SIP stack within the web-browser seems not enough
>>flexible IMHO. I also expect many limitations and lack-of-features in the
>>different SIP implementations of each browser (and each version of the
>>browser).
>>
>>In the other side, if the SIP stack is coded within a JavaScript library
and makes
>>usage of the WebSocket protocol, innovation depends on the developer and
>>not on the browser native capabilities. A web page could offer a minimal
SIP
>>stack just implementing basic outgoing calls (i.e. "Click2Call" buttons in
the
>>web), while another web page could prefer to provide a powerful SIP stack
>>implementing blink/attended transfer, subscription to presence and
>>dialogs/calls, conference features, call-pickup, SIP messaging and so on
>>(imagine such phone integrated within an enterprise intranet). I don't
expect
>>that the SIP stack integrated within *every* existing web-browsers would
>>implement all those SIP features in a correct way (because that does not
>>happen neither when using expensive SIP desktop phones or softphones).
>>
>>Also, the specification defined in the draft solves NAT issues (at
signaling
>>level) without requiring server side solutions for fixing NAT in clients.
>>
>>WebSocket protocol is becoming a new "transport" protocol.
>>Implementing SIP protocol on top of it can only bring advantages and new
>>possibilities. The specification in the draft is an adaptation of SIP to
make use
>>of WebSocket, as it already does with UDP, TCP and SCTP transports.
>>
>>
>>BTW, as said in the first mail, we have published the draft after having a
>>working prototype making usage of the specification described in the
>>document. After that, we see no real advantage on having a native SIP
stack
>>within a web browser. The prototype will be shown soon.
>>
>>Best regards.
>>
>>--
>>Iñaki Baz Castillo
>><[e-mail]>
>>_______________________________________________
>>rtcweb mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>