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

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

2011/9/14 Christer Holmberg <[e-mail]>:
> 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]).
-----------------------------------------------------


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

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.


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



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


Thanks a lot for your input.
Best regards.

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