[VoiceOps] 503 usage
Peter E
peeip989 at gmail.com
Wed Dec 14 11:26:29 EST 2016
+1 on this response.
We watch our metrics closely so we can measure when something begins to move in the wrong direction. We ultimately had to stop paying attention to 503's because of their casual interpretation of the RFC's intention of 5xx responses. It seems like we need a new "Not Now I Have a Headache" response code. In the meantime, we route advance.
On Dec 14, 2016, at 00:17, Alex Balashov <abalashov at evaristesys.com> wrote:
On Tue, Dec 13, 2016 at 06:04:43PM -0800, Glenn Geller (VDOPh) wrote:
> We frequently encounter carriers that use the 503 for anything they cannot
> classify otherwise.
>
> So, generally, unless it is OUR system, we treat 503 as a "Progress to
> another route".
My $.02 is that there is no industry "best practice", as widespread use
of 503 is a "worst" (or "pessimal") practice.
As far as I can tell, 503 (and to a lesser extent, alarmingly, 603) has
got to be a catch-all epithet for any sort of call completion failure.
The short duration-orientated service providers are the worst offenders,
mostly because--as someone pointed out--they aim to obscure any and all
possible upstream vendors' failure cause codes with a blanket 503 in the
interest of secrecy. However, even relatively respectable members of the
food chain will send 503 rather generically in a variety of cases. I
would definitely treat it as a "advance to next route" cause. It is very
seldom that a 503 is caused by anything from which it can reasonably
follow that the destination cannot be reached through any other carrier,
and in any case, that's not what 503 is for.
As a Class 4/LCR software platform vendor, we've tried to behave
correctly and send nuanced SIP cause codes that speak as closely as
possible to the genuine nature of the failure, sticking to ISUP mappings
where possible and returning 503 only in cases where the call is not
processed for business reasons (e.g. unprofitable routes) or some other
miscellaneous reason. What we have found is that many customers balk at
this, though the short duration & call centre traffic constituencies'
protests have been especially howling. Apparently they deal with a lot
of customer call centre equipment that expects a 503 in almost all cases
and can't properly route-advance on most other codes.
So, at least to some extent, as this bad behaviour has crystallised into
established practice, the expectation on the endpoint side has also
evolved to expect opaque 503s in case of almost all kinds of failure.
Dumb, dumb, dumb. Alas, regressions to the stupidest possible common
denominator are common in the technology world.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
More information about the VoiceOps
mailing list