[sr-dev] recursive calls to failure_route strange behavior

[Michal Matyska]

Daniel-Constantin Mierla píše v Pá 20. 11. 2009 v 16:53 +0100:
> 
> On 20.11.2009 16:38 Uhr, 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?
> >
> > 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.
> 
> ... actually, while it might be questionable whether to select the reply 
> to be sent back to caller from last serial forking set of branches or 
> from entire set of branches, triggering failure route should be with a 
> reply from last set of branches, otherwise you cannot take the right 
> decision for new branches.

If I understand correctly, then whenever you start above mentioned "new
set of branches" just call t_drop_replies() and you are done.

Michal

> 
> Cheers,
> Daniel
> 
> 
> > 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.
> >
>