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

[Iñaki Baz Castillo <[e-mail]>]

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]>