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

[Saúl Ibarra Corretgé <[e-mail]>]

Hi,

On Sep 14, 2011, at 8:23 AM, Avasarala, Ranjit wrote:

> Hi Inaki
> 
> I have few initial comments on your draft
> 
> 1) in Section 3, its mentioned that there is no real benefit of using SIP over Websockets. If this is the case, why are you proposing integrating SIP with Websockets?

That's not exactly what it says. It says that there is no real benefit in using SIP over WbSocket *IF* not using it within a browser. And we are talking browsers here :-)

> 2) Also just integrating SIP for signaling case is really no use, as there are several other ways of achieving signaling in web - E.g. using libjingle of WebRTC, etc

Then if you'd want to interoperate with SIP you'd have to build a gateway, whereas if we already use SIP, no gateway is needed, just a new transport.

> 3) In Section 4, you mentioned that since Websocket is a reliable transport protocol, the websocket sub-protocol defined for SIP also becomes reliable. I don't agree with this - The websocket connection is actually initiated by the web browser client towards the web server and this connection needs to be kept alive through some keep alive mechanism. Otherwise the connection may close. I am not sure of reliability.

Have a look at section 8. Since the WebSocket keepalive is not yet standardized a TCP style (CRLFCRLF) keepalive could be used. I would consider WebSocket reliable, do you see it as UDP?

> 4) In Section 4.1,I am not clear of the Via transport parameter having the value of "WS". Why do you need this when the whole SIP message is going as part of WebSocket payload [Using websocket API]?
> 

The packet may traverse numerous proxies, someone might be interested in knowing it. Its also consistent, since the packet did originate in a WS transport.


Regards,

--
Saúl Ibarra Corretgé
AG Projects