Hi!
I have a problem with my failure route. In the failure route, I send the call to voicemail, except the call is CANCELED by the caller:
failure_route[1] { if(t_check_status("487")) { xlog("L_INFO","caller cancelled call, no voicemail needed...\n"); exit; } route(4); # route to voicemail }
The problem is, when a call is forked and one of the destinations is busy or has any other reasons to not accept the call.
/-------- <-486 phone1 / caller ----------------- <-488 phone2 \ -------- <-487 phone3
In the above case, phone1 and 2 immedately response with an error message. Then several seconds later, the caller hangs up and now phone3 sends 487.
If I now check the status in the failure route it will be 486 (the lowest one). Also any other algorithm (the highest one, the first one, the last one) would be ambiguous. Thus, deciding if the call will be sent to voicemail or not is not possible using t_check_status.
AFAIK there is no other method to check the status of the transaction in the failure route. IMO this is an issue which should be solved.
I suggest setting the status explicitly to "487" if the transaction was cancelled by the caller, independent of the resonse status received from the phones.
regards klaus
Hi Klaus,
maybe adding to t_check_status() a second parameter to tell the check scheme: UAS reply code (code to be fwd to UAC, the min one) UAC reply code (branch codes) - last received; - any of them
comments?
regards, bogdan
Klaus Darilion wrote:
Hi!
I have a problem with my failure route. In the failure route, I send the call to voicemail, except the call is CANCELED by the caller:
failure_route[1] { if(t_check_status("487")) { xlog("L_INFO","caller cancelled call, no voicemail needed...\n"); exit; } route(4); # route to voicemail }
The problem is, when a call is forked and one of the destinations is busy or has any other reasons to not accept the call.
/-------- <-486 phone1 /caller ----------------- <-488 phone2 \ -------- <-487 phone3
In the above case, phone1 and 2 immedately response with an error message. Then several seconds later, the caller hangs up and now phone3 sends 487.
If I now check the status in the failure route it will be 486 (the lowest one). Also any other algorithm (the highest one, the first one, the last one) would be ambiguous. Thus, deciding if the call will be sent to voicemail or not is not possible using t_check_status.
AFAIK there is no other method to check the status of the transaction in the failure route. IMO this is an issue which should be solved.
I suggest setting the status explicitly to "487" if the transaction was cancelled by the caller, independent of the resonse status received from the phones.
regards klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Bogdan!
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.
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.
regards klaus
Bogdan-Andrei Iancu wrote:
Hi Klaus,
maybe adding to t_check_status() a second parameter to tell the check scheme: UAS reply code (code to be fwd to UAC, the min one) UAC reply code (branch codes) - last received; - any of them
comments?
regards, bogdan
Klaus Darilion wrote:
Hi!
I have a problem with my failure route. In the failure route, I send the call to voicemail, except the call is CANCELED by the caller:
failure_route[1] { if(t_check_status("487")) { xlog("L_INFO","caller cancelled call, no voicemail needed...\n"); exit; } route(4); # route to voicemail }
The problem is, when a call is forked and one of the destinations is busy or has any other reasons to not accept the call.
/-------- <-486 phone1 /caller ----------------- <-488 phone2 \ -------- <-487 phone3
In the above case, phone1 and 2 immedately response with an error message. Then several seconds later, the caller hangs up and now phone3 sends 487.
If I now check the status in the failure route it will be 486 (the lowest one). Also any other algorithm (the highest one, the first one, the last one) would be ambiguous. Thus, deciding if the call will be sent to voicemail or not is not possible using t_check_status.
AFAIK there is no other method to check the status of the transaction in the failure route. IMO this is an issue which should be solved.
I suggest setting the status explicitly to "487" if the transaction was cancelled by the caller, independent of the resonse status received from the phones.
regards klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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; };
which makes 487 a no-op and i don't have experienced any problems with it.
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.
-- juha
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
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
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
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:
- 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
Klaus Darilion writes:
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 :-(
perhaps this could be solved by changing the "winning" algorithm so that in failure route "478" always wins.
i need to check what rfc3261 says about this.
-- juha
Juha Heinanen writes:
perhaps this could be solved by changing the "winning" algorithm so that in failure route "478" always wins.
i need to check what rfc3261 says about this.
here is what i found:
16.7 Response Processing
6. Choosing the best response
...
Otherwise, the proxy MUST forward a response from the responses stored in the response context. It MUST choose from the 6xx class responses if any exist in the context. If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. The proxy MAY select any response within that chosen class. The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen.
so it would be perfectly ok to select 487 over 486 and looks like it would solve the problem.
- juha
-
Bogdan-Andrei Iancu -
Juha Heinanen -
Klaus Darilion