[VoiceOps] SIP 404 Not Found vs 603 Decline

Peter Beckman beckman at angryox.com
Tue Jun 2 16:58:40 EDT 2015


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/
---------------------------------------------------------------------------


More information about the VoiceOps mailing list