Hi Andres,
The simplest solution is to register all the time a failure route for
INVITES (as you do now) and from the failure route before doing fork
(proxying to the other server) check the reply code and skip the one
like busy :
t_on_failure[x] {
if ( !t_check_status("486|408") ) {
append("xxxxx");
t_relay();
}
}
in this example you will do forking to the other server only if the
reply status from the first INVITE is different than 486 or 408;
t_check_status takes as argument a regular expression
Regards,
Bogdan
Andres wrote:
Hi,
We have a setup where there is a main SER server and an alternate SER
server. They both replicate all registrations to each other. We are
using the "t_on_failure" directive to send INVITES to the other server
when it fails the first attempt (this may happen because there was a
failure on the replication or because the called user is behind a
"restricted cone" or "port restricted cone" NAT and he had
registered
on the other server--- we use STUN BTW).
In any case, this setup works relatively well, but we would like to
fine tune it a bit. In the case where the called user is BUSY. We
would like to implement some logic in ser.cfg so that "t_on_failure"
does not spit the INVITE again to the alternate server. Something like:
if (user is busy) then send STATUS 486 to caller,
else if (some other failure) then send INVITE to alternate server
Is this possible?
Our problem is that we are getting an increasing number of complaints
from users saying they just hear "dead air" on their phone for a long
time. Ethereal traces show that this happens because the first
INVITE gets a STATUS 486 (user is busy) so the SER server sends the
INVITE again to the alternate. But the alternate cannot reach the end
user because he is behind a "resticted cone" NAT and that user is
registered on the main server, hence the "fr_timer" kicks in and the
caller just hears "dead air" for a while, until finaly he gets a 408 -
Request Timeout.
Thanks.