The xferfailsound was read from the channel at the beginning of the transfer,
and that value is "cached" for the duration of the transfer. Therefore, changing
the xferfailsound on the channel using the FEATURE() dialplan function does
nothing once the transfer is under way.

This makes it so the transfer code instead gets the xferfailsound configuration
options from the channel when it is actually going to be used.

This patch also fixes a potential memory leak of the props object as well as
making sure the condition variable gets initialized before being destroyed.

ASTERISK-25696 #close

Change-Id: Ic726b0f54ef588bd9c9c67f4b0e4d787934f85e4

Change-Id: Id5bd18ef1f60ef8be453e677e98478298358a9d1

* Add freed regions totals to allocations and summary.

* Add totals for all allocations and not just the selected allocations.

Change-Id: I61d5a5112617b0733097f2545a3006a344b4032a

If the attended transfer destination answers (picks call up or goes to
voicemail) and then hangs up on the transferer then transferer hears the
fail sound.

This patch makes it so the fail sound is not played when the transfer
destination/target hangs up after answering.

ASTERISK-25697 #close

Change-Id: I97f142fe4fc2805d1a24b7c16143069dc03d9ded

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