Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport - Christer's Review

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Mar 2012 14:06:40 +0100

Hi,

Below are my comments on the SIP WebSocket (WS) transport draft. My comments are mainly related to the mandated SIP extensions and the relaxed 3261 procedures.

I also include some editorial comments, eventhough I realize those are probably not the main focus of this specific review.

(Some of the comments I already gave on an earlie version of the draft.)

Also, eventhough I have some issues,  I want to clarify that I in general DO support adopting this work :)

GENRAL:
-----------

Q_GEN_1:	I think it would be good to explicitly indicate that the draft only deals with SIP signaling, and that media transport is outside the scope of the document, and is expected to be transported using already standardized mechanisms (or, mechanisms standardized elsewhere).

Section 1:
------------

Q_1-1:		Add an RFC 6455 reference to "WebSocket Sub-Protocol".

Section 4:
------------

Q_4-1:		I would suggest to add two sub-sections, one which contains the general description of the sub-protocol, and one which contains the procedures.

Section 5.3:
--------------

Q_5_3-1:	What does the following text mean?

	"This requires the server transport to maintain an association 
	between server transactions and transport connections."

Q_5_3-2:	The text says:

	"The SIP server transport uses the value of the top Via header field
   	in order to determine where to send a response.  If the "sent-
   	protocol" is "WS" or "WSS" the response MUST be sent using the
  	existing WebSocket connection to the source of the original request,"

	I would suggest to simply say that SIP responses MUST be sent using the same WebSocket connection on which the associated request was received.

Q_5_3-3:	The text says:

	"If that connection is no longer open, the server MUST
   	NOT attempt to open a WebSocket connection to the Via "sent-
   	by"/"received"/"rport". "

	I would suggest to simply say that the server MUST NOT attempt to re-open a WebSocket connection.

Section 6:
------------

Q_6-1:	Regarding the MUST implement Outbound.

The text says:

	"Therefore clients and servers implementing SIP over the WebSocket
  	 transport MUST implement the Outbound mechanism [RFC5626], being this
  	 the most suitable solution for SIP clients behind Network Address
   	Translation (NAT) using reliable transports for contacting SIP
   	servers."

Therefore why? Because they may not know the WS address they MUST implement Outbound?

I also don't understand the part saying that "Outbound is the most suitable solution for contacting SIP servers".

Also, unless you intend to explicitly forbid it, I guess a WS connection could be established between two SIP proxies. And, as they don't register, they can't use Outbound.

Q_6-3:	Why is there a SHOULD to implement GRUU? If you want that, you need some justification, and say how it is specific to the WS transport.

Q_6-4:	As SIP registrars are outside the scope of this specification, so I don't think we can tell them to implement GRUU.

Section 8.1:
--------------

Q_8_1-1:	If the client application wants to become reachable again, I guess it MUST (the text says SHOULD) create a new WS connection, unless it has created additional WS connections using Outbound.

Section 10:
-------------

Q_10-1: 	In section 8.1 you say that a client SHOULD re-establish the WS connection if it goes down, but in section 10 you say that the decision whether to maintain the WS connection is outside the scope of the document.

Q_10-2:	The text says "a SIP server implementing the WebSocket transport MUST support the CRLF Keep-Alive Technique.". In that case I guess it SHOULD/MUST also support the negotiation mechanism, as described in RFC 6223 (eventhough CRLF keep-alives can be sent without explicit support indication from the receiving server).

Section 13.3:
---------------

Q_13_3-1:	Do we really want to relax the 3261 procedures regarding "received"? In my opinion topology hiding can be done as an implementation thing - we don't need to specify it.

Q_13_3-2:	I don't understand the text regarding not honoring the "rport" parameter. I guess you mean to say that the port number is not added. But, again, I am not sure we should specify such things.

Q_13_3-3:	If you are updating RFC 3261, by relaxing the usage of received etc, I think there should be a "Updates to RFC 3261" section name.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 13 Mar 2012 17:01:06 +0100

2012/3/13 Christer Holmberg <[email-masked]>:
> Hi,
>
> Below are my comments on the SIP WebSocket (WS) transport draft.

Hi Christer, we are addressing the issues you have mentioned and will
reply your mail soon.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 22:03:04 +0100

> Also, eventhough I have some issues,  I want to clarify that I in general DO support adopting this work :)

Thanks a lot for your review Christer, we appreciate it.

> GENERAL:

Makes sense, we'll include a note clarifying this.

> Section 1:

Sure, it will be added.

> Section 4:

Good idea, it will be included in the next revision.

> Section 5.3:

All the above are adaptations from RFC3261-Section18.2.2 in order to
meet the requirements imposed by the websocket nature. We'll follow-up
on this in a separate thread along with some discussion on outbound
applicability and keepalive mechanisms.

> Section 6:

Since WS servers can only perform "passive opens", ie; only a WS
client can actively initiate a WS connection, servers shall reuse
client-initiated connections to transmit SIP messages. Please see
separate thread on outbound applicability.

> Also, unless you intend to explicitly forbid it, I guess a WS connection could be established between two SIP proxies. And, as they don't register, they can't use Outbound.

Please see the separate thread on outbound applicability.

> Q_6-3:  Why is there a SHOULD to implement GRUU? If you want that, you need some justification, and say how it is specific to the WS transport.

Assuming that a SIP WS client cannot listen for incoming WS
connection, the only way it can receive incoming requests is on top of
the WS connection it has previously opened. If Alice (SIP WS client)
is in a call with Bob (SIP UDP/TCP client) and Bob sends a REFER to
Carol (SIP UDP/TCP client) whose "Refer-To" header contains the
Contact of Alice, Carol could only reach Alice if the given Refer-To
URI is a GRUU URI (so the INVITE from Carol would reach Alice's
registrar and would use the Outbound connection of Alice to arrive to
her).

Please see the separate thread on outbound applicability.

> Section 8.1:

Ok.

> Section 10:

OK, the exact text says "The decision for a WebSocket endpoint to
maintain, or not, the connection over time is out of scope of this
document".
With this we wanted to describe that the WS client MAY use of the
Ping/Pong keepalive mechanism defined for the WebSocket protocol
(which of course works at WebSocket level). This is a MAY since it's
expected that some WS implementations (i.e. web browsers) decide by
themself whether to use WS Ping/Pong or not.

This is not negotiable at WebSocket protocol level. Any peer (client
and/or server) can decide to send WS Ping frames so the remote peer
must reply with WS Pong frame. Also the application level could be not
aware of it. For example a JavaScript application is not aware of the
WebSocket Ping/Pong usage by the browser or by the server. It's like a
TCP keepalive (a TCP packet with no application data, so it does not
reach the application level).

This will be also discussed in the separate thread.

> Q_10-2: The text says "a SIP server implementing the WebSocket transport MUST support the CRLF Keep-Alive Technique.". In that case I guess it SHOULD/MUST also support the negotiation mechanism, as…

Good point.

> Section 13.3:

Yes, maybe it is much better just to remove such a section and let it
up to the implementor.

> Q_13_3-3:       If you are updating RFC 3261, by relaxing the usage of received etc, I think there should be a "Updates to RFC 3261" section name.

Sure, it's clear that we need to properly comment those aspects in a
well defined "Updates to RFC 3261" section.

Thanks again for your comments. We'll include them in the next
revision of the draft.

-- 
Iñaki Baz Castillo
<[email-masked]>