[OpenSIPS-Users] [OpenSIPS-Devel] Why the best response is 408 instead of 486 when parallel forking?

Klaus Darilion klaus.mailinglists at pernau.at
Mon Oct 27 22:08:19 CET 2008


Dan Pascu wrote:
> On Monday 27 October 2008, Iñaki Baz Castillo wrote:
>> 2008/10/27 Iñaki Baz Castillo <ibc at aliax.net>:
>>>> 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).
>> I understand what you say. You are talking about devices that decide
>> to reply a 6XX. An endpoint should never sent a 6XX (since it could
>> also break sequential forwarding to a voicemail server for example),
>> but the fact is that, in terms of RFC 3261, a 6XX must break parallel
>> and serial forking and must be chosen as winner reply.
> 
> It doesn't matter who sends the 6xx (device, proxy, gateway, ...). Once 
> you use parallel forking, 6xx should never be used IMO. 6xx means that 
> some device/proxy/gateway _knows_ that _no other device_ can answer the 
> call for whatever reason. Now if you used parallel forking and you also 
> receive a 4xx/3xx from another device, than it is obvious that the other 
> device didn't agree with the assumption the first device made. Which 
> means that the 6xx reply was a bad assumption. Even more, at some point 
> you cannot know if an upstream device did parallel forking or not. So 
> even if you are sure you do not do parallel forking and you can assume 
> you know there is a final global 6xx answer, you have no idea if that 
> won't clash with a 3xx/4xx somewhere upstream.

I wonder how there can be a clash (except in race conditions)? If one 
branch replies with 6xx, the other branches will be canceled (at least 
they should be cancelled).

regards
klaus



More information about the Users mailing list