Locking some objects like sorcery objects can be tricky because the underlying
ao2 object may not be the same for all callers.  For instance, two threads that
call ast_sorcery_retrieve_by_id on the same aor name might actually get 2
different ao2 objects if the underlying wizard had to rehydrate the aor from a
database. Locking one ao2 object doesn't have any effect on the other even if
those objects had locks in the first place.

Named locks allow access control by keyspace and key strings.  Now an "aor"
named "1000" can be locked and any other thread attempting to lock "aor" "1000"
will wait regardless of whether the underlying ao2 object is the same or not.
Mutex and rwlocks are supported.

This capability will initially be used to lock an aor when multiple threads may
be attempting to prune expired contacts from it.

Change-Id: If258c0b7f92b02d07243ce70e535821a1ea7fb45

* Pull out a loop invariant.

* Convert an else-if ladder to a switch statement.

Change-Id: I0a95cfa9474a4600b9865f7b444534d275b37e95

Change-Id: Id1403b12136de62a272c01bb355aef65fd2c2d1e

When shutting down, the PJSIP sorcery is destroyed. The registrar
expiration module queries the PJSIP sorcery to determine what
to expire. As there was no synchronization between termination
of the expiration thread and the unloading of the module it was
possible for the thread to try to access the PJSIP sorcery after
it had been destroyed.

This change ensures that the thread is shut down before allowing
the module to be considered unloaded.

Change-Id: I69fd239edbaaf160c2d37ae00d3ac06e5596fe8b

Due to a merge problem two options were swapped causing the
regcontext setting to not get set.

Change-Id: Icb33edc668e7357bacbaec2861a6b5ac64edaff1

The problem is ast_frdup() does not copy whole frame.subclass for voice,
video and image frames, only the format is copied.  For video frames, the
subclass structure contains the .frame_ending flag used to put the RTP
marker where it needs to be.

ASTERISK-25894 #close

Change-Id: I812ca90e84ed5d4f473b997d0dd0d3c5a915fe33

This adds a new ARI method that allows for you to dial a channel that
you previously created in ARI.

By combining this with the create method for channels, it allows for a
workflow where a channel can be created, manipulated, and then dialed.
The channel is under control of the ARI application during all stages of
the Dial and can even be manipulated based on channel state changes
observed within an ARI application.

The overarching goal for this is to eventually be able to add a dialed
channel to a Stasis bridge earlier than the "Up" state. However, at the
moment more work is needed in the Dial and Bridge APIs in order to
facilitate that.

ASTERISK-25889 #close

Change-Id: Ic6c399c791e66c4aa52454222fe4f8b02483a205

This adds a new ARI method to the channels resource that allows for the
creation of a new channel. The channel is created and then placed into
the specified Stasis application.

This is different from the existing originate method that creates a
channel, dials it, and then places the answered channel into the
dialplan or a Stasis application. This method does not attempt to call
the channel at all. Dialing is left as a later step after channel
creation. This allows for pre-dialing channel manipulation if desired.

ASTERISK-25889

Change-Id: I3c96a0aba914b08e39f6256371a5bd4c92cbded8

This change introduces the concept of autohints. These are hints
which are created as a result of device state changes occurring within
the core. When this happens a hint will be created (if it does not
exist already) using the device name as the extension.

For example if a device state change is received for "PJSIP/bob"
and autohints are enabled on a context then a hint will exist in
that context for "bob" with a device of "PJSIP/bob".

For virtual or custom device states the name after the type will
be used. For example if the device state of "Custom:bob" changes
then a hint will exist in that context for "bob" with a device of
"Custom:bob".

This functionality can be enabled in extensions.conf by placing
"autohints=yes" in a context.

ASTERISK-25881 #close

Change-Id: I7e444c7da41b7b7d33374420fec658beeb18584e

Some SIP devices indicate hold/unhold using deferred SDP reinvites. In
other words, they provide no SDP in the reinvite.

A typical transaction that starts hold might look something like this:

* Device sends reinvite with no SDP
* Asterisk sends 200 OK with SDP indicating sendrecv on streams.
* Device sends ACK with SDP indicating sendonly on streams.

At this point, PJMedia's SDP negotiator saves Asterisk's local state as
being recvonly.

Now, when the device attempts to unhold, it again uses a deferred SDP
reinvite, so we end up doing the following:

* Device sends reinvite with no SDP
* Asterisk sends 200 OK with SDP indicating recvonly on streams
* Device sends ACK with SDP indicating sendonly on streams

The problem here is that Asterisk offered recvonly, and by RFC 3264's
rules, if an offer is recvonly, the answer has to be sendonly. The
result is that the device is not taken off hold.

What is supposed to happen is that Asterisk should indicate sendrecv in
the 200 OK that it sends. This way, the device has the freedom to
indicate sendrecv if it wants the stream taken off hold, or it can
continue to respond with sendonly if the purpose of the reinvite was
something else (like a session timer refresher).

The fix here is to alter the SDP negotiator's state when we receive a
reinvite with no SDP. If the negotiator's state is currently in the
recvonly or inactive state, then we alter our local state to be
sendrecv. This way, we allow the device to indicate the stream state as
desired.

ASTERISK-25854 #close
Reported by Robert McGilvray

Change-Id: I7615737276165eef3a593038413d936247dcc6ed

The Dial API takes responsiblity for creating an outbound channel when
calling ast_dial_append(). This commit adds a new function,
ast_dial_append_channel(), which allows us to create the channel outside
the Dial API and then to append the channel to the ast_dial structure.

This is useful for situations where the channel's creation and dialing
are distinct operations. Upcoming ARI early bridge work will illustrate
its usage.

ASTERISK-25889

Change-Id: Id8179f64f8f99132f80dead8d5db2030fd2c0509

In sorcery based config files where there are multiple categories with the same
name, you can't use the (+) operator to reliably append to a category because
config.c stops looking when it finds the first one with the same name.

Example:

[1000]
type = endpoint

[1000]
type = aor

[1000](+)
authenticate_qualify = yes

This config will fail because config.c appends authenticate_qualify to the
first category it finds, the endpoint, and that's not valid for endpoint.

Solution:

The capability to find a category that contains a certain variable already
exists so the only real change was to parse anything after the '+' that's not a
comma, as a filter string.

[1000]
type = endpoint

[1000]
type = aor

[1000](+type=aor)
authenticate_qualify = yes

This now works as expected.

Although the following example doesn't make any sense for pjsip, you can even
specify multiple filters:

[1000](+type=aor&qualify_frequency=10)

ASTERISK-25868 #close
Reported-by: Nick Repin

Change-Id: I10773da4c79db36fbf1993961992af63d3441580

Websockets are a core part of ARI support and as such this
module should also be core supported.

Change-Id: I8f9283c6a167152761b92984779bb39e3db51a9c

String fields are great, except that you can't add new ones without breaking
ABI compatibility because it shifts down everything else in the structure.
The only alternative is to add your own char * field to the end of the
structure and manage the memory yourself which isn't ideal, especially since
you then can't use the OPT_STRINGFIELD_T type.

Background:

The reason string fields had to be declared inside the
AST_DECLARE_STRING_FIELDS block was to facilitate iteration over all declared
fields for initialization, compare and copy.  Since AST_DECLARE_STRING_FIELDS
declared the pool, then the fields, then the manager, you could use the offsets
of the pool and manager and iterate over the sequential addresses in between to
access the fields. The actual pool, field allocation and field set operations
don't actually care where the field is.  It's just iteration over the fields
that was the problem.

Solution: Extended String Fields

An extended string field is one that is declared outside the
AST_DECLARE_STRING_FIELDS block but still (anywhere) inside the parent
structure.  Other than using AST_STRING_FIELD_EXTENDED instead of
AST_STRING_FIELD, it looks the same as other string fields.  It's storage comes
from the pool and it participates in string field compare and copy operations
peformed on the parent structure. It's also a valid target for the
OPT_STRINGFIELD_T aco option type.

Implementation:

To keep track of the extended fields and make sure that ABI isn't broken, the
existing embedded_pool pointer in the manager structure was repurposed to be a
pointer to a separate header structure that contains the embedded_pool pointer
plus a vector of fields.  The length of the manager structure didn't change and
the embedded_pool pointer isn't used in the macros, only the stringfields C
code.  A side benefit of this is that changing the header structure in the
future won't break ABI.

ast_string_fields_init initializes the normal string fields and appends them to
the vector, and subsequent calls to ast_string_field_init_extended initialize
and append the extended fields. Cleanup, ast_string_fields_cmp, and
ast_string_fields_copy can now work on the vector instead of sequentially
traversing the addresses between the pool and manager.

The total size of a structure using string fields didn't change, whether using
extended fields or not, nor have the offsets of any structure members, either
inside the original block or outside.  Adding an extended field to the end of a
structure is the same as adding a char *.

Details:

The stringfield C code was pulled out from utils.c and into stringfields.c.
It just made sense.

Additional work was done in ast_string_field_init and
ast_calloc_with_stringfields to handle the allocation of the new header
structure and the vector, and the associated cleanup.  In the process some
additional NULL pointer checking was added.

A lot of work was done in stringfields.h since the logic for compare and copy
is there.  Documentation was added as well as somne additional NULL checking.

The ability to call ast_calloc_with_stringfields with a number of structures
greater than 1 never really worked.  Well, the calloc worked but there was no
way to access the additional structures or clean them up.  It was agreed that
there was no use case for requesting more than 1 structure so an ast_assert
was added to prevent it and the iteration code removed.

Testing:

The stringfield unit tests were updated to test both normal and extended
fields.  Tests for ast_string_field_ptr_set_by_fields and
ast_calloc_with_stringfields were also added.

As an ABI test, 13 was compiled from git and the res_pjsip_* modules, except
res_pjsip itself, saved off.  The patch was then added and a full compile and
install was performed.  Then the older res_pjsip_* moduled were copied over the
installed versions so res_pjsip was new and the rest were old.  No issues.

contact->aor, which is a char * at the end of contact, was then changed to an
extended string field and a recompile and reinstall was performed, again
leaving stock versions of the the res_pjsip_* modules.  Again, no issues with
the res_pjsip_* modules using the old stringfield implementation and with
contact->aor as a char *, and res_pjsip itself using the new stringfield
implementation and contact->aor being an extended string field.

Finally, several existing string fields were converted to extended string
fields to test OPT_STRINGFIELD_T.  Again, no issues.

Change-Id: I235db338c5b178f5a13b7946afbaa5d4a0f91d61

I forgot the new voicemail_extension wasn't a stringfield and didn't check
for NULL where I should have.

Change-Id: I029482d5c2ab72474838750461bd46b0809c90fb

check_installed_debs wasn't handling virtual packages like libsrtp-dev and
libresample-dev and on multiarch systems it was accidentally filtering out all
packages if any :i386 packages were found instead of just filtering out the
:i386 packages themselves.

Change-Id: Ifd68da0d1ee30cc84df14de3f9b9079d7c3cecda

ast_cli_allow_on_shutdown(e) should have been ast_cli_allow_at_shutdown(e).

Change-Id: I4f092495c0b2bfd85c2651e0b5877bf4d05d9faf

LDCONFIG apparently isn't set to something sane on all systems so the creation
of the shared library links fails.  Instead of just testing for non-blank,
main/Makefile now checks that LDCONFIG is actually executable and reverts to
LN if it isn't.

This applies to both libasteriskpj and libasteriskssl.

Thanks to 'abelbeck' for pointing out that the issue was LDCONFIG.

ASTERISK-25873 #close
Reported-by: Hans van Eijsden

Change-Id: I25b76379bc637726ec044b2c0e709b56b3701729

The stasis_app_playback and stasis_app_recording structs need to have a
struct stasis_app_control ref.  Other threads can get a reference to the
playback and recording structs from their respective global container.
These other threads can then use the control pointer they contain after
the control struct has gone.

* Add control ref to stasis_app_playback and stasis_app_recording structs.

With the refs added, the control command queue can now have a circular
control reference which will cause the control struct to never get
released if the control's command queue is not flushed when the channel
leaves the Stasis application.  Also the command queue needs better
protection from adding commands if the control->is_done flag is set.

* Flush the control command queue on exit.

ASTERISK-25882 #close

Change-Id: I3cf1fb59cbe6f50f20d9e35a2c07ac07d7f4320d