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