Re: [sr-dev] Websocket module

2012/8/7 Peter Dunkley <peter.dunkley(a)crocodile-rcs.com> 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(a)aliax.net>