On Fri, Jan 29, 2010 at 10:31 AM, Kevin P. Fleming <[email protected]> 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)? -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com -- _____________________________________________________________________ -- 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
