20 Nov
2009
20 Nov
'09
6:21 p.m.
Hi,
On 11/20/2009 04:57 PM, Michal Matyska wrote:
Daniel-Constantin Mierla píše v Pá 20. 11. 2009 v
16:53 +0100:
yes, you can solve it this way.
Back to Daniel's example, if I was the caller then I would like to
receive the 486 back so that I know that the callee is busy and I should
retry the call later. This means that the 408 should be dropped, but
only if there was already a branch replied with 486. Or the 408 should
be given some preference from failure route. Neither of them is
implemented as far as I know.
On the other hand, the script can get really complicated because of
these checks and drops.
Miklos
On 20.11.2009 16:38 Uhr, Daniel-Constantin Mierla
wrote:
If I understand correctly, then whenever you start above mentioned "new
set of branches" just call t_drop_replies() and you are done.
On 20.11.2009 9:53 Uhr, Miklos Tirpak wrote:
... 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. 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.
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.