https://origsvn.digium.com/svn/asterisk/trunk
........
r209256 | kpfleming | 2009-07-27 16:21:43 -0500 (Mon, 27 Jul 2009) | 10 lines
Make T.38 switchover in ReceiveFAX synchronous.
In receive mode, if the channel that ReceiveFAX is running on supports T.38,
we should *always* attempt to switch T.38, rather than listening for an incoming
CNG tone and only triggering on that. The channel may be using a low-bitrate
codec that distorts the CNG tone, the sending FAX endpoint may not send CNG
at all, or there could be a variety of other reasons that we don't detect it,
but in all those cases if T.38 is available we certainly want to use it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@209262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
Don't impose an arbitrary limit on member lines in queues.conf
I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"
Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.
(closes issue #15559)
Reported by: amorsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r208464 | kpfleming | 2009-07-23 16:57:24 -0500 (Thu, 23 Jul 2009) | 46 lines
Rework of T.38 negotiation and UDPTL API to address interoperability problems
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r208113 | qwell | 2009-07-22 16:43:57 -0500 (Wed, 22 Jul 2009) | 9 lines
Restore an int declaration on PPC platforms.
This x is one crafty little bugger...
It was used for 2 different things (one of which was only done on PPC) in 1.4.
One of the uses were removed in trunk, and with it went the declaration.
(closes issue #14038)
Reported by: ffloimair
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r205770 | kpfleming | 2009-07-10 10:28:11 -0500 (Fri, 10 Jul 2009) | 12 lines
Fix some remaining T.38 negotiation problems in app_fax.
Revision 205696 did not quite fix all the issues with the T.38 negotiation
changes and app_fax; this patch corrects them, along with a couple of other
minor issues.
(closes issue #15480)
Reported by: dimas
Patches:
test2-15480.patch uploaded by dimas (license 88)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@205772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r205696 | kpfleming | 2009-07-09 16:20:23 -0500 (Thu, 09 Jul 2009) | 16 lines
Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover.
Recent changes in T.38 negotiation in Asterisk caused these applications to
not respond when the other endpoint initiated a switchover to T.38; this
resulted in the T.38 switchover failing, and the FAX attempt to be made
using an audio connection, instead of T.38 (which would usually cause the
FAX to fail completely).
This patch corrects this problem, and the applications will now correctly
respond to the T.38 switchover request. In addition, the response will include
the appopriate T.38 session parameters based on what the other end offered
and what our end is capable of.
(closes issue #14849)
Reported by: afosorio
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@205698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r205350 | mmichelson | 2009-07-08 14:26:55 -0500 (Wed, 08 Jul 2009) | 20 lines
Merged revisions 205349 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205349 | mmichelson | 2009-07-08 14:26:13 -0500 (Wed, 08 Jul 2009) | 14 lines
Prevent phantom calls to queue members.
If a caller were to hang up while a periodic announcement or position
were being said, the return value for those functions would incorrectly
indicate that the caller was still in the queue. With these changes,
the problem does not occur.
(closes issue #14631)
Reported by: latinsud
Patches:
queue_announce_ghost_call2.diff uploaded by latinsud (license 745)
(with small modification from me)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@205352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r203721 | dbrooks | 2009-06-26 15:13:51 -0500 (Fri, 26 Jun 2009) | 16 lines
Fixing voicemail's error in checking max silence vs min message length
Max silence was represented in milliseconds, yet vmminsecs (minmessage) was represented
as seconds.
Also, the inequality was reversed. The warning, if triggered, was "Max silence should
be less than minmessage or you may get empty messages", which should have been logged
if max silence was greater than minmessage, but the check was for less than.
Also, conforming if statement to coding guidelines.
closes issue #15331)
Reported by: markd
Review: https://reviewboard.asterisk.org/r/293/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@203727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r201783 | tilghman | 2009-06-18 15:52:36 -0500 (Thu, 18 Jun 2009) | 6 lines
One of the changes in 1.6.1 was to allow app_directory to use functionality
within app_voicemail for directory functions. It is therefore no longer
necessary for app_directory to be linked against the ODBC libraries (and it
never was necessary for app_directory to be linked against IMAP, though it
was).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@201784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201445 | dvossel | 2009-06-17 14:45:35 -0500 (Wed, 17 Jun 2009) | 25 lines
Merged revisions 201423 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r201423 | dvossel | 2009-06-17 14:28:12 -0500 (Wed, 17 Jun 2009) | 19 lines
StopMixMonitor race condition (not giving up file immediately)
StopMixMonitor only indicates to the MixMonitor thread to stop
writing to the file. It does not guarantee that the recording's
file handle is available to the dialplan immediately after execution.
This results in a race condition. To resolve this, the filestream
pointer is placed in a datastore on the channel. When StopMixMonitor
is called, the datastore is retrieved from the channel and the
filestream is closed immediately before returning to the dialplan.
Documentation indicating the use of StopMixMonitor to free files
has been updated as well.
(closes issue #15259)
Reported by: travisghansen
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/283/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@201448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201056 | kpfleming | 2009-06-16 13:54:30 -0500 (Tue, 16 Jun 2009) | 18 lines
Merged revisions 200991 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines
Improve support for media paths that can generate multiple frames at once.
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@201096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r200943 | mvanbaak | 2009-06-16 17:51:36 +0200 (Tue, 16 Jun 2009) | 9 lines
add FILE_STORAGE to Voicemail Build Options
Voicemail can only use one storage module at the moment.
Because it's unclear that selecting one of the storage modules
in menuselect will disable filesystem storage we now have
a FILE_STORAGE option that conflicts with the other modules.
(closes issue #15333)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@200947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updated the MixMonitor documentation for the 'b' option so that
it is more obvious that you must not optimize awat the Local
channel when using this option.
(issue #14829)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197897 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197543 | mmichelson | 2009-05-28 09:58:06 -0500 (Thu, 28 May 2009) | 27 lines
Merged revisions 197537 via svnmerge from
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/branches/1.6.1@197545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r195316 | mmichelson | 2009-05-18 13:58:26 -0500 (Mon, 18 May 2009) | 18 lines
Fix externalivr's setvariable command so that it properly sets multiple variables.
The command had a for loop that was guaranteed to only execute once since
the continuation operation of the loop would set the input buffer NULL. I rewrote
the loop so that its operation was more obvious, and it would set multiple variables
correctly.
I also reduced stack space required for the function, constified the input string,
and modified the function so that it would not modify the input string while I was
at it.
(closes issue #15114)
Reported by: chris-mac
Patches:
15114.patch uploaded by mmichelson (license 60)
Tested by: chris-mac
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@195318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r195162 | eliel | 2009-05-18 10:45:23 -0400 (Mon, 18 May 2009) | 9 lines
Warn about the use of the application WaitExten() within a Macro().
Update applications documentation to warn the user about the use of the
WaitExten() application within a Macro(). Recommend the use of Read()
instead.
(closes issue #14444)
Reported by: ewieling
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@195167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r193756 | tilghman | 2009-05-11 17:50:47 -0500 (Mon, 11 May 2009) | 25 lines
Recorded merge of revisions 193755 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193755 | tilghman | 2009-05-11 17:48:20 -0500 (Mon, 11 May 2009) | 18 lines
Move 300 bytes around on the stack, to make more room for an extension buffer.
This allows more concurrent extensions to be copied for a single voicemail,
without creating a possibility of upsetting existing users, where a dialplan
could run out of stack space where it had run fine before. Alternatively,
we could have allocated off the heap, but that is a larger change and would
have increased the chance for instability introduced by this change.
This is really solved starting in 1.6.0.11, as the use of an ast_str buffer
allows an unlimited number of extensions (up to available memory). We
additionally create a new warning message when the buffer length is exceeded,
permitting administrators to see an issue after the fact, whereas previously
the list was silently truncated.
(closes issue #14739)
Reported by: p_lindheimer
Patches:
20090417__bug14739.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@193822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A user reported via #asterisk that with very long lists of members, a crash
occurs in ast_strdupa, so just use a single buffer and ast_copy_string instead
of stack allocating copys of each interface name.
(Related to revision 191041 in branches/1.4)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@191454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188032 | mmichelson | 2009-04-13 09:17:56 -0500 (Mon, 13 Apr 2009) | 6 lines
Set all queue variables on both the caller and member channels.
This allows for the variables to be accessed if a member macro is run.
Thanks to Grigoriy Puzankin for bringing this up on the -dev list.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@188038 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r186286 | mmichelson | 2009-04-03 09:32:05 -0500 (Fri, 03 Apr 2009) | 20 lines
Fix the ability to retrieve voicemail messages from IMAP.
A recent change made interactive vm_states no longer get
added to the list of vm_states and instead get stored in
thread-local storage.
In trunk and all the 1.6.X branches, the problem is that
when we search for messages in a voicemail box, we would
attempt to update the appropriate vm_state struct by directly
searching in the list of vm_states instead of using the
get_vm_state_by_imap_user function. This meant we could not
find the interactive vm_state that we wanted.
(closes issue #14685)
Reported by: BlargMaN
Patches:
14685.patch uploaded by mmichelson (license 60)
Tested by: BlargMaN, qualleyiv, mmichelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@186288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
