[reSIProcate] TransactionState::processStateless() should not assert in stateful timer case

[John Gregg]

This is a change my company has seen fit to make to the resiprocate 
source code in 1.9.6 in TransactionState.cxx.

In TransactionState::processStateless(), if a timer fired, and it is not 
stateless, the code asserts. This could happen, however, if the other 
side of the connection sends something wrong. You certainly don't want 
to provide a way of allowing the other end of the connection to crash 
your code on demand. The comment we put in explains the situation in 
more detail below (modified source file attached). We saw this when we 
receive a REGISTER, we send a 200 OK, and the other guy then (wrongly) 
sends an ACK. Note that we found this problem in version 1.7.1 and have 
ported it forward to 1.9.6.

    else if (isTimer(message))
    {
       TimerMessage* timer = dynamic_cast<TimerMessage*>(message);
       if (timer->getType() == Timer::TimerStateless)
       {
          delete message;
          delete this;
       }
       else
       {
          // AYLUS_CHANGE: if the client (wrongly) sends an ACK in 
response to a response on a non-INVITE
          // transaction (like a registration), resiprocate will create 
a stateless TransactionState
          // to handle it, but some timers running against the old, dead 
TransactionState will still
          // be out there with the same tid. When they fire, we will hit 
this. Don't assert.

          InfoLog(<< "got timer " << *timer << " for stateless 
transaction " << *this);
          delete timer;
          //         assert(0);
       }
    }

-John Gregg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TransactionState.cxx
Type: text/x-c++src
Size: 102917 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140519/589ee24b/attachment.cxx>