[OpenSIPS-Users] [OpenSIPS-Devel] Why the best response is 408 instead of 486 when parallel forking?
Victor Pascual Ávila
victor.pascual.avila at gmail.com
Mon Oct 27 19:18:07 CET 2008
On Mon, Oct 27, 2008 at 6:55 PM, Iñaki Baz Castillo <ibc at aliax.net> wrote:
> 2008/10/27 Dan Pascu <dan at ag-projects.com>:
>> On Monday 27 October 2008, Iñaki Baz Castillo wrote:
>>> 2008/10/27 Dan Pascu <dan at ag-projects.com>:
>>> > I don't know about all internally generated replies, but I know that
>>> > if a reply came from an end user device, it doesn't make much sense
>>> > to pick an internally generated 408 Timeout on a dead branch.
>>> >
>>> > Maybe doing a custom selection, instead of the "lower reply code
>>> > wins", would avoid the need to consider internal and external replies
>>> > in a different way.
>>>
>>> That is why I suggested:
>>>
>>> - 2XX (inmediate)
>>> - 6XX (except if disable_6xx_block == 1)
>>
>> I do not think that 6xx should be considered before 4xx or 3xx. 6xx means
>> global response and if you get a 4xx and a 6xx at the same time, it is
>> obvious that a device took a global decision that another device doesn't
>> agree upon. 6xx should only be sent when a device knows _for sure_ that
>> no other device can answer a call and it can give a final answer in the
>> name of all devices (which is practically almost never when you have
>> parallel forking).
>
> If a 6xx is sent (for any reason) it should "win", so a 6xx should be
> chosen over any other negative reply.
> If both a 6XX and 4XX are received from two locations, 6XX must be the
> winner, I don't understand why you say "no" here.
> Well, 6xx are painful when are wrongly used, but for that we have an
> option in TM module to treat a 6xx as a 4xx.
I agree-- 6xx class responses must be chosen as the "best" final
response. If one desires to break the standard behavior (maybe because
the 6xx class responses are improperly used) it should be allowed
(this is actually an option in TM).
http://tools.ietf.org/html/draft-worley-6xx-considered-harmful-00
--
Victor Pascual Ávila
More information about the Users
mailing list