When a config file is read, an unescaped semicolon signals comments which are
stripped from the value before it's stored. Escaped semicolons are then
unescaped and become part of the value. Both of these behaviors are normal
and expected. When the config is serialized either by 'dialplan save' or
AMI/UpdateConfig however, the now unescaped semicolons are written as-is.
If you actually reload the file just saved, the unescaped semicolons are
now treated as start of comments.
Since true comments are stripped on read, any semicolons in
ast_variable.value must have been escaped originally. This patch
re-escapes semicolons in ast_variable.values before they're written to
file either by 'dialplan save' or config/ast_config_text_file_save which
is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting
issues nearby in pbx_config.c
Tested-by: George Joseph
ASTERISK-20127 #close
Review: https://reviewboard.asterisk.org/r/4132/
........
Merged revisions 427275 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427276 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel is imparted to a bridge, the invocation of the function may
provide an ast_bridge_features struct. Upon passing this to ast_bridge_impart,
the caller must assume that ownership has passed to the function, as in all
paths the function destroys the struct prior to returning (as its purpose is
to configure the behavior of the channel while in the bridge). On one off
nominal path - where the channel already has a PBX thread - the struct was not
being destroyed.
This patch fixes that glitch.
ASTERISK-24437 #close
Reported by: Scott Griepentrog
........
Merged revisions 426431 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 426432 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix the AMI Status action read and write translation path strings from
growing for each channel in the status event list by reseting the ast
string given to ast_translate_path_to_str() to fill in the given
translation path.
........
Merged revisions 426079 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two aspects to the vulnerability:
(1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use
TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the
TCP/TLS core, which should be done as an improvement at a latter date.
(2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified,
will default to the OpenSSL SSLv23_method. This method allows for all
ecnryption methods, including SSLv2/SSLv3. A MITM can exploit this by
forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE.
This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration,
and explicitly disables SSLv2/SSLv3 if using SSLv23_method.
For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is
explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or
SSLv3.
Much thanks to abelbeck for reporting the vulnerability and providing a patch
for the res_jabber/res_xmpp modules.
Review: https://reviewboard.asterisk.org/r/4096/
ASTERISK-24425 #close
Reported by: abelbeck
Tested by: abelbeck, opsmonitor, gtjoseph
patches:
asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903)
asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903)
AST-2014-011-1.8.diff uploaded by mjordan (License 6283)
AST-2014-011-11.diff uploaded by mjordan (License 6283)
........
Merged revisions 425987 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425991 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tasks that were marked for pending deletion in the scheduler would be moved to
the cache for later reuse, but after being recycled the deleted mark wouldn't
be removed resulting in fresh tasks being deleted without reason... and
immediately moved back into the cache where they could be reused again. This
could cause horrendous things to happen in just about anything that used a
scheduler.
ASTERISK-24321 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4071/
........
Merged revisions 425503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Masquerades into and out of channels that are involved in a dial operation
don't create the expected dial end event. The missing dial end event goes
against the model for things like CDRs and generating Dial end manager
actions and such.
There are four cases:
1) A channel masquerades into the caller channel. The case happens when
performing a blonde transfer using the channel driver's protocol.
2) A channel masquerades into a callee channel. The case happens when
performing a directed call pickup.
3) The caller channel masquerades out of dial. The case happens when
using the Bridge application on the caller channel.
4) A callee channel masquerades out of dial. The case happens when using
the Bridge application on a peer channel.
As it turned out, all four cases need to be handled instead of just the
first one.
ASTERISK-24237
Reported by: Richard Mudgett
ASTERISK-24394 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4066/
........
Merged revisions 425430 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425455 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides the capability to manipulate templates and categories
with non-unique names via AMI.
Summary of changes:
GetConfig and GetConfigJSON: Added "Filter" parameter: A comma separated list
of name_regex=value_regex expressions which will cause only categories whose
variables match all expressions to be considered. The special variable name
TEMPLATES can be used to control whether templates are included. Passing
'include' as the value will include templates along with normal categories.
Passing 'restrict' as the value will restrict the operation to ONLY templates.
Not specifying a TEMPLATES expression results in the current default behavior
which is to not include templates.
UpdateConfig: NewCat now includes options for allowing duplicate category
names, indicating if the category should be created as a template, and
specifying templates the category should inherit from. The rest of the
actions now accept a filter string as defined above. If there are non-unique
category names, you can now update specific ones based on variable values.
To facilitate the new capabilities in manager, corresponding changes had to be
made to config, most notably the addition of filter criteria to many of the
APIs. In some cases it was easy to change the references to use the new
prototype but others would have required touching too many files for this
patch so a wrapper with the original prototype was created. Macros couldn't
be used in this case because it would break binary compatibility with modules
such as res_digium_phone that are linked to real symbols.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4033/
........
Merged revisions 425383 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425384 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.
This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
........
Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds the AllVariables parameter to the Status AMI action such that
if defined and set to "true", all channel variables will be reported in
the subsequent Status event(s). This parameter does not negate the
functionality of the "Variables" parameter so that global variables and
dialplan functions can be requested.
Review: https://reviewboard.asterisk.org/r/3915/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a few issues:
1) The order of Dial events have been changed when performing a call forward.
The order has now been altered to
1) Dial begins dialing channel A.
2) When A forwards the call to B, we issue the dial end event to channel
A, indicating the dial is being canceled due to a forward to B.
3) When the call to channel B occurs, we then issue a new dial begin to
channel B.
2) Call forwards are now reported on the calling channel, not the peer channel.
3) AMI DialEnd events have been altered to display the extension the call is
being forwarded to when relevant.
4) You can now get the values of channel variables for channels that are not
currently in the Stasis application. This brings the retrieval of channel
variables more in line with the rest of channel read operations since they
may be performed on channels not in Stasis.
ASTERISK-24134 #close
Reported by Matt Jordan
ASTERISK-24138 #close
Reported by Matt Jordan
Patches:
forward-shenanigans.diff uploaded by Matt Jordan (License #6283)
Review: https://reviewboard.asterisk.org/r/3899
........
Merged revisions 420794 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL typically tracks a lot of information using the unique ID of the channel.
This is typically needed due to tying events together using the linked ID of
the various channels involved in a "call", which is derived from the channel ID
of the oldest channel involved in a bridge (or in the case of a Dial, the
parent channel).
Previously, we had updated the extra fields to include the involved channel
names, but forgot to put in the unique ID. This patch corrects that error.
........
Merged revisions 421037 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421042 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a manager or CLI user attached a mixmonitor to a call running a dynamic
bridge feature while in a bridge, the feature would be interrupted and the
channel would be forcibly kicked out of the bridge (usually ending the call
during a simple 1 to 1 call). This would also occur during any similar action
that could set the unbridge soft hangup flag, so the fix for this was to
remove unbridge from the soft hangup flags and make it a separate thing all
together.
ASTERISK-24027 #close
Reported by: mjordan
Review: https://reviewboard.asterisk.org/r/3900/
........
Merged revisions 420934 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 420940 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit adds the ability for a user to configure
a resource list in pjsip.conf. Subscribing to this
list simultaneously subscribes the subscriber to all
resources listed. This has the potential to reduce
the amount of SIP traffic when loads of subscribers
on a system attempt to subscribe to each others' states.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed the iax.conf bandwidth option. This is the root cause of
ASTERISK-24150.
* Added checks in iax2_request() to ensure that there are actual formats
requested for the new channel to prevent any more fracks from issues like
ASTERISK-24150. This is a consequence of the iax.conf bandwidth option
not working.
* Fixed struct iax2_codec_pref.order member size mismatch issue when
converting to and from the codec preference order list passed over the
wire. In addition the values sent over the wire are now compatible with
previous Asterisk versions.
* Fixed several issues dealing with the struct iax2_codec_pref members.
Off-by-one, array limit errors, and the order/framing members always need
to be updated together.
* Made iax2_request() setup the channel's native format preference order
according to the user's wishes. The new media format strategy needs the
order specified earler.
* Fixed usage of ast_format_compatibility_bitfield2format(). The function
can return NULL if the bitfield was not associated with a function.
* Deleted dead code iax2_codec_pref_getsize() and
iax2_codec_pref_setsize().
* Made iax2_parse_allow_disallow() and iax2_codec_pref_string() call
iax2_codec_pref_to_cap() instead of inlining it.
* Made IAX_CAPABILITY_MEDBANDWIDTH, IAX_CAPABILITY_LOWBANDWIDTH, and
IAX_CAPABILITY_LOWFREE constants again as they were in Asterisk v1.8.
* Renamed prefs to prefs_global so it won't get confused with the local
pref versions.
* Fixed too small buffer in handle_cli_iax2_show_peer().
* Fixed ast_cli() calls in handle_cli_iax2_show_peer() to output complete
lines.
* Changed struct create_addr_info.prefs to be struct iax2_codec_pref as an
optimization so iax2_request() and iax2_call() do less work.
* Fixed a potential deadlock in ast_iax2_new() on an off-nominal path when
the pbx could not get started.
* Made set_config() setup a local prefs list along side the local
capability format bitfield. Once the config is loaded, then the local
copies are put into the global versions.
* Fix unininialized codec_buf in function_iaxpeer().
ASTERISK-24150 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3890/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Hints that are a pattern match are technically stored in the hint container in
the same fashion as concrete implementations of hints. The pattern matching
hints, however, are not "real" in the sense that things can subscribe to them:
rather, they are stored in the hints container so that when a subscription is
made a "real" hint can be generated for the subscription if one does not yet
exist. The extension state core takes care of this correctly by matching
against non-pattern matching extensions prior to pattern matching extensions.
Because of this, however, the ExtensionStateList AMI action was returning
pattern matching hints when executed. These hints are meaningless from the
perspective of AMI clients: their state will never change, they cannot be
subscribed to, and events would never normally be generated from them. As such,
we now filter these out of the response.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-23818 (lua contexts being overwritten by contexts of the same name in
pbx_config) surfaced because pbx_lua, having the AST_MODFLAG_GLOBAL_SYMBOLS
set, was always force loaded before pbx_config. Since I couldn't find any
reason for pbx_lua to export it's symbols to the rest of Asterisk, I simply
changed the flag to AST_MODFLAG_DEFAULT. Problem solved. What I didn't
realize was that the symbols need to be exported not because Asterisk needs
them but because any external Lua modules like luasql.mysql need the base
Lua language APIs exported (ASTERISK-17279).
Back to ASTERISK-23818... It looks like there's an issue in pbx.c where
context_merge was only merging includes, switches and ignore patterns if
the context was already existing AND has extensions, or if the context was
brand new. If pbx_lua is loaded before pbx_config, the context will exist
BUT pbx_lua, being implemented as a switch, will never place extensions in
it, just the switch statement. The result is that when pbx_config loads,
it never merges the switch statement created by pbx_lua into the final
context.
This patch sets pbx_lua's modflag back to AST_MODFLAG_GLOBAL_SYMBOLS and adds
an "else if" in context_merge that catches the case where an existing context
has includes, switchs or ingore patterns but no actual extensions.
ASTERISK-23818 #close
Reported by: Dennis Guse
Reported by: Timo Teräs
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3891/
........
Merged revisions 420146 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 420147 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 420148 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420149 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces stasis.conf and a mechanism to prevent certain message
types from being published. Internally, this works by preventing the
chosen message types from being created which ensures that those
message types can never be published. This patch also adjusts message
publishers such that message payloads are not created if the related
message type is not available.
ASTERISK-23943 #close
Review: https://reviewboard.asterisk.org/r/3823/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.
Inbound messages can now be received over ARI as well. An ARI application that
subscribes to endpoints will receive messages from those endpoints:
{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" <sip:alice@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has
two callbacks: one to determine if the handler has a destination for the
message, and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them.
Various other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when
the lifetime of things is well defined and the number of things is very
small.
res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.
Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
fix for that as well.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new module to Asterisk, res_hep_rtcp. The module subscribes
to the RTCP topics in Stasis and receives RTCP information back from the
message bus. It encodes into HEPv3 packets and sends the information to the
res_hep module for transmission.
Using this, someone with a Homer server can get live call quality monitoring
for all RTP-based channels in their Asterisk 12+ systems.
In addition, there were a few bugs in the RTP engine, res_rtp_asterisk, and
chan_pjsip that were uncovered by the tests written for the Asterisk Test
Suite. This patch fixes the following:
1) chan_pjsip failed to set its channel unique ids on its RTP instance on
outbound calls. It now does this in the appropriate location, in the
serialized call callback.
2) The rtp_engine was overflowing some values when packed into JSON.
Specifically, some longs and unsigned ints can't be be packed into integer
values, for obvious reasons. Since libjansson only supports integers,
floats, strings, booleans, and objects, we print these values into strings.
3) res_rtp_asterisk had a few problems:
(a) it would emit a source IP address of 0.0.0.0 if bound to that IP
address. We now use ast_find_ourip to get a better IP address, and
properly marshal the result into an ast_strdupa'd string.
(b) Reports can be generated with no report bodies. In particular, this
occurs when a sender is transmitting information to a receiver (who
will send no RTP back to the sender). As such, the sender has no report
body for what it received. We now properly handle this case, and the
sender will emit SR reports with no body. Likewise, if we receive an
RTCP packet with no report body, we will still generate the appropriate
events.
ASTERISK-24119 #close
........
Merged revisions 419823 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for an <example /> tag in the XML documentation schema.
For CLI help, this doesn't change the formatting too much:
- Preceeding white space is removed
- Unlike with para elements, new lines are preserved
However, having an <example /> tag in the XML schema allows for the wiki
documentation generation script to surround the documentation with {code} or
{noformat} tags, generating much better content for the wiki - and allowing us
to put dialplan examples (and other code snippets, if desired) into the
documentation for an application/function/AMI command/etc.
Review: https://reviewboard.asterisk.org/r/3807/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds three new AMI commands:
* ExtensionStateList (pbx.c) - list all known extension state hints
and their current statuses. Events emitted by the list action are
equivalent to the ExtensionStatus events.
* PresenceStateList (res_manager_presencestate) - list all known
presence state values. Events emitted are generated by the stasis
message type, and hence are PresenceStateChange events.
* DeviceStateList (res_manager_devicestate) - list all known device
state values. Events emitted are generated by the stasis message
type, and hence are DeviceStateChange events.
Patch-by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3799/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-24124 #close
Reported by Matt Jordan
AFS-131 #close
Reported by Matt Jordan
Patches:
userevent.patch uploaded by Matt Jordan (License #6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When creating the alphabetical sorted list each module is added to a list
temporarily. On the second iteration each module already has a pointer to
another module, causing stuff to go into a loop.
ASTERISK-24123 #close
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "bridge destroy" CLI command is invasive to bridges and can leave them in an unexpected
state for the users of them. Since this command may be useful for developers it is now
only available when developer mode is available. To take its place "all" has been added
as a valid option to the "bridge kick" CLI command. It will kick all of the channels
in the bridge out.
ASTERISK-23987
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3840/
........
Merged revisions 419536 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous behavior was to simply set the accountcode of an outgoing
channel to the accountcode of the channel initiating the call. It was
done this way a long time ago to allow the accountcode set on the SIP/100
channel to be propagated to a local channel so the dialplan execution on
the Local;2 channel would have the SIP/100 accountcode available.
SIP/100 -> Local;1/Local;2 -> SIP/200
Propagating the SIP/100 accountcode to the local channels is very useful.
Without any dialplan manipulation, all channels in this call would have
the same accountcode.
Using dialplan, you can set a different accountcode on the SIP/200 channel
either by setting the accountcode on the Local;2 channel or by the Dial
application's b(pre-dial), M(macro) or U(gosub) options, or by the
FollowMe application's b(pre-dial) option, or by the Queue application's
macro or gosub options. Before Asterisk v12, the altered accountcode on
SIP/200 will remain until the local channels optimize out and the
accountcode would change to the SIP/100 accountcode.
Asterisk v1.8 attempted to add peeraccount support but ultimately had to
punt on the support. The peeraccount support was rendered useless because
of how the CDR code needed to unconditionally force the caller's
accountcode onto the peer channel's accountcode. The CEL events were thus
intentionally made to always use the channel's accountcode as the
peeraccount value.
With the arrival of Asterisk v12, the situation has improved somewhat so
peeraccount support can be made to work. Using the indicated example, the
the accountcode values become as follows when the peeraccount is set on
SIP/100 before calling SIP/200:
SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200
acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200
peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100
If a channel already has an accountcode it can only change by the
following explicit user actions:
1) A channel originate method that can specify an accountcode to use.
2) The calling channel propagating its non-empty peeraccount or its
non-empty accountcode if the peeraccount was empty to the outgoing
channel's accountcode before initiating the dial. e.g., Dial and
FollowMe. The exception to this propagation method is Queue. Queue will
only propagate peeraccounts this way only if the outgoing channel does not
have an accountcode.
3) Dialplan using CHANNEL(accountcode).
4) Dialplan using CHANNEL(peeraccount) on the other end of a local
channel pair.
If a channel does not have an accountcode it can get one from the
following places:
1) The channel driver's configuration at channel creation.
2) Explicit user action as already indicated.
3) Entering a basic or stasis-mixing bridge from a peer channel's
peeraccount value.
You can specify the accountcode for an outgoing channel by setting the
CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue
applications. Queue adds the wrinkle that it will not overwrite an
existing accountcode on the outgoing channel with the calling channels
values.
Accountcode and peeraccount values propagate to an outgoing channel before
dialing. Accountcodes also propagate when channels enter or leave a basic
or stasis-mixing bridge. The peeraccount value only makes sense for
mixing bridges with two channels; it is meaningless otherwise.
* Made peeraccount functional by changing accountcode propagation as
described above.
* Fixed CEL extracting the wrong ie value for the peeraccount. This was
done intentionally in Asterisk v1.8 when that version had to punt on
peeraccount.
* Fixed a few places dealing with accountcodes that were reading from
channels without the lock held.
AFS-65 #close
Review: https://reviewboard.asterisk.org/r/3601/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk, it is possible for a device to have a status of ONHOLD. This is
not typically an easy thing to determine, as a channel being on hold is not
a direct channel state. Typically, this has to be calculated outside of the
core independently in channel drivers, notably, chan_sip and chan_pjsip. Both
of these channel drivers already have to calculate device state in a fashion
more complex than the core can handle, as they aggregate all state of all
channels associated with a peer/endpoint; they also independently track
whether or not one of those channels is currently on hold and mark the device
state appropriately.
In 12+, we now have the ability to report an AST_DEVICE_ONHOLD state for all
channels that defer their device state to the core. This is due to channel hold
state actually now being tracked on the channel itself. If a channel driver
defers its device state to the core (which many, such as DAHDI, IAX2, and
others do in most situations), the device state core already goes out to get a
channel associated with the device. As such, it can now also factor the channel
hold state in its calculation.
This patch adds this logic to the device state core. It also uses an existing
mapping between device state and channel state to handle more channel states.
chan_pjsip has been updated slightly as well to make use of this (as it was,
for some reason, reporting a channel state of BUSY as a device state of INUSE,
which feels slightly wrong).
Review: https://reviewboard.asterisk.org/r/3771/
ASTERISK-24038 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
(1) It updates the unit tests to expect additional stasis messages. More
messages are now sent to the endpoint topic, due to forwarding all
channel messages and the forwarding relationship set up between
endpoints themselves.
(2) Remove the technology forwarding subscription during
ast_endpoint_shutdown. This prevents an improper double shutdown of
an endpoint from occurring.
........
Merged revisions 419318 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Say you wanted to include variables in an application map and have those
variables substituted and passed along to the application being executed;
currently this does not happen.
This patch adds this ability to pass channel variable values to an
application before being executed.
ASTERISK-22608 #close
Reported by: Michael L. Young
patches:
features_substitute_arguments_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3819/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When updating a row, we are currently doing an INSERT OR REPLACE INTO. The
downside to this is that the row is deleted if it exists and then a new row is
inserted. So, we are hitting the disk twice. One for the deletion and one for
the insertion.
This patch changes this statement to an INSERT INTO and if the insert fails
because a row with that key exists, we will IGNORE the failure. Then we will
attempt to perform an UPDATE on the existing row if that row wasn't just
INSERTed.
ASTERISK-24050 #close
Reported by: Michael L. Young
patches:
astdb-insert-update-io-help_trunk_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3815/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
for sending/receiving arbitrary out of call text messages through ARI in a
technology agnostic fashion.
The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
arbitrary technology defined URI. This is less straight forward, as
endpoints are formed from a tech + resource pair. We don't have a
mechanism to note that a technology that *may* have endpoints exists.
This patch provides such a mechanism, and fixes a few bugs along the way.
The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
most of the interesting bits (such as channel creation, destruction, state
changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
This resulted in endpoints missing the channel creation message, which
limited the usefulness of the subscription in the first place (a major use
case being 'tell me when this endpoint has a channel'). Unfortunately,
this meant another parameter to ast_channel_alloc. Since not all channel
technologies support an ast_endpoint, this patch makes such a call
optional and opts for a new function, ast_channel_alloc_with_endpoint.
When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.
Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
ARI, through the applications resource, can:
- subscribe to endpoint:PJSIP/foo and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
- subscribe to endpoint:PJSIP/bar and get notifications for channels
PJSIP/bar-1 and endpoint PJSIP/bar
- subscribe to endpoint:PJSIP and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).
This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents a crash in the Dial API triggered by use of the Page()
application where a format capability struct was used before checking
whether it was NULL.
ASTERISK-24074 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a reference count goes negative, instead of
just logging that fact, be more helpful with a
backtrace and an assert that will DO_CRASH.
This patch also removes the duplicate ao2_bt()
function and cleans up extraneous usage of the
ast_log_backtrace() call.
Review: https://reviewboard.asterisk.org/r/3765/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.
Review: https://reviewboard.asterisk.org/r/3721/
........
Merged revisions 418914 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418936 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the PresenceState action is executed, the nominal path fails to include
the ActionID in the successful response. This patch adds a call to
astman_start_ack, which guarantees that an ActionID (if provided) will be
sent back to the AMI client.
Unlike the Asterisk 11 and 12 patches, this patch also deprecates the
duplicate Message key in the response to the action, replacing it with the
key 'PresenceMessage'.
Review: https://reviewboard.asterisk.org/r/3776/
ASTERISK-23985 #close
........
Merged revisions 418713 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 418714 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Create a Stasis bridge sub-class to propagate linkedids and
accountcodes.
* Fixed the basic bridge sub-class to update peeraccount codes when the
number of channels in the bridge drops back down to two parties.
* Refactored ast_bridge_channel_update_accountcodes() to handle channels
joining/leaving the bridge.
* Fixed the basic bridge sub-class to not call the base bridge class pull
method twice.
AFS-105 #close
ASTERISK-23852 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/3720/
........
Merged revisions 418225 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects two issues with the extra field information in Asterisk
12+ in channel event logs.
It is possible to inject custom values into the dialstatus provided by
ast_channel_dial_type() Stasis messages that fall outside the
enumeration allowed for the DIALSTATUS channel variable. CEL now
filters for the allowed values and ignores other values.
The "hangupsource" extra field key is always blank if the far end
channel is a chan_pjsip channel. This is because the hangupsource is
never set for the pjsip channel driver. This change sets the
hangupsource whenever a hangup is queued for chan_pjsip channels.
This corrects an issue with the pjsip channel driver where the
hangupcause information was not being set properly.
Review: https://reviewboard.asterisk.org/r/3690/
........
Merged revisions 418071 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous patch (r418034) fixed the 'glitch' that the channels/h323
Makefile no longer existed. Unfortunately, removing the entire line was a bit
of a blunder, as it meant that build_tools/menuselect-deps was never
generated. Hilarity ensued when actually trying to compile.
But hey! At least configure worked.
This patch fixes *that* glitch, and removes some more of the vestiges of h323.
(It had tendrils in the main Makefile? Crazy.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Billing records are fair,
To get paid is quite bright,
You should really use ODBC;
Good-bye cdr_sqlite.
Microsoft did once push H.323,
Hell, we all remember NetMeeting.
But try to compile chan_h323 now
And you will take quite a beating.
The XMPP and SIP war was fierce,
And in the distant fray
Was birthed res_jabber/chan_jingle;
But neither to stay.
For everyone did care and chase what Google professed.
"Free Internet Calling" was what devotees cried,
But Google did change the specs so often
That the developers were happy the day chan_gtalk died.
And then there was that odd application
Dedicated to the Polish tongue.
app_saycountpl was subsumed by Say;
One could say its bell was rung.
To read and parse a file from the dialplan
You could (I guess) use an application.
app_readfile did fill that purpose, but I think
A function is perhaps better in its creation.
Barging is rude, I'm not sure why we do it.
Inwardly, the caller will probably sigh.
But if you really must do it,
Don't use app_dahdibarge, use ChanSpy.
We all despise the sound of tinny robots
It makes our queues so cold.
To control such an abomination
It's better to not use Wait/SetMusicOnHold.
It's often nice to know properties of a channel
It makes our calls right
We have a nice function called CHANNEL
And so SIPCHANINFO is sent off into the night.
And now things get odd;
Apparently one could delimit with a colon
Properties from the SIPPEER function!
Commas are in; all others are done.
Finally, a word on pipes and commas.
We're sorry. We can't say it enough.
But those compatibility options in asterisk.conf;
To maintain them forever was just too tough.
This patch removes:
* cdr_sqlite
* chan_gtalk
* chan_jingle
* chan_h323
* res_jabber
* app_saycountpl
* app_readfile
* app_dahdibarge
It removes the following applications/functions:
* WaitMusicOnHold
* SetMusicOnHold
* SIPCHANINFO
It removes the colon delimiter from the SIPPEER function.
Finally, it also removes all compatibility options that were configurable from
asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems.
Review: https://reviewboard.asterisk.org/r/3698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Persistent HTTP connection support is needed due to the increased usage of
the Asterisk core HTTP transport and the frequency at which REST API calls
are going to be issued.
* Add http.conf session_keep_alive option to enable persistent
connections.
* Parse and discard optional chunked body extension information and
trailing request headers.
* Increased the maximum application/json and
application/x-www-form-urlencoded body size allowed to 4k. The previous
1k was kind of small.
* Removed a couple inlined versions of ast_http_manid_from_vars() by
calling the function. manager.c:generic_http_callback() and
res_http_post.c:http_post_callback()
* Add missing va_end() in ast_ari_response_error().
* Eliminated unnecessary RAII_VAR() use in http.c:auth_create().
ASTERISK-23552 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3691/
........
Merged revisions 417880 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The patch for ASTERISK-23905 that added PFS support in Asterisk depends on the
elliptic curve library support being present in OpenSSL. As it turns out, some
versions of OpenSSL don't have this library - notably the version running on
our build agents.
This patch fixes the build by providing a configure check for the specific
library calls that the PFS patch relies on.
Review: https://reviewboard.asterisk.org/r/3709/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch enables Perfect Forward Secrecy (PFS) in Asterisk's core TLS API.
Modules that wish to enable PFS should consider the following:
- Ephemeral ECDH (ECDHE) is enabled by default. To disable it, do not
specify a ECDHE cipher suite in a module's configuration, for example:
tlscipher=AES128-SHA:DES-CBC3-SHA
- Ephemeral DH (DHE) is disabled by default. To enable it, add DH parameters
into the private key file, i.e., tlsprivatekey. For an example, see the
default dh2048.pem at
http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-35.1/src/apps/dh2048.pem?txt
- Because clients expect the server to prefer PFS, and because OpenSSL sorts
its cipher suites by bit strength, (see "openssl ciphers -v DEFAULT")
consider re-ordering your cipher suites in the conf file. For example:
tlscipher=AES128+kEECDH:AES128+kEDH:3DES+kEDH:AES128-SHA:DES-CBC3-SHA:-ADH:-AECDH
will use PFS when offered by the client. Clients which do not offer PFS
fall-back to AES-128 (or even 3DES as recommend by RFC 3261).
Review: https://reviewboard.asterisk.org/r/3647/
ASTERISK-23905 #close
Reported by: Alexander Traud
patches:
tlsPFS_for_HEAD.patch uploaded by Alexander Traud (License 6520)
tlsPFS.patch uploaded by Alexander Traud (License 6520)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A loop in ast_careful_fwrite exists that will continually attempt to write to
a file stream, even in the presence of EAGAIN/EINTR errors. However, if a
connection that uses ast_careful_fwrite closes suddenly, ast_careful_fwrite's
call to fflush may return EAGAIN/EINTER along with EOF. A subsequent call to
fflush will return EOF but not clear errno, resulting in an infinite loop.
This patch clears errno after it is detected and handled the loop, such that
any subsequent call to fflush will not get erroneously stuck.
Review: https://reviewboard.asterisk.org/r/3704
#ASTERISK-23984 #close
Reported by: Steve Davies
patches:
fflush_loop_fix uploaded by one47 (License 5012)
........
Merged revisions 417797 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 417798 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417799 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417800 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip and chan_pjsip have also been added to
allow behavior to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
Review: https://reviewboard.asterisk.org/r/3686/
........
Merged revisions 417678 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Corey Farrell
Joshua Colp
Richard Mudgett
George Joseph
Matthew Jordan
Jonathan Rose
Kinsey Moore
Walter Doekes
Mark Michelson
Scott Griepentrog
Rusty Newton
Michael L. Young
Sean Bright