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