Same destination IP for both rate decks, so I need to go by something else, like the gw_name.
----- Reply message ----- From: "Stagg Shelton" stagg@vocalcloud.com Date: Sat, Jan 29, 2011 8:27 am Subject: [SR-Users] LCR next_gw() - certain GW, source from other IP address To: sr-users@lists.sip-router.org
Do the provider gateways have the same IP address for the different rate plans? If the gateways are different then the following may be relevant.
if (next_gw()) { # prepare for lcr failover t_on_failure("2"); if($rd=="aaa.aaa.aaa.aaa") { xlog ("L_INFO", "This is a request for Some Rate Plan"); force_send_socket(udp:xxx.xxx.xxx.xxx:5060); } else { xlog ("L_INFO", "This is a request for another rate plan"); force_send_socket(udp:yyy.yyy.yyy.yyy:5060); }; route(2); } else { xlog("No gateways found!");
Stagg
On 1/29/11 9:10 AM, Graham Wooden wrote:
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Stagg,
While the Ips are the same, the suggestion to use “rd” along with an entry in the “hostname” column appears to be what I want.
I assigned in my DNS some testing hostnames to the single IP in question. When debugging, I see that rd contains the hostname, not the IP. I believe with that, I can differentiate between the two... And when I see hostname of blah.blah.tld, then go ahead and do the force_send_socket.
This definitely solves the issue for the time being. However, I am wondering if/when call volume increases if the call-setup time be delayed because of these look ups. Everything that I have read so far is that the gw_name is just information, the module doesn’t actually have access to it. Boo.
-graham
On 1/29/11 8:36 AM, "GP Wooden" graham@g-rock.net wrote:
Well, ran into another wall .... I can’t seem to do the force_send_socket at the point of when next_gw() is called in the failure route.
Is there anyway to clear and/or re-assign the data that is making it where I can’t re-write the transaction to come from another IP addy?
On 1/29/11 11:01 AM, "Graham Wooden" graham@g-rock.net wrote:
I have the force send socket in the branch route too. So assume the first attempt fails and the call makes it to the failure route that I setup. Once it gets to the branch route then it executes the following where you can perform your logic again.
branch_route[2] { xlog("new branch at $ru\n"); if($rd=="aaa.aaa.aaa.aaa") { xlog ("L_INFO", "This is a request for A Plan"); force_send_socket(udp:xxx.xxx.xxx.xxx:5060); } else { xlog ("L_INFO", "This is a request for another plan"); force_send_socket(udp:yyy.yyy.yyy.yyy:5060); }; }
Stagg
On 1/29/11 12:32 PM, Graham Wooden wrote:
Ah I didn’t have the same routine in branch_route I think that’s the key. Seems to be working now. I see now that I am sourcing out the IP addy that I need to be.
Thanks for that extra hint Stagg.
-graham
On 1/29/11 11:45 AM, "Stagg Shelton" stagg@vocalcloud.com wrote:
go
-
GP Wooden -
Graham Wooden
-
Stagg Shelton