[Users] failure route problem

[Klaus Darilion]

I do not understand the whole scheme of codes and UAS codes, and local 
generated responses vs. received responses.

I think it should be simple like:
1. if CANCEL is received, mark the corresponding transaction as 
"canceled by caller"
2. allow to check if a transcation is "canceled by caller"

regards
klaus

Bogdan-Andrei Iancu wrote:
> Hi Klaus, Hi Juha,
> 
> I agree with Juha - failure route must catch all negative replies 
> disregarding its cause; also "487" is RFC compliant for cancelled 
> INVITEs, so we should stick to it.
> 
> secondly, I also see your problem and I agree that somehow, the admin 
> must have the possibility (via scripting) to deal with it.
> 
> I suggested a solution in a previous email (like t_check_status to be 
> able to check also the UAC codes and not only the UAS)... but no opinion 
> on this.....
> 
> regards,
> bogdan
> 
> 
> Klaus Darilion wrote:
> 
>> Hi Juha!
>>
>>
>> Juha Heinanen wrote:
>>
>>> Klaus Darilion writes:
>>>
>>>  > I wonder if there is any reason at all, why a failure route will 
>>> be  > executed in case of the caller cancels the call. Thus, another 
>>> option  > would be to remove execution of the failure route if the 
>>> caller cancels  > the call.
>>>
>>> i don't like these kind of exceptions.  a failure route will be
>>> definition be called if failure response is received.  i have in my
>>> failure route test
>>>
>>>     if (t_check_status("487")) {
>>>         return;
>>>     };
>>
>>
>>
>> This is also what I do at the moment.
>>
>>> which makes 487 a no-op and i don't have experienced any problems with
>>> it.
>>
>>
>>
>> imagine a parallel forked call: one phone is busy (486), the other 
>> phone is ringing.
>>
>> If the caller cancels the call, the status is 486, thus 
>> t_check_status("487") won't match and you send a canceled call to the 
>> voicebox :-(
>>
>>>  > If we still want to execute the failure route, having the call 
>>> canceled  > by the caller should be visible in a status variable, 
>>> which is  > explicitly set by the caller action, not by any reply 
>>> code from the  > clients. Imagine a broken client which sends 4xx 
>>> instead of 487 for any  > reason. If this is the last response, the 
>>> failure route again won't work  > if it checks for status 487.
>>>
>>> coping with all kinds of broken clients in the proxy makes life very
>>> complicated.
>>>
>>> whatever you decide to do make sure it is backwards compatible with
>>> current behavior, i.e., introduce a new module option or something.
>>> this is very dedicated stuff and i don't want to get into a position
>>> where i need to re-test my ser.cfg.
>>
>>
>>
>> ACK. Maybe we could introduce a new function which allows to test if 
>> the called canceled the call.
>>
>> regards
>> klaus
>>
> 
>