Indeed, it may happen that a the cancellation of an INVITE transaction results in the transaction callback being invoked, which results in the transaction being destroyed immediately while still doing processing with the creation of the cancel transaction. The exact case would be that the sending of the CANCEL generates a transport error that is immediately notified to the INVITE transaction (because the CANCEL and the INVITE use the same transport) with an internal 503 response, which goes to flexisip, and calls OutgoingTransaction::destroy(), which calls nta_outgoing_destroy(). nta_outgoing_tcancel() is then left with the INVITE transaction freed (full of 0xaaaaaaaa), which crashes.