Added new global option (regcontext) to pjsip. When set, Asterisk will
dynamically create and destroy a NoOp priority 1 extension
for a given endpoint who registers or unregisters with us.

ASTERISK-25670 #close
Reported-by: Daniel Journo

Change-Id: Ib1530c5b45340625805c057f8ff1fb240a43ea62

This issue was exposed when executing a connected line subroutine.
When connected or redirected subroutines or macros are executed it is
expected that the underlying applications and logic invoked are fast
and do not consume frames. In practice this constraint is not enforced
and if not adhered to will cause channels to continue when they shouldn't.
This is because each caller of the connected or redirected logic does not
check whether the channel has been hung up on return. As a result the
the hung up channel continues.

This change makes it so when the API to execute a subroutine or
macro is invoked the channel is checked to determine if it has hung up.
If it has then a hangup is queued again so the caller will see it
and stop.

ASTERISK-25690 #close

Change-Id: I1f9a8ceb1487df0389f0d346ce0f6dcbcaf476ea

There are two ways in which the reload() function in res_musiconhold can be
called from the CLI:

  * module reload res_musiconhold.so
  * moh reload

In the former case, the module loader holds a lock that prevents multiple
concurrent calls, but in the latter there is no such protection.

This patch changes the 'moh reload' CLI command to invoke the module loader
directly, rather than call reload() explicitly.

ASTERISK-25687 #close

Change-Id: I408968b4c8932864411b7f9ad88cfdc7b9ba711c

PJPROJECT has a function available to dump the compile time
options used when building the library.

* Add CLI "pjsip show buildopts" command.

* Update contrib/scripts/autosupport to get pjproject information.

Change-Id: Id93a6a916d765b2a2e5a1aeb54caaf83206be748

* changes:
  Sorcery: Create human friendly serializer names.
  Stasis: Create human friendly taskprocessor/serializer names.
  taskprocessor.c: New API for human friendly taskprocessor names.
  taskprocessor.c: Sort CLI "core show taskprocessors" output.

* changes:
  taskprocessor.c: Fix CLI "core show taskprocessors" unref.
  taskprocessor.c: Add CLI "core ping taskprocessor" missing unlock.

res_sorcery_realtime's search-by-regex callback performed a check to
ensure that the passed-in regex began with a caret (^). If it did not,
then no results would be returned.

This callback only started to become used when "like" support was added
to PJSIP CLI commands. The CLI command for listing objects would pass an
empty regex ("") to the sorcery backend if no "like" statement was
present. For most sorcery backends, this resulted in returning all
objects. However, for realtime, this resulted in returning no objects.

This commit seeks to fix the regression by removing the requirement from
res_sorcery_realtime for the passed-in-regex to begin with a caret.

ASTERISK-25689 #close
Reported by Marcelo Terres

Change-Id: I22b4dc5d7f3f11bb29ac2e42ef94682e9bab3b20

On a system with multiple ip addresses in the same subnet, if a
transport is bound to a specific ip address and endpoint/media_address
 is set, the SIP/SDP will have the correct address in all fields but
the rtp stream MAY still originate from one of the other ip addresses,
most probably the "primary" ip address.  This happens because
 res_pjsip_sdp_rtp/create_rtp always calls ast_instance_new with
the "all" ip address (0.0.0.0 or ::).

The new option causes res_pjsip_sdp_rtp/create_rtp to call
ast_rtp_instance_new with the endpoint's media_address (if specified)
instead of the "all" address.  This causes the packets to originate from
the specified address.

ASTERISK-25632
ASTERISK-25637
Reported-by: Olivier Krief
Reported-by: Dan Journo

Change-Id: I3dfaa079e54ba7fb7c4fd1f5f7bd9509bbf8bd88

Recent changes (ASTERISK-25394 commit 2bd27d12)
introduced the possibility of a deadlock. Due to the mentioned modifications
ast_change_hints now needs to keep both merge/delete and state callbacks from
occurring while it executes. Unfortunately, sometimes ast_change_hints can be
called with the contexts container locked. When this happens it's possible for
another thread to grab the context_merge_lock before the thread calling into
ast_change_hints does and then try to obtain the contexts container lock. This
of course causes a deadlock between the two threads. The thread calling into
ast_change_hints waits for the other thread to release context_merge_lock and
the other thread is waiting on that one to release the contexts container lock.

Unfortunately, there is not a great way to fix this problem. When hints change,
the subsequent state callbacks cannot run at the same time as a merge/delete,
nor when the usual state callbacks do. This patch alleviates the problem by
having those particular callbacks (the ones run after a hint change) occur in a
serialized task. By moving the context_merge_lock to a task it can now safely be
attempted or held without a deadlock occurring.

ASTERISK-25640 #close
Reported by: Krzysztof Trempala

Change-Id: If2210ea241afd1585dc2594c16faff84579bf302

ASTERISK-25681 #close

Change-Id: I64337c70f0ebd8c77f70792042684607c950c8f1

ASTERISK-25680 #close

Change-Id: I3251d781cbc3f48a6a7e1b969ac4983f552b2446

ASTERISK-25679 #close

Change-Id: I839159bf6882cccc1b23494c7aa2bc2a2624613f

Due to locking issues within pjnath these changes are being
reverted until pjnath can be changed.

ASTERISK-25645

Revert "res_rtp_asterisk.c: Fix DTLS negotiation delays."

This reverts commit 24ae124e.

Change-Id: I2986cfb2c43dc14455c1bcaf92c3804f9da49705

Revert "res_rtp_asterisk: Resolve further timing issues with DTLS negotiation"

This reverts commit 965a0eee.

Change-Id: Ie68fafde27dad4b03cb7a1e27ce2a8502c3f7bbe

This reverts commit 0a9941de.

Matt,

This patch causes another problem and should not have been needed.
Before this patch, persistent_endpoint_contact_deleted_observer WAS
deleting the contact_status when ast_sip_location_delete_contact was
called.  By deleting it yourself in ast_sip_location_delete_contact
it was gone before the observer could run and the observer therefore
was throwing an error and not sending stasis/AMI/statsd messages.

So, I don't think this was the cause of your original issue.  I also
had verified the contact AMI and statsd lifecycle and it was working.
I'll double check now though.

ASTERISK-25675
Reported-by: Daniel Journo

Change-Id: Ib586a6b7f90acb641b0c410f659743ab90e84f1a

During failed startup of pbx_dundi no cleanup was performed.  Add a call
to unload_module before returning AST_MODULE_LOAD_DECLINE.

ASTERISK-25677 #close

Change-Id: I8ffa226fda4365ee7068ac1f464473f1a4ebbb29

This change causes res_crypto to unregister CLI at shutdown while still
preventing the module from being unloaded.

ASTERISK-25673 #close

Change-Id: Ie5d57338dc2752abfc0dd05d0eec86413f2304fc

PJSIP name formats:
pjsip/aor/<aor>-<seq> -- registrar thread pool serializer
pjsip/default-<seq> -- default thread pool serializer
pjsip/messaging -- messaging thread pool serializer
pjsip/outreg/<registration>-<seq> -- outbound registration thread pool
serializer
pjsip/pubsub/<endpoint>-<seq> -- pubsub thread pool serializer
pjsip/refer/<endpoint>-<seq> -- REFER thread pool serializer
pjsip/session/<endpoint>-<seq> -- session thread pool serializer
pjsip/websocket-<seq> -- websocket thread pool serializer

Change-Id: Iff9df8da3ddae1132cb2ef65f64df0c465c5e084

Sorcery name formats:
sorcery/<type>-<seq> -- Sorcery thread pool serializer

Change-Id: Idc2e5d3dbab15c825b97c38c028319a0d2315c47

Stasis name formats:
subm:<topic>-<seq> -- Stasis subscription mailbox task processor
subp:<topic>-<seq> -- Stasis subscription thread pool serializer

Change-Id: Id19234b306e3594530bb040bc95d977f18ac7bfd

* Add new API call to get a sequence number for use in human friendly
taskprocessor names.

* Add new API call to create a taskprocessor name in a given buffer and
append a sequence number.

Change-Id: Iac458f05b45232315ed64aa31b1df05b875537a9

Update the CLI "core show taskprocessors" output format to not be
distorted because UUID names are longer than previously used taskprocessor
names.

Change-Id: I1a5c82ce3e8f765a0627796aba87f8f7be077601

Change-Id: I1d9f4e532caa6dfabe034745dd16d06134efdce5