SIP 404 Not Found vs 603 Decline
I offer a feature to our customers that allows them to configure their DID to respond with "This number is disconnected" message for specific, annoying callers, based on their CallerID. Some customers send a Busy signal (486 BUSY) for these annoying callers. It seems that some Robocallers will retry numbers that ring busy repeatedly, sometimes annoyingly aggressively. I'm switching the default to declining the call, which brings me to which SIP response is correct and/or ideal.
From the RFC: https://www.ietf.org/rfc/rfc3261.txt
Section 21.4.5 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. Section 21.6.2 603 Decline The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request. We are currently sending a 603 Decline, which seems appropriate given the nature. However we also get calls to numbers we service which are not active, in which case 404 Not Found seems more appropriate. What is the real-world behavior of the calling party for these responses? If I change the cause code, will there be unintended consequences? Any suggestions or experience is appreciated. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Our experience has been that it is difficult to predict this, due to the way in which 6xx cause codes have been misused throughout the supply chain. As RFC 3261 states, 603 Declined is for those cases in which the UAS has authoritative knowledge that the destination cannot be reached in principle, including by any other means. Proxies are not supposed to serially fork beyond a gateway returning this class of error, and UAs aren't supposed to attempt a new call leg to that destination either. Practically, ?603 Declined is a popular catch-all epithet for "cannot complete the call", much as 503 Service Unavailable, and route-advancing upon receipt of such is, accordingly, more the norm than not. This means that it is subject to as much unpredictable adaptation to ISUP / ISDN as anything else.? So, it's impossible to say exactly what the PSTN caller's experience will be with any certainty. -- Alex?Balashov?|?Principal?|?Evariste?Systems?LLC 303?Perimeter?Center?North,?Suite?300 Atlanta,?GA?30346 United?States Tel:?+1-800-250-5920?(toll-free)?/?+1-678-954-0671 (direct) Web:?http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent?from?my?BlackBerry.
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 *per vendor/route* if there is no pre-session media. 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. Regards, *Calvin Ellison* Voice Services Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com <http://www.voxox.com/> * 9276 Scranton Rd, Suite 200 San Diego, CA 92121 [image: Voxox] On Tue, Jun 2, 2015 at 1:58 PM, Peter Beckman <beckman at angryox.com> wrote:
I offer a feature to our customers that allows them to configure their DID to respond with "This number is disconnected" message for specific, annoying callers, based on their CallerID.
Some customers send a Busy signal (486 BUSY) for these annoying callers. It seems that some Robocallers will retry numbers that ring busy repeatedly, sometimes annoyingly aggressively.
I'm switching the default to declining the call, which brings me to which SIP response is correct and/or ideal.
From the RFC: https://www.ietf.org/rfc/rfc3261.txt
Section 21.4.5 404 Not Found
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
Section 21.6.2 603 Decline
The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request.
We are currently sending a 603 Decline, which seems appropriate given the nature.
However we also get calls to numbers we service which are not active, in which case 404 Not Found seems more appropriate.
What is the real-world behavior of the calling party for these responses? If I change the cause code, will there be unintended consequences?
Any suggestions or experience is appreciated.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 6/2/15 1:58 PM, Peter Beckman wrote:
I offer a feature to our customers that allows them to configure their DID to respond with "This number is disconnected" message for specific, annoying callers, based on their CallerID.
Some customers send a Busy signal (486 BUSY) for these annoying callers. It seems that some Robocallers will retry numbers that ring busy repeatedly, sometimes annoyingly aggressively.
I'm switching the default to declining the call, which brings me to which SIP response is correct and/or ideal.
486 Busy has the advantage that it usually won't route-advance, ending the churn on the network for that call. Letting the abusers churn and waste their resources retrying forever may not be a bad thing. 200 OK followed by a "Go away" intercept recording[1] would be another option. Let the call supervise and cost the abusers a fraction of a cent without bothering any humans on the receiving end. You don't want to do this if the endpoint is a tollfree number, obviously. [1] Asterisk's "Our phone system has been eaten by monkeys" might be a good choice. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
I would play a 183 message saying "The subscriber you have dialed has selective call reject enabled." Then send a 487 Request Terminated. That way you don't have to answer the call and still get the message across. I thought Verizon had a test case for this in interop. I'm not sure if 487s get thrown back into the redial queue usually or if most LCRs fail over on it. I would rather send a 603 or 604 back, but I know LCRs typically route advance on 500 and 600 level responses. On Wed, Jun 3, 2015 at 9:44 AM, Jay Hennigan <jay at west.net> wrote:
On 6/2/15 1:58 PM, Peter Beckman wrote:
I offer a feature to our customers that allows them to configure their DID to respond with "This number is disconnected" message for specific, annoying callers, based on their CallerID.
Some customers send a Busy signal (486 BUSY) for these annoying callers. It seems that some Robocallers will retry numbers that ring busy repeatedly, sometimes annoyingly aggressively.
I'm switching the default to declining the call, which brings me to which SIP response is correct and/or ideal.
486 Busy has the advantage that it usually won't route-advance, ending the churn on the network for that call. Letting the abusers churn and waste their resources retrying forever may not be a bad thing.
200 OK followed by a "Go away" intercept recording[1] would be another option. Let the call supervise and cost the abusers a fraction of a cent without bothering any humans on the receiving end.
You don't want to do this if the endpoint is a tollfree number, obviously.
[1] Asterisk's "Our phone system has been eaten by monkeys" might be a good choice.
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
487 is normally expected only for scenarios in which the INVITE transaction has been terminated due to a CANCEL'd branch. 3261 says: The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself. So, it's not an appropriate final negative response to send when not commanded by a CANCEL. I recommend 503 Service Unavailable. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
participants (5)
-
abalashov＠evaristesys.com -
beckman＠angryox.com -
calvin.ellison＠voxox.com -
jared＠compuwizz.net -
jay＠west.net