[sr-dev] Websocket module

[Iñaki Baz Castillo]

2012/8/7 Peter Dunkley <peter.dunkley at crocodile-rcs.com>

> You don't need to use OverSIP to use the WebSocket module in Kamailio.
> The Kamailio implementation will allow you connect one or more WebSocket
> clients directly to Kamailio and make calls between them.  It can also be
> used to convert calls from the WebSocket transport to SCTP/TCP/UDP for
> routing to other proxies.


Hi Peter, I wonder if Kamailio's WebSocket implementation provides the
folllowing callbacks and features:

1) A callback (i.e. a script "route[X]" in kamailio.cfg) that is called
when a new WebSocket connection is requested by a client, by providing
access to the HTTP GET request (so the admin, based on local policy can
inspect the HTTP request and allow/dissalow the connection after checking
the Cookie header, the Origin header, the Host header or whatever).

2) A mechanism to associate custom attributes for each WebSocket connection
(i.e. an authorized user identifier, which has been authorized by means of
the previous HTTP GET request inspection in step 1).

3) A mechanism to retrieve, in the kamailio.cfg script, the attributes of
the WebSocket connection from which a SIP request arrives to Kamailio (i.e.
useful to enforce that the From URI matches the connection user identifier
retrieved in any custom way in step 1).

4) A mechanism to close an existing WebSocket connection from the
kamailio.cfg script (i.e: during the WebSocket handshake we decided,
somehow, that the user identifier is "alice", but at some point we receive
an INVITE from that WS connection with From user "bob", so it could be an
attacker and we want to close the connection).

5) A callback that is called when a previously accepted WebSocket
connection is closed (by passing as argument the terminator of the
connection: the client or kamailio.cfg).


Said that, WWW people WON'T like the idea of providing a SIP username and
SIP password in the JavaScript code retrieved by the user when visiting the
web page, and for sure most of WWW people will prefer to
validate/authenticate/authorize the WebSocket connections by inspecting the
HTTP GET request (Origin, Cookie, some custom API_KEY in the request-URI of
the GET method or whatever).


Cheers.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120807/2dc8b33c/attachment.htm>