10 Oct
2008
10 Oct
'08
4:16 a.m.
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?