This prevents a leak of a sorcery object type when realtime sorcery
objects are retrieved by fields or when multiple objects are retrieved.

The extent of this leak is that sorcery object types would be leaked.
These are allocated whenever an object type is registered with sorcery,
meaning that on module shutdown, these objects would be leaked. This
could be problematic if many reloads were performed, but it is not as
severe as if every sorcery object retrieved from realtime were being
leaked.

ASTERISK-25165 #close
Reported by Corey Farrell

Change-Id: I625c3b50eee4576670b7eeb013c81ad043b4b4f8

When 8297136f was merged for ASTERISK-25040, a regression was introduced
surrounding the case sensitivity of device names within hints.
Previously, device names - such as 'sip/foo' - were compared in a case
insensitive fashion. Thus, 'sip/foo' was equivalent to 'SIP/foo'. After
that patch, only the case sensitive name would match, i.e., 'SIP/foo'.
As a result, some dialplan hints stopped working.

This patch re-introduces case insensitive matching for device names in
hints.

ASTERISK-25040

ASTERISK-25202 #close

Change-Id: If5046a7d14097e1e3c12b63092b9584bb1e9cb4c
(cherry picked from commit 96bbcf49)

The client_state objects contain a serializer used to send the outbound
REGISTER messages.  Once all those message transactions are complete then
the module can shutdown.

ASTERISK-24907 #close
Reported by: Kevin Harwell

Change-Id: Ibb2fe558f98190f2a06da830e0fadfa25516f547

res_pjsip_refer will attempt to add Referred-By or Replaces headers to
outbound INVITEs at times. If the INVITE gets challenged for
authentication, then we will resend the INVITE. Prior to this patch, the
Referred-By or Replaces header would be re-added to the outbound INVITE,
resulting in duplicated headers.

ASTERISK-25204 #close
Reported by Mark Michelson

Change-Id: I59fb5c08b4d253c0dba9ee3d3950b5025358222d

ASTERISK-25189 #close
Reported by: John Hardin

Change-Id: I2b1778c3fdc1dca0ed55db4e3a639eddfb16c2ac

When performing some provider testing, the rewrite_contact option was
interfering with proper construction of a route set when sending an ACK
after receiving a 200 OK response to an INVITE.

The initial INVITE was sent to address sip:foo. The 200 OK had a Contact
header with URI sip:bar. In addition, the 200 OK had Record-Route
headers for sip:baz and sip:foo, in that order. Since the Record-Route
headers had the lr parameter, the result should have been:

* Set R-URI of the ACK to sip:bar.
* Add Route headers for sip:foo and sip:baz, in that order.

However, the rewrite_contact option resulted in our rewriting the
Contact header on the 200 OK to sip:foo. The result was:

* R-URI remained sip:foo.
* We added Route headers for sip:foo and sip:baz, in that order.

The result was that sip:bar was not indicated in the ACK at all, so the
far end never received our ACK. The call eventually dropped.

The intention of rewrite_contact is to rewrite the most immediate
destination of our SIP request to be the same address on which we
received a request or response. In the case of processing a SIP response
with Record-Route headers, this means that instead of rewriting the
Contact header, we should instead rewrite the bottom-most Record-Route
header. In the case of processing a SIP request with Record-Route
headers, this means we rewrite the top-most Record-route header.
Like when we rewrite the Contact header, we also ensure to update
the dialog's route set if it exists.

ASTERISK-25196 #close
Reported by Mark Michelson

Change-Id: I9702157c3603a2d0bd8a8215ac27564d366b666f

A module trying to unload needs to wait for all serializers it creates and
uses to complete processing before unloading.

ASTERISK-24907
Reported by: Kevin Harwell

Change-Id: I8c80b90f2f82754e8dbb02ddf3c9121e5e966059

* handle_client_state_destruction() must always be passed a ref to
client_state because it will always unref client_state.
handle_registration_response() was not passing a client_state ref.

* Made the final un-REGISTER message get sent normally using the pjproject
register control structure in handle_client_state_destruction().  The
previous code attempted to short circuit the response handling for the
module to unload.  That doesn't work for a couple reasons.  One,
pjsip_regc_send() may call the registered callback before it returns and
unbalance the client_state ref count.  Two, the registered callback
handles any authentication for the un-REGISTER message.

* Made the distinction between internal registration state and external
registration status with sip_outbound_registration_status_str().  This is
necessary to avoid altering documented AMI messages with internal
changes.

* Removed references to client_state->client outside of the serializer
thread.  When handle_client_state_destruction() destroys the pjproject
register control structure that memory is freed and cannot be referenced
anymore.  These accesses were to provide information for debug and
off-nominal warning messages.

* In sip_outbound_registration_timer_cb() you should not access entry->id
after unrefing client_state because the passed in entry is normally
pointing to the timer entry in the client_state object.

ASTERISK-24907
Reported by: Kevin Harwell

Change-Id: Ia7b446d8644b6b4550ef5bea49527671de65183f

The sorcery pjsip 'registration' config object needs to be destroyed on
module unload.  Otherwise, a reload of res_pjsip could try to use
callbacks for a previously unloaded instance of the module provided by
ast_sorcery_object_register() or one of the variants.  Also, if
res_pjsip_outbound_registration were subsequently reloaded, the sorcery
config field objects would be registered in sorcery twice.

ASTERISK-24907
Reported by: Kevin Harwell

Change-Id: I304fad13dece2604af48353f6c6d9d5c7b064697

Find and unlink the specified sorcery object type to complement
ast_sorcery_object_register().  Without this function you cannot
completely unload individual modules that use sorcery for configuration.

ASTERISK-24907
Reported by: Kevin Harwell

Change-Id: I1c04634fe9a90921bf676725c7d6bb2aeaab1c88

It is best if the loading code creates and initializes the module's
infrastructure before letting the system know of its existence.  The
unloading code needs to reverse the actions of the loading code and in the
reverse order.

ASTERISK-24907
Reported by: Kevin Harwell

Change-Id: I5d151383e9787b5b60aa5e1627b10f040acdded4

Added checks when a unit test is registered to see that the summary and
description strings do not end with a new-line '\n' for consistency.

The check generates a warning message and will cause the
/main/test/registrations unit test to fail.

* Updated struct ast_test_info member doxygen comments.

Change-Id: I295909b6bc013ed9b6882e85c05287082497534d

Analyzing the code shows that the unit test summary and description
strings should not end with a new-line character.  Where these strings are
used in the code a new-line is provided for output.

Change-Id: I2f4f37988ec363c8d1c5077a2fc8ca841c5cd30c

Analyzing the code shows that the unit test summary and description
strings should not end with a new-line character.  Where these strings are
used in the code a new-line is provided for output.

Change-Id: I129284f5e7ca93d82532334076da4c462d3d9fba

Change-Id: Icf5f13c8e1c2c92a4473bb573ed2dd856ce1b64e

Currently when requesting a channel the native formats of the
calling channel are provided to the core for usage when dialing
the outbound channel. This occurs without holding the channel lock
or keeping a reference to the formats. This is problematic as
the channel driver may end up changing the formats during this time.
In the case of chan_sip this happens when an SDP negotiation
completes.

This change makes it so app_dial keeps a reference to the native
formats of the calling channel which guarantees that they will
remain valid for the period of time needed.

ASTERISK-25172 #close

Change-Id: I2f0a67bd0d5d14c3bdbaae552b4b1613a283f0db

Change-Id: I39ae612746d892d2dbe86f3ff2d7027fa1da57f7

Change-Id: I399cb9d61bbba706b48c98e0bf75e98984cd9a9e

* Break some long lines.

* Fix doxygen comment.

Change-Id: I8f12ba6822f84d5e7bb575280270cd7e2fefb305

After completing an attended transfer the transfer target channel was not being
hung up after leaving the bridge. Added an explicit softhangup to hangup said
channel, but only if it was previously bridged.

ASTERISK-24782 #close
Reported by: John Bigelow

Change-Id: Idde9543d56842369384a5e8c00d72a22bbc39ada

The res_pjsip_mwi previously required a reload to set up the proper
subscriptions to allow unsolicited MWI to work. This change
makes it so the act of registering will also cause this to occur.
This is particularly useful if realtime is involved as no reload
needs to occur within Asterisk to cause the MWI information
to get sent.

ASTERISK-25180 #close

Change-Id: Id847b47de4b8b3ab8858455ccc2f07b0f915f252

Change-Id: I82e6e388e3688aebe0783f16c9e0800a747584b5

On reload, previously allowed codecs were not removed. Therefore, it was not
possible to remove codecs while Asterisk was running. Furthermore, newly added
codecs got appended behind the previous codecs. Therefore, it was not possible
to add a codec with a priority of #1. This change removes the old capabilities
before the current ones are added.

ASTERISK-25182 #close
Reported by: Alexander Traud
patches:
 asterisk_13_allow_codec_reload.patch uploaded by Alexander Traud (License 6520)

Change-Id: I62a06bcf15e08e8c54a35612195f97179ebe5802

Due to the use of stasis_unsubscribe_and_join in the peer destructor
it is possible for a deadlock to occur when an event callback is
occurring at the same time.

This happens because the peer may be destroyed while holding the
peers container lock. If this occurs the event callback will never
be able to acquire the container lock and the unsubscribe will
never complete.

This change makes it so the peers that have been removed from the
peers container are not destroyed with the container lock held.

ASTERISK-25163 #close

Change-Id: Ic6bf1d9da4310142a4d196c45ddefb99317d9a33

This resolves two observed race conditions.

First, a bit of background on what the Stasis application does:

1a Creates a stasis_app_control structure. This structure is linked into
   a global container and can be looked up using a channel's unique ID.
2a Puts the channel in an event loop. The event loop can exit either
   because the stasis_app_control structure has been marked done, or
   because of some other factor, such as a hangup. In the event loop, the
   stasis_app_control determines if any specific ARI commands need to be
   run on the channel and will run them from this thread.
3a Checks if the channel is bridged. If the channel is bridged, then
   ast_bridge_depart() is called since channels that are added to Stasis
   bridges are always imparted as departable.
4a Unlink the stasis_app_control from the container.

When an ARI command is received by Asterisk, the following occurs
1b A thread is spawned to handle the HTTP request
2b The stasis_app_control(s) that corresponds to the channel(s) in the
   request is/are retrieved. If the stasis_app_control cannot be
   retrieved, then it is assumed that the channel in question has exited
   the Stasis app or perhaps was never in Stasis in the first place.
3b A command is queued onto the stasis_app_control, and the channel's
   event loop thread is signaled to run the command.
4b While most ARI commands do nothing further, some, such as adding or
   removing channels from a bridge, will block until the command they
   issued has been completed by the channel's event loop.

The first race condition that is solved by this patch involves a crash
that can occur due to faulty detection of the channel's bridged status
in step 3a. What can happen is that in step 2a, the event loop may run
the ast_bridge_impart() function to asynchronously place the channel
into a bridge, then immediately exit the event loop because the channel
has hung up. In step 3a, we would detect that the channel was not
bridged and would not call ast_bridge_depart(). The reason that the
channel did not appear to be bridged was that the depart_thread that is
spawned by ast_bridge_impart() had not yet started. That is the thread
where the channel is marked as being bridged. Since we did not call
ast_bridge_depart(), the Stasis application would exit, and then the
channel would be destroyed Then the depart_thread would start up and
try to manipulate the destroyed channel, causing a crash.

The fix for this is to switch from using ast_channel_is_bridged() to
checking the NULLity of ast_channel_internal_bridge_channel() to
determine if ast_bridge_depart() needs to be called. The channel's
internal bridge_channel is set when ast_bridge_impart() is called and
is NULLed by the call to ast_bridge_depart(). If the channel's internal
bridge_channel is non-NULL, then the channel must have been imparted
into the bridge and needs to be departed, even if the actual bridging
operation has not yet started. By departing the channel when necessary,
the thread that is running the Stasis application will block until the
bridge gives the okay that the depart_thread has exited.

The second race condition that is solved by this patch involves a leak
of HTTP handler threads. The problem was that step 2b would successfully
retrieve a stasis_app_control structure. Then step 2a would exit the
channel from the event loop due to a hangup. Steps 3a and 4a would
execute, and then finally steps 3b and 4b would. The problem is that at
step 4b, when attempting to add a channel to a bridge, the thread would
block forever since the channel would never execute the queued command
since it was finished with the event loop. This meant that the HTTP
handling thread would be leaked, along with any references that thread
may have owned (in my case, I was seeing bridges leaked).

The fix for this is to hone in better on when the channel has exited the
event loop. The stasis_app_control structure has an is_done field that
is now set at each point where the channel may exit the event loop. If
step 2b retrieves a valid stasis_app_control structure but the control
is marked as done, then the attempted operation exits immediately since
there will be nothing to service the attempted command.

ASTERISK-25091 #close
Reported by Ilya Trikoz

Change-Id: If66265b73b4c9f8f58599124d777fedc54576628