Hi Vitaliy,
On 09/24/2013 12:45 AM, Vitaliy Aleksandrov wrote:
The patch only handles the case where a tcp connection is directly made to the registrar, as no event route is fired, right?
You are right. Current version works only when registrar accepts tcp connections. Anyway it's a good idea to call event_route[] when kamailio looses a tcp connection to give user a chance to process it somehow.
On the one hand it's great when experienced user can achieve what he wants by different ways depending on the situation, but on the other it makes a mess for new kamailio users.
I think the implementation is fine for "normal" use cases where you just have one combined registrar/proxy, which is probably what new kamailio users are starting with.
The reason I'd love to see an event-route is to handle cases for scaled architectures, where you have load-balancers/edge-servers accepting tcp/tls connections from clients and forward them to a back-end farm of registrars/proxies e.g. via udp.
The implementation of that event-route would be completely independent of the current solution anyways, because it won't hook up with usrloc (on the edge proxies there is usually no usrloc loaded), rather than having the code somewhere in the core and just firing an event-route, where the system developer can do arbitrary actions (like creating a custom sip message to be sent to the back-end servers, which triggers an unregister there). Honestly I have no clue yet as of how to actually do that. Firing the event-route would be the rather easy part I guess, but do we have all the information needed to do an unregister on the back-end registrar? Probably the only info we have is the source ip/port/proto of the disconnected client, so we'd need some logic in the registrar/usrloc module on the back-end registrar to match a location entry with that info somehow.
I'm just throwing in some thoughs on that topic for further discussions, so no clear idea how to accomplish that from my side.
Andreas