[Serusers] Selective t_on_failure ?

Bogdan-Andrei IANCU iancu at fokus.fraunhofer.de
Thu Jan 29 10:26:39 CET 2004


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.
>





More information about the sr-users mailing list