Harneet, More philosophically, it should be added that routing determinations based on the dialed number should never be done based on the To header, but only the Request URI.
— Alex > On Apr 25, 2023, at 1:39 AM, Henning Westerholt <h...@gilawa.com> wrote: > > 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 <hbill...@gmail.com> > Sent: Montag, 24. April 2023 12:16 > To: Henning Westerholt <h...@gilawa.com> > Cc: Kamailio (SER) - Users Mailing List <sr-users@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 <h...@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 <hbill...@gmail.com> > Sent: Donnerstag, 20. April 2023 14:48 > To: Kamailio (SER) - Users Mailing List <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 should be routed to destinationsip.elementB.com, > where as if the To URI contains sip.elementC.com, the request should be > routed tosip.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 > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
