On Feb 27, 2007 at 23:33, Bogdan Pintea pintea@iptego.de wrote:
Andrei Pelinescu-Onciul wrote:
On Feb 26, 2007 at 17:45, Martin Hoffmann hn@nvnc.de wrote:
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).
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.
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