[sr-dev] recursive calls to failure_route strange behavior
Miklos Tirpak
miklos at iptel.org
Fri Nov 20 17:21:00 CET 2009
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:
>> 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.
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
>
> 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.
More information about the sr-dev
mailing list