In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
........
Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The UW IMAP library is instrinsically not thread-safe, and relies upon higher
level applications to guarantee thread safety. For the most part, this is
provided by the vms object, which provides locking for individual streams.
Unfortunately, this is not sufficient for calls to mail_open which create the
IMAP stream. mail_open can, on some systems, call into a UW IMAP specific
function for determining the address of a system based on a hostname,
ip_nametoaddr.
In the ip6_unix implementation of this function, static variables are used
to hold parsing buffers. This can cause a crash if multiple threads attempt
to convert a hostname to an address at the same time. Locking on a single
mail stream is not sufficient to prevent simultaneous access to these static
variables.
In the IMAP library, this function can be called from the mail_open and
imap_status functions. As the imap_status function is not used by
app_voicemail, locking on access to mail_open is sufficient to prevent
any mangling of the buffers.
Review: https://reviewboard.asterisk.org/r/4188/
ASTERISK-24516 #close
Reported by: David Duncan Ross Palmer
Tested by: David Duncan Ross Palmer
patches:
ASTERISK-24516.diff uploaded by David Duncan Ross Palmer (License 6660)
........
Merged revisions 428863 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428864 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428865 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Confbridge dialplan function permission escalation via AMI and inappropriate
class authorization on the ConfbridgeStartRecord action. The CONFBRIDGE dialplan
function when executed from an external protocol (for instance AMI), could
result in a privilege escalation. Also, the AMI action “ConfbridgeStartRecord”
could also be used to execute arbitrary system commands without first checking
for system access. The AMI “ConfbridgeStopRecord” has also been updated to
only run under a system authorization.
Asterisk now inhibits the CONFBRIDGE function from being executed from an
external interface if the live_dangerously option is set to no. Also, the
“ConfbridgeStartRecord” AMI action is now only allowed to execute under a
user with system level access.
ASTERISK-24490
Reported by: Gareth Palmer
........
Merged revisions 428332 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428334 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428339 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When r428077 was made for ASTERISK-24522, it failed to take into account users
who are neither wait_marked nor end_marked. These users are *also* supposed to
hear the 'leader has left the conference' message. Granted, this behaviour is
a bit odd; however, that is how it used to work... and behaviour changes are
not good.
This patch ensures that if there are any 'normal' users present when the last
marked user leaves the conference, the message will still be played to them.
Note that this regression was caught by the Asterisk Test Suite's
confbridge_nominal test, which has a quirky combination of users.
........
Merged revisions 428113 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428114 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428115 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Consider the following:
- A marked user in a conference
- One or more end_marked only users in the conference
When the marked users leaves, we will be in the conf_state_multi_marked state.
This currently will traverse the users, kicking out any who have the end_marked
flags. When they are kicked, a full ast_bridge_remove is immediately called on
the channels. At this time, we also unilaterally set the need_prompt flag.
When the need_prompt flag is set, we then playback a sound to the bridge
informing everyone that the leader has left; however, no one is left in the
bridge. This causes some odd behaviour for the end_marked users - they are
stuck waiting for the bridge to be unlocked. This results in them waiting for
5 or 6 seconds of dead air before hearing that they've been kicked.
Unfortunately, we do have to keep the bridge locked while we're playing back
the 'leader-has-left' prompt. If there are any wait_marked users in the
conference, this behaviour can't be easily changed - but we do make the case
of the end_marked users better with this patch.
Review: https://reviewboard.asterisk.org/r/4184/
ASTERISK-24522 #close
Reported by: Matt Jordan
........
Merged revisions 428077 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428078 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428079 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An issue existed in r420577, which added multiple recipients to voicemail
emails. The patch, when looking at the intended recipients, looked ahead for
the '|' character inside a while loop which already had pulled out the
appropriate field parsing on the '|' character. This would cause it to skip
the recipients.
This patch fixes it such that it relies completely on the while loop to parse
through the e-mail fields.
Note that the original author of the patch looked at this fix and approved it.
ASTERISK-24250 #close
Reported by: abelbeck
patches:
voicemail-420577-to-comma-fix.diff uploaded by abelbeck (License 5903)
........
Merged revisions 427585 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Made agent able to interrupt the alerting beep playback with DTMF. Any
digit can interrupt if the call does not need to be acknowledged. Only
the first digit of the acknowledgement can interrupt if the call needs to
be acknowledged. The agent interrupting the alerting playback builds on
the ASTERISK-24447 patch because it knows what digit interrupted the
playback and needs to be able to pass that digit to the DTMF hook digit
collection code.
ASTERISK-24257 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4123/
........
Merged revisions 427508 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427512 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427519 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
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
The QUEUE_GET_CHANNEL function returns the caller's channel name at the
specified position in a queue.
QUEUE_GET_CHANNEL(<queuename>[,<position>])
The queue position parameter defaults to 1 if not specified.
Noop(${QUEUE_GET_CHANNEL(queuename, 2)})
"SIP/peer-00000002", if queue exist and have at least 2 callers
Noop(${QUEUE_GET_CHANNEL(queuename, 1)})
Noop(${QUEUE_GET_CHANNEL(queuename)})
"SIP/peer-00000000", if queue exist and have at least 1 caller
ASTERISK-24365 #close
Reported by: Kristian Hogh
Patches:
queue_get_firstchannel.patch (license #6639) patch uploaded by Kristian Hogh
rb4035.patch (license #6639) patch uploaded by Kristian Hogh
Patch morphed from QUEUE_GET_FIRSTCHANEL to the more general QUEUE_GET_CHANNEL
on reviewbord.
Review: https://reviewboard.asterisk.org/r/4035/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424493 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
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
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 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
The same function, meetme_stasis_generate_msg, handles creating and publishing
Stasis message both when there are channels in the MeetMe conference and when
there are no channels in the conference. When the performance improvement was
made to use cached snapshots, this created a situation where Asterisk would
crash: obtaining a cached snapshot is not NULL tolerant.
This patch restores the previous implementation, which used a NULL safe set
of routines to produce a blob containing the channel snapshot (if available)
and information about the MeetMe conference.
ASTERISK-24234 #close
Reported by: Shaun Ruffell
Tested by: Shaun Ruffell
........
Merged revisions 421270 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421273 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421276 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 patch gives the optional ability to keep queue rules in RealTime. It is
important to note that with this patch:
(a) Queue rules in RealTime are only examined on module load/reload
(b) Queue rules are loaded both from the queuerules.conf file as well as the
RealTime backend
To inform app_queue to examine RealTime for queue rules, a new setting has been
added to queuerules.conf's general section "realtime_rules". RealTime queue
rules will only be used when this setting is set to "yes".
The schema for the database table supports a rule_name, time, min_penalty, and
max_penalty columns. min_penalty and max_penalty can be relative, if a '-' or
'+' literal is provided. Otherwise, the penalties are treated as constants.
For example:
rule_name, time, min_penalty, max_penalty
'default', '10', '20', '30'
'test2', '20', '30', '55'
'test2', '25', '-11', '+1111'
'test2', '400', '112', '333'
'test3', '0', '4564', '46546'
'test_rule', '40', '15', '50'
which would result in :
Rule: default
- After 10 seconds, adjust QUEUE_MAX_PENALTY to 30 and adjust
QUEUE_MIN_PENALTY to 20
Rule: test2
- After 20 seconds, adjust QUEUE_MAX_PENALTY to 55 and adjust
QUEUE_MIN_PENALTY to 30
- After 25 seconds, adjust QUEUE_MAX_PENALTY by 1111 and adjust
QUEUE_MIN_PENALTY by -11
- After 400 seconds, adjust QUEUE_MAX_PENALTY to 333 and adjust
QUEUE_MIN_PENALTY to 112
Rule: test3
- After 0 seconds, adjust QUEUE_MAX_PENALTY to 46546 and adjust
QUEUE_MIN_PENALTY to 4564
Rule: test_rule
- After 40 seconds, adjust QUEUE_MAX_PENALTY to 50 and adjust
QUEUE_MIN_PENALTY to 15
If you use RealTime, the queue rules will be always reloaded on a module
reload, even if the underlying file did not change. With the option disabled,
the rules will only be reloaded if the file was modified.
Review: https://reviewboard.asterisk.org/r/3607/
ASTERISK-23823 #close
Reported by: Michael K
patches:
app_queue.c_realtime_trunk.patch uploaded by Michael K (License 6621)
........
Merged revisions 420624 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420625 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
Bridges created by app_bridgewait previously had the "dissolve when empty" flag set.
This caused the bridge core to destroy them when the last channel had left. This
introduced a race condition where we may have a reference to the bridge but it is
not actually joinable when we try to join it. This flag has now been removed and the
bridge is guaranteed to be joinable at all times.
ASTERISK-23987 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3836/
........
Merged revisions 419538 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419539 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
We have a new periodic beep feature but sometimes a user needs some sort of
feedback, without the need to have a periodic beep during the recording, to let
them know that MixMonitor started recording or ended the recording. The use
case where this patch is being used is when using Dynamic Features to start and
end MixMonitor.
This patch adds an option to play a beep when MixMonitor starts and an option to
play a beep when MixMonitor ends.
ASTERISK-24051 #close
Reported by: Michael L. Young
patches:
mixmonitor-play-beep-start-stop.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3820/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419238 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