[sr-dev] recursive calls to failure_route strange behavior

[Daniel-Constantin Mierla]

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?

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

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/