[Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Andrei Pelinescu-Onciul andrei at iptel.org
Wed Feb 28 18:59:25 CET 2007


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



More information about the sr-users mailing list