28 Feb
2007
28 Feb
'07
7:59 p.m.
On Feb 27, 2007 at 23:33, Bogdan Pintea <pintea(a)iptego.de> wrote:
Andrei Pelinescu-Onciul wrote:
Good point. I guess the choice is between a potential CANCEL DOS and
more reliability in sending CANCELs.
You could workaround the potential CANCEL DOS using ratelimit, pike or
something similar.
The big problems that statefull CANCELs solve are:
- it's not so uncommon to have an INVITE quickly followed by a CANCEL
and the INVITE processing delayed due to auth/db lookups/a.s.o. In
this case the CANCEL could reach tm before the INVITE. If you would
drop or forward the CANCEL statlessly, you won't be able to match it
to the INVITE and so you'll have an INVITE after CANCEL (and the phone
will ring). If you forward the CANCEL statefully in the worst case
you'll get an error reply from the destination (no transaction), but
when tm gets to the INVITE it can see that's already canceled and stop
its processing (if the delay is no longer then wt_timer - 5 s by
default).
- if you missed the INVITE (e.g. restart, failover to another server,
INVITE silently terminated) it's important to forward the CANCEL
exactly in the same way as the INVITE. If we would forward it
statelessly you won't have any failure routes for it so it won't be
forwarded in the same way as an INVITE that (for example) could be
forwarded on timeout to some other host (in the failure route). Same
goes for dns (e.g. foo resolves to several ips and the first ips
returns 503 => the INVITE will be forwarded to the next one, but if you
forward the CANCEL statelessly it will go only to the first ip).
OTOH if it makes everybody happy I will make CANCEL handling a tm
option (with the current behaviour as default) so that everyone can
choose between: forward statefully (and solve also the CANCEL arrived in
tm before the INVITE), forward statelessly (RFC) or drop (for Martin :-)).
Andrei
On Feb 26, 2007 at 17:45, Martin Hoffmann
<hn(a)nvnc.de> wrote:
But isn't there a potential for DOS? Since CANCELs can only be accepted
(no auth*), sending CANCELs to nowhere (from anonymous.invalid :) )
seems the easiest solution to eat fast the shm. Which makes it all the more apparent that
t_relay() should never relay a
CANCEL. Ever. It should return with an error and I then can decide
whether I have a stateless proxy or not to statelessly forward the
CANCEL or just error it away.
I think it should relay the CANCEL and if an INVITE comes and the CANCEL
transaction is still alive, it should reply w/ 487 (Ottendorf does
this).