[Users] failure route problem

[Bogdan-Andrei Iancu]

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
>