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

(closes issue #17336)
Reported by: snuffy
Patches:
      doxygen-fixes1.diff uploaded by snuffy (license 35)
Tested by: russell

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268969 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r260049 | dvossel | 2010-04-29 10:31:02 -0500 (Thu, 29 Apr 2010) | 14 lines
  
  Fixes crash in audiohook_write_list
  
  The middle_frame in the audiohook_write_list function was
  being freed if a audiohook manipulator returned a failure.
  This is incorrect logic.  This patch resolves this and
  adds detailed descriptions of how this function should work
  and why manipulator failures must be ignored.
  
  (closes issue #17052)
  Reported by: dvossel
  Tested by: dvossel

  (closes issue #16196)
  Reported by: atis
  
  Review: https://reviewboard.asterisk.org/r/623/
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260050 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Added a new manager command to mute/unmute MixMonitor audio on a channel. 
Added a new feature to audiohooks so that you can mute either read / write
(or both) types of frames - this allows for MixMonitor to mute either side
of the conversation without affecting the conversation itself.

(closes issue #16740)
Reported by: jmls

Review: https://reviewboard.asterisk.org/r/487/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258190 65c4cc65-6c06-0410-ace0-fbb531ad65f3

During the process of removing an audiohook from one channel
and attaching it to another the audiohook's status is updated
to DONE and then back to whatever it was previously.  Typically
updating the status after setting it to DONE is not a good idea
because DONE can trigger unrecoverable audiohook destruction
events... because of this a conditional check was added to
audiohook_update_status to explicitly prevent the audiohook
from ever changing after being set to DONE.  It was this check
that prevented audiohook inherit from work properly though.

Now ast_audiohook_move_by_source is treated as a special exception,
as the audiohook must be returned to its previous status after
attaching it to the new channel.  This is only a safe operation
because the audiohook's lock is held the entire time, otherwise
this could cause trouble.

(closes issue #16522)
Reported by: corruptor



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@238635 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(issue #14618)

Review: https://reviewboard.asterisk.org/r/434/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@230583 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Reviewboard: https://reviewboard.asterisk.org/r/416/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r224855 | tilghman | 2009-10-20 17:07:11 -0500 (Tue, 20 Oct 2009) | 5 lines
  
  Pay attention to the return value of the manipulate function.
  While this looks like an optimization, it prevents a crash from occurring
  when used with certain audiohook callbacks (diagnosed with SVN trunk,
  backported to 1.4 to keep the source consistent across versions).
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224856 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r197537 | mmichelson | 2009-05-28 09:49:13 -0500 (Thu, 28 May 2009) | 21 lines
  
  Add flags to chanspy audiohook so that audio stays in sync.
  
  There are two flags being added to the chanspy audiohook here. One
  is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
  we ensure that the read and write slinfactories on the audiohook do
  not skew beyond a certain tolerance.
  
  In addition, there is a new audiohook flag added here,
  AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
  a slinfactory to build up a substantial amount of audio before 
  flushing it. For this particular issue, this means that the person 
  spying on the call will hear the conversations in real time with very 
  little delay in the audio.
  
  (closes issue #13745)
  Reported by: geoffs
  Patches:
        13745.patch uploaded by mmichelson (license 60)
  Tested by: snblitz
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197543 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191419 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187599 65c4cc65-6c06-0410-ace0-fbb531ad65f3

audio_audiohook_write_list() did not take into account that the sample size may change after translation depending on if the original frame is is 8khz or 16khz.  the sample size is now updated after translating to reflect this possibility.  This caused the audio on the receiving end to sound terrible.  Thanks to jcolp and mmichelson for helping me work this out.

(issue AST-197)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186379 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r185196 | file | 2009-03-31 11:06:39 -0300 (Tue, 31 Mar 2009) | 8 lines
  
  Fix crash when moving audiohooks between channels.
  
  Handle the scenario where we are called to move audiohooks between channels
  and the source channel does not actually have any on it.
  
  (closes issue #14734)
  Reported by: corruptor
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@185197 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #14574)
Reported by: KNK
Patches:
      audiohook_volume_fix.diff uploaded by KNK (license 545)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179291 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Always detach and destroy the whisper and barge audiohooks. Additionally also allow an audiohook to be detached if it has not been attached.
(closes issue #14414)
Reported by: bluecrow76


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173902 65c4cc65-6c06-0410-ace0-fbb531ad65f3

I don't know how this crept back in when I had already
fixed it earlier



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166162 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel 
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor 
continue recording the call even after the transfer
has completed.

It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.

(closes issue #13538)
Reported by: mbit
Patches:
      13538.patch uploaded by putnopvut (license 60)
	  Tested by: putnopvut

Review: http://reviewboard.digium.com/r/102/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166092 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r149204 | mmichelson | 2008-10-14 18:00:01 -0500 (Tue, 14 Oct 2008) | 12 lines

Add a tolerance period for sync-triggered audiohooks
so that if packetization of audio is close (but not equal)
we don't end up flushing the audiohooks over small
inconsistencies in synchronization.

Related to issue #13005, and solves the issue
for most people who were experiencing the problem.
However, a small number of people are still experiencing
the problem on long calls, so I am not closing
the issue yet


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149205 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@137082 65c4cc65-6c06-0410-ace0-fbb531ad65f3

make datastore creation and destruction a generic API since it is not really channel related, and add the ability to add/find/remove datastores to manager sessions


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135680 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r130634 | russell | 2008-07-14 05:38:14 -0500 (Mon, 14 Jul 2008) | 2 lines

Bump up the debug level for a message.

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130635 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r130236 | mmichelson | 2008-07-11 15:03:23 -0500 (Fri, 11 Jul 2008) | 3 lines

Remove redundant logic


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130237 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r130173 | mmichelson | 2008-07-11 14:13:29 -0500 (Fri, 11 Jul 2008) | 7 lines

Fix a typo in audiohook_read_frame_both.

While this change has not been proven to fix any
specific issue, it is incorrect and could cause
unforeseen problems.


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130174 65c4cc65-6c06-0410-ace0-fbb531ad65f3

- make data member of the ast_frame struct a named union instead of a void

Recently the ast_queue_hangup function got a new parameter, the hangupcause
Feedback came in that this is no good and that instead a new function should be created.
This I did.

The hangupcause was stored in the seqno member of the ast_frame struct. This is not very
elegant, and since there's already a data member that one should be used.
Problem is, this member was a void *.
Now it's a named union so it can hold a pointer, an uint32 and there's a padding in case someone
wants to store another type in there in the future.

This commit is so massive, because all ast_frame.data uses have to be
altered to ast_frame.data.data

Thanks russellb and kpfleming for the feedback.

(closes issue #12674)
Reported by: mvanbaak


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117802 65c4cc65-6c06-0410-ace0-fbb531ad65f3

and denoising to a channel, AGC() and DENOISE(). Also included, is a change 
to the audiohook API to add a new function (ast_audiohook_remove) that can 
remove an audiohook from a channel before it is detached.

This code is based on a contribution from Switchvox.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114926 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r113296 | file | 2008-04-08 12:03:43 -0300 (Tue, 08 Apr 2008) | 4 lines

If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute.
(closes issue #12296)
Reported by: jvandal

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113297 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Merge over ast_audiohook_volume branch. This adds API calls for use by developers to adjust the volume on a channel.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110542 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines

Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue #11945)
Reported by: xheliox

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108084 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103842 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103840 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103838 65c4cc65-6c06-0410-ace0-fbb531ad65f3

audiohooks.  This causes an error when we attempt to destroy the lock later
when freeing the audiohook.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98581 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98432 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98424 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This works in much the same way as the automonitor, except that instead of using the monitor
app, it uses the mixmonitor app. By providing an 'x' or 'X' as a dial or queue option, a DTMF
sequence may be entered (as defined in features.conf) to start the one-touch mixmonitor.

This patch also introduces some new API calls to the audiohooks code for searching for an audiohook
by type and for searching for a running audiohook by type.

Big thanks to joetester for writing the initial patch, testing it and patiently waiting for it to 
be committed.

(closes issue #10185, reported and patched by xmarksthespot)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90388 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89511 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89425 65c4cc65-6c06-0410-ace0-fbb531ad65f3

build times - tested, there is no measureable difference before and
after this commit.

In this change:

use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h

Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.

Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better. 

For the time being I have left alone second-level directories
(main/db1-ast, etc.).



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3

this helps portability.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89109 65c4cc65-6c06-0410-ace0-fbb531ad65f3

  - the *_CURRENT macros no longer need the list head pointer argument
  - add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89106 65c4cc65-6c06-0410-ace0-fbb531ad65f3