You have to call ast_taskprocessor_unref() outside of the taskprocessor
implementation code. Taskprocessor use since v12 has become more
transient than just the singleton uses in earlier versions.
Change-Id: If7675299924c0cc65f2a43a85254e6f06f2d61bb
This removes logchannels locking from init_logger_chain, puts the
responsibility on the caller. Adds locking around the one call that was
missing it.
ASTERISK-24833
Change-Id: I6cc42117338bf9575650a67bcb78ab1a33d7bad8
When the Asterisk is restared is not preseved reason paused of members.
This patch fixed this cases, retain data on astdb and set when Asterisk
is started.
ASTERISK-25732 #close
Report by: Rodrigo Ramírez Norambuena
Change-Id: Id3fb744c579e006d27cda4a02334ac0e4bed9eb5
Corrects the qualify_timeout column type from Integer to Decimal
ASTERISK-25686 #close
Reported-by: Marcelo Terres
Change-Id: I757d0e3c011ee9be6cd5abd48bc92441a405d3c8
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
* 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
Asterisk uses a Makefile macro to associate additional sources with a
module. This macro is responsible for creating clean targets but
previously left behind *.gcna and *.gcno files.
ASTERISK-25683 #close
Reported by yaron nahum
Change-Id: Idc0823fe80a25c42cefae901fde875e9fc38d8ea
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.
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 2bd27d1222)
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
