[sr-dev] Websocket module

[Peter Dunkley]

On 7 Aug 2012, at 23:57, Iñaki Baz Castillo <ibc at aliax.net> wrote:

>> 
>> All new WebSocket connections are handled by an
>> event_route[xhttp:request].  This allows any inspection of the headers you
>> want, and you can perform HTTP digest authentication using this
>> event_route.
> 
> Note that, even if RFC 6455 gives the door open to HTTP basic/digest
> authentication, currently no one browser with WebSocket support reacts
> on a 401/407 for the WS GET.
> 
> I strongly know that WWW people does not like authentication
> mechanisms other than those based on HTML forms ;)
> 
Fortunately, even this should be do-able with Kamailio.  Another reason I used event_route[xhttp:request] is that it enables me to differentiate the HTTP requests (so I can do things like handle WebSockets and run XCAP on the same port).  This leaves open the possibility to serve pages/forms (possibly using app_lua do do the heavy lifting) from Kamailio - so HTML form authentication (as unpleasant an idea as it is) should be possible.

> 
>> Once you are happy that the connection should be allowed you
>> call the ws_handle_handshake() function to do some further checks,
>> generate the handshake response, and upgrade the connection in Kamailio
>> core.  So, for example:
>> 
>> event_route[xhttp:request] {
>>        set_reply_close();
>>        set_reply_no_connect();
>> 
>>        if ($Rp != 80 && $Rp != 443) {
>>                xlog("L_WARN", "HTTP request received on $Rp\n");
>>                xhttp_reply("403", "Forbidden", "", "");
>>                exit;
>>        }
>> 
>>        xlog("L_DBG", "HTTP Request Received\n");
>> 
>>        if ($hdr(Upgrade)=~"websocket"
>>                        && $hdr(Connection)=~"Upgrade"
>>                        && $rm=~"GET") {
> 
> But the Sec-WebSocket-Accept header is generated (and added to the 101
> response) by the WS module itself, am I right?
> 
The ws_handle_handshake() performs the header and 101 response generation (as well as handling a number of other protocol issues with the handshake).  The checks in event_route[xhttp:request] are only there to determine if the request should be passed to the WebSocket module for handling (and do things with Origin and cookies) or whether it is an ordinary HTTP request that should be handled outside of that module.

> 
>>                xlog("L_DBG", "WebSocket\n");
>>                xlog("L_DBG", " Host: $hdr(Host)\n");
>>                xlog("L_DBG", " Origin: $hdr(Origin)\n");
>> 
>>                if ($hdr(Host) == $null || !is_myself($hdr(Host))) {
>>                        xlog("L_WARN", "Bad host $hdr(Host)\n");
>>                        xhttp_reply("403", "Forbidden", "", "");
>>                        exit;
>>                }
>> 
>>                # Optional... validate Origin
>>                # Optional... perform HTTP authentication
>> 
>>                # ws_handle_handshake() exits (no further configuration file
>>                # processing of the request) when complete.
>>                ws_handle_handshake();
>>        }
>> 
>>        xhttp_reply("404", "Not found", "", "");
>> }
> 
> 
> It seems a good decision :)
> 
> 
> Thanks a lot for your explanations, and congratulations for your work.
> 
> 
Thanks for the feedback.  The one thing that I would like to do now is get Outbound into Kamilio so that I don't need the aliasing.  I am trying to get my head around what is missing, but what needs to be done to support this is a little unclear to me at the moment.

Also, I don't think sipml5 (which I've been using for testing) supports outbound at the moment.

However, I would much prefer to be using Outbound for both WebSockets and TCP from behind NAT where I can.


> -- 
> Iñaki Baz Castillo
> <ibc at aliax.net>
> 
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev