<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
One of the issues with SIP in an ISUP world is that the SIP
Status-Codes are clumsy and inarticulate for real-world telephony.
<br>
<br>
Take a look at RFC 3398 Section 7.2.4.1
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc3398#section-7.2.4.1">https://tools.ietf.org/html/rfc3398#section-7.2.4.1</a> 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. <br>
<br>
Generally, I want "quality" providers to use 404 <i>only</i> for
ISDN Cause 1. For just about anything else <i>other than </i>Cause
17 I would want a 503, and then I can route advance. <br>
<br>
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 <i>other than</i> 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) <i>followed
by</i> busy signal. <br>
<br>
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 <i>average </i>and <i>peak</i>
interval from <b><tt>100 TRYING</tt></b> 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." <br>
<br>
My US$ 0.02.<br>
<br>
John S. Robinson<br>
Communichanic Consultants, Inc.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 12/13/2016 20:34, Calvin E. wrote:<br>
</div>
<blockquote
cite="mid:CAC_jndp_xpfR7zGU+Yhnau0QWjca-tKhFyi1AORpKYYgVx+-1g@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>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.<br>
<div><br>
</div>
<div>Here are some examples of what I've seen:
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Dec 13, 2016 at 5:22 PM <<a
moz-do-not-send="true" href="mailto:slocoach@gmail.com">slocoach@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_msg" lang="EN-US">
<div class="m_7454500841729569732WordSection1 gmail_msg">
<p class="MsoNormal gmail_msg">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</p>
<p class="MsoNormal gmail_msg"> </p>
<p class="MsoNormal gmail_msg">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?</p>
<p class="MsoNormal gmail_msg"> </p>
<p class="MsoNormal gmail_msg">Sent from my Windows 10
phone</p>
<p class="MsoNormal gmail_msg"> </p>
</div>
</div>
_______________________________________________<br
class="gmail_msg">
VoiceOps mailing list<br class="gmail_msg">
<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org"
class="gmail_msg" target="_blank">VoiceOps@voiceops.org</a><br
class="gmail_msg">
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer" class="gmail_msg" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br
class="gmail_msg">
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<br>
</body>
</html>