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

[<[e-mail]>]

[e-mail]<mailto:[e-mail]> wrote:
> BTW, is there any WebSocket capable web browser for smartphones?

I don't know as of today. But IE, Firefox and Chrome are all making their way to smartphones, and they have all some version of the websocket draft implemented at least in some experimental form. And everyone else is talking about "HTML5" support too. So I belive websockets will be there at least sooner than we will have RTP or STUN. So we will be able to setup the virtual calls but not transport the media :)

RTP and STUN (and SIP, for that matter) implementations are as such available on various smartphone OS's, they just need to be integrated within the browser.

Then there are several practical aspects, like the UI, the fact that the phone may all of a sudden switch between Wi-Fi and the cellular connectivity, the other fact that too frequent keepalives will kill the battery, not all codecs are available and can't be that easily just installed (especially video encoding would benefit from "HW acceleration"), that if you actually browse (or do some other TCP stuff) at the same time as you use VoIP/RTP, bufferbloat will kick in and the call will be garbage for a few seconds - regardless of if the TCP initial window is 3 or 10, and so on. Perhaps worth writing a short draft in the near future.

Markus


From: ext José Luis Millán [mailto:[e-mail]]
Sent: 13 September, 2011 23:16
To: [e-mail]; Isomaki Markus (Nokia-CIC/Espoo)
Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP)

On Tue, Sep 13, 2011 at 9:25 PM,  <[e-mail]<mailto:[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]> [mailto:[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]<mailto:[e-mail]>
>>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport
>>for Session Initiation Protocol (SIP)
>>
>>2011/9/13 Ravindran Parthasarathi <[e-mail]<mailto:[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]<mailto:[e-mail]>>
>>_______________________________________________
>>rtcweb mailing list
>>[e-mail]<mailto:[e-mail]>
>>https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtcweb
>