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
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 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.comhttp://sip.elementA.com should be routed to destination sip.elementB.comhttp://sip.elementB.com, where as if the To URI contains sip.elementC.comhttp://sip.elementC.com, the request should be routed to sip.elementC.comhttp://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
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 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 *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 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
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@gmail.com Sent: Montag, 24. April 2023 12:16 To: Henning Westerholt hw@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 <hw@gilawa.commailto: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.commailto:hbilling@gmail.com> Sent: Donnerstag, 20. April 2023 14:48 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto: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.comhttp://sip.elementA.com should be routed to destination sip.elementB.comhttp://sip.elementB.com, where as if the To URI contains sip.elementC.comhttp://sip.elementC.com, the request should be routed to sip.elementC.comhttp://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
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 hw@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 hbilling@gmail.com Sent: Montag, 24. April 2023 12:16 To: Henning Westerholt hw@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 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 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-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Appreciate your response Henning..
Thanks Alex, I agree to what you said and it will be done that way based on the Request URI and not the To Header.
Regards, Harneet Singh
On Tue, Apr 25, 2023 at 5:34 PM Alex Balashov abalashov@evaristesys.com wrote:
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 hw@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 hbilling@gmail.com Sent: Montag, 24. April 2023 12:16 To: Henning Westerholt hw@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 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 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-leave@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-leave@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 -
harneet singh -
Henning Westerholt