13 Oct
2008
13 Oct
'08
11:05 a.m.
On Oct 12, 2008 at 12:18, Frank Durda IV <frank.durda(a)hypercube-llc.com> wrote:
[...]
> Meanwhile, back to the original problem I
have of making SER emit
> a 503 or having to dump SER: Someone else pointed out that
> sl_reply wasn't appropriate where I suggested I could used it,
> will try t_reply(). If that is still overridden by the SER
> internals as well (and I was really hoping someone here would
> save me time by saying if the internal rule could not be
> defeated via the config file but no one has come forward on
> that point), then I have no choice then to make another
> round of changes to the SER source code, or buy a turnkey
> box and throw SER away.
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