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

[Martin Hoffmann]

Frank Durda IV wrote:
> 
> Well, yes and no.  Thanks for pointing out this item in the RFC which
> I missed, but if the RFC action is honored, then SER should have
> emitted "500 Server Internal Error" which is in the RFC, and
> not the hybrid and made-up "500 Service Unavailable", which is
> not in the RFC.  So, I think SER is wrong at least on that point.

Reason phrases are not writ in stone. You are free and even encouraged
to replace the default phrases with more meaningful text if you have
one.

> (Personally I think SIP desperately needs at least 20 additional
> defined Response Codes so we can all quit using the existing
> not-entirely-inappropriate values to cover real-life situations,
> but right now the book says that's all the codes that we've all
> got to work with.   When you see a dozen SS7 release codes all
> map to the same SIP Response Codes, you don't have nearly enough
> SIP Response Codes, but I digress.)

Feel free to write a draft and enjoy your time at IETF. Personally, I
think there is more then enough status codes. Already people just seem
to pick one without actually reading up on what it is supposed to mean.
Like using 488 when an anonymous call is rejected.

If you desperately need to send around SS7 release codes, there is
the Reason header. 

> That said, our SER server knows the given condition sent from
> a paired PSTN switch is permanent, eg the SIP caller can't
> call this number via our network now, tomorrow or next week
> because of who you they or whom their provider is (or what
> they failed to buy), so in this situation returning 503 all
> the way out of our network is correct behavior (as stated in
> the RFC), and doing so allows the upstream entity to click
> over to the next preferred carrier that might reach that
> destination.

I think it isn't. Neither 500 nor 503 is a status code for a permanent
situation. The gateway should return a 4xx class code instead because
actually this is a client error -- the client is not allowed to call
this specific number. Sounds like a 403 to me.

> So, our SER must send them back a 503 and not a 500 in this
> situation.  If I explicitly state one in a reply rule, will that
> override this default behavior, or will some deeper part of SER
> veto even a sl_reply("503", "Service Unavailable"); added to the
> onreply_route?

That'll break horribly. Once you successfully called t_relay(), you
can't use sl_* anymore.

There is t_reply() with the same parameters. I am not sure, though, if
it really works, but you could give it a try.

Regards,
Martin