[SR-Users] t_branch_timeout()

Daniel-Constantin Mierla miconda at gmail.com
Tue Nov 20 21:23:34 CET 2012


On 11/19/12 5:46 PM, Alex Balashov wrote:
> I don't have an explicit value set, and did not know about this 
> parameter.  So, I suppose it defaults to 0.
>
> What should I set it to to get the correct reply from every failed 
> branch in failure_route?

IIRC, the default value is the one closer to RFC interpretation, but 
that is quite broken from the point of view of serial forking logic. It 
got there with the new tm module from 3.0.

Look at default kamailio.cfg, it should have the value for what kamailio 
used to have all these years.

Cheers,
Daniel

>
> On 11/19/2012 04:13 AM, Daniel-Constantin Mierla wrote:
>
>> Hello,
>>
>> what value you have for failure_reply_mode parameter of tm?
>>
>> Cheers,
>> Daniel
>>
>> On 11/14/12 3:12 PM, Alex Balashov wrote:
>>> I am using the latest pull of branch 3.3, and t_branch_timeout()
>>> doesn't work if the previous branch resulted in a reply (i.e. a
>>> negative final reply).
>>>
>>> That is to say, t_branch_timeout() == FALSE on a genuine timeout, as
>>> long as the preceding branch provided a result (such as 404).
>>>
>>> t_branch_timeout() == TRUE if this is a timeout, on the first branch.
>>>
>>> In other words, it appears that if t_any_replied() == TRUE, then
>>> t_branch_timeout() == FALSE, even for this branch, and even if the
>>> branch really did time out (no response at all from destination).
>>>
>>> That's not how the documentation says it should behave.  Am I doing
>>> something wrong?  If so, how do I find out if _this particular_ branch
>>> timed out, from the failure_route[]?
>>>
>>
>> -- 
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>>
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda




More information about the sr-users mailing list