When a smart bridge operation occurs and a bridge transitions from one
technology to another the old technology is provided the channels formerly
in it and told that they are leaving. Unfortunately the bridge provided
along with them is incomplete. The bridge, despite there being channels in it,
contains none. This forces technology implementations to have additional
logic when channels are leaving or to store their own duplicated
state.
This change makes the bridge more complete so it contains the expected
channels. Now that the bridge is complete special logic within
bridge_native_rtp is no longer needed and has been removed.
Review: https://reviewboard.asterisk.org/r/4057/
........
Merged revisions 425242 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425243 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes res_phoneprov more modular so other modules (like pjsip)
can provide configuration information instead of res_phoneprov relying solely
on users.conf and sip.conf. To accomplish this a new ast_phoneprov public API
is now exposed which allows config providers to register themselves, set
defaults (server profile, etc) and add user extensions.
* ast_phoneprov_provider_register registers the provider and provides callbacks
for loading default settings and loading users.
* ast_phoneprov_provider_unregister clears the defaults and users.
* ast_phoneprov_add_extension should be called once for each user/extension
by the provider's load_users callback to add them.
* ast_phoneprov_delete_extension deletes one extension.
* ast_phoneprov_delete_extensions deletes all extensions for the provider.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/3970/
........
Merged revisions 424963 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424964 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424965 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 13+, any given message type is not guaranteed to exist even
if Asterisk comes up correctly since creation of the message type could
be declined. The indexer should not prevent Asterisk from starting
under these conditions.
........
Merged revisions 424833 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When message type creation is declined via stasis.conf, certain
operations log errors assuming that the declined type is being used
before initialization or after destruction. These error messages get
quite spammy for oft used message types and should not be logged in the
first place since the message type is validly NULL.
Reported by: Matt DiMeo
........
Merged revisions 424769 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adding a mixmonitor to a channel causes the bridge to change technologies
from native to simple_bridge so the call can be recorded. However, when
the mixmonitor is stopped the bridge does not switch back to the native
technology.
* Added unbridge requests to reevaluate the bridge when a channel
audiohook is removed.
* Moved the unbridge request into ast_audiohook_attach() ensure that the
bridge reevaluates whenever an audiohook is attached. This simplified the
mixmonitor and chan_spy start code as well.
* Added defensive code to stop_mixmonitor_full() in case additional
arguments are ever added to the StopMixMonitor application.
* Made ast_framehook_detach() not do an unbridge request if the framehook
does not exist.
* Made ast_framehook_list_fixup() do an unbridge request if there are any
framehooks. Also simplified the loop.
ASTERISK-24195 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4046/
........
Merged revisions 424506 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424507 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r423414 (13) / r423415 (trunk), an API call that determines if a format
capability structure is empty was added. This returns true if the format
capability structure is completely empty or "none". A check for this was added
in channel.c's set_format call. Unfortunately, when this check was true, it
returned from the function while still holding the channel lock. This caused
the CDR unit tests - which have a tendency to create channels with no formats -
to deadlock. Whoops.
This patch unlocks the channel on the off-nominal path.
........
Merged revisions 423641 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change gives framehooks a reverse-direction masquerade callback in
addition to chan_fixup_cb similar to the callback added to datastores
to handle the same situation. The new callback provides the same
parameters as the fixup callback, but is called on the new channel's
framehooks before moving framehooks from the old channel to the new
channel. This gives the framehooks an oppurtunity to decide whether
they should remain on the new channel or be removed.
This new callback is used to prevent the PJSIP T.38 framehook from
remaining on a masqueraded channel if the new channel is not also a
PJSIP channel. This was causing a crash when a local channel was
masqueraded into a PJSIP channel and the framehook was executed on the
local channel since the channel's tech private data was not structured
as expected.
Review: https://reviewboard.asterisk.org/r/4001/
........
Merged revisions 423503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function acts like strsep with three exceptions...
* The separator is a single character instead of a string.
* Separators inside quotes are treated literally instead of like separators.
* You can elect to have leading and trailing whitespace and quotes
stripped from the result and have '\' sequences unescaped.
Like strsep, ast_strsep maintains no internal state and you can call it
recursively using different separators on the same storage.
Also like strsep, for consistent results, consecutive separators are not
collapsed so you may get an empty string as a valid result.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3989/
........
Merged revisions 423476 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423478 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423480 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Empty here means that there are no formats in the format_cap structure
or the only format in it is the "none" format.
I've added calls to check the emptiness of a format_cap in a few places
in order to short-circuit operations that would otherwise be pointless
as well as to prevent some assertions from being triggered in cases
where channels with no formats are used.
........
Merged revisions 423414 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes made during format improvements resulted in the
recording to voicemail option 'm' of the MixMonitor app
writing a zero length duration in the msgXXXX.txt file.
This change introduces a new function ast_ratestream(),
which provides the sample rate of the format associated
with the stream, and updates the app_voicemail function
for ast_app_copy_recording_to_vm to calculate the right
duration.
Review: https://reviewboard.asterisk.org/r/3996/
ASTERISK-24328 #close
........
Merged revisions 423192 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_play_and_record_full() has a parameter called "acceptdtmf" that is a
string of acceptable DTMF digits that may be pressed by a caller to end
and accept the recording.
ARI uses this function in order to perform recording, and it provides
options for what is passed as acceptdtmf to ast_play_and_record_full().
By default, ARI passes an empty string, with the intention that no DTMF
can be used to end the recording.
The problem is that ast_play_and_record_full() attempts to be "helpful"
by setting "#" as the acceptdtmf if an empty string or NULL pointer
has been passed in. With ARI, this results in unexpected behavior
occurring if you have attempted to intercept "#" yourself in order
to perform some other manipulation of the live recording.
This change removes the "helpful" behavior by no longer accepting
"#" as a default acceptdtmf if none is specified by the caller of
ast_play_and_record_full(). This makes the ARI scenario work as
expected.
The other callers of ast_play_and_record_full() are app_voicemail
and app_minivm, and in both cases, they pass an explicit "#" to
ast_play_and_record_full() as acceptdtmf, so they are unaffected
by this change.
........
Merged revisions 422964 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422965 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a CDR is forked, a new CDR is created and appended to the CDR chain for
the Party A. The forked CDR starts life off as a clone of the last
non-finalized for the particular Party A. In the past, merely copying over
the snapshots for Party A/Party B would be sufficient. However, as the CDRs
now contain cached information from Party A - specifically application/data,
context, and extension - we need to copy that over during a fork as well.
Huzzah for unit tests catching this when the context/extension were derived
from a cached value on the CDR instead of on Party A.
........
Merged revisions 422769 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422770 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On some systems, a timeval's tv_sec/tv_usec will be unsigned lont ints, as
opposed to long ints. When the RTP engine formats these as strings, it was
previously formatting them as signed integers, which can result in some
odd negative timestamp values (particularly on 32-bit systems). This patch
formats the values as unsigned long integers.
........
Merged revisions 422766 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422767 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The context/extension in a CDR is generally considered the destination of a
call. When looking at a 2-party call CDR, users will typically be presented
with the following:
context exten channel dest_channel app data
default 1000 SIP/8675309 SIP/1000 Dial SIP/1000,,20
However, if the Dial actually takes place in a Macro, the current behaviour
in 12 will result in the following CDR:
context exten channel dest_channel app data
macro-dial s SIP/8675309 SIP/1000 Dial SIP/1000,,20
The same is true of a GoSub:
context exten channel dest_channel app data
subs dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20
This generally makes the context/exten fields less than useful.
It isn't hard to preserve these values in the CDR state machine; however, we
need to have something that informs us when a channel is executing a
subroutine. Prior to this patch, there isn't anything that does this.
This patch solves this problem by adding a new channel flag,
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
Macro or a GoSub. The CDR engine looks for this value when updating a Party A
snapshot; if the flag is present, we don't override the context/exten on the
main CDR object. In a funny quirk, executing a hangup handler must *not* abide
by this logic, as the endbeforehexten logic assumes that the user wants to see
data that occurs in hangup logic, which includes those subroutines. Since
those execute outside of a typical Dial operation (and will typically have
their own dedicated CDR anyway), this is unlikely to cause any heartburn.
Review: https://reviewboard.asterisk.org/r/3962/
ASTERISK-24254 #close
Reported by: tm1000, Tony Lewis
Tested by: Tony Lewis
........
Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes an issue where CDRs would get stuck generating an infinite
number of CDRs, eventually crashing Asterisk (and consuming a lot of memory
along the way).
When a channel enters into a multi-party bridge, the CDR engine creates
mappings of each participant to each other participant, picking the 'A' party
as it goes. So, if we have four channels in a multi-party bridge (Alice, Bob,
Charlie, Denise), we would have something like:
Alice => Bob
Alice => Charlie
Alice => Denise
Bob => Charlie
Bob => Denise
Charlie => Denise
This works fine when participants enter the bridge a single time.
When a participant leaves a bridge, the CDRs for that channel are transitioned
to a finalized state.
The bug occurs if Bob rejoins. When the CDR engine creates mappings between the
channels, it walks through all the participants currently in the bridge, and
realizes that no one in the bridge can create a CDR with the channel (Bob).
As such it creates a new CDR for the candidate and appends it to that
candidate's chain. Unfortunately, on this particular code path, it doesn't
stop traversing the candidate's chain. Since we just added ourselves to the
chain, this causes the loop to keep going, constantly adding new CDRs.
This patch makes it so the engine bails when it creates a CDR match in this
case.
Review: https://reviewboard.asterisk.org/r/3964/
ASTERISK-24241 #close
Reported by: Deepak Singh Rawat
Tested by: Deepak Singh Rawat
ASTERISK-24208
Reported by: Frankie Chin
........
Merged revisions 422715 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422716 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds an option to the dial API that marks an outgoing dial as replacing the dialing channel for the purpose of propagating accountcode. When it is used, AST_CHANNEL_REQUESTOR_REPLACEMENT is used instead of AST_CHANNEL_REQUESTOR_BRIDGE_PEER when setting accountcodes on the involved channels with ast_channel_req_accountcodes.
Review: https://reviewboard.asterisk.org/r/3968/
........
Merged revisions 422684 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When scheduled tasks run, they are removed from the heap (or hashtab).
When a scheduled task is deleted, if the task can't be found in the
heap (or hashtab), an assertion is triggered. If DO_CRASH is enabled,
this assertion causes a crash.
The problem is, sometimes it just so happens that someone attempts
to delete a scheduled task at the time that it is running, leading
to a crash. This change corrects the issue by tracking which task
is currently running. If that task is attempted to be deleted,
then we mark the task, and then wait for the task to complete.
This way, we can be sure to coordinate task deletion and memory
freeing.
ASTERISK-24212
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/3927
........
Merged revisions 422070 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422071 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When issuing a POST /channels/{channel_id}/play on a channel that is not
yet answered, ARI is supposed to:
* Queue up an AST_CONTROL_PROGRESS on the channel
* Start up the playback of the media
Instead, we sneak an answer on the channel right before starting playing media.
This is due to ARI's usage of control_streamfile. This function implicitly
answers the channel (and doesn't give ARI the option to stop it). The answering
of the channel here is probably unnecessary:
* app_voicemail, by far the biggest consumer of this function, always answers
the channels anyway
* control stream file (in res_agi) and ControlPlayback probably shouldn't be
implicitly answering the channel. Answering should not be tied directly to
playing back media.
As it turns out, the answering of the channel here is pretty old:
356042 twilson if (ast_channel_state(chan) != AST_STATE_UP) {
3087 anthm res = ast_answer(chan);
180259 tilghman }
(As in, ancient?)
Note that others ran into this problem and commented about it on various
mailing lists.
Review: https://reviewboard.asterisk.org/r/3907/
ASTERISK-24229 #close
Reported by: Matt Jordan
........
Merged revisions 421695 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421696 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes gcc warnings that occur due to the type qualifier 'const'
being ignored on a return type of int.
ASTERISK-24246 #close
Reported by: Shaun Ruffell
patches:
0001-main-uri-Quiet-warning-about-ignored-attribute-on-re.patch uploaded by Shaun Ruffell (License 5417)
........
Merged revisions 421675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On a SIP reinvite that changes media strams, the PJSIP channel driver was
flooding the log with "Asked to transmit frame type %s, while native
formats is %s" warnings.
* Fixes PJSIP not setting up translation paths when the formats change on
a reinvite. AFS-63 was effectively reintroduced because of the media
formats work. res_pjsip_sdp_rtp.c:set_caps()
* Improved the unexpected frame format WARNING message to include more
information.
* Added protective locking while altering formats on a channel. Reworked
set_format() to simplify and protect the formats under manipulation.
* Restored some code that got lost in the media_formats work.
(channel.c:set_format() and res_pjsip_sdp_rtp.c:set_caps())
AFS-137 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3906/
........
Merged revisions 421645 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Joshua Colp
Kinsey Moore
George Joseph
Richard Mudgett
Matthew Jordan
Corey Farrell
Walter Doekes
Jonathan Rose
Mark Michelson
Scott Griepentrog