** Hi, You don't need to use OverSIP to use the WebSocket module in Kamailio. The Kamailio implementation will allow you connect one or more WebSocket clients directly to Kamailio and make calls between them. It can also be used to convert calls from the WebSocket transport to SCTP/TCP/UDP for routing to other proxies. Although Kamailio doesn't support the full set of outbound features needed for WebSockets (yet) it is possible to use the same NAT traversal techniques that are used for TCP clients that connect through a NAT. These are pretty trivial to use/set-up and there is an example Kamailio configuration file in the WebSockets module directory that does this. Regards, Peter On Tue, 2012-08-07 at 09:30 +0200, Muhammad Shahzad wrote: For WS client, you can try SIPML5, http://code.google.com/p/sipml5/ Just download source code to some web server's root and edit call.html to point to your web sockets server (Kamailio or OverSIP). You can install OverSIP as follows (below instructions are for Debian 6.x / Ubuntu 11.x) apt-get install build-essential ruby1.9.1-full libev-dev gem1.9.1 install oversip ln -s /var/lib/gems/1.9.1/gems/oversip-1.0.5/etc /etc/oversip And then finally edit /etc/oversip/oversip.conf for your needs. Your web sockets address and port should be same as what you have mentioned in sipml5/call.html page. You can start oversip as, (there is an init.d script in sources, but its not installed by gem1.9.1) oversip -P /var/run/oversip.pid The advantage of OverSIP is that it supports PATH and outbound support, so you can create chain of SIP proxies. Thank you. On Tue, Aug 7, 2012 at 12:40 AM, Carlos Ruiz Díaz < carlos.ruizdiaz(a)gmail.com&gt; wrote: Hello list, I'm trying to test the websocket module on Kamailio but I currently lack of a working web SIP phone that makes use of the websocket transport protocol. I'm trying with OverSIP <https://github.com/versatica/OverSIP> but there's no documentation on how to try it (and I don't do Ruby). Is there another HTML5 SIP client that I can use or at least a page where I can find documentation about how to configure OverSIP? Regards. Carlos. _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Muhammad Shahzad ----------------------------------- CISCO Rich Media Communication Specialist (CRMCS) CISCO Certified Network Associate (CCNA) Cell: +92 334 422 40 88 MSN: shari_786pk(a)hotmail.com Email: shaheryarkh(a)googlemail.com _______________________________________________ sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

** Hi Carlos, You do need a SIP over WebSockets client (for example, an HTML5 SIP phone) to use the WebSocket transport. sipml5, running on Google Chrome Beta (or Canary) with the PeerConnection API enabled, works just fine with the Kamailio WebSocket implementation without any additional software being needed. OverSIP is alternative SIP proxy that you could use instead of (or in addition to Kamailio), but you do not need this at all if you just want to connect a WebSocket client to Kamailio. You can make calls between WebSocket clients, or you can make calls between WebSocket clients and non-WebSocket clients using Kamailio (you just need to make sure that the non-WebSocket clients support the correct set of media options). If you look in the history of the sr-dev mailing list there is a thread between 07/07/2012 and 09/07/2012 about using the WebSocket module. Regards, Peter On Tue, 2012-08-07 at 11:25 -0400, Carlos Ruiz Díaz wrote: Hi Peter, Could you please explain a little bit more about how to test the module without using a HTML5 SIP phone? AFAIK, I need a HTML5 SIP client (on a browser that supports websocket) plus a media stack capable of transporting RTP packets, such webRTC. So far I couldn't be able to get this components to work at all. Thanks for your help. Carlos On Tue, Aug 7, 2012 at 5:41 AM, Peter Dunkley < peter.dunkley(a)crocodile-rcs.com&gt; wrote: Hi, You don't need to use OverSIP to use the WebSocket module in Kamailio. The Kamailio implementation will allow you connect one or more WebSocket clients directly to Kamailio and make calls between them. It can also be used to convert calls from the WebSocket transport to SCTP/TCP/UDP for routing to other proxies. Although Kamailio doesn't support the full set of outbound features needed for WebSockets (yet) it is possible to use the same NAT traversal techniques that are used for TCP clients that connect through a NAT. These are pretty trivial to use/set-up and there is an example Kamailio configuration file in the WebSockets module directory that does this. Regards, Peter On Tue, 2012-08-07 at 09:30 +0200, Muhammad Shahzad wrote: For WS client, you can try SIPML5, http://code.google.com/p/sipml5/ Just download source code to some web server's root and edit call.html to point to your web sockets server (Kamailio or OverSIP). You can install OverSIP as follows (below instructions are for Debian 6.x / Ubuntu 11.x) apt-get install build-essential ruby1.9.1-full libev-dev gem1.9.1 install oversip ln -s /var/lib/gems/1.9.1/gems/oversip-1.0.5/etc /etc/oversip And then finally edit /etc/oversip/oversip.conf for your needs. Your web sockets address and port should be same as what you have mentioned in sipml5/call.html page. You can start oversip as, (there is an init.d script in sources, but its not installed by gem1.9.1) oversip -P /var/run/oversip.pid The advantage of OverSIP is that it supports PATH and outbound support, so you can create chain of SIP proxies. Thank you. On Tue, Aug 7, 2012 at 12:40 AM, Carlos Ruiz Díaz < carlos.ruizdiaz(a)gmail.com&gt; wrote: Hello list, I'm trying to test the websocket module on Kamailio but I currently lack of a working web SIP phone that makes use of the websocket transport protocol. I'm trying with OverSIP <https://github.com/versatica/OverSIP> but there's no documentation on how to try it (and I don't do Ruby). Is there another HTML5 SIP client that I can use or at least a page where I can find documentation about how to configure OverSIP? Regards. Carlos. _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Muhammad Shahzad ----------------------------------- CISCO Rich Media Communication Specialist (CRMCS) CISCO Certified Network Associate (CCNA) Cell: +92 334 422 40 88 MSN: shari_786pk(a)hotmail.com Email: shaheryarkh(a)googlemail.com _______________________________________________ sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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).

Hi Inaki, 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.

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") {

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", "", ""); }

You can do this by creating a hash table using the htable module (http://kamailio.org/docs/modules/stable/modules_k/htable.html). This table can be filled in as part of the event_route[xhttp:request] above. If required ws_handle_handshake() could easily be updated to return success/failure instead of exiting on completion to help with this (but that change may not be needed). The hash table should be indexed on the source address and port of the connection.

This information can be put in the hash table and retrieved on demand. You can always get the source address and port (which the hash table would be indexed on) of a request in the Kamailio configuration.

I believe that calling the existing "set_reply_close()" function and then sending a SIP reply to the INVITE will kill the connection. Adding an API to explicitly kill the WebSocket connection immediately wouldn't be hard - but shouldn't be needed. There is no support for this at the moment, but it would be relatively easy to add an event_route[] to the WebSocket module (probably just a few lines in ws_conn.c:wsconn_close_now() or ws_conn.c:wsconn_rm()). If the event_route[] makes sure appropriate pseudo-vars (containing information like source address and port of the terminated connection and so on) are provided then this can be used to clean-up the hash-table (otherwise entries will just have to time-out).

Yes I thought that. That is one of the reasons I decided to use the xhttp module to handle the WebSocket handshake instead of coding it all in the module.

On 7 Aug 2012, at 23:57, Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt; wrote: you 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. 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. file 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. _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hi, I've added comments below... On Wed, 2012-08-08 at 10:16 +0200, Muhammad Shahzad wrote: There is no reason this won't work as long as you take the NAT-like issues into account. If it didn't work, then it won't have worked for the same reason that forwarding registers from a TCP client behind a NAT wouldn't work. This does work, but you have to make sure the client media stack supports the right set of options. If there is a problem here it is probably to do with RTCweb interworking - not WebSockets. I did a lot of testing with Boghe (http://code.google.com/p/boghe/ ) which does support the right media options. This will be a problem for the same reason as above. Kamailio does have Path support (http://kamailio.org/docs/modules/stable/modules_k/path.html ), but it may require a small update to work with WebSockets. Kamailio doesn't have Outbound support (yet), but there is a simple mechanism that means you can work without it (the example configuration for the WebSockets module contains this). When I tested I used the following scenarios: * WebSocket client -> Kamailio -> WebSocket client * WebSocket client -> Kamailio -> TCP client * WebSocket client -> Kamailio -> TLS client * WebSocket client -> Kamailio -> UDP client * WebSocket client -> Kamailio -> SCTP trunk -> Kamailio -> WebSocket client * WebSocket client -> Kamailio -> TCP trunk -> Kamailio -> WebSocket client * WebSocket client -> Kamailio -> TLS trunk -> Kamailio -> WebSocket client * WebSocket client -> Kamailio -> UDP trunk -> Kamailio -> WebSocket client * WebSocket client -> Kamailio -> SCTP trunk -> Kamailio -> TCP client * WebSocket client -> Kamailio -> TCP trunk -> Kamailio -> TCP client * ... and so on I also did some testing with secure WebSocket connections. All worked for me. Regards, Peter _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

From the side of sipml5, which I tried before writing my first mail, I had

wrote:

wrote:

2012/8/7 Carlos Ruiz Díaz &lt;carlos.ruizdiaz(a)gmail.com&gt;om>: a be a version OverSIP is not officially published yet (I'm writting the documentation right now). BTW it requires Ruby >= 1.9.2. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt; _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev