[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