Re: [sipcore] Proposal for a new SIP transport (WebSocket)

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

2011/11/3 Paul Kyzivat <[e-mail]>:
>> However I don't think that omitting the ;received stuff in the SIP
>> WebSocket server is something critical. As said before, ;received is
>> useless in SIP over WebSocket: it's a connection oriented protocol so
>> responses are sent using the same connection, and in case such
>> connection is closed responses cannot be sent to the WS client since
>> the WS client does not liste for incoming connections. The same occurs
>> with SIP TCP natted clients, but in this last case revealing the
>> ;received IP is not a risk.
>
> IMO this isn't something that it makes sense to deal with piecemeal.
> If a case can be made that this sort of privacy is important enough to
> introduce architectural changes in protocols, then we should be talking
> about that in general.

Hi Paul. I see a bit difference here:

In SIP we all assume that an element in the path of a SIP
communication is a IP layer box (a router) or a SIP box (a SIP
proxy/B2BUA/SBC). Let's forget NAT routers for now.

But in HTTP world is very common to have TCP/HTTP load balancers in
the path (while in SIP we use SIP proxies for balancing). Those
elements alter the received IP:port in the HTTP server but nobody
cares since such information is never told to the HTTP client. This is
not true in SIP since Via ;received / ;rport are supposed to reveal to
the client the source IP:port from which the server has received the
request.

In the case of WebSocket, the WS connection is made using an HTTP GET
replied with an HTTP 101. And then we have a TCP connection in which
both the WS client and WS server can send data by encapsulating it
over WebSocket frames.

Since we are defining here WebSocket as a transport for SIP, IMHO it
should not matter the TCP/HTTP load balancers in the path. Those are
in a layer below the WebSocket communication. The link I pasted in my
previous mail clearly shows how the received IP:port can be totally
useless for a WebSocket server.


Thanks a lot.


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