[VoiceOps] 503 usage

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 7.2.4.1 
https://tools.ietf.org/html/rfc3398#section-7.2.4.1   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 
"what-to-do-next" decision.

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>
>     https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20161213/d8ee933d/attachment-0001.html>