Here is a full overview of the way we did this in reSIProcate / repro:
http://www.resiprocate.org/SIP_Over_WebSocket_Cookies
Here is a PHP test script which sets the cookies:
http://svn.resiprocate.org/viewsvn/resiprocate/main/repro/test/web/websocket...
JSCommunicator can set the extension header for passing supplementary data in config.js:
https://github.com/opentelecoms-org/jscommunicator/blob/master/config-sample... (look for extra_headers)
To build a complete solution, you can simply combine the phone.shtml code from JSCommunicator and the PHP test code into a simple script.
Notice we put a version number in the cookie. If the Kamailio implementation of this evolves and adds extra fields, please increment the version number or use different cookie names to distinguish it from the reSIProcate cookie scheme.
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.
Regards,
Peter
On 4 February 2014 06:55, Daniel Pocock daniel@pocock.com.au wrote:
Here is a full overview of the way we did this in reSIProcate / repro:
http://www.resiprocate.org/SIP_Over_WebSocket_Cookies
Here is a PHP test script which sets the cookies:
http://svn.resiprocate.org/viewsvn/resiprocate/main/repro/test/web/websocket...
JSCommunicator can set the extension header for passing supplementary data in config.js:
https://github.com/opentelecoms-org/jscommunicator/blob/master/config-sample... (look for extra_headers)
To build a complete solution, you can simply combine the phone.shtml code from JSCommunicator and the PHP test code into a simple script.
Notice we put a version number in the cookie. If the Kamailio implementation of this evolves and adds extra fields, please increment the version number or use different cookie names to distinguish it from the reSIProcate cookie scheme.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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?
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?
-
Daniel Pocock -
Peter Dunkley