[sr-dev] recursive calls to failure_route strange behavior
miconda at gmail.com
Fri Nov 20 16:38:31 CET 2009
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
>> 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
> 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.
More information about the sr-dev