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

[Andrei Pelinescu-Onciul]

On Oct 20, 2008 at 22:03, Frank Durda IV <frank.durda at hypercube-llc.com> wrote:
> 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?

Just ignore them, it's perfectly safe in this case (just some bug
catching code that outlived its usefulness :-)).
For a more detailed discussion see:
http://bugs.iptel.org/browse/SER-302.

I'll try to fix it if I can find an easy non-intrusive way.

Andrei

[...]