I have same the SRV failover problem with uac_registrant-generated REGISTER requests.
After little bit of digging it looks like there is no proxy structure associated with internally generated requests, and no DNS-based failover without it. Issue #140 <https://github.com/OpenSIPS/opensips/issues/140> logged. - Jeff On Tue, Nov 26, 2013 at 9:23 AM, Jeff Pyle <[email protected]> wrote: > Hello, > > I have an SRV name as follows: > > $ dig +short -tSRV _sip._udp.proxyname.domain.com > 1 10 5060 host1.domain.com. > 2 10 5060 host2.domain.com. > > If I t_relay() a request with proxyname.domain.com as the request domain, > and host1 does not answer within fr_timer seconds, the request is > re-relayed to host2. This is good. > > If I b2b_init_request("top hiding") instead of t_relay(), the 408 is > forwarded back towards the UAC after host1 doesn't answer. The request is > never re-relayed to host2. > > There is a difference in the debug output after the 408 is generated for > host1. With the B2BUA it looks like is_3263_failure() never happens. > > t_relay: > Nov 26 09:03:38 [16296] DBG:tm:timer_routine: timer > routine:0,tl=0x7fbe6c7c0060 next=(nil), timeout=61 > Nov 26 09:03:38 [16296] DBG:tm:final_response_handler: Cancel sent out, > sending 408 (0x7fbe6c7bfe10) > Nov 26 09:03:38 [16296] DBG:tm:t_should_relay_response: T_code=100, > new_code=408 > Nov 26 09:03:38 [16296] DBG:tm:t_pick_branch: picked branch 0, code 408 > (prio=800) > Nov 26 09:03:38 [16296] DBG:tm:is_3263_failure: dns-failover test: > branch=0, last_recv=408, flags=1 > Nov 26 09:03:38 [16296] DBG:tm:t_should_relay_response: trying DNS-based > failover > Nov 26 09:03:38 [16296] DBG:tm:do_dns_failover: new destination available > Nov 26 09:03:38 [16296] DBG:core:check_ip_address: params 127.0.0.1, > 127.0.0.1, 0 > Nov 26 09:03:38 [16296] DBG:tm:set_timer: relative timeout is 500000 > > b2b_init_request: > Nov 26 09:12:21 [16401] DBG:tm:timer_routine: timer > routine:0,tl=0x7f09ddcbf7e8 next=(nil), timeout=11 > Nov 26 09:12:21 [16401] DBG:tm:final_response_handler: Cancel sent out, > sending 408 (0x7f09ddcbf598) > Nov 26 09:12:21 [16401] DBG:tm:t_should_relay_response: T_code=0, > new_code=408 > Nov 26 09:12:21 [16401] DBG:tm:t_pick_branch: picked branch 0, code 408 > (prio=800) > Nov 26 09:12:21 [16401] DBG:tm:local_reply: branch=0, save=0, winner=0 > Nov 26 09:12:21 [16401] DBG:tm:local_reply: local transaction completed > Nov 26 09:12:21 [16401] DBG:tm:run_trans_callbacks: trans=0x7f09ddcbf598, > callback type 256, id 0 entered > Nov 26 09:12:21 [16401] DBG:b2b_entities:b2b_tm_cback: tm [0x7f09ddcbf598] > notification cb for [408] reply > Nov 26 09:12:21 [16401] DBG:b2b_entities:b2b_parse_key: hash_index = [472] > - local_index= [2611231] > Nov 26 09:12:21 [16401] DBG:b2b_entities:b2b_tm_cback: Received reply > [408] for dialog [0x7f09ddcbf2b8], method [INVITE] > > Is there something extra that must occur in the script to get DNS failover > behavior with the B2BUA? Or, is this a bug? > > > Regards, > Jeff > > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
