Jeroen van Bemmel wrote:
Frank,
RFC3261 specifically specifies that proxies should convert response code 503 into 500:
A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one for the Request- URI in the request which generated the 503. If the only response that was received is a 503, the proxy SHOULD generate a 500 response and forward that upstream.
So SER is behaving in accordance with the standard. There might be a configuration option to turn this off?
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.
(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.)
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.
We have found that many SIP providers simply blindly lob all calls at the cheapest carrier and if a given call bounces, repeat that action with the next-cheapest carrier, and the next until they finally resort to a Tandem that will take anything, but will also be the most expensive way to route the call. Nearly all require us to send them back a 503 (a few want us to send 502 back instead) to say back to them "not via here, try next door". Deplorable and this method certainly causes slow call set-up times, but that is what quite a few of these outfits are doing.
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? If so, where is this piece of source code, so that I may break this well-intended but undesired behavior?