29 jan 2010 kl. 17.20 skrev Kristian Kielhofner:
> On Fri, Jan 29, 2010 at 10:31 AM, Kevin P. Fleming <kpflem...@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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
