ACK not sent using an existing TLS transport

[nanangizz]

Scenario

1. connect to a remote TLS server & send INVITE
2. receive 100 & 180 responses
3. TLS connection dropped (due to IP change), so remote initiates a new TLS connection from a different IP address
4. receive 200 response
5. send ACK will initiate another TLS connection instead of reusing the existing (established in step 3).

Analysis

The dialog will store the remote name in dlg->intial_dest in step 1 (see #3310) by dlg_update_routeset():

pjproject/pjsip/src/pjsip/sip_dialog.c

Lines 1876 to 1881 in c224f26

	/* Update initial destination host from transport's info. */
	if (rdata->tp_info.transport->dir == PJSIP_TP_DIR_OUTGOING)
	{
	pj_strdup(dlg->pool, &dlg->initial_dest,
	&rdata->tp_info.transport->remote_name.host);
	}

And in step 4, the remote name is supposed to be updated/reset by the same code above, but it does not happen as the transport used by 200 response is a server transport. So in sending the ACK in step 5, the transport manager won't find/reuse the transport created in step 3 because it is being requested for remote address in step 3 but with wrong/old remote name (set by step 1). Note that a TLS transport can be reused if it matches both: remote address and remote name (for TLS verification).

Resetting the dialog's remote name should be sufficient because later it will be initialized to the target address by pjsip_endpt_send_request_stateless() (or pjsip_endpt_send_response() if it is a response).

Thanks to Peter Koletzki for the report.

[PeterKoletzki]

We implement this patch and it solves the issue. Good catch.

[nanangizz]

@PeterKoletzki Thanks for the confirmation.