Re-work logic around calculating average delay when we had to do some retransmits. In that case it is not possible to figure out whether or not this reply is related to the original request or one of the retransmits. Therefore, using it to estimate delay could easily produce bogus value that is too low or even negative if we cook up retransmit while the original response is already in the queue waiting to be processed. This should not be a big issue since UDP command channel does not work very well if the packet loss goes to more than 30-40%.
Re-work logic around calculating average delay when we had to do
some retransmits. In that case it is not possible to figure out whether
or not this reply is related to the original request or one of the
retransmits. Therefore, using it to estimate delay could easily produce
bogus value that is too low or even negative if we cook up retransmit
while the original response is already in the queue waiting to be
processed. This should not be a big issue since UDP command channel does
not work very well if the packet loss goes to more than 30-40%.

Organize code a little bit better to store persistent data as a
class, not as a tuple.

Add fake go_offline() method to make self-test happy.

sippy/b2bua,sippy/b2bua