Hi,
The `tcpops` module exposes,
* event_route[tcp:closed] * event_route[tcp:timeout] * event_route[tcp:reset]
These fire on closure of TCP connections and TLS connections. TLS is considered a separate transport in Kamailio, having distinct identifiers in all cases where transport protocol is relevant, configured by separate and specific parameters, and provided by a separate module (tls). But TLS runs on top of TCP, of course, so treating a TLS disconnection as a superset of TCP disconnection makes sense.
WebSocket is considered a separate transport in Kamailio, having distinct identifiers in all cases where transport protocol is relevant, configured by separate and specific parameters, and provided by a separate module (websocket). But WebSocket runs on top of TCP, of course...
... yet it doesn't trigger these TCP connection events. Instead, one must use a separate `event_route[websocket_closed]` event route for this.
Is there a reason for this inconsistency? I would think that the common denominator of TCP would lead to the same hierarchy of abstraction when it comes to events.
It becomes important because if one wishes for Kamailio to log or notify disconnections for vanilla SIP or browser-based clients, one must essentially implement the same code twice.
Thank you,
-- Alex
Hello,
I haven't implemented the code for these event routes, but looking at the code, at least for tls (and in most of the cases, websocket is over tls), the file descriptor for connection is passed to libssl for handling, so our C code gets directly the decrypted traffic, therefore the management of the close event is also coming though libssl and handled in the tls module.
Now, of course the execution of these event routes can be added also in the tls module (and websocket module if still needed), it just requires someone to go though these case (closed, timeout, reset) and place the corresponding event route callbacks execution. I could spot a few places for EOF (connection closed) inside tls module. Anyhow, what I wanted to highlight here is that it does not seem possible to get it for all in the plain tcp connection handling code -- there the handling is based on the return code and errno set by read() libc, while for tls has to be based on libssl read and error functions.
What should be there now is the destroy of (basic) tcp connection structure which is common for tls and websocket as well. So there should be possible to have a single place for executing an event_route[tcp:destroyed], but that may happen slightly latter than getting the closed event.
Cheers, Daniel
On 18.09.20 08:57, Alex Balashov wrote:
Hi,
The `tcpops` module exposes,
- event_route[tcp:closed]
- event_route[tcp:timeout]
- event_route[tcp:reset]
These fire on closure of TCP connections and TLS connections. TLS is considered a separate transport in Kamailio, having distinct identifiers in all cases where transport protocol is relevant, configured by separate and specific parameters, and provided by a separate module (tls). But TLS runs on top of TCP, of course, so treating a TLS disconnection as a superset of TCP disconnection makes sense.
WebSocket is considered a separate transport in Kamailio, having distinct identifiers in all cases where transport protocol is relevant, configured by separate and specific parameters, and provided by a separate module (websocket). But WebSocket runs on top of TCP, of course...
... yet it doesn't trigger these TCP connection events. Instead, one must use a separate `event_route[websocket_closed]` event route for this.
Is there a reason for this inconsistency? I would think that the common denominator of TCP would lead to the same hierarchy of abstraction when it comes to events.
It becomes important because if one wishes for Kamailio to log or notify disconnections for vanilla SIP or browser-based clients, one must essentially implement the same code twice.
Thank you,
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users