24 Aug
2005
24 Aug
'05
11:11 a.m.
Hi Juha!
Juha Heinanen wrote:
ACK. Maybe we could introduce a new function which allows to test if the
called canceled the call.
regards
klaus
Klaus Darilion writes:
This is also what I do at the moment.
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;
}; 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.