[Devel] [ openser-Bugs-1650015 ] When DNS fails on t_relay(), failure_route is not called

Fri Feb 2 17:56:32 CET 2007

Bugs item #1650015, was opened at 2007-02-01 19:18
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1650015&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: axlh (axlh)
Assigned to: Bogdan (bogdan_iancu)
Summary: When DNS fails on t_relay(), failure_route is not called

Initial Comment:
I have a setup where an ENUM query returns 2 uri's with different q-values (the 2nd uri being used for failover routing). I want to use serial forking to relay the request to them. The first URI contains a non-existing dns name and fails. After that, I want to try to relay to the second URI, but failure_route is never entered after the failing DNS lookup.

This very same setup works fine if the first uri is valid though.

Log snippet follows (OpenSER v1.1.0):

: load_contacts(): DEBUG: Loaded <sip:1234567890 at existant.example.com>, q_flag <0>
: load_contacts(): DEBUG: Loaded <sip:0987654321 at non-existant.example.com>, q_flag <4>
: next_contacts(): DEBUG: R-URI is <sip:0987654321 at non-existant.example.com>
: DEBUG: t_newtran: msg id=1 , global msg id=0 , T on entrance=0xffffffff
: parse_headers: flags=ffffffffffffffff
: parse_headers: flags=78
: t_lookup_request: start searching: hash=45745, isACK=0
: DEBUG: RFC3261 transaction matching failed
: DEBUG: t_lookup_request: no transaction found
: DBG: trans=0xa3c88520, callback type 1, id 0 entered
: parse_headers: flags=58
: DEBUG: noisy_timer set for accounting
: DEBUG:tm:t_relay: new INVITE
: parse_headers: flags=ffffffffffffffff
: check_via_address(213.148.240.237, 213.148.240.237, 0)
: WARNING:vqm_resize: resize(0) called
: DEBUG:tm:_reply_light: reply sent out. buf=0x81350c8: SIP/2.0 1..., shmem=0xa3c89e30: SIP/2.0 1
: DEBUG:tm:_reply_light: finished
: DEBUG: mk_proxy: doing DNS lookup...
: DEBUG:sip_resolvehost2: no port, no proto -> do NAPTR lookup!
: get_record: lookup(non-existant.example.com, 35) failed
: DEBUG:sip_resolvehost2: no valid NAPTR record found for non-existant.example.com, trying direct SRV lookup...
: get_record: lookup(_sip._udp.non-existant.example.com, 33) failed
: DEBUG:sip_resolvehost2: no valid SRV record found for _sip._udp.non-existant.example.com, trying A record lookup...
: ERROR: mk_proxy: could not resolve hostname: "non-existant.example.com"
: ERROR: uri2proxy: bad host name in URI <sip:0987654321 at non-existant.example.com>
: ERROR:tm:t_forward_nonack: failure to add branches
: ERROR:tm:t_relay_to:  t_forward_nonack returned error
: parse_headers: flags=ffffffffffffffff
: check_via_address(213.148.240.237, 213.148.240.237, 0)
: DBG: trans=0xa3c88520, callback type 128, id 0 entered
: DEBUG: cleanup_uac_timers: RETR/FR timers reset
: DEBUG: add_to_tail_of_timer[4]: 0xa3c885d0
: DEBUG: add_to_tail_of_timer[0]: 0xa3c885e0
: DEBUG:tm:_reply_light: reply sent out. buf=0x8135238: SIP/2.0 4..., shmem=0xa3c89e30: SIP/2.0 4
: DEBUG:tm:_reply_light: finished
: ERROR: generation of a stateful reply on error succeeded
: DEBUG:tm:UNREF_UNSAFE: after is 0
: DEBUG:destroy_avp_list: destroying list (nil)
: receive_msg: cleaning up

----------------------------------------------------------------------

>Comment By: Bogdan (bogdan_iancu)
Date: 2007-02-02 18:56

Message:
Logged In: YES 
user_id=1275325
Originator: NO

yes, but the dns-based failover is also available only in devel version
:). By the end of the week, the devel branch will enter in testing phase
and soon it will become the next stable.

if you want to submit a wish, please use the Feature Request of the
tracker. I will close this bug reports.

regards,
bogdan

----------------------------------------------------------------------

Comment By: axlh (axlh)
Date: 2007-02-02 12:50

Message:
Logged In: YES 
user_id=1212856
Originator: YES

Thanks for the info.

Your suggestion is only available in devel version. Is it in a usable
state? 

Can I turn this bugreport into a wishlist item? I'd like t_relay() to
(optionally) produce an internal error code (e.g. 503) on failure, and
proceed with failure_route if present. Just as is done currently for
timeouts. This way all failure logic can be located in one place:
failure_route. If no failure_route is defined, current behaviour is fine.

----------------------------------------------------------------------

Comment By: Bogdan (bogdan_iancu)
Date: 2007-02-02 11:46

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi there,

the failure route is triggered only by negative replies (received or
internally generated). In your case, when using the first URI, no valid IP
is found (based on DNS), so the request is never sent out, so failure route
will not be triggered at all.

what will happen is that t_rely() will return with negative return in
script, if you disabled the out error reply - please see the t_reply() 's
flags in TM docs.

Let me know if it works for you.

regards,
bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1650015&group_id=139143