[Serusers] How can I keep SER from changing reply Response Code from 503 to 500?

Frank Durda IV frank.durda at hypercube-llc.com
Tue Oct 21 05:03:57 CEST 2008


Andrei Pelinescu-Onciul wrote:
> If you want to override the final reply sent by ser, you have to catch
> it in the failure route and send a new reply in its place (if you send a
> reply " by hand" in the failure route, its value won't be fixed by ser
> final reply processing code) e.g.:
>
>
> failure_route[0]{
> if (t_check_status("503")){
> t_reply("503", "Keeping 503 because I don't like the rfc");
> return;
> }
> /* ... */
> }
>
> There are other ways to do it, but I think this is the shortest one.
>
>
> Andrei

This suggestion does appear to override the reply and that's great.
I found that I have to do a t_on_failure("FAILURE_ROUTE")
on all INVITEs, not just those where the @to.tag==""
(as written in the sample ser.cfg file).

However, this alteration triggers another problem, as the
logs report:

Oct 21 02:37:47 ser1 ser[19225]: WARNING: -_set_fr_timer- already added: 
0x80252
7400 , tl=0x802527418!!!
Oct 21 02:37:47 ser1 ser[19225]: BUG: set_final_timer: start retr failed 
for 0x8
02527400

Neither of these appear to be things I have intentionally
specified/set in ser.cfg, although perhaps they go by other
names.   Anybody have any idea what it is complaining about?


The pieces that might help troubleshoot this:

route[PSTN_FORWARD]
{
log(1, "Route PSTN_FORWARD\n");
#       here you could decide wether this call needs a RTP relay or not

#       Set where packets should be sent.  If you don't do this here,
#       OPTIONS and other messages will be transmitted back to the
#       outside interface and processed all over again, and you eventually
#       get a Too Many Hops error on every OPTIONS message.
#       Code to make this point in multiple directions would be needed
#       to implement two-way origination.

        rewritehost("10.131.0.2");      #Send to Telica

xlog("L_ERR", "DDD method:<%rm>   From URI:<%fu> From Tag:<%ft> 
Destination Set:<%ds>  Request's R-URI:<%ru> To URI:<%tu>  Received 
IP:<%Ri> Source IP:<%si> Sou
rce Port:<%sp> Call ID:<%ci>  Host's Hostname:<%Hn>  Hosts 
Domainname:<%Hd>  Hosts FQDN <%Hf>  Hosts IP <%Hi>");

        if (method == "BYE" || method == "CANCEL") {
                unforce_rtp_proxy();
        }
        else if (method == "INVITE") {

...Customer-specific sanity checks here, pass or reject, no modifications...

#       Force record routing if either party is behind NAT

                $record_route_nated = true;

                force_rtp_proxy("he","10.131.128.18");

        }

        t_on_reply("PSTN_REPLY");

#       if this is called from the failure route we need to open a new 
branch

        if (isflagset(FLAG_FAILUREROUTE)) {
                append_branch();
        }

#       if this is an initial INVITE (without a To-tag) we might try another
#       (forwarding or voicemail) target after receiving an error

#Use_next_for_503_fixup#       if (method=="INVITE" && @to.tag=="") {
        if (method=="INVITE") {
                xlog("L_ERR", "route[PSTN] arm FAILURE_ROUTE");
                t_on_failure("FAILURE_ROUTE");
        }

#       send it out now; use stateful forwarding as it works reliably
#       even for UDP2TCP

        if (!t_relay()) {
                sl_reply_error();
        }
        drop;
}

onreply_route["PSTN_REPLY"]
{
        xlog("L_ERR","In onreply_route %rs %rr");

#xlog("L_ERR", "EEE method:<%rm>   From URI:<%fu> From Tag:<%ft> 
Destination Set:<%ds>  Request's R-URI:<%ru> To URI:<%tu>  Received 
IP:<%Ri> Source IP:<%si> So
urce Port:<%sp> Call ID:<%ci>  Host's Hostname:<%Hn>  Hosts 
Domainname:<%Hd>  Hosts FQDN <%Hf>  Hosts IP <%Hi>");

#       Rewrite Contact in 200 OK if UAS is behind NAT

        if (@cseq.method == "INVITE") {
                xlog("L_ERR","onreply_route[NAT_MANGLE] R1 %rs %rr");
        } else {
                xlog("L_ERR","onreply_route[NAT_MANGLE] R2 %rs %rr");
        }

#       Apply RTP proxy if necessary, but only for INVITE transactions
#       and 183 or 2xx replies

        if (@cseq.method != "INVITE") return;

        if ((status =~ "(183)|2[0-9][0-9]") && 
search("^(Content-Type|c):.*application/sdp")) {
#               xlog("L_ERR","onreply_route[NAT_MANGLE] force rtp proxy 
%rs %rr K5");

#       Fix outbound c= value to reflect what client can reach

                route(OUTBOUND_RTP_FIXUP);
#               xlog("L_ERR","onreply_route[NAT_MANGLE] back from 
force_rtp_proxy %rs %rr K6");
        }
        return;
}




failure_route[FAILURE_ROUTE]
{
log(1, "Route ROUTE FAILURE\n");
        if (t_check_status("503")) {
                t_reply("503", "Keeping 503 because I don't like the rfc");
                log(1, "DID 503 FIX\n");
                return;
        }
 
#       mark for the other routes that we are operating from here on from a
#       failure route
               
        setflag(FLAG_FAILUREROUTE);

       
#       if we received a busy and a busy target is set, forward it there
#       Note: again the forwarding target has to be a routeable URI
      
        if (t_check_status("486|600")) {
                if ($tu.fwd_busy_target) {
                        route(FORWARD);
                }
#       alternatively you could forward the request to SEMS/voicemail here
 
        } else if (t_check_status("408|480")) {

#       if we received no answer and the noanswer target is set,
#       forward it there
#       Note: again the target has to be a routeable URI

                if ($tu.fwd_noanswer_target) {
                        route(FORWARD);
                }

#       alternatively you could forward the request to SEMS/voicemail here

        }
}

Debugging log messages:

Oct 21 02:37:47 ser1 ser[19224]: Route PSTN_FORWARD
Oct 21 02:37:47 ser1 ser[19224]: DDD method:<INVITE>   From 
URI:<sip:9999999999 at 11.22.33.44> From Tag:<as5e682242> Destination 
Set:<Contact: sip:6666666666 at 10.131.0.2>  Request's 
R-URI:<sip:6666666666 at 10.131.0.2> To 
URI:<sip:6666666666 at 222.222.222.222>  Received IP:<10.181.90.6> Source 
IP:<11.22.33.44> Source Port:<5060> Call 
ID:<5624efc06bde6e38543ebd53687a5b2b at 11.22.33.44>  Host's 
Hostname:<ser1>  Hosts Domainname:<the.test.box.notvalid>  Hosts FQDN 
<the.test.box.notvalid>  Hosts IP <>
Oct 21 02:37:47 ser1 ser[19224]: route[PSTN] arm FAILURE_ROUTE
Oct 21 02:37:47 ser1 ser[19225]: In onreply_route 100 Trying
Oct 21 02:37:47 ser1 ser[19225]: onreply_route[NAT_MANGLE] R1 100 Trying
Oct 21 02:37:47 ser1 ser[19225]: In onreply_route 503 Service Unavailable
Oct 21 02:37:47 ser1 ser[19225]: onreply_route[NAT_MANGLE] R1 503 
Service Unavailable
Oct 21 02:37:47 ser1 ser[19225]: Route ROUTE FAILURE
Oct 21 02:37:47 ser1 ser[19225]: DID 503 FIX
Oct 21 02:37:47 ser1 ser[19225]: WARNING: -_set_fr_timer- already added: 
0x802527400 , tl=0x802527418!!!
Oct 21 02:37:47 ser1 ser[19225]: BUG: set_final_timer: start retr failed 
for 0x802527400
Oct 21 02:37:47 ser1 ser[19224]: MAIN ROUTE WITH   method:<ACK>   From 
URI:<sip:9999999999 at 11.22.33.44> From Tag:<as5e682242> Destination 
Set:<<null>>  Request's R-URI:<sip:6666666666 at 222.222.222.222> To 
URI:<sip:6666666666 at 222.222.222.222>  Received IP:<10.181.90.6> Source 
IP:<11.22.33.44> Source Port:<5060> Call 
ID:<5624efc06bde6e38543ebd53687a5b2b at 11.22.33.44>  Host's 
Hostname:<ser1>  Hosts Domainname:<the.test.box.notvalid>  Hosts FQDN 
<the.test.box.notvalid>  Hosts IP <>
...

Thanks in advance for any sage advice on what is going on here.












More information about the sr-users mailing list