Hangup not yet confirmed outgoing calls in IP change

[nanangizz]

There was PR #2737 for avoiding call disconnection on IP change, but its scope is limited to a confirmed call. Also this PR #2683 for maintaining INVITE transactions in the UAS/callee side. While for UAC/caller in the connecting state, it is actually a bit more complex, an attempt to handle it has been done in PR #3288 (still unsolved).

Some of the challenges are:

• as the INVITE transaction is not completed yet, by standard we cannot send another INVITE to update remote about our new address, we can only use UPDATE and not all endpoints support UPDATE,
• if the initial INVITE contains SDP offer, and the SDP negotiation is not completed yet, also by standard, the UPDATE cannot contain another SDP offer, we need to renegotiate the SDP to update the media addresses,
• updating routing info for the INVITE transaction so remote/server can send its response to the correct latest address, but is not a simple task as remote/server may already send the response before our UPDATE is sent.

So for now, let's just hang up not confirmed outgoing call in IP change scenario. Note that the remote may see a dangling call as there may be race condition, e.g: remote has sent some response but not received by local/caller.

[sauwming]

why not combine it with the above?

[nanangizz]

• For readibility, because they are conceptually different. The above is intentional hangup via configured settings, the latter is forced hangup due to specific conditions.
• Also the actions can also be different, for example with the current patch, pjsua_call_hangup() which will send CANCEL and CANCEL may not be useful if remote does not receive the INVITE (due to local IP change) or remote have sent its final answer (either success/2xx or failure/3xx-6xx) but local does not received it (due to IP change), so perhaps terminating the call forcefully somehow may be better.