<div dir="ltr">In my experience, some systems will not route advance on a non-200 response if pre-session media exists, e.g. a 183 voice reject before 603 final response, but will route advance if there is no pre-session media. In this context, calling parties using least-cost routing with multiple vendors would be expected to produce one call attempt total if there is pre-session media, and one attempt <i>per vendor/route</i> if there is no pre-session media.<div><br></div><div>If you can spare the media bandwidth and channels to provide a brief voice reject, this may reduce the total number of attempts regardless of cause code.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Regards,<div><br></div><div><p style="font-family:helvetica,arial,sans-serif;font-size:12px;margin:0px;padding:0px 0px 20px;color:rgb(0,0,0)"><strong>Calvin Ellison</strong><br>Voice Services Engineer<br><a href="mailto:calvin.ellison@voxox.com" style="text-decoration:none;color:rgb(14,123,174)" target="_blank">calvin.ellison@voxox.com</a><br>+1 (213) 285-0555<br><br>-----------------------------------------------<br><strong><a href="http://www.voxox.com/" style="text-decoration:none;color:rgb(14,123,174)" target="_blank">voxox.com</a> </strong><br>9276 Scranton Rd, Suite 200<br>San Diego, CA 92121<br></p><img src="http://cdn.voxox.com/img/voxox-logo.png" alt="Voxox" style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:medium"><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jun 2, 2015 at 1:58 PM, Peter Beckman <span dir="ltr"><<a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I offer a feature to our customers that allows them to configure their DID<br>
to respond with "This number is disconnected" message for specific,<br>
annoying callers, based on their CallerID.<br>
<br>
Some customers send a Busy signal (486 BUSY) for these annoying callers. It<br>
seems that some Robocallers will retry numbers that ring busy repeatedly,<br>
sometimes annoyingly aggressively.<br>
<br>
I'm switching the default to declining the call, which brings me to which<br>
SIP response is correct and/or ideal.<br>
<br>
>From the RFC: <a href="https://www.ietf.org/rfc/rfc3261.txt" target="_blank">https://www.ietf.org/rfc/rfc3261.txt</a><br>
<br>
    Section 21.4.5 404 Not Found<br>
<br>
        The server has definitive information that the user does not<br>
        exist at the domain specified in the Request-URI.  This status<br>
        is also returned if the domain in the Request-URI does not match<br>
        any of the domains handled by the recipient of the request.<br>
<br>
    Section 21.6.2 603 Decline<br>
<br>
        The callee's machine was successfully contacted but the user<br>
        explicitly does not wish to or cannot participate.  The response<br>
        MAY indicate a better time to call in the Retry-After header field.<br>
        This status response is returned only if the client knows that no<br>
        other end point will answer the request.<br>
<br>
We are currently sending a 603 Decline, which seems appropriate given the<br>
nature.<br>
<br>
However we also get calls to numbers we service which are not active, in<br>
which case 404 Not Found seems more appropriate.<br>
<br>
What is the real-world behavior of the calling party for these responses?<br>
If I change the cause code, will there be unintended consequences?<br>
<br>
Any suggestions or experience is appreciated.<br>
<br>
Beckman<br>
---------------------------------------------------------------------------<br>
Peter Beckman                                                  Internet Guy<br>
<a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a>                                 <a href="http://www.angryox.com/" target="_blank">http://www.angryox.com/</a><br>
---------------------------------------------------------------------------<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote></div><br></div>