24 Sep
2013
24 Sep
'13
1:47 p.m.
Hi Vitaliy,
On 09/24/2013 12:45 AM, Vitaliy Aleksandrov wrote:
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
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.