I fixed my problem by calling
serialize_branches() and setting up a failure_route that uses next_branches(). enum
wasn’t putting them in any kind of order based on the q values.
Works great now, even with SRV failover
for the first NAPTR record.
- Bob
From:
users-bounces@lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf Of Robert McGilvray
Sent: Friday, January 18, 2008
10:45 AM
To:
Subject: [OpenSER-Users] Problems
with NAPTR records and failover
Greetings list,
I’m trying to setup uri rewriting and failover using
NAPTR records. I’ve gone wrong somewhere since instead of trying the
first uri and only failing over if there’s a transactional and/or
communications problem it’s creating two branches and doing parallel
forking on the records.
Example:
From my test SIP phone I dial 3759.
Openser receives this INVITE and does a private ENUM lookup
on it which returns two NAPTR records:
9.5.7.3
NAPTR 10 10 "u" "E2U+sip"
"!^.*$!sip:3759@mygateway1.whoever.com!" .
NAPTR
20 10 "u" "E2U+sip"
"!^.*$!sip:7100@myfailovergateway1.whoever.com!" .
From what I understand this should first try to contact my
gateway (a cisco box) using a uri of sip:3759@mygateway1.whoever.com. If this
fails it should then take the second higher order and rewrite the URI to
sip:7100@myfailovergateway1.whoever.com.
Instead what I end up with is two parallel calls to gateway
and failover, the second NAPTR record is a conference bridge so the cisco
immediately sends back a 200 OK and openser cancels the first branch. First
gateway barely gets off a ring to my phone. I haven’t adjusted any of the
SIP timers so the defaults should allow plenty of time for call setup etc.
Debug output from the call is in http://www.idled.net/~bobm/openser-debug.txt
. Am I handling the INVITE incorrectly in my config? Any assistance would be
appreciated.
route[1] {
if (!t_relay()) {
xlog("L_NOTICE", "sipprx-wpf1.globeop.com: $mi route[$rm][0] $fu
-> $ru -> Error with t_relay\n");
sl_reply_error();
}
exit;
}
INVITE routing block
route[6] {
sl_send_reply("100",
"Trying");
if (isflagset(1))
{
xlog("L_NOTICE", "sipprx-wpf1.globeop.com: $mi route[$rm][0] $fu
-> $ru Processing INVITE\n");
}
if
(!proxy_authorize("", "subscriber")) {
proxy_challenge("", "0");
exit;
}
if
(!check_from()) {
sl_send_reply("403","Forbidden auth ID");
exit;
}
consume_credentials();
if ((uri =~
"sip:[0-9]{4}@.*") || (uri =~ "sip:[0-9]{10}@.*")) {
prefix ("+");
if (enum_query("e164.globeop.com")) {
xlog("L_INFO", "sipprx-wpf1.globeop.com: Number found in ENUM,
new uri is $ru\n");
} else {
xlog("L_INFO", "sipprx-wpf1.globeop.com: Number not found in
ENUM\n");
revert_uri();
}
}
if
(!is_uri_host_local()) {
append_hf("P-hint: outbound\r\n");
route(1);
} else if
(lookup("location")) {
append_hf("P-hint: usrloc applied\r\n");
route(1);
} else {
sl_send_reply("404","Not found");
exit;
}
exit;
}
-- Bob
This email with all information contained herein or
attached hereto may contain confidential and/or privileged information intended
for the addressee(s) only. If you have received this email in error, please
contact the sender and immediatley delete this email in its entirety and any
attachments thereto.