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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
