19 Jan
2008
19 Jan
'08
2:02 a.m.
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(a)lists.openser.org
[mailto:users-bounces@lists.openser.org] On Behalf Of Robert McGilvray
Sent: Friday, January 18, 2008 10:45 AM
To: users(a)lists.openser.org
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.
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.