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