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