< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index |
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
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel