[asterisk-users] Use of "603 Declined"

Sat Jan 30 03:01:04 CST 2010

29 jan 2010 kl. 17.20 skrev Kristian Kielhofner:

> On Fri, Jan 29, 2010 at 10:31 AM, Kevin P. Fleming <kpfleming at digium.com> wrote:
>> 
>> Well, that's the problem, and it's the reason why 603 is so commonly
>> used. This is a situation where the current request has failed, but
>> there is no indication that repeating the request will also fail. 403
>> means that the request should not be repeated without either changing it
>> or authenticating as a different entity, which is a different scenario.
> 
>  This is true...  Authenticating as a different entity would/could
> potentially match other peers (causing a 407) and probably isn't
> technically correct.  However, if they didn't match an existing peer
> (to be challenged or not) using Asterisk's standard peer matching, how
> did they end up in the "nocrackers" context anyway?  Either way I
> wasn't considering 5xx responses because of Olle's request.
> 
>> It is very likely that there is no standard-defined 4xx code for 'cannot
>> process this call right now', only the 5xx and 6xx variants.
> 
>  Asterisk has certainly "bent" standards (which real world
> implementation hasn't) before.  It seems to me that the best reply is
> the one that's most likely to encourage "correct" behavior from the
> far end...  603 almost certainly doesn't do that.  In this scenario
> any forking proxy faced with a 603 coming from Asterisk has to break
> RFC compliance just to successfully complete the request on another
> host.  Nasty.
> 
>  Are we back to the next-most-generic SIP error, 503 (as originally
> suggested by Alex)?

503 is definitely more wrong than 603. The 603 is often used when a user presses the "red" button on a phone and denies the call.

After reading through the RFC and the complete list of defined responsed codes on IANA, I haven't found a good alternative. There's no code for "call terminated", which is what we want to say. We might have played early media, then terminate the call setup. 

There are two actions here:
- Find the code path and make sure we set a resonable hangup cause. We should have proper hangup causes set on hangups.
- Agree on a reasonable error code that doesn't hurt proxy forking and doesn't claim that our server has a problem - which can cause the server to be taken out of load balancing clusters.

IANA lists these for our menu:

Request Failure 4xx
    400 Bad Request
    401 Unauthorized
    402 Payment Required
    403 Forbidden
    404 Not Found
    405 Method Not Allowed
    406 Not Acceptable
    407 Proxy Authentication Required 
    408 Request Timeout
    410 Gone
    412 Conditional Request Failed            [RFC3903]
    413 Request Entity Too Large
    414 Request-URI Too Long
    415 Unsupported Media Type
    416 Unsupported URI Scheme
    417 Unknown Resource-Priority             [RFC4412]
    420 Bad Extension
    421 Extension Required
    422 Session Interval Too Small            [RFC4028]
    423 Interval Too Brief
    428 Use Identity Header                   [RFC4474]
    429 Provide Referrer Identity             [RFC3892]
    430 Flow Failed                           [RFC5626]
    433 Anonymity Disallowed                  [RFC5079]
    436 Bad Identity-Info                     [RFC4474]
    437 Unsupported Certificate               [RFC4474]
    438 Invalid Identity Header               [RFC4474]
    439 First Hop Lacks Outbound Support      [RFC5626]
    440 Max-Breadth Exceeded                  [RFC5393]
    470 Consent Needed                        [RFC5360]
    480 Temporarily Unavailable
    481 Call/Transaction Does Not Exist
    482 Loop Detected
    483 Too Many Hops
    484 Address Incomplete
    485 Ambiguous
    486 Busy Here
    487 Request Terminated
    488 Not Acceptable Here
    489 Bad Event                             [RFC3265]
    491 Request Pending 
    493 Undecipherable
    494 Security Agreement Required           [RFC3329]

Now, you have to read the deinitions in the RFCs to understand these, one can't just pick one where the english text sounds reasonable close to what we want to do, since there are logic in various servers that we will affect. 403 is too strong, the server will propably not contact us ever again.

Here's something interesting:

21.4.25 487 Request Terminated
The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL
request itself.

This is only used in combination with Cancel's, but in this case the call was cancelled by the dialplan, not by the caller. It's a misuse, but a bit clever one.

Now, I realize that we also need a setting to indicate whether Asterisk is authorative for a domain or not. If we're the only owners of a domain, we should generate 6xx class errors, if not, 4xx error. So this also applies to 486/600 busy 488/606 and 404/604. If we start separating 4xx and 6xx replies, we might as well do it right. So the domain configuration needs an option per domain whether we're just part of a cluster handling a domain or if we're THE domain handler.

/O