Re: Why the best response is 408 instead of 486 when parallel forking?

Re: Why the best response is 408 instead of 486 when parallel forking?

Hi Inaki,

Iñaki Baz Castillo wrote:

> 2008/10/30 Bogdan-Andrei Iancu <[hidden email]>:
>
>
>> 2) priorities in reply selection (parallel forking) - based on the list
>> started by Iñaki:
>>
>> - 6XX (except if disable_6xx_block == 1)
>> - 3XX
>> - 401 / 407 (authentication)
>> - 415 (Unsupported Media Type)
>> - 420 (Bad Extension)
>> - 484 (Address Incomplete)
>> - 4XX
>> - 408
>> - 5XX
>>
>> 486,480 - should not have priority (according to RFC algorithm) as they do
>> not provide additional information that may trigger resending the request.
>>
>
> 480 is a bit confused since some phones use it for DND or call reject,
> but it could be also the response from a proxy where the user belongs
> but it's not registered.
> But 486 is always a reply for the final user (it could be replied by
> the proxy if the user has all him assigned concurrent lines in use,
> but 486 always means "user busy"). 486 is also used as DND or call
> reject in some phones but again is a final user response.
>
> So I would suggest that 486 is preferred over 480 since it could be
> more realistic (there is in fact a real user capable of receiving your
> call but he can't do it just now)

well, I think we go back to the same discussion about who is entitled to
say "user is not able to receive a call" - like the 6xx replies case.

Let's try a first version when the priority is strictly based on the
possibility (on the reply) to trigger some re-fresh of the call.