For INVITE transactions generate and dispense ACK before we call

final response handling routine. This makes sure that for example
2-nd INVITE after 401/407 is going to be send after ACK, not
before. Previous behaviour while not strictly against RFC (since
it could be often caused by reordering on network), but it can
cause confuse some "naive" UAS implementation out there leading
to various interop issues.

Discovered at: OpenSIPIt'00

sippy/SipTransactionManager.py

@@ -429,11 +429,6 @@ def incomingResponse(self, msg, t, checksum):
                         t.resp_cb(msg, t)
             else:
                 # Final response - notify upper layer and remove transaction
-                if t.resp_cb != None:
-                    if t.cb_ifver == 1:
-                        t.resp_cb(msg)
-                    else:
-                        t.resp_cb(msg, t)
                 if t.needack:
                     # Prepare and send ACK if necessary
                     fcode = msg.getSCode()[0]
@@ -479,9 +474,15 @@ def incomingResponse(self, msg, t, checksum):
                         t.ack_checksum = checksum
                         self.l1rcache[checksum] = SipTMRetransmitO()
                         t.teG = Timeout(self.timerG, 64, 1, t)
-                        return
                 else:
                     self.l1rcache[checksum] = SipTMRetransmitO()
+                if t.resp_cb != None:
+                    if t.cb_ifver == 1:
+                        t.resp_cb(msg)
+                    else:
+                        t.resp_cb(msg, t)
+                if t.state == UACK:
+                    return
                 del self.tclient[t.tid]
                 t.cleanup()