[OpenSER-Users] Problems with NAPTR records and failover

[Robert McGilvray]

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 at mygateway1.whoever.com!" .

                        NAPTR 20 10 "u" "E2U+sip"
"!^.*$!sip:7100 at myfailovergateway1.whoever.com!" .

 

>From what I understand this should first try to contact my gateway (a
cisco box) using a uri of sip:3759 at mygateway1.whoever.com. If this fails
it should then take the second higher order and rewrite the URI to
sip:7100 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20080118/6eaa5f9e/attachment.htm