23 Aug
2005
23 Aug
'05
11:37 a.m.
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
23 Aug
23 Aug
6:53 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
24 Aug
24 Aug
9:26 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
9:48 a.m.
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
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.
1:02 p.m.
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:
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.
1:50 p.m.
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:
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.
29 Aug
29 Aug
12:55 p.m.
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
24 Aug
24 Aug
3:37 p.m.
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
3:48 p.m.
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
7035
days inactive
7041
days old
9 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Juha Heinanen -
Klaus Darilion