Assertion of pending transport when retransmission timer fires

[nanangizz]

Reported that this assertion is raised:

/* Must not be triggered while transport is pending. */ 
pj_assert((tsx->transport_flag & TSX_HAS_PENDING_TRANSPORT) == 0);

with call stack:

tsx_on_state_proceeding_uas + 2168
tsx_timer_callback + 868
pj_timer_heap_poll + 764

Normally when a transport is pending (due to async resolve/connect/send), TSX_HAS_PENDING_TRANSPORT will be set and transaction will not start the retransmission timer. It will just set transport flag TSX_HAS_PENDING_RESCHED so the retransmission timer will be started later after the operation is done. So TSX_HAS_PENDING_TRANSPORT should never be set when the retransmission timer fires (hence the assertion check is there).

However, tsx_retransmit() seems to restart the retransmission timer before performing the send operation, so there may be a condition that the sending is async (TSX_HAS_PENDING_TRANSPORT is set) and the retransmission timer is started. Note that normally the order should be the other way around (i.e: send first, start the timer when transport is not pending), code comment says something about loop transport, but I don't really understand it, so I don't want to change it.

Also note that retransmission interval is usually much longer than delay in async operation, hence the assertion should be rarely raised. But on IP change scenario, recreating & reconnecting transport may take longer than retransmission interval.