Is there a way to have OpenSER try each NAPTR record when multiple are returned?
4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 15 "u" "E2U+sip" "!^.*$!sip:+15555551234@server2" . 4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:+15555551234@server1" . 4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 25 "u" "E2U+sip" "!^.*$!sip:+15555551234@server3" .
That would route the calls to server1 (order 100, preference 10) but if server1 is not responding I would like it to move on and try server2.
-Jonathan
Jonathan Creasy writes:
Is there a way to have OpenSER try each NAPTR record when multiple are returned?
4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 15 "u" "E2U+sip" "!^.*$!sip:+15555551234@server2" . 4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:+15555551234@server1" . 4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 25 "u" "E2U+sip" "!^.*$!sip:+15555551234@server3" .
That would route the calls to server1 (order 100, preference 10) but if server1 is not responding I would like it to move on and try server2.
enum function appends all matching naptr records as branches to the request. you can then decide in your openser.cfg script what to do with them.
-- juha
Oh. I didn't understand what the branches were. Excellent!
If you have a moment can you post a link to some good documentation on that? If not...I can find it, I know I saw it earlier....
Juha Heinanen wrote:
Jonathan Creasy writes:
Is there a way to have OpenSER try each NAPTR record when multiple are returned?
4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 15 "u" "E2U+sip" "!^.*$!sip:+15555551234@server2" . 4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:+15555551234@server1" . 4.3.2.1.5.5.5.5.5.5.1.mysite.enum. 0 IN NAPTR 100 25 "u" "E2U+sip" "!^.*$!sip:+15555551234@server3" .
That would route the calls to server1 (order 100, preference 10) but if server1 is not responding I would like it to move on and try server2.
enum function appends all matching naptr records as branches to the request. you can then decide in your openser.cfg script what to do with them.
-- juha
Jonathan Creasy writes:
Oh. I didn't understand what the branches were. Excellent!
If you have a moment can you post a link to some good documentation on that? If not...I can find it, I know I saw it earlier....
for example, see load_contacts() and next_contacts() functions of lcr module.
-- juha
Juha Heinanen wrote:
Jonathan Creasy writes:
Oh. I didn't understand what the branches were. Excellent!
If you have a moment can you post a link to some good documentation on that? If not...I can find it, I know I saw it earlier....
for example, see load_contacts() and next_contacts() functions of lcr module.
-- juha
I'm going to show my ignorance here. I'm reading through the documentation and old messages floating around the internet and I really don't get it. The proper use of these functions is eluding me. I have not been able to get the system to move on and try the second contact. I can see from the debug that it pulls both records and they have the right preference and priority but it will not change to the second one even though the first on is an IP that has nothing on it to listen on 5060 and can't possibly be seen as a viable destination.
Jun 26 18:41:01 lugsy-raw openser[7214]: lookup(): '+13144803536' Not found in usrloc Jun 26 18:41:01 lugsy-raw openser[7214]: alias_db_lookup: no alias found for R-URI Jun 26 18:41:01 lugsy-raw openser[7214]: lookup(): '+13144803536' Not found in usrloc Jun 26 18:41:01 lugsy-raw openser[7214]: enum_query(6.3.5.3.0.8.4.4.1.3.1.enum.failover): order 50, pref 5, flen 1, flags 'u', slen 7, services 'E2U+sip', rlen 37, regexp '!^.*$!sip:+13144803536@206.80.75.243!' Jun 26 18:41:01 lugsy-raw openser[7214]: reg_replace(): pattern: '^.*$', replacement: 'sip:+13144803536@206.80.75.243', string: '+13144803536' Jun 26 18:41:01 lugsy-raw openser[7214]: enum_query(): resulted in replacement: 'sip:+13144803536@206.80.75.243' Jun 26 18:41:01 lugsy-raw openser[7214]: rewrite_uri: Rewriting Request-URI with 'sip:+13144803536@206.80.75.243' Jun 26 18:41:01 lugsy-raw openser[7214]: enum_query(6.3.5.3.0.8.4.4.1.3.1.enum.failover): order 100, pref 10, flen 1, flags 'u', slen 7, services 'E2U+sip', rlen 41, regexp '!^.*$!sip:+13144803536@sikosu.myogre.com!' Jun 26 18:41:01 lugsy-raw openser[7214]: reg_replace(): pattern: '^.*$', replacement: 'sip:+13144803536@sikosu.myogre.com', string: '+13144803536' Jun 26 18:41:01 lugsy-raw openser[7214]: enum_query(): resulted in replacement: 'sip:+13144803536@sikosu.myogre.com' Jun 26 18:41:01 lugsy-raw openser[7214]: ******* setting for branch 0 flags 0 Jun 26 18:41:01 lugsy-raw openser[7214]: ENUM lookup returned sip:+13144803536@206.80.75.243 , sending on Jun 26 18:41:01 lugsy-raw openser[7214]: parse_headers: flags=ffffffffffffffff Jun 26 18:41:01 lugsy-raw openser[7214]: load_contacts(): DEBUG: Loaded sip:+13144803536@sikosu.myogre.com, q_flag <0> Jun 26 18:41:01 lugsy-raw openser[7214]: load_contacts(): DEBUG: Loaded sip:+13144803536@206.80.75.243, q_flag <4> Jun 26 18:41:01 lugsy-raw openser[7214]: Route(2) Req 1 ACK From sip:+13142664000@206.80.75.228 To sip:+13144803536@janice.netlogic.net RURI sip:+13144803536@206.80.75.243 Jun 26 18:41:01 lugsy-raw openser[7214]: next_contacts(): DEBUG: R-URI is sip:+13144803536@206.80.75.243
Here is an excerpt from my configuration.
if (enum_query("enum.failover")) { xlog("L_INFO", "ENUM lookup returned <$ru> , sending on\n"); append_hf("P-hint: enum applied\r\n"); route(2); return; } Then the routes:
route[2] { if (!load_contacts()) { sl_send_reply("500", "Server Internal Error - Cannot load contacts"); exit; }; xlog("L_INFO", "Route(2) Req $mi $rm From <$fu> To <$tu> RURI <$ru>\n"); # !! Nathelper if (uri=~"[@:](192.168.|10.|172.(1[6-9]|2[0-9]|3[0-1]).)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); return; };
# if client or openserver know to be behind a NAT, enable relay of RTP if (isflagset(6)) { force_rtp_proxy(); };
# NAT processing of replies; apply to all transactions (for example, # re-INVITEs from public to private UA are hard to identify as # NATed at the moment of request processing); look at replies t_on_reply("1");
if (!next_contacts()) { sl_send_reply("500", "Server Internal Error"); exit; } else { xlog("L_INFO", "route2: Sending to <$ru>\n"); t_relay(); };
# After this gets processed it will go back to the statement it was called from }
failure_route[2] { if (next_contacts()) { route(2); exit; }; }
jonathan,
in order to get to failure_route[2], you need to set t_on_failure("2").
-- juha
Yeah, I have that in there. I'm learning how this thing works. I inherited these systems so I'm starting with someone else's production environment and trying to add functionality to it in my lab.
I can print out the $bR variable and see the second route. It goes to failure_route[2] but I can't get it to go back. I tried next_contact and next_branch the calling route(2) again. It does not go to the next entry retrieved from ENUM.
-Jonathan
Juha Heinanen wrote:
jonathan,
in order to get to failure_route[2], you need to set t_on_failure("2").
-- juha
-
jh＠tutpro.com -
Jonathan Creasy