Hello,
you could just query any supported database e.g. with the sqlops module. The dialplan
module might be also interesting, or htable if you prefer to have it in-memory (it also
supports reading and caching from a DB).
Cheers,
Henning
From: harneet singh <hbilling(a)gmail.com>
Sent: Montag, 24. April 2023 12:16
To: Henning Westerholt <hw(a)gilawa.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Configuring dynamic Destination identification for Kamailio
Routing
Thanks for the response Henning. I was wondering if we needed to do the routing based on
the following logic:
* Based on the From and To Header, select the next hop.The mappings for these fields will
be prefed in a db or some configuration file and that can be read at Kamailio startup.
Is such an option readily available in any of the existing modules?
Regards,
Harneet Singh
On Thu, Apr 20, 2023 at 9:49 PM Henning Westerholt
<hw@gilawa.com<mailto:hw@gilawa.com>> wrote:
Hello,
usually this kind of routing is done by using the dispatcher module. If you need to match
on a certain key of the SIP message, there are other possibilities, like the lcr module
for example. It supports regular expression match from a database, that can be reloaded
without Kamailio restart.
Cheers,
Henning
From: harneet singh <hbilling@gmail.com<mailto:hbilling@gmail.com>>
Sent: Donnerstag, 20. April 2023 14:48
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Configuring dynamic Destination identification for Kamailio Routing
Hi Experts,
We have been using Kamailio as a sip proxy for a fair bit of time now(version 5.3.2
though) and do understand the native routing mechanism that can be instrumented through
the kamailio cfg scripts.
We initially had only two sides, where the traffic could come from into Kamailio and it
just passed through to the other side(ie Traffic from A was routed to B and that from B
was routed to A). Off late, a few more sip elements have been introduced in the deployment
and now there is a need for a more formal/robust mechanism to select the intended
destination to forward an initial SIP INVITE to.
I believe that we could still keep all the logic in the native kamailio script and do the
routing(for example, an incoming call where the From URI contains
sip.elementA.com<http://sip.elementA.com> should be routed to destination
sip.elementB.com<http://sip.elementB.com>, where as if the To URI contains
sip.elementC.com<http://sip.elementC.com>, the request should be routed to
sip.elementC.com<http://sip.elementC.com>). Since we have many sip elements like
A,B.C,D,E etc where the requests might have to be routed to, based on certain different
criteria, this logic would become cumbersome. What would be the best way to accommodate
this?
Would it be possible to rewire this routing logic at runtime(like in some csv file that
can be reloaded) without a Kamailio restart?
Regards,
Harneet Singh
--
"Once you eliminate the impossible, whatever remains, no matter how improbable, must
be the truth" - Sir Arthur Conan Doyle
--
"Once you eliminate the impossible, whatever remains, no matter how improbable, must
be the truth" - Sir Arthur Conan Doyle