[Users] failure route problem

[Bogdan-Andrei Iancu]

Hi Klaus,

I just committed a new function on TM module which allows you to check 
if an INVITE was explicitly cancelled by the UAC via a CANCEL request. See:
    http://www.openser.org/docs/modules/0.10.x/tm.html#AEN482

regards,
bogdan

Klaus Darilion wrote:

> 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
>>>
>>
>>
>
>