[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:10:57 CET 2008


Iñaki Baz Castillo wrote:
> El Lunes, 27 de Octubre de 2008, Dan Pascu escribió:
> 
>> So are you saying that we should base the selection logic in the proxy on
>> the assumption that devices are well behaved and won't send a 6xx? What
>> if a proxy sends a 6xx because a clueless admin wrote a script where he
>> used 6xx because he thought they are better? Will you contact all the
>> proxies/devices/gateways out there and ask them nicely to fix their
>> behavior because your proxy cannot work properly? Don't you see someone's
>> ability to cause DOS using this?
> 
> Dan, I'm completely anti-6xx responses, in fact you can read this thread from 
> me in sip-implementors:
>   
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-June/019413.html
> 
> In fact, the only I don't like in my prefer softphone (Twinkle) is the fact 
> that it uses 603 to decline a call instead of 480/486.

If I have a phone in the bed room and in the living room, and I want to 
reject a call, a 603 is IMO very useful.

regards
klaus

> 
> But note that OpenSers/OpenSIPS/Kamailio already has an option in "tm" module 
> to dissable 6XX behaviour (don't break parallel/serial forking):
>   disable_6xx_block == 1
> (in fact I patched my OpenSer in production with that option 1 minute after it 
> was submitted XD).
> 
> I just say that being RFC3261 puristic means allowing 6XX painful behaviour. 
> And if the proxy administrator wants that behaviour then a 6XX response wins 
> over [345]XX.
> 
> In conclusion, we have already a way to dissable 6XX "feature" as a "tm" 
> option, so we don't need to change it in the official proxy behaviour.
> 
> Regards.
> 




More information about the Users mailing list