Hello,

On 6/14/12 4:49 PM, Iñaki Baz Castillo wrote:

2012/6/14 Peter Dunkley peter.dunkley@crocodile-rcs.com

...

Hello,

Crocodile is looking at adding WebSocket as a SIP transport to Kamailio (including WebSockets over TLS).

I wanted to check to see if anyone else was working on this, or if anyone else is interested in working on this with us?

Also, I would be interested in any advice or notes anyone has on adding a new protocol/transport, as this touches on a lot of parts of Kamailio I am not familiar with.

Hi Peter, I've implemented SIP WebSocket transport in my own SIP proxy and also planned to add it in Kamailio (by initially playing a bit in my local sources copy), so yes, I'm fully interested. It is a big task since, as you said, it involves touching lot of Kamailio core.

So if you want, feel free to contact me and let's start it.

I will be here to guide whenever needed to navigate through the transport layers.

At some point it time when someone was looking to sponsor the development of web sockets support I was investigating a bit, unfortunately the project was postponed. From what I remember, the core touches will be:

- sip uri and via parsers enhanced to deal with websocket transport values - tcp connection structure to keep a flag its websocket in order to generate proper values for via/record-route

I planned to put the specific code in a module, like Peter started with his last commit. Eventaully, some hooks can be added in core to execute callbacks from the module in case its needed, existing support in core for receiving http over tcp proved to be a time saver -- the overall impact was estimated to be much lower that I initially thought.

Thanks everyone for allocating resources for it, I will help as much as I can, as well, looking forward to the outcome.

Cheers, Daniel

Hello,

On 6/15/12 10:40 AM, Iñaki Baz Castillo wrote:

2012/6/15 Daniel-Constantin Mierla miconda@gmail.com:

...

I will be here to guide whenever needed to navigate through the transport layers.

Hi Daniel, thanks a lot. Some initial questions:

• What about the TLS layer? WebSocket session is established via an

HTTP GET request on top of TCP ot TCP-TLS. Web browsers usually don't present a certificate during TLS handshake so probably we don't want to obtain client certificate. But, is already possible to use the Kamailio HTTP stack on top of TLS?

yes, you can do http over tcp or tls in kamailio.

• About the relationship between the TCP/WS connection and SIP message

fields (to properly route incoming requests):

I'm pretty sure the proper solution here is Outbound. I've implemented it in my proxy and works great (forget mangling the Contact URI or creating "alias" in Kamailio that could be overridn by other users and so...). Is there a chance to investigate adding Outbound to Kamailio? I've lot of experience with the spec and can help here.

Which RFC are you talking about? There was work done for registrar/usrloc in 3.3 to handle as per RFC5626 (as well as RFC5627 GRUU).

But overall, the selection of outgoing connection has an algorithm based on port/ip/proto, like it is for old tcp/tls. This time I assume the double record routing will have one with WS/WSS and the other will be UDP/TCP/TLS or, if needed, we can add another WS/WSS.

Cheers, Daniel

Hi Daniel,

Thanks for the encouragement.

I could do with a guide here. I think there is only a few hours work left to finish off the handshake and basic module stuff. After that I think the next step needs to be: - Getting the module to register with core to receive WS frames (which may arrive over TCP or TLS) - Giving the module/core the ability to "change" the connection the handshake came in on from SIP/HTTP to WS (so that new messages go straight to the handler in the new module) - In the module adding handling for Close, Ping, and Pong - To do the handling for Ping the module needs to be able to send WS frames out (over TCP or TLS) - In the module "printing" received binary and text frames (which will contain SIP requests)

The bits I need help with here the most are the registering the module to receive the WS frames and sending WS frames (over TCP or TLS), and adding the ability for the module/core to "upgrade" the connection from SIP/HTTP to WS after successful handshake.

Regards,

Peter

On Fri, 2012-06-15 at 08:25 +0200, Daniel-Constantin Mierla wrote:

I will be here to guide whenever needed to navigate through the transport layers.

At some point it time when someone was looking to sponsor the development of web sockets support I was investigating a bit, unfortunately the project was postponed. From what I remember, the core touches will be:

• sip uri and via parsers enhanced to deal with websocket transport values
• tcp connection structure to keep a flag its websocket in order to

generate proper values for via/record-route

Hi,

One of the things I need to be able to do from the WebSocket module is to cleanly close TCP/TLS connections when I receive/send a Close() frame.

Is there an easy way to do this from a Kamailio module?

Regards,

Peter

Hello,

On 6/15/12 11:33 AM, Peter Dunkley wrote:

...

Hi Daniel,

Thanks for the encouragement.

I could do with a guide here. I think there is only a few hours work left to finish off the handshake and basic module stuff. After that I think the next step needs to be:

• Getting the module to register with core to receive WS frames (which

may arrive over TCP or TLS)

• Giving the module/core the ability to "change" the connection the

handshake came in on from SIP/HTTP to WS (so that new messages go straight to the handler in the new module)

• In the module adding handling for Close, Ping, and Pong
• To do the handling for Ping the module needs to be able to send WS

frames out (over TCP or TLS)

• In the module "printing" received binary and text frames (which will

contain SIP requests)

The bits I need help with here the most are the registering the module to receive the WS frames and sending WS frames (over TCP or TLS), and adding the ability for the module/core to "upgrade" the connection from SIP/HTTP to WS after successful handshake.

I think of doing it like:

• when WS handshake is completed, mark the tcp connection as being WS

from the module (a new flag or so)

• then in the TCP read function (iirc, tcp_read.{c,h} in core) if the

connection is marked WS, then execute a callback that is registered by the module

• this is pretty much how http and msrp work, but there the detection is

on the content, not on the socket type. HTTP is using so called no-SIP content callback, while MSRP is using a dedicated core event

For sending, using tcp_send(...) (looking at msrp module will give the right directions) should do it -- the function takes the tcp connection as parameter as well as the outgoing buffer and encrypts the content if actually is over TLS. The send operation may become transparent as soon as the algorithm for finding the connection can grep on WS/WSS protocol.

Cheers, Daniel

...

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

Hi Klaus,

Thanks but it doesn't do what I need. That function closes the connection after the next send by setting SND_F_CON_CLOSE (which is the what the tcpconn_close_after_send() macro in tcp_conn.h does too).

Unfortunately, I need to be able to cleanly close a connection immediately without any further sends.

Thanks,

Peter

On Mon, 2012-06-18 at 12:01 +0200, Klaus Darilion wrote:

See how this function works:

http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#set_forward_cl...

It might help you

On 17.06.2012 15:11, Peter Dunkley wrote:

...

Hi,

One of the things I need to be able to do from the WebSocket module is to cleanly close TCP/TLS connections when I receive/send a Close() frame.

Is there an easy way to do this from a Kamailio module?

Regards,

Peter

...

Hello,

On 6/15/12 11:33 AM, Peter Dunkley wrote:

...

Hi Daniel,

Thanks for the encouragement.

I could do with a guide here. I think there is only a few hours work left to finish off the handshake and basic module stuff. After that I think the next step needs to be:

• Getting the module to register with core to receive WS frames (which

may arrive over TCP or TLS)

• Giving the module/core the ability to "change" the connection the

handshake came in on from SIP/HTTP to WS (so that new messages go straight to the handler in the new module)

• In the module adding handling for Close, Ping, and Pong
• To do the handling for Ping the module needs to be able to send WS

frames out (over TCP or TLS)

• In the module "printing" received binary and text frames (which will

contain SIP requests)

The bits I need help with here the most are the registering the module to receive the WS frames and sending WS frames (over TCP or TLS), and adding the ability for the module/core to "upgrade" the connection from SIP/HTTP to WS after successful handshake.

I think of doing it like:

• when WS handshake is completed, mark the tcp connection as being WS

from the module (a new flag or so)

• then in the TCP read function (iirc, tcp_read.{c,h} in core) if the

connection is marked WS, then execute a callback that is registered by the module

• this is pretty much how http and msrp work, but there the detection is

on the content, not on the socket type. HTTP is using so called no-SIP content callback, while MSRP is using a dedicated core event

For sending, using tcp_send(...) (looking at msrp module will give the right directions) should do it -- the function takes the tcp connection as parameter as well as the outgoing buffer and encrypts the content if actually is over TLS. The send operation may become transparent as soon as the algorithm for finding the connection can grep on WS/WSS protocol.

Cheers, Daniel

...

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

Yes there is, I just wanted to ask the question and see if anyone else knew of a simple and clean way to immediately close the connection already before I started hacking away the TCP code further ;-)

On Mon, 2012-06-18 at 13:59 +0200, Klaus Darilion wrote:

I guess there is code somewhere that closes the TCP connection when the maximum TCP-idle-time is reached

regards Klaus