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

[Christer Holmberg <[e-mail]>]

Hi, 

>> I have a comment, related to this.
>>
>> The text says:
>>
>>   "Even more, the WebSocket protocol is not symmetric since
>>   just a WebSocket client can open a connection to a 
>>   WebSocket server (a WebSocket client does not listen for incoming 
>>   connections)."
>>
>> But, this is of course also true when you DO use a browser, 
>> but it's not really addressed in the draft. You need to 
>> describe that it is assumed that the WebSocket connection has 
>> been established at the point when the browser is supposed to 
>> be able to receive incoming SIP calls.
> 
> Hi Christer. IMHO that is already addressed in the draft:
> 
> ----------------------------------------------------
> 6.  WebSocket Client Usage
> 
>    As stated in [I-D.ietf-hybi-thewebsocketprotocol], a WebSocket URI
>    [RFC3986] is given to the WebSocket client (typically within a web-
>    based application) who resolves the URI destination and 
>    establishes a WebSocket connection with the corresponding server (by 
>    performing the handshake and negotiation procedures described in
>    [I-D.ietf-hybi-thewebsocketprotocol]).
> -----------------------------------------------------

Well, that describes HOW the WebSocket is established.

--------

>>For example, the WebSocket could be established once the JS app is 
>>downloaded,
> 
>But that is obvious given the WebSocket protocol nature. The 
>client MUST establish a WebSocket connection with the server 
>before attempting to send or receive WebSocket messages.

Of course. But, as you describe the WebSocket usage for SIP, I think it needs to be stated WHEN that can occur for SIP.

--------

>Could you please point to the exact section in the draft in 
>which you miss such explanation? We'll be very glad to improve it.

I would like something like:

	"When the WebSocket is used to transport SIP traffic, the WebSocket MUST be established at the point where
	the browser SIP application shall be able to place and receive SIP calls. Based on local policy, this might
	e.g. occur once the JavaScript SIP application has been downloaded from the web server, or when the
	SIP user using the browser application registers itself to a SIP registrar (assuming that calls cannot be
	placed or received before that)."

I guess text text could fit either in section 4.x, or in section 6. 

--------

>>or when the JS SIP client registers (similar to how SIP 
>>Outbound works).
> 
>In normal scenarios the client must register in order to 
>receive incoming SIP calls, but that is not a MUST. For 
>example a WebSocket server could route INVITE requests to 
>connected WebSocket clients without previous SIP registration 
>made by the clients. It would be up to the provider local 
>policy. I don't think the draft should mandate SIP 
>registration in order to receive calls (neither RFC 3261 
>mandates it), as registration is just one of the existing 
>ways for receiving incoming calls, but not the unique. Am I wrong?

I was not suggesting that we mandate registration. It was just an example of when one could choose to establish the WebSocket, IF the browser shall be able to receive incoming calls after registration. If it shall be able to receive incoming calls before the registration (or, if there is no registration in the first place), the WebSocket needs to be established at some other point.

--------

>>> The keep-alive mechanism is needed for cases in which 
>>> there is a NAT router in the path. Those routers usually close a TCP connection 
>>> after some minutes of inactivity. This happens in any TCP 
>>> connection from client to server through a NAT box.
>>
>> Since WebSocket provides a keep-alive function, you can of 
>> course use that.
> 
> Current limitation exists in WebSocket API since it does not 
> provide a way for the client to send Ping frames to the 
> server. Please check the open request in the W3C tracker 
> about this topic:
> 
>   http://www.w3.org/Bugs/Public/show_bug.cgi?id=13104#c3
> 
> 
>> I guess it could still be mentioned that a SIP level 
>> mechanism exists.
> 
> I assume you mean the CRLF+CRLF mechanism defined in RFC 5626 
> "Managing Client-Initiated Connections in SIP" which is a 
> technique for SIP clients to keep the connection open by 
> sending CRLF+CRLF and receiving CRLF reply from the proxy/server.
> 
> RFC 5626 says:
> 
> ---------------------------------
> 3.5.1.  CRLF Keep-Alive Technique
> 
>    This approach can only be used with connection-oriented transports
>    such as TCP or SCTP.  The client periodically sends a double-CRLF
>    (the "ping") then waits to receive a single CRLF (the "pong").  If
>    the client does not receive a "pong" within an appropriate 
> amount of
>    time, it considers the flow failed.
> -------------------------------
> 
> 
> Since SIP WebSocket transport (as defined in the draft) is 
> also a reliable transport, we could mention the usage of this 
> keepalive technique in the draft, is it ok?

I think it's better to refer to RFC 6223, which only covers the keep-alive part of RFC 5626.

(RFC 5626 contains also contains other stuff that most likely doesn't apply for the browser case).

--------

Regards,

Christer