Call disconnection in failover scenario due to transport error on previous INVITE request

[nanang]

Scenario:

1. DNS lookup returning two servers.
2. Sending INVITE to first server over TCP.
3. Response received with code 503 (Service Unavailable).
4. Failover to second server, sending second INVITE after restarting the session.
5. TCP connection for the first INVITE getting disconnected and causing call disconnection (while second INVITE is still outstanding).

The call disconnection is issued from here​, it is because the first INVITE transaction is terminated with status code PJSIP_SC_TSX_TRANSPORT_ERROR.

The idea is to ignore transport error on transaction that is already PJSIP_TSX_STATE_COMPLETED (sent/received final response) as it is kind of useless, and even can be dangerous. Note that transport error piggybacks tsx timeout timer, which is usually used for shifting tsx state. So cancelling timeout timer and rescheduling for transport error must be followed by another rescheduling (from transport error handler) for shifting tsx state, or otherwise the tsx will stuck in that state.

When investigating this issue, we found a related issue. Based on #1619, a call should be disconnected upon transport error only when the transaction is initial INVITE transaction, in the scenario, the transport error happens in INVITE transaction but not (or no longer) the initial INVITE transaction. Moreover, the block that disconnecting call​ in inv_on_state_calling() is supposed to be applicable for non-INVITE transaction only, so transport error case should be excluded from that block.

Thanks Joshua Colp for the report and the analysis.

[nanang]

In 5714:

Fixed #2076:

• Ignore transport error on completed transaction.
• Don't disconnect call if transport error happens on transaction that is not initial INVITE transaction.