[VoiceOps] 503 usage
calvine at gmail.com
Tue Dec 13 21:34:29 EST 2016
In my experience, the answer is yes to both. It depends who or what you are
dealing with and the expectations for that particular service. Overall I'd
say if you have backup carriers, first route advance then decide if it's
worth your time to seek a remedy.
There's also a difference between immediate 503 and 503 with only a few
seconds ring time. The latter is usually ticket worthy since you wouldn't
typically route advance after a ring.
Here are some examples of what I've seen:
A small/medium enterprise product, like a SIP trunk or hosted PBX. There's
an expectation that calls to any valid number will connect or return busy,
so a 503 would be worthy of a trouble ticket to determine the cause. This
assumes the service provider can reliably send things like 404 Not Found
and 486 Busy Here when appropriate.
A wholesale conversational SIP trunk might 503 anything that isn't a 200 OK
to protect you from downstream carriers who return 404, 486, etc. when they
shouldn't, and to keep you from seeing things like "Insufficient Balance"
or "Payment Required" coming back from their LCR. You might open a ticket
if they are your carrier of choice and it's worth your time, otherwise
Short duration/dialer products are expected to produce a lot of 503, and a
handful of failed calls isn't going to impress anyone. If your overall ASR
through a particular carrier drops with no other explanation then it could
be ticket worthy.
On Tue, Dec 13, 2016 at 5:22 PM <slocoach at gmail.com> wrote:
> I tend to see a 503 as a symptom of a critical situation (per
> cpu/cps/license threshold breach). And I would consider 503 spikes a
> decent canary for a sip trunk coal mine. Others view 503s as business as
> usual, specifically in LCR arrangements, and don't alarm/study them
> What's the general idea behind industry best practice? E.g. 503 simply
> signifies another route should be taken, or 503 is cause for a remedy?
> Sent from my Windows 10 phone
> VoiceOps mailing list
> VoiceOps at voiceops.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the VoiceOps