https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r288341 | russell | 2010-09-22 11:45:18 -0500 (Wed, 22 Sep 2010) | 25 lines
Merged revisions 288340 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r288340 | russell | 2010-09-22 11:44:13 -0500 (Wed, 22 Sep 2010) | 18 lines
Merged revisions 288339 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r288339 | russell | 2010-09-22 11:39:16 -0500 (Wed, 22 Sep 2010) | 11 lines
Fix a 100% CPU consumption problem when setting console=yes in asterisk.conf.
The handling of -c and console=yes should be the same, but they were not.
When you specify -c, it sets both a flag for console module and for asterisk
not to fork() off into the background. The handling of console=yes only set
console mode, so you would end up with a background process() trying to run
the Asterisk console and freaking out since it didn't have anything to read
input from.
Thanks to beagles for reporting and helping debug the problem!
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r288079 | rmudgett | 2010-09-21 15:29:51 -0500 (Tue, 21 Sep 2010) | 2 lines
Protect channel access in CONNECTED_LINE and REDIRECTING interception macro launch code.
........
r288080 | rmudgett | 2010-09-21 15:29:59 -0500 (Tue, 21 Sep 2010) | 8 lines
Simplify locking code for REDIRECTING interception macro when forwarding a call.
Simplified the locking code by using a local copy of the redirecting party
information in app_dial.c:do_forward() and app_queue.c:wait_for_answer()
for launching the REDIRECTING interception macro when a call is forwarded.
Reduced the lock time of the 'o->chan' and 'in' channels.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r287685 | alecdavis | 2010-09-21 11:16:45 +1200 (Tue, 21 Sep 2010) | 18 lines
ast_channel_masquerade: Avoid recursive masquerades.
Check all 4 combinations of (original/clonechan) * (masq/masqr).
Initially original->masq and clonechan->masqr were only checked.
It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.
(closes issue #16057;#17363)
Reported by: amorsen;davidw,alecdavis
Patches:
based on bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287661 | alecdavis | 2010-09-21 10:21:50 +1200 (Tue, 21 Sep 2010) | 14 lines
ast_do_masquerade. Keep channels ao2_container locked while unlink and linking channels.
Previously, Masquerade would unlock 'original' and 'clonechan' and allow another masq thread to run.
End result would be corrupted memory, and the frequent report 'Bad Magic Number'.
(closes issue #17801,#17710)
Reported by: notthematrix
Patches:
Based on bug17801.diff1.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/928
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
Addition of the FrameHook API (AKA AwesomeHooks)
So far all our tools for viewing and manipulating media streams
within Asterisk have been entirely focused on audio. That made
sense then, but is not scalable now. The FrameHook API lets us
tap into and manipulate _ANY_ type of media or signaling passed
on a channel present today or in the future. This tool is a step
in the direction of expanding Asterisk's boundaries and will help
generate some rather interesting applications in the future.
In addition to the FrameHook API, a simple dialplan function
exercising the api has been included as well. This function
is called FRAME_TRACE(). FRAME_TRACE() allows for the internal
ast_frames read and written to a channel to be output. Filters
can be placed on this function to debug only certain types of frames.
This function could be thought of as an internal way of doing
ast_frame packet captures.
Review: https://reviewboard.asterisk.org/r/925/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r286931 | jpeeler | 2010-09-15 14:22:15 -0500 (Wed, 15 Sep 2010) | 16 lines
Add parking extension for non-default parking lots.
This is a new feature that allows for parking to custom parking lots to be
accessed directly, rather than with channel variables or by changing the
default parking lot. The extension is set with the parkext option just as the
default parking lot is done. Also, the manager action has been updated to
optionally allow a specified parking lot.
(closes issue #14882)
Reported by: vmikhnevych
Patches:
patch_14882.txt uploaded by mnick (license 874)
modified by me
Review: https://reviewboard.asterisk.org/r/884/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286682 | mnicholson | 2010-09-14 13:04:21 -0500 (Tue, 14 Sep 2010) | 21 lines
Merged revisions 286681 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286681 | mnicholson | 2010-09-14 13:02:24 -0500 (Tue, 14 Sep 2010) | 14 lines
Merged revisions 286679 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286679 | mnicholson | 2010-09-14 13:00:01 -0500 (Tue, 14 Sep 2010) | 7 lines
Only drop duplicate answer frames if the channel is bridged.
Back in r3710 ast_read() was modified to drop answer frames on channels that were in the UP state. This modification prevented bridges that were up before the answer from being broken and reestablished by an ANSWER control frame. That change also prevents pickup of channels called from the ast_dial framework from working properly. The ast_dial framework expects to see an ANSWER frame after dialing and the pickup code queues one but ast_read() drops it. This new change only drops ANSWER frames when the channel is bridged, allowing the answer queued by the pickup code to properly pass through ast_read() on to the ast_dial framework.
ABE-2473
(related to issue #2342)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r286112 | russell | 2010-09-10 15:31:58 -0500 (Fri, 10 Sep 2010) | 9 lines
Rate limit calls to fsync() to 1 per second after astdb updates.
Astdb was determined to be one of the most significant bottlenecks in SIP
registration processing. This patch improved the speed of an astdb load
test by 50000% (yes, Fifty-Thousand Percent). On this particular load test
setup, this doubled the number of SIP registrations the server could handle.
Review: https://reviewboard.asterisk.org/r/825/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284477 | twilson | 2010-09-01 13:44:36 -0500 (Wed, 01 Sep 2010) | 17 lines
Fix SRTP for changing SSRC and multiple a=crypto SDP lines
Adding code to Asterisk that changed the SSRC during bridges and masquerades
broke SRTP functionality. Also broken was handling the situation where an
incoming INVITE had more than one crypto offer. This patch caches the SRTP
policies the we use so that we can change the ssrc and inform libsrtp of the
new streams. It also uses the first acceptable a=crypto line from the incoming
INVITE.
(closes issue #17563)
Reported by: Alexcr
Patches:
srtp.diff uploaded by twilson (license 396)
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/878/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284065 | russell | 2010-08-28 16:29:45 -0500 (Sat, 28 Aug 2010) | 13 lines
Be more flexible with whitespace on AMI action headers.
Previously, this code required exactly one space to be after the ':' in headers
for an AMI action. This now makes whitespace optional, and allows whitespace that
is there to vary in amount.
(closes issue #17862)
Reported by: cmoye
Patches:
manager.c.patch_trunk uploaded by cmoye (license 858)
manager.c.patch_1.8 uploaded by cmoye (license 858)
Tested by: cmoye
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r283230 | russell | 2010-08-23 08:23:12 -0500 (Mon, 23 Aug 2010) | 7 lines
Make the AST_CEL_AMA enum match up with the AST_CDR_ ama flag values.
Really, having 2 enums for this is silly and error prone, demonstrated by
the crash that I hit because there was an assumption in the code that the
values in each matched up. However, this is a quick fix to get them to
match up so it will work.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r282468 | twilson | 2010-08-16 12:53:44 -0500 (Mon, 16 Aug 2010) | 30 lines
Merged revisions 282467 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r282467 | twilson | 2010-08-16 12:32:01 -0500 (Mon, 16 Aug 2010) | 23 lines
Merged revisions 282430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r282430 | twilson | 2010-08-16 12:06:37 -0500 (Mon, 16 Aug 2010) | 16 lines
Send a SRCCHANGE indication when we masquerade
Masquerading a channel means that the src of the audio is potentially
changing, so send a SRCCHANGE so that RTP-based media streams can get
a new SSRC generated to reflect the change. Original patch by addix
(along with lots of testing--thanks!).
(closes issue #17007)
Reported by: addix
Patches:
1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006)
srcchange.diff uploaded by twilson (license 396)
Tested by: addix, twilson
Review: https://reviewboard.asterisk.org/r/862/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282098 | rmudgett | 2010-08-12 17:06:06 -0500 (Thu, 12 Aug 2010) | 7 lines
Separate call completion config parameter allocation and default initialization.
If you ever have a need to reset the call completion config parameters
to defaults, now you can.
And no Virginia, C++ idioms do not always work in C.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282099 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282047 | dvossel | 2010-08-12 15:15:41 -0500 (Thu, 12 Aug 2010) | 35 lines
improved translation paths for wideband codecs
The problem I'm addressing is that Asterisk's current
method of building the least cost translation paths
between codecs does not take into account sample rate.
For instance, it was possible for siren14 (a 32khz codec),
to contain the a translation path to siren7 (a 16khz
audio codec) that goes through slin at 8khz. In this
case Asterisk takes a 32khz codec, down samples it to
8khz and then up samples it to 16khz which is terrible
regardless if it is computationally less expensive. This
patch now builds translation paths that give priority to
maintaining the best possible sample rate before taking
into consideration computational cost. This patch also
adds cli commands to expose what translation paths are
actually being used.
Changes:
1. Translation paths will never contain a step that changes
the sample rate unless absolutely necessary.
2. When choosing the best codec to make two channels compatible.
Shared codecs with the highest sample rate are given priority.
3. A new cli command to show all translation paths available
for a specific codec 'core show translation paths [codec name]'
has been added.
4. 'core show translation' which displays the translation
matrix now includes the new higher bit audio codecs in the table.
5. 'core show channel [channel name]' now displays the
translation paths if translation is used.
(closes issue #16841)
Reported by: dvossel
Review: https://reviewboard.asterisk.org/r/842/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r281982 | russell | 2010-08-12 11:33:30 -0500 (Thu, 12 Aug 2010) | 5 lines
Remove debugging output from verbose messages.
Pointer values to internal objects is not terribly useful to users in the
verbose messages about adding extensions and contexts.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281913 | jpeeler | 2010-08-11 22:03:37 -0500 (Wed, 11 Aug 2010) | 34 lines
Merged revisions 281912 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r281912 | jpeeler | 2010-08-11 22:01:38 -0500 (Wed, 11 Aug 2010) | 27 lines
Merged revisions 281911 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281911 | jpeeler | 2010-08-11 22:00:14 -0500 (Wed, 11 Aug 2010) | 20 lines
Ensure SSRC is changed when media source is changed to resolve audio delay.
This change causes the SSRC to change right before the channels are bridged,
which is what used to happen. It seems that fixes were made to attempt limiting
SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting the SSRC
with this change.
There are two other control frames sent in ast_channel_bridge that probably
should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm going to leave
this change up to the discretion of resolving issue #17007.
For reference - old review implementing new control frame SRCCHANGE:
https://reviewboard.asterisk.org/r/540
(closes issue #17404)
Reported by: sdolloff
Patches:
bug17404.patch uploaded by jpeeler (license 325)
Tested by: sdolloff
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281575 | russell | 2010-08-10 13:05:07 -0500 (Tue, 10 Aug 2010) | 16 lines
Merged revisions 281574 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r281574 | russell | 2010-08-10 13:04:32 -0500 (Tue, 10 Aug 2010) | 9 lines
Don't move the time threshold for running scheduled events on every iteration.
Instead, only calculate the time threshold each time ast_sched_runq() is called.
(closes issue #17742)
Reported by: schmidts
Patches:
sched.c.patch uploaded by schmidts (license 1077)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281052 | russell | 2010-08-05 08:16:11 -0500 (Thu, 05 Aug 2010) | 16 lines
Merged revisions 281051 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r281051 | russell | 2010-08-05 08:11:32 -0500 (Thu, 05 Aug 2010) | 9 lines
Cleanup default option value handling for cdr.conf [general].
The default values would differ depending on whether or not cdr.conf exists.
That is no longer the case.
Apply a default value to the unanswered option.
Define all default values as named constants.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281054 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r280307 | mnicholson | 2010-07-29 08:56:35 -0500 (Thu, 29 Jul 2010) | 11 lines
Merged revisions 280306 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r280306 | mnicholson | 2010-07-29 08:45:11 -0500 (Thu, 29 Jul 2010) | 2 lines
Implement support for ast_channel_queryoption on local channels. Currently only AST_OPTION_T38_STATE is supported.
ABE-2229
Review: https://reviewboard.asterisk.org/r/813/
........
Additionally, pass AST_CONTROL_T38_PARAMETERS control frames through generic bridges. This change appears to have been unintentionally left out of rev 203699.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r279949 | dvossel | 2010-07-27 15:57:00 -0500 (Tue, 27 Jul 2010) | 31 lines
Merged revisions 279946 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r279946 | dvossel | 2010-07-27 15:54:32 -0500 (Tue, 27 Jul 2010) | 24 lines
Merged revisions 279945 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r279945 | dvossel | 2010-07-27 15:33:40 -0500 (Tue, 27 Jul 2010) | 19 lines
remove empty audiohook write list on channel
If a channel has an audiohook write list created on it, that
list stays on the channel until the channel is destroyed. There
is no reason to keep that list on the channel if it becomes empty.
If it is empty that just means we are doing needless translating
for every ast_read and ast_write. This patch removes the audiohook
list from the channel once it is detected to be empty on either a
read or write. If a audiohook is added back to the channel after
this list is destroyed, the list just gets recreated as if it never
existed to begin with.
(closes issue #17630)
Reported by: manvirr
Review: https://reviewboard.asterisk.org/r/799/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In particular, Solaris and perhaps others do not support the above mentioned
GNU extension. In this case the paths are simply expanded without the braces
and the calls to glob are made separately.
Note: I could not explain memory allocation failures that were being reported
from within libxml itself when making calls to glob without using GLOB_NOCHECK.
This is the only reason why that flag is being used.
(closes issue #15402)
Reported by: snuffy
Patches:
bug_xmlpatt-v3.diff uploaded by snuffy (license 35),
modified by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r278618 | mmichelson | 2010-07-22 09:55:04 -0500 (Thu, 22 Jul 2010) | 13 lines
Allow PLC to function properly when channels use SLIN for audio.
If a channel involved in a bridge was using SLIN audio, then translation
paths were not guaranteed to be set up properly since in all likelihood
the number of translation steps was only 1.
This patch enforces the transcode_via_slin behavior if transcode_via_slin
or generic_plc is enabled and one of the formats to make compatible is
SLIN.
AST-352
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation for this option did not match the code. Fix that along with
some minor cleanups to the code along the way. Document a slight change in
behavior (to something that was previously undocumented) in UPGRADE.txt.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277906 | jeang | 2010-07-19 15:16:36 -0500 (Mon, 19 Jul 2010) | 7 lines
Avoid trying to pickup a parked extension before the park operation is completed.
A crash could occur if the extension is picked up while the parking extension is
being announced. Testing pu->notquiteyet while searching for a parked extension
resolves this crash.
(ABE-2418)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ACLs can now be configured to match IPv6 networks. This is only
relevant for ACLs in chan_sip for now since other channel drivers
do not support IPv6 addressing. However, once those channel drivers
are outfitted to support IPv6 addressing, the ACLs will already be
ready for IPv6 support.
https://reviewboard.asterisk.org/r/791
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277814 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277568 | tilghman | 2010-07-16 16:54:29 -0500 (Fri, 16 Jul 2010) | 8 lines
Since we split values at the semicolon, we should store values with a semicolon as an encoded value.
(closes issue #17369)
Reported by: gkservice
Patches:
20100625__issue17369.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277773 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277625 | tringenbach | 2010-07-16 17:43:39 -0500 (Fri, 16 Jul 2010) | 9 lines
Save and restore AST_FLAG_BRIDGE_HANGUP_DONT on attended transfer.
ast_bridge_call() clears AST_FLAG_BRIDGE_HANGUP_DONT. But during an attended
transfer, ast_bridge_call() is called for a second bridge on the same channel,
and it clears that flag, which still needs to get set for when the original
ast_bridge_call() gets control back and checks it.
Review: https://reviewboard.asterisk.org/r/741
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277657 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277247 | mnicholson | 2010-07-16 12:29:57 -0500 (Fri, 16 Jul 2010) | 4 lines
For pass through DTMF tones, measure the actual duration between the begin and end packets on the wire. If it is detected to be less than AST_MIN_DTMF_DURATION, trigger dtmf emulation.
AST-362
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277250 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_sockaddr_stringiy_fmt (which is call by all ast_sockaddr_stringify* functions)
uses thread-local storage for storing the string that it creates. In cases where
ast_sockaddr_stringify_fmt was being called twice within the same statement, the
result of one call would be overwritten by the result of the other call. This
usually was happening in printf-like statements and was resulting in the same
stringified addressed being printed twice instead of two separate addresses.
I have fixed this by using ast_strdupa on the result of stringify functions if
they are used twice within the same statement. As far as I could tell, there were
no instances where a pointer to the result of such a call were saved anywhere, so
this is the only situation I could see where this error could occur.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275994 | russell | 2010-07-13 11:51:18 -0500 (Tue, 13 Jul 2010) | 14 lines
Access peer->cdr directly instead of through a saved off reference.
At this point in the code, it is possible that peer_cdr may be invalid.
Specifically, in the blind transfer code, CDRs are swapped between channels.
So, peer_cdr is no longer == peer->cdr.
The scenario that exposed a crash in this code was a blind transfer that hit
the system call limit, causing the transferee channel to get destroyed after
the transfer attempt failed. Even if it succeeds and this code doesn't crash,
this code was still trying to reset a CDR on a channel that was now owned by
a different thread, which is a BadThing(tm).
(ABE-2417)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275665 | jpeeler | 2010-07-12 11:58:39 -0500 (Mon, 12 Jul 2010) | 11 lines
Change ast_write to not stop generator when called from ast_prod.
For SIP channels configured with the progressinband option on, the ringback was
being immediately stopped. This problem was due to ast_prod being moved for a
deadlock fix in 259858. Prodding the channel after setting up the generator
triggered the check in ast_write to stop the generator. The fix here should
write the frame the same as was done before the call to ast_prod was moved.
(closes issue #17372)
Reported by: tech_admin
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge handling code did not properly consider feature groups when setting
parameters that would affect whether or not a native bridge would be attempted.
If DYNAMIC_FEATURES only include a feature group, a native bridge would occur
that may prevent features from working.
Fix a bug in verbose output that would show the key mapping as empty if it was
using the default mapping and not a custom mapping in the feature group.
Add feature groups to the output of "features show".
Adjust the feature execution logic to match that of the logic when executing
a feature that was not configured through a feature group.
Update features.conf.sample to show that an '=' is still required if using
the default key mapping from [applicationmap].
Finally, clean up a little bit of formatting to better coform to coding
guidelines while in the area.
(closes issue #17589)
Reported by: lmadsen
Patches:
issue_17589.rev4.txt uploaded by russell (license 2)
Tested by: russell, lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
warning (at least with gcc 4.4.4):
netsock2.c:492: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules
So we're back to using memcpy()...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274909 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273565 | russell | 2010-07-01 17:09:19 -0500 (Thu, 01 Jul 2010) | 7 lines
Don't return a partially initialized datastore.
If memory allocation fails in ast_strdup(), don't return a partially
initialized datastore. Bad things may happen.
(related to ABE-2415)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Otherwise, it goes to all manager sessions and may exclude the current session,
if the Events mask excludes it.
(closes issue #17504)
Reported by: rrb3942
Patches:
showdialplan_patch.diff uploaded by rrb3942 (license 1003)
Tested by: rrb3942
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273054 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a ref count leak in event filters and checks for
a filter container allocation failure during session creation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch as documented in the sample config allows one to optionally apply
white, black, or both types of filtering to manager events. The new
'eventfilter' option is set per user.
(closes issue #14861)
Reported by: fnordian
Patches:
eventfilter3.patch uploaded by fnordian (license 110),
modified by me
Review: https://reviewboard.asterisk.org/r/673/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If both the transferer and transferee of a attended transfer hangup before
the new channel picks up, the new channel should be hung up as well as it
has no endpoint to talk to. This mirrors the expected behavior used in 1.4.
(closes issue #17444)
Reported by: corruptor
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If there is a problem with a firmware file, Polycom phones will close the
connection. We were continuing to send the file anyway. There should be no
reason to continue sending a file if there is an error writing it.
(closes issue #16682)
Reported by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines
Fix potential crash when writing raw SLIN audio on a PLC-enabled channel.
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind pointed out that attempting to get an IE value from an event that has
no IEs produces an invalid memory read past the end of the event. Thanks to
mmichelson for pointing the problem out to me and then testing the fix.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269334 | pabelanger | 2010-06-09 13:24:53 -0400 (Wed, 09 Jun 2010) | 12 lines
Fix Debian init script to not use -c.
When using the init script as-is currently, it could cause issues on Debian
such as high CPU usage. This fix has worked for several people so I'm
implementing the change. We now handle color displays properly.
(closes issue #16784)
Reported by: pabelanger
Patches:
20100530__issue16784__2.diff.txt uploaded by tilghman (license 14)
Tested by: pabelanger, tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269346 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Suppress the warning about unexpected control subclass frames for
AST_CONTROL_CONNECTED_LINE, AST_CONTROL_REDIRECTING, and AST_CONTROL_AOC
in file.c:waitstream_core().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
What I did not originally see in my previous commit was that even though the
next digit could be detected before the previous was considered ended, the
detection of the next digit effectively ends the detection of the previous.
Therefore, the length moves in lockstep with the digit, and no separate counter
is needed for the length alone.
(closes issue #17371)
Reported by: alecdavis
(closes issue #17474)
Reported by: kenner
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ASTCFLAGS was specified with the make command, Makefile.rules was using
the specified value from the command line and not the one here, making it so this
flag would go missing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Actions (or failures to act) by external clients should not cause memory leaks
in Asterisk, especially when those continued leaks could cause Asterisk to
misbehave later.
(closes issue #17234)
Reported by: mav3rick
Patches:
20100510__issue17234.diff.txt uploaded by tilghman (license 14)
20100517__issue17234__trunk.diff.txt uploaded by tilghman (license 14)
Tested by: mav3rick, davidw
(closes issue #17365)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266585 | tilghman | 2010-06-01 10:17:46 -0500 (Tue, 01 Jun 2010) | 11 lines
Prevent CLI prompt from distorting output of lines shorter than the prompt.
Uses the VT100 method of clearing the line from the cursor position to the
end of the line: Esc-0K
(closes issue #17160)
Reported by: coolmig
Patches:
20100531__issue17160.diff.txt uploaded by tilghman (license 14)
Tested by: coolmig
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266142 | tilghman | 2010-05-26 16:11:44 -0500 (Wed, 26 May 2010) | 14 lines
Use sigaction for signals which should persist past the initial trigger, not signal.
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch breaks up every part of the sip registry string during
config parsing and removes all parsing from transmit_register().
Thanks to Nick_Lewis for contributing this patch!
(closes issue #14331)
Reported by: Nick_Lewis
Patches:
chan_sip.c-domparse.patch uploaded by Nick Lewis (license 657)
chan_sip.c.patch uploaded by Nick Lewis (license 657)
chan_sip.c.domainparse3.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse4.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse5.patch uploaded by Nick Lewis (license 657)
nicklewispatch.diff uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
Review: https://reviewboard.asterisk.org/r/628/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The handling of the control subclass AST_CONTROL_READ_ACTION frame leaked
connected line string memory in __ast_read().
Also in __ast_read() the frame type switch should not have had a case for
AST_CONTROL_READ_ACTION. AST_CONTROL_READ_ACTION is not a frame type.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
__ast_channel_alloc_ap() has several points in the initialization of a new
channel structure where it could fail. Since the channel structure is now
an ao2 object, the destructor callback needs to be able to handle clean up
when the structure setup is incomplete.
Problems corrected:
1) Failing to setup the alertpipe would not unreference the structure but
free it directly. Doing this to an ao2_object is very bad.
2) File descriptors need to be initialized to -1 before a construction
failure could occur so the destructor will not close unopened descriptors.
3) The destructor needs to check that the string field has been
initialized before using any string field values. Crashes expected.
4) The destructor should not notify devstate if the device name is empty.
It is a waste of cycles and a couple ERROR log messages are generated.
Review: https://reviewboard.asterisk.org/r/675/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines
Allow ast_safe_sleep to defer specific frames until after the sleep has concluded.
From reviewboard
Background:
A Digium customer discovered a somewhat odd bug. The setup is that parties A
and B are bridged, and party A places party B on hold. While party B is
listening to hold music, he mashes a bunch of DTMF. Party A takes party
B off hold while this is happening, but party B continues to hear hold
music. I could reproduce this about 1 in 5 times.
The issue:
When DTMF features are enabled and a user presses keys, the channel that
the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
from the channel during the sleep, the frame is dropped. Thus the
unhold indication is never made to the channel that was originally placed
on hold.
The fix:
Originally, I discussed with Kevin possible ways of fixing the specific
problem reported. However, we determined that the same type of problem
could happen in other situations where ast_safe_sleep() is used. Using
autoservice as a model, I modified ast_safe_sleep_conditional() to
defer specific frame types so they can be re-queued once the sleep has
finished. I made a common function for determining if a frame should
be deferred so that there are not two identical switch blocks to
maintain.
Review: https://reviewboard.asterisk.org/r/674/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264820 | rmudgett | 2010-05-20 18:23:21 -0500 (Thu, 20 May 2010) | 6 lines
ast_callerid_parse() had a path that left name uninitialized.
Several callers of ast_callerid_parse() do not initialize the name
parameter before calling thus there is the potential to use an
uninitialized pointer.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Nick Lewis pointed out that the patch as committed wouldn't actually include
dynamic logger levels, which was missed by the other reviewers. Thanks!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When decode_length returns the length there is a check to see if that
length is negative, if so the decode loop breaks as this means the
limit has been reached. The problem here is that length is an
unsigned int, so length can never be negative. This resulted in
an infinite loop.
(issue #17352)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #17235)
Reported by: frawd
Patches:
new_dtmf_dsp_len.patch uploaded by frawd (license 610)
20100518__issue17235.diff.txt uploaded by tilghman (license 14)
Tested by: frawd
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264204 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now that Asterisk modules can dynamically create and destroy logger levels
on demand, it's useful to be able to configure a logger channel (console,
file, whatever) to be able to accept log messages from *all* levels, even
levels created dynamically. This patch adds support for this, by allowing
the '*' level name to be used in logger.conf.
Review: https://reviewboard.asterisk.org/r/663/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the keyword 'all' to the 'channel hangup request' CLI command
so that you can request all channels to be hungup without having to
restart Asterisk.
(closes issue #16009)
Reported by: moy
Patches:
hangup-all-rev-221688.patch uploaded by moy (license 222)
Tested by: moy, russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263949 | tilghman | 2010-05-19 01:32:27 -0500 (Wed, 19 May 2010) | 8 lines
Because progress is called multiple times, across several frames, we must persist states when detecting multitone sequences.
(closes issue #16749)
Reported by: dant
Patches:
dsp.c-bug16749-1.patch uploaded by dant (license 670)
Tested by: dant
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263639 | mmichelson | 2010-05-17 17:00:28 -0500 (Mon, 17 May 2010) | 10 lines
Fix logic error when checking for a devstate provider.
When using strsep, if one of the list of specified separators is not found,
it is the first parameter to strsep which is now NULL, not the pointer returned
by strsep.
This issue isn't especially severe in that the worst it is likely to do is waste
some cycles when a device with no '/' and no ':' is passed to ast_device_state.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sean Bright pointed out that we lost a set of newline characters in commit
190349 on a line I had recently changed. Yay for code review on commits.
(issue #17231, #10961)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263456 | lmadsen | 2010-05-17 09:35:18 -0500 (Mon, 17 May 2010) | 11 lines
Manager cookies are not compatible with RFC2109.
The Version field in the cookies we're setting contain quotes around the version
number which is not compatible with RFC2109 and breaks some implementations.
(closes issue #17231)
Reported by: ecarruda
Patches:
manager_rfc2109-trunk-v1.patch uploaded by ecarruda (license 559)
manager_rfc2109-1.6.2-v1.patch uploaded by ecarruda (license 559)
Tested by: ecarruda, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
