res_pjsip_outbound_registration: Don't fail on delayed processing: 13.

This is the Asterisk 13 version of a change to master that allows for
registration responses to be processed successfully potentially after
the original transaction has timed out. The main difference between this
and the master change is that the master version has API changes that
are unacceptable for 13. For 13, this is worked around by adding a new
API call that the outbound registration code uses instead.

The following is the text from the master version of this commit:

Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.

Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.

To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now also hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.

ASTERISK-25020
Reported by Mark Michelson

Change-Id: If1ee5f601be839479a219424f0358a229f358f7c

1 files changed, 10 insertions, 4 deletions

diff --git a/res/res_pjsip_outbound_authenticator_digest.c b/res/res_pjsip_outbound_authenticator_digest.c
index 35e59f21a..aa35fbac0 100644
--- a/res/res_pjsip_outbound_authenticator_digest.c
+++ b/res/res_pjsip_outbound_authenticator_digest.c
@@ -101,14 +101,14 @@ cleanup:
 	return res;
 }
 
-static int digest_create_request_with_auth(const struct ast_sip_auth_vector *auths, pjsip_rx_data *challenge,
-		pjsip_transaction *tsx, pjsip_tx_data **new_request)
+static int digest_create_request_with_auth_from_old(const struct ast_sip_auth_vector *auths, pjsip_rx_data *challenge,
+		pjsip_tx_data *old_request, pjsip_tx_data **new_request)
 {
 	pjsip_auth_clt_sess auth_sess;
 	pjsip_cseq_hdr *cseq;
 
 	if (pjsip_auth_clt_init(&auth_sess, ast_sip_get_pjsip_endpoint(),
-				tsx->pool, 0) != PJ_SUCCESS) {
+				old_request->pool, 0) != PJ_SUCCESS) {
 		ast_log(LOG_WARNING, "Failed to initialize client authentication session\n");
 		return -1;
 	}
@@ -119,7 +119,7 @@ static int digest_create_request_with_auth(const struct ast_sip_auth_vector *aut
 	}
 
 	switch (pjsip_auth_clt_reinit_req(&auth_sess, challenge,
-				tsx->last_tx, new_request)) {
+				old_request, new_request)) {
 	case PJ_SUCCESS:
 		/* PJSIP creates a new transaction for new_request (meaning it creates a new
 		 * branch). However, it recycles the Call-ID, from-tag, and CSeq from the
@@ -150,6 +150,12 @@ static int digest_create_request_with_auth(const struct ast_sip_auth_vector *aut
 	return -1;
 }
 
+static int digest_create_request_with_auth(const struct ast_sip_auth_vector *auths, pjsip_rx_data *challenge,
+		pjsip_transaction *tsx, pjsip_tx_data **new_request)
+{
+	return digest_create_request_with_auth_from_old(auths, challenge, tsx->last_tx, new_request);
+}
+
 static struct ast_sip_outbound_authenticator digest_authenticator = {
 	.create_request_with_auth = digest_create_request_with_auth,
 };