4 Feb
2014
4 Feb
'14
8:55 a.m.
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/websocke…
JSCommunicator can set the extension header for passing supplementary
data in config.js:
https://github.com/opentelecoms-org/jscommunicator/blob/master/config-sampl…
(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.
4 Feb
4 Feb
11:26 a.m.
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(a)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/websocke…
JSCommunicator can set the extension header for passing supplementary
data in config.js:
https://github.com/opentelecoms-org/jscommunicator/blob/master/config-sampl…
(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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
4:37 p.m.
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?
4:50 p.m.
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(a)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
3945
days inactive
3945
days old
3 comments
2 participants
participants (2)
-
Daniel Pocock -
Peter Dunkley