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.