[Asterisk-code-review] res pjsip outbound registration: Don't fail on delayed proce... (asterisk[13])

[Mark Michelson]

Hello Joshua Colp,

I'd like you to reexamine a change.  Please visit

    https://gerrit.asterisk.org/265

to look at the new patch set (#2).

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

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.

There are two fixes introduced here.

First, we prevent the transaction from being destroyed before we are
ready by adding a reference to the transaction group lock and
decrementing that reference once we are completely finished processing
the REGISTER response.

Even though we now ensure that the transaction memory cannot be freed
before we are ready, this is not enough to ensure that we can
successfully perform actions like creating a REGISTER with
authentication credentials. This is because when the transaction times
out, most data is wiped from the transaction. Even though the
transaction is not freed, it's a shell of its former self.

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. 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
---
M include/asterisk/res_pjsip.h
M res/res_pjsip.c
M res/res_pjsip_outbound_authenticator_digest.c
M res/res_pjsip_outbound_registration.c
4 files changed, 55 insertions(+), 9 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/65/265/2
-- 
To view, visit https://gerrit.asterisk.org/265
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If1ee5f601be839479a219424f0358a229f358f7c
Gerrit-PatchSet: 2
Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-Owner: Mark Michelson <mmichelson at digium.com>
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>