https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r53052 | file | 2007-01-31 18:24:20 -0600 (Wed, 31 Jan 2007) | 2 lines
When going on hold have the side that was put on hold reinvite back to Asterisk. When going off hold have the side that was taken off hold reinvited back to the other party.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@53053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r52904 | russell | 2007-01-30 11:19:39 -0600 (Tue, 30 Jan 2007) | 17 lines
Merged revisions 52903 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r52903 | russell | 2007-01-30 11:12:04 -0600 (Tue, 30 Jan 2007) | 9 lines
The SIGHUP handler was implemented to allow admins to send SIGHUP to a running
Asterisk process to reload the configuration. However, doing the actual reload
in the signal handler itself is a very bad thing to do, because the reload
process includes calling non-reentrant functions such as malloc/calloc/etc.
If Asterisk is running in the background, then the reload will happen
immediately. However, if running in console mode, the reload doesn't work
until something is typed at the console. That sort of defeats the purpose,
but I don't see an easy way to get around it at this point.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@52905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r52645 | russell | 2007-01-29 15:26:27 -0600 (Mon, 29 Jan 2007) | 6 lines
Fix a problem with packet-to-packet bridging and DTMF mode translation. P2P
bridging can only be used when the DTMF modes don't match if the core is
monitoring DTMF in both directions. Then, the core will handle the translation.
Otherwise, this bridging method can not be used.
(issue #8936)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@52646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- changing the actionlock to a rwlock
- not locking the session before doing the action callback
The crash issue in 8711 should not be an issue here.
Merged revisions 52611 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r52611 | russell | 2007-01-29 14:39:20 -0600 (Mon, 29 Jan 2007) | 10 lines
The session lock can not be held while calling action callbacks. If so, then
when the WaitEvent callback gets called, then no event can happen because the
session can't be locked by another thread. Also, the session needs to be
locked in the HTTP callback when it reads out the output string. This fixes
the deadlock reported in both 8711 and 8934.
Regarding issue 8711, there still may be an issue. If there is a second action
requested before the processing of the first action is finished, there could
still be some corruption of the output string buffer used to build the result.
(issue #8711, #8934)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@52613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r52494 | jdixon | 2007-01-28 22:18:36 -0600 (Sun, 28 Jan 2007) | 4 lines
Fixed problem with jitterbuf, whereas it would not complain about, and
would allow itself to be overfilled (per the max_jitterbuf parameter). Now
it rejects any data over and above that size, and complains about it.
........
r52506 | russell | 2007-01-29 10:54:27 -0600 (Mon, 29 Jan 2007) | 5 lines
Clean up a few things in the last commit to the adaptive jitterbuffer code.
- Specifically indicate to the compiler that the "dropem" variable only
needs one but.
- Change formatting to conform to coding guidelines.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@52522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r51848 | russell | 2007-01-23 18:59:58 -0600 (Tue, 23 Jan 2007) | 14 lines
Merged revisions 51843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r51843 | russell | 2007-01-23 18:57:28 -0600 (Tue, 23 Jan 2007) | 6 lines
Fix an issue related to synchronization of recordings when using Monitor().
The bug is a miscalculation of the amount to seek the stream for writing to
disk when the number of samples coming in and out of a channel do not match up.
(issue #8298, #8887, report and patch by guillecabeza, patch files created and
testing done by whoiswes)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51781 | russell | 2007-01-23 16:04:01 -0600 (Tue, 23 Jan 2007) | 6 lines
Fix some bugs in process_message(). The manager session lock needs to be held
when sending some sort of response, or calling one of the manager action
callbacks. This resolves an issue where people using the GUI would get random
crashes when they start clicking around a lot.
(issue #8711, reported and debugged by zandbelt)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51750 | russell | 2007-01-23 15:33:15 -0600 (Tue, 23 Jan 2007) | 4 lines
When traversing the list of manager actions, the iterator needs to be
initialized to the list head *after* locking the list. Also, lock the actions
list in one place it is being accessed where it was not being done.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51683 | murf | 2007-01-23 11:58:27 -0700 (Tue, 23 Jan 2007) | 1 line
via 8748 (callerid.c loses name when returning PRIVATE_NUMBER flag), the user suggested this mod, saying it would allow 'WITHHELD' to appear in the name field, which would be useful
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51311 | russell | 2007-01-19 11:49:38 -0600 (Fri, 19 Jan 2007) | 23 lines
Merge the changes from the /team/group/vldtmf_fixup branch.
The main bug being addressed here is a problem introduced when two SIP
channels using SIP INFO dtmf have their media directly bridged. So, when a
DTMF END frame comes into Asterisk from an incoming INFO message, Asterisk
would try to emulate a digit of some length by first sending a DTMF BEGIN
frame and sending a DTMF END later timed off of incoming audio. However,
since there was no audio coming in, the DTMF_END was never generated. This
caused DTMF based features to no longer work.
To fix this, the core now knows when a channel doesn't care about DTMF BEGIN
frames (such as a SIP channel sending INFO dtmf). If this is the case, then
Asterisk will not emulate a digit of some length, and will instead just pass
through the single DTMF END event.
Channel drivers also now get passed the length of the digit to their digit_end
callback. This improves SIP INFO support even further by enabling us to put
the real digit duration in the INFO message instead of a hard coded 250ms.
Also, for an incoming INFO message, the duration is read from the frame and
passed into the core instead of just getting ignored.
(issue #8597, maybe others...)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
has been found so that 'cat' is non-NULL. This way, users.conf is only checked
when necessary. (issue #8852, akohlsmith, committed patch a bit different)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51262 | russell | 2007-01-18 15:54:23 -0600 (Thu, 18 Jan 2007) | 5 lines
Ensure that the locations given to the Asterisk configure script for ncurses,
curses, termcap, or tinfo are further passed along to the editline configure
script. This fixes some cross-compilation environments.
(issue #8637, reported by ovi, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51263 65c4cc65-6c06-0410-ace0-fbb531ad65f3
