[VoiceOps] 503 usage
John S. Robinson
jsr at communichanic.com
Tue Dec 13 22:14:13 EST 2016
One of the issues with SIP in an ISUP world is that the SIP Status-Codes
are clumsy and inarticulate for real-world telephony.
Take a look at RFC 3398 Section 126.96.36.199
https://tools.ietf.org/html/rfc3398#section-188.8.131.52 There you will see
all sorts of things map to 404 and 503. Yes, there is a Reason header
which can return q.931 Cause Codes back to SIP, but most sip routing
equipment does not look that deep into a response when making the
Generally, I want "quality" providers to use 404 /only/ for ISDN Cause
1. For just about anything else /other than /Cause 17 I would want a
503, and then I can route advance.
Calvin E. wrote below about the difference between immediate 503 and 503
with only a few seconds ring time. IMNSHO, after any sort of alerting
indication (18x, with or without SDP) it is generally unforgivable to to
return anything /other than/ 200 OK after a Connected indication, unless
calling side sends a Cancel, in which case the call is Abandoned, and
the appropriate response is Request Terminated. In a real world
environment, under what conditions would "Service" suddenly be
"Unavailable" after the far end was allegedly Alerting? Microsoft
Lync (now Skype for Business) used to return premature "alerting"
indications to mask outrageous PDD in their systems. That had the
bizarre effect of causing strange things like "ring tone" (or audible
ring for your AT&T types) /followed by/ busy signal.
There is another potential gotcha' especially with some of the
bottom-tier service providers. In addition to frequency of 503
response from your providers, watch the /average /and /peak/ interval
from *100 TRYING* from a provider and 503 Service unavailable. I have
seen some providers take up to 20 seconds to decide that they just can't
handle a call. If a provider can't handle a call, it shouldn't take
very long for them to "figure that out."
My US$ 0.02.
John S. Robinson
Communichanic Consultants, Inc.
On 12/13/2016 20:34, Calvin E. wrote:
> 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 route advance.
> 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
> <mailto: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 <mailto:VoiceOps at voiceops.org>
> VoiceOps mailing list
> VoiceOps at voiceops.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the VoiceOps