Hello,

On Kamailio you handle the WebSocket handshake as just another HTTP request (in an event_route).

You do any processing and checking of headers you want in that event_route before calling ws_handle_handshake(). That includes using URI parameters (often more useful than Cookies: for authentication), checking Cookie: contents, checking the Host: and Origin: headers, etc.

You can use the auth_ephemeral module at this point or, (if you have a WebSocket client capable of handling a request for HTTP digest authentication) HTTP digest authentication. You can also use sqlops (and other similar modules) at this point too.

ws_handle_handshake() validates the WebSocket specific headers and generates the 101 response if everything is OK from a protocol point-of-view.

Regards,

Peter

On 4 February 2014 14:37, Daniel Pocock <daniel@pocock.com.au> wrote:

On 04/02/14 10:26, Peter Dunkley wrote:

Hello,

I don't think this is relevant to the Kamailio implementation.

The Kamailio implementation doesn't do anything with headers like Cookie: at all. If an implementer of a Kamailio solution wants to do anything with the Cookie: header (or any other), they can do whatever they want using the Kamailio configuration file "programming language".

You can make use of all of the standard Kamailio header/parameter selects and transformations to help you do whatever you want with these headers.

Just to clarify: we are talking about HTTP Cookie headers sent during the WebSocket handshake, not about a Cookie header in any SIP message

Does the Kamailio WebSocket transport provide access to the HTTP WebSocket handshake headers and their contents or only the SIP headers?

Is there a way to invoke some route block in the configuration file to examine the HTTP headers and decide whether a WebSocket connection will be accepted?

Peter Dunkley

Technical Director

Crocodile RCS Ltd