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@crocodile-rcs.com> 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@gmail.com> 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@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@hotmail.com Email: shaheryarkh@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Ok, now I understand.

I changed parts of the code starting at line 298 in the file *call.htm* of sipml5. The modified code looks something like this:

*//i_port = 4062 + (((ew Date().getTime()) % 5) * 1000);^M* *i_port = 5060;* *// s_proxy = "sipml5.org";^M* *s_proxy = "127.0.0.1";* * * Having done that, sipml5 started to try to authenticate against my Kamailio and the next step is to make SIP calls which is where I'm heading right now.

Thanks a lot for your help.

Carlos.

On Tue, Aug 7, 2012 at 12:15 PM, Peter Dunkley < peter.dunkley@crocodile-rcs.com> wrote:

** 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@crocodile-rcs.com> 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@gmail.com> 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@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@hotmail.com Email: shaheryarkh@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hi Inaki,

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

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

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

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.

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

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.

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

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.

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

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

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

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.

Regards,

Peter

2012/8/7 Peter Dunkley peter.dunkley@crocodile-rcs.com:

Hi Inaki,

...

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

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

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?

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

}

...

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

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.

Ok.

...

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

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.

Sure, ok.

...

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

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.

...

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

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

Makes sense :)

...

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

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.

It seems a good decision :)

Thanks a lot for your explanations, and congratulations for your work.

Interesting discussion is going on, great.

Just wanted to add some notes from my own experience. I have used both OverSIP and Kamailio for web sockets testing. In my experience, using kamailio i was able to register two web socket clients to kamailio and make calls between them. But if try to do the following nothing works,

1. try to forward registration requests to another registrar. 2. try to make calls between a webrtc and non-webrtc client. 3. try to send call from webrtc client to asterisk / freeswitch server to play e.g. some IVR, voice mail etc.

and many other scenarios, which all have one thing common, that is one or more sip servers behind kamailio, webrtc clients do not work at all. They work only and only if kamailio is the only SIP server on the server side, mostly because kamailio currently do not have neither PATH nor outbound support.

On the other hand OverSIP is merely a basic SIP proxy with web sockets support, but it is has real good support for PATH and outbound, perhaps because it was designed as an edge SIP proxy that can work and relay client requests to another SIP server in the setup. This makes it easy to integrate in an existing SIP infrastructure, where one may have dedicated servers for e.g. SIP registration, PSTN termination, Announcement and voice mail services etc. etc.

Right now i am working on media side, i am able establish call between a webrtc and non-webrtc client but media does not flow either way. I am working with all possible options, using media servers e.g. asterisk, freeswitch, media proxy etc. I did got some success with asterisk after adding support ICE, SAVPF and VP8 pass through but still a lot needs to done and tested before we have a proper integration of webrtc clients in existing voip setups.

Thank you.

On Wed, Aug 8, 2012 at 2:31 AM, Peter Dunkley < peter.dunkley@crocodile-rcs.com> wrote:

On 7 Aug 2012, at 23:57, Iñaki Baz Castillo ibc@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@aliax.net

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

The Path module should now support the WebSocket transport.

Regards,

Peter

On Wed, 2012-08-08 at 09:47 +0100, Peter Dunkley wrote:

Hi,

I've added comments below...

On Wed, 2012-08-08 at 10:16 +0200, Muhammad Shahzad wrote:

...

1. try to forward registration requests to another registrar.

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.

...

2. try to make calls between a webrtc and non-webrtc client.

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.

...

3. try to send call from webrtc client to asterisk / freeswitch

server to play e.g. some IVR, voice mail etc.

This will be a problem for the same reason as above.

...

and many other scenarios, which all have one thing common, that is one or more sip servers behind kamailio, webrtc clients do not work at all. They work only and only if kamailio is the only SIP server on the server side, mostly because kamailio currently do not have neither PATH nor outbound support.

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hello and thank you for answering.

I did what you suggested but I couldn't be able to install it.

When I run: *sudo gem install oversip.gemspec* I get *ERROR*: *Could not find a valid gem 'oversip.gemspec' (>= 0) in any repository. *I thought it may be a problem with my ruby version but after I updated it I got the 1.8.7 version but the problem is still there.

Bellow is the output of *gem env* *RubyGems Environment:* * - RUBYGEMS VERSION: 1.5.0* * - RUBY VERSION: 1.8.7 (2011-02-18 patchlevel 334) [i586-linux]* * - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8* * - RUBY EXECUTABLE: /usr/bin/ruby* * - EXECUTABLE DIRECTORY: /usr/bin* * - RUBYGEMS PLATFORMS:* * - ruby* * - x86-linux* * - GEM PATHS:* * - /usr/lib/ruby/gems/1.8* * - /home/carlos/.gem/ruby/1.8* * - GEM CONFIGURATION:* * - :update_sources => true* * - :verbose => true* * - :benchmark => false* * - :backtrace => false* * - :bulk_threshold => 1000* * - REMOTE SOURCES:* * - http://rubygems.org/* * *

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

no luck either. I checked the call.htm file but I don't know where to modify it in order to make in point to my Kamailio. I just filled the input boxes with my local SIP credentials.

Regards.

Carlos.

On Tue, Aug 7, 2012 at 3:30 AM, Muhammad Shahzad <shaheryarkh@googlemail.com

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@gmail.com> 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@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@hotmail.com Email: shaheryarkh@googlemail.com

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hi Iñaki.

My old opensuse 11.4 doesn't have that version in the repositories so I'll have to install it from sources.

Do you recommend me to keep trying without any documentation or should I wait for the official release instead?

Regards.

Carlos.

On Tue, Aug 7, 2012 at 2:16 PM, Iñaki Baz Castillo ibc@aliax.net wrote:

2012/8/7 Carlos Ruiz Díaz carlos.ruizdiaz@gmail.com:

...

When I run: sudo gem install oversip.gemspec I get ERROR: Could not find

a

...

valid gem 'oversip.gemspec' (>= 0) in any repository. I thought it may

be a

...

problem with my ruby version but after I updated it I got the 1.8.7

version

...

but the problem is still there.

OverSIP is not officially published yet (I'm writting the documentation right now). BTW it requires Ruby >= 1.9.2.

-- Iñaki Baz Castillo ibc@aliax.net

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev