[sr-dev] recursive calls to failure_route strange behavior

[Daniel-Constantin Mierla]

Hello,

On 20.11.2009 17:04 Uhr, Miklos Tirpak wrote:
> Hi Daniel,
>
> On 11/20/2009 04:38 PM, Daniel-Constantin Mierla wrote:
>>
>>
>> On 20.11.2009 9:53 Uhr, Miklos Tirpak wrote:
>>> On 11/20/2009 12:58 AM, Andres Moya wrote:
>>>> Dear all!
>>>>
>>>> Please help. I have problem dealing with recursive call in failure 
>>>> route.
>>>>
>>>> this route happen first time for authentication to external SIP 
>>>> provider (react on code 401), then it have response 480 i want to 
>>>> direct traffic to another operator via cr_route.
>>>>
>>>> First i relay INVITE and getting 401, then sending authentication, 
>>>> but provider gives 480. I can see it in a dump of SIP session. But 
>>>> my failure_route still thinking that reply code is 401 on second 
>>>> reply. Maybe because i dont understand well how branches concept 
>>>> work here? Or using kamailio 3.0? ;) Looks like it give me status 
>>>> code of first reply and ignoring actual code in reply. :( I don't 
>>>> know if it something with development version or my own 
>>>> misunderstanding. sorry
>>>
>>> This is correct, the proxy must choose one of the two responses to 
>>> forward and 401 has higher precedence than 480 (RFC3261, 16.7: 
>>> "Choosing the best response"). The failure route always works on the 
>>> selected response as opposed to the last response received.
>> I think this is wrong imo, if I got it right from your email, because 
>> the failure route should work on a selected reply from the last set 
>> of branches in serial forking.
>>
>> Do you say that if I get 301 with couple of contacts, then in failure 
>> route I create new branches, relay, all failed because of timeout 
>> and/or busy, I get back in failure route with the 301?
>
> yes.
>
>>
>> I cannot drop all replies because maybe the reply I want to be sent 
>> back to caller is from a previous branch. Think at:
>>
>> A calls B
>> B phone gives busy
>> B has redirect to C in such case
>> C phone gives timeout
>> C has now redirect to voice mail
>> Voice mail returns server failure
>>
>> If I need to drop the replies then I will send the 500 reply which is 
>> wrong. If I do no drop replies, then it is hard to implement the 
>> proper logic for different kinds of redirects:
>> - no answer
>> - busy
>
> Yes, the above case is quite complicated, by default I think the 408 
> will be sent back because it is the lowest response code.
>
> The priority list is: 6xx > 3xx > 4xx > 5xx.
> The lowest response wins within the class but 401, 407, 415, 420, 484 
> are preferred over other 4xx responses.
also 487 (request canceled) has the highest priority.


>
> If this is an issue then we can implement more sophisticated drop 
> commands that drop only selected branches, for example a single branch 
> that is being processed in failure route.

It just looks a bit unpredictable right now, mainly with what happens in 
failure route because the reply code presented there is not what is 
expected. So I would add a parameter:

t_drop_replies("all");
t_drop_replies("last");

It is not hard to implement at all. In SR is a flag to mark the start of 
last set of branches -- so getting the first branch in the last step 
would be:

    for(first_branch=t->nr_of_outgoings-1; first_branch>=0; first_branch--)
        if(t->uac[first_branch].flags&TM_UAC_FLAG_FB)
            break;

But I would do it opposite, to have script simpler (and be K compatible 
and have uac_redirect and other k modules work as expected :-) ), 
instead of drop function, have drop by default the replies from last set 
of branches, and then t_keep_replies() so one ca decide to keep the 
replies. Probably can be switched one way or another (K or S) but config 
compatibility mode.

Cheers,
Daniel

>
> Miklos
>
>>
>> Cheers,
>> Daniel
>>
>>>
>>> Try to add t_drop_replies() to the failure route block when the 401 
>>> is processed. This function drops all the existing replies, 401 in 
>>> your case, hence 401 will not be selected again when 480 is received.
>>

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/