Hello,
I am/will be a newbie to 1.3.x and beyond and have a question regarding a new requirement of two of my upstream providers. We have been running 1.1.1-notls since it was released. We have been in the mindset of, "if it's not broken, don't fix it". But our upstream providers are now telling us to move to DNS/SRV for signaling outbound - for good reason.
We have been using LCR for carrier/gateway selection and for URI manipulation prior to relaying to a cluster of session boarder controllers. As you know the DB table for LCR only supports integers in the gw table for ip_addr. I have been reading up on 1.2.x and 1.3.x to upgrade to a solution that would allow us to stay within the same call processing (script) design, but still support the new upstream requirement. I noticed the carrierroute table rewrite_host column is string. Could this be used to satisfy my needs of manipulating the URI for an IP where the carrier still uses a list of gateway IP's to try and use the DNS/SRV domain name where the carrier requires the use for SRV look-up? The session boarder controllers will conduct the SRV look-up after receiving the relayed message from Kamailio, it is just getting the domain name on the URI instead of IP address that I am looking to accomplish. Will the carrierroute module assist in this effort or is there another way that I am totally missing?
Figured I would ask the gurus before following Alice down the rabbit hole.
Hello,
On 10/02/08 15:51, Krom wrote:
Hello,
I am/will be a newbie to 1.3.x and beyond and have a question regarding a new requirement of two of my upstream providers. We have been running 1.1.1-notls since it was released. We have been in the mindset of, "if it's not broken, don't fix it". But our upstream providers are now telling us to move to DNS/SRV for signaling outbound
- for good reason.
We have been using LCR for carrier/gateway selection and for URI manipulation prior to relaying to a cluster of session boarder controllers. As you know the DB table for LCR only supports integers in the gw table for ip_addr. I have been reading up on 1.2.x and 1.3.x to upgrade to a solution that would allow us to stay within the same call processing (script) design, but still support the new upstream requirement. I noticed the carrierroute table rewrite_host column is string. Could this be used to satisfy my needs of manipulating the URI for an IP where the carrier still uses a list of gateway IP's to try and use the DNS/SRV domain name where the carrier requires the use for SRV look-up? The session boarder controllers will conduct the SRV look-up after receiving the relayed message from Kamailio, it is just getting the domain name on the URI instead of IP address that I am looking to accomplish. Will the carrierroute module assist in this effort or is there another way that I am totally missing?
Figured I would ask the gurus before following Alice down the rabbit hole.
every request that leaves kamailio/openser is relayed based on SRV lookup, if it has a domain name in R-URI. I believe carrierroute does not cache the IP addresses for destination at startup, so you will get the domain name in the R-URI -- the developer of carrierroute module will confirm anyhow, be patient a bit, he is offline for few days.
Cheers, Daniel
On Thursday 02 October 2008, Daniel-Constantin Mierla wrote:
I am/will be a newbie to 1.3.x and beyond and have a question regarding a new requirement of two of my upstream providers. We have been running 1.1.1-notls since it was released. We have been in the mindset of, "if it's not broken, don't fix it". But our upstream providers are now telling us to move to DNS/SRV for signaling outbound
- for good reason.
We have been using LCR for carrier/gateway selection and for URI manipulation prior to relaying to a cluster of session boarder controllers. As you know the DB table for LCR only supports integers in the gw table for ip_addr. I have been reading up on 1.2.x and 1.3.x to upgrade to a solution that would allow us to stay within the same call processing (script) design, but still support the new upstream requirement. I noticed the carrierroute table rewrite_host column is string. Could this be used to satisfy my needs of manipulating the URI for an IP where the carrier still uses a list of gateway IP's to try and use the DNS/SRV domain name where the carrier requires the use for SRV look-up? The session boarder controllers will conduct the SRV look-up after receiving the relayed message from Kamailio, it is just getting the domain name on the URI instead of IP address that I am looking to accomplish. Will the carrierroute module assist in this effort or is there another way that I am totally missing?
every request that leaves kamailio/openser is relayed based on SRV lookup, if it has a domain name in R-URI. I believe carrierroute does not cache the IP addresses for destination at startup, so you will get the domain name in the R-URI -- the developer of carrierroute module will confirm anyhow, be patient a bit, he is offline for few days.
Hello Kyle,
Daniel is right, carrierroute just rewrite the R-URI with the string that is found in the routing rule. It does not cache any DNS lookups. The rewritten message (with a domain) will be proceeded by the server core as any other message. So the scenario you described should work.
As a side note, if you only need to route to a few destinations, its also possible to use carrierroute without a database, which is perhaps easier to setup.
Cheers,
Henning
Daniel is right, carrierroute just rewrite the R-URI with the string that is found in the routing rule. It does not cache any DNS lookups. The rewritten message (with a domain) will be proceeded by the server core as any other message. So the scenario you described should work.
As a side note, if you only need to route to a few destinations, its also possible to use carrierroute without a database, which is perhaps easier to setup.
Cheers,
Henning
Henning,
I greatly appreciate your confirmation. I currently have 98 routes in the openser.lcr table, but I plan on initially using the configuration file to get my feet wet.
Thanks again. Kyle