https://origsvn.digium.com/svn/asterisk/trunk
................
r199051 | seanbright | 2009-06-04 10:31:24 -0400 (Thu, 04 Jun 2009) | 47 lines
Merged revisions 199022 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r199022 | seanbright | 2009-06-04 10:14:57 -0400 (Thu, 04 Jun 2009) | 40 lines
Safely handle AMI connections/reload requests that occur during startup.
During asterisk startup, a lock on the list of modules is obtained by the
primary thread while each module is initialized. Issue 13778 pointed out a
problem with this approach, however. Because the AMI is loaded before other
modules, it is possible for a module reload to be issued by a connected client
(via Action: Command), causing a deadlock.
The resolution for 13778 was to move initialization of the manager to happen
after the other modules had already been lodaded. While this fixed this
particular issue, it caused a problem for users (like FreePBX) who call AMI
scripts via an #exec in a configuration file (See issue 15189).
The solution I have come up with is to defer any reload requests that come in
until after the server is fully booted. When a call comes in to
ast_module_reload (from wherever) before we are fully booted, the request is
added to a queue of pending requests. Once we are done booting up, we then
execute these deferred requests in turn.
Note that I have tried to make this a bit more intelligent in that it will not
queue up more than 1 request for the same module to be reloaded, and if a
general reload request comes in ('module reload') the queue is flushed and we
only issue a single deferred reload for the entire system.
As for how this will impact existing installations - Before 13778, a reload
issued before module initialization was completed would result in a deadlock.
After 13778, you simply couldn't connect to the manager during startup (which
causes problems with #exec-that-calls-AMI configuration files). I believe this
is a good general purpose solution that won't negatively impact existing
installations.
(closes issue #15189)
(closes issue #13778)
Reported by: p_lindheimer
Patches:
06032009_15189_deferred_reloads.diff uploaded by seanbright (license 71)
Tested by: p_lindheimer, seanbright
Review: https://reviewboard.asterisk.org/r/272/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@199053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
................
r198958 | seanbright | 2009-06-03 16:49:11 -0400 (Wed, 03 Jun 2009) | 17 lines
Blocked revisions 198957 via svnmerge
........
r198957 | seanbright | 2009-06-03 16:39:10 -0400 (Wed, 03 Jun 2009) | 11 lines
Fix a possible crash in pbx_spool.
We were trying to reference members of a struct that had previously been freed.
This patch makes sure that we free the struct after it has been removed from
the spooler queue.
(closes issue #15072)
Reported by: garlew
Patches:
spool.diff uploaded by garlew (license 376)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198960 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines
Generic call forward api, ast_call_forward()
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
(closes issue #13630)
Reported by: festr
Review: https://reviewboard.asterisk.org/r/271/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198824 | dvossel | 2009-06-02 12:55:35 -0500 (Tue, 02 Jun 2009) | 8 lines
fixes issue with channels not going down after transfer
Iax2 currently does not support native bridging if the timeoutms value is set. We check for that in iax2_bridge, but then set timeoutms to 0 by default. If the timeoutms is not provided it is set to -1. By setting timeoutms to 0 it is processed causing a bridging retry loop.
(closes issue #15216)
Reported by: oxymoron
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198826 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198375 | seanbright | 2009-05-30 16:11:33 -0400 (Sat, 30 May 2009) | 13 lines
Properly terminate the receive buffer before sending to iksemel.
aji_io_recv takes the maximum number of bytes to read (instead of the total
buffer size), so we have to subtract 1 from our buffer size. Without this, when
we receive packets that are larger than our buffer, iksemel will choke and
things get wonky.
(closes issue #15232)
Reported by: lp0
Patches:
05302009_res_jabber.c.patch uploaded by seanbright (license 71)
Tested by: seanbright, lp0
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198146 | russell | 2009-05-29 15:06:59 -0500 (Fri, 29 May 2009) | 38 lines
Resolve issues with choppy sound when using res_timing_pthread.
The situation that caused this problem was when continuous mode was being
turned on and off while a rate was set for a timing interface. A very easy
way to replicate this bug was to do a Playback() from behind a Local channel.
In this scenario, a rate gets set on the channel for doing file playback.
At the same time, continuous mode gets turned on and off about every 20 ms
as frames get queued on to the PBX side channel from the other side of the
Local channel.
Essentially, this module treated continuous mode and a set rate as mutually
exclusive states for the timer to be in. When I dug deep enough, I observed
the following pattern:
1) Set timer to tick every 20 ms.
2) Wait almost 20 ms ...
3) Continuous mode gets turned on for a queued up frame
4) Continuous mode gets turned off
5) The timer goes back to its tick per 20 ms. state but starts counting
at 0 ms.
6) Goto step 2.
Sometimes, res_timing_pthread would make it 20 ms and produce a timer tick,
but not most of the time. This is what produced the choppy sound (or sometimes
no sound at all).
Now, the module treats continuous mode and a set rate as completely independent
timer modes. They can be enabled and disabled independently of each other and
things work as expected.
(closes issue #14412)
Reported by: dome
Patches:
issue14412.diff.txt uploaded by russell (license 2)
issue14412-1.6.1.0.diff.txt uploaded by russell (license 2)
Tested by: DennisD, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198147 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r198088 | jpeeler | 2009-05-29 14:19:51 -0500 (Fri, 29 May 2009) | 9 lines
New signaling module to handle analog operations in chan_dahdi
This branch splits all the analog signaling logic out of chan_dahdi.c into
sig_analog.c. Functionality in theory should not change at all. As noted
in the code, there is still some unused code remaining that will be cleaned
up in a later commit.
Review: https://reviewboard.asterisk.org/r/253/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r198072 | mnicholson | 2009-05-29 14:04:24 -0500 (Fri, 29 May 2009) | 21 lines
Merged revisions 198068 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r198068 | mnicholson | 2009-05-29 13:53:01 -0500 (Fri, 29 May 2009) | 15 lines
Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition.
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
(closes issue #12946)
Reported by: meral
Patches:
null-cdr2.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, dbrooks
(closes issue #15122)
Reported by: sum
Tested by: sum
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198074 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r198000 | seanbright | 2009-05-29 14:15:15 -0400 (Fri, 29 May 2009) | 15 lines
Merged revisions 197998 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197998 | seanbright | 2009-05-29 14:14:12 -0400 (Fri, 29 May 2009) | 8 lines
Fix 'make config' target for Slackware.
There was a missing semi-colon after the echo statement in the Makefile that was
causing problems for some users. Fix suggested by reporter.
(closes issue #15225)
Reported by: pdavis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198005 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
........
r197738 | twilson | 2009-05-28 14:57:18 -0500 (Thu, 28 May 2009) | 19 lines
Add Calendaring support for Asterisk
This commit add Calendaring support to Asterisk for iCalendar, CalDAV, and MS
Exchange calendars. Exchange support has only been tested on Exchange Server 2k3
and does not support forms-based authentication at this time (patches *very*
welcome). Exchange support is also currently missing the ability to return a
list of a meting's attendees (again, patches are very, very welcome).
Features include:
Querying a calendar for events over a specific time range
Checking a calendar's busy status via the dialplan
Writing calendar events via the dialplan (CalDAV and Exchange only)
Handling calendar event notifications through the dialplan
(closes issue #14771)
Tested by: lmadsen, twilson, Shivaprakash
Review: https://reviewboard.asterisk.org/r/58
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197621 | eliel | 2009-05-28 12:01:48 -0400 (Thu, 28 May 2009) | 19 lines
Merged revisions 197562 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197562 | eliel | 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) | 13 lines
Use the address we already know when reloading a peer with nat=yes.
If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
(closes issue #15194)
Reported by: ibc
Patches:
sip.patch uploaded by eliel (license 64)
Tested by: manwe
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197606 | mmichelson | 2009-05-28 10:32:19 -0500 (Thu, 28 May 2009) | 22 lines
Recorded merge of revisions 197588 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197588 | mmichelson | 2009-05-28 10:27:49 -0500 (Thu, 28 May 2009) | 16 lines
Allow for media to arrive from an alternate source when responding to a reinvite with 491.
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Review: https://reviewboard.asterisk.org/r/252
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197618 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
................
r197467 | file | 2009-05-28 10:47:45 -0300 (Thu, 28 May 2009) | 15 lines
Merged revisions 197466 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197466 | file | 2009-05-28 10:44:58 -0300 (Thu, 28 May 2009) | 8 lines
Fix a bug where the flag indicating the presence of rport would get overwritten by the nat setting.
The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
(closes issue #13823)
Reported by: dimas
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r197260 | seanbright | 2009-05-27 16:08:16 -0400 (Wed, 27 May 2009) | 6 lines
Use bash explicitly when calling build_tools/mkpkgconfig from the Makefile.
Since we use bashisms in build_tools/mkpkgconfig, we should call on bash
explicitly when running from the Makefile, otherwise we get errors during a
'make install.'
(closes issue #15209)
Reported by: seandarcy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197209 | tilghman | 2009-05-27 14:20:56 -0500 (Wed, 27 May 2009) | 12 lines
Recorded merge of revisions 197194 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197194 | tilghman | 2009-05-27 14:09:42 -0500 (Wed, 27 May 2009) | 5 lines
Use a different determinator on whether to print the delimiter, since leading fields may be blank.
(closes issue #15208)
Reported by: ramonpeek
Patch by me, though inspired in part by a patch from ramonpeek
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge was terminating immediately after the attended transfer was
completed. The problem was because upon reentering ast_channel_bridge
nexteventts was checked to see if it was set and if so could possibly
return AST_BRIDGE_COMPLETE.
(closes issue #15183)
Reported by: andrebarbosa
Tested by: andrebarbosa, tootai, loloski
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r196988 | seanbright | 2009-05-27 09:02:54 -0400 (Wed, 27 May 2009) | 9 lines
Display an error message when chan_alsa fails to load due to a missing
or inaccessible configuration file.
Before this change, when chan_alsa failed to load due to a missing or
inaccessible configuration file, no message would be displayed. With this
change, when chan_alsa fails to load due to a missing or inaccessible
configuration file, a message will be displayed.
(closes issue #14760)
Reported by: Nick_Lewis
Patches:
chan_alsa.c-confload.patch uploaded by Nick (license 657)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@196990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r196843 | russell | 2009-05-26 13:20:57 -0500 (Tue, 26 May 2009) | 16 lines
Merged revisions 196826 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r196826 | russell | 2009-05-26 13:14:36 -0500 (Tue, 26 May 2009) | 9 lines
Resolve a file handle leak.
The frames here should have always been freed. However, out of luck, there was
never any memory leaked. However, after file streams became reference counted,
this code would leak the file stream for the file being read.
(closes issue #15181)
Reported by: jkroon
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@196869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r196416 | dvossel | 2009-05-22 16:09:45 -0500 (Fri, 22 May 2009) | 19 lines
SIP set outbound transport type from Registration
In sip.conf the transport option allows for the configuration of what transport types (udp, tcp, and tls) a peer will accept, but only the first type listed was used for outbound connections. This patch changes this. Now the default transport type is only used until the peer registers. When registration takes place the transport type is parsed out of the Contact header. If the Contact header's transport type is equal to one that the peer supports, the peer's default transport type for outbound connections is set to match the Contact header's type. If the Contact header's transport type is not present, then the peer's default transport type is set to match the one the peer registered with. When a peer unregisters or the registration expires, the default transport type for that peer is reset.
(closes issue #12282)
Reported by: rjain
Patches:
reg_patch_1.diff uploaded by dvossel (license 671)
Tested by: dvossel
(closes issue #14727)
Reported by: pj
Patches:
reg_patch_3.diff uploaded by dvossel (license 671)
Tested by: pj, dvossel
Review: https://reviewboard.asterisk.org/r/249/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@196453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r195995 | dvossel | 2009-05-21 14:11:49 -0500 (Thu, 21 May 2009) | 20 lines
Merged revisions 195991 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195991 | dvossel | 2009-05-21 14:04:56 -0500 (Thu, 21 May 2009) | 14 lines
Sign problem calculating timestamp for iax frame leads to no audio on the receiving peer.
There are rare cases in which a frame's delivery timestamp is slightly less than the iax2_pvt's offset. This causes the pvt's timestamp to be a small negative number, but since the timestamp value is unsigned it looks like a huge positive number. This patch checks for this negative case and sets the ms to zero. A similar check is already done right below this one in the 'else' statement.
(closes issue #15032)
Reported by: guillecabeza
Patches:
chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380)
Tested by: guillecabeza
(closes issue #14216)
Reported by: Andrey Sofronov
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@195998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r195882 | mnicholson | 2009-05-21 10:33:55 -0500 (Thu, 21 May 2009) | 20 lines
Merged revisions 195881 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195881 | mnicholson | 2009-05-21 10:25:50 -0500 (Thu, 21 May 2009) | 13 lines
This commit prevents cdr records with AST_CDR_FLAG_ANSLOCKED and AST_CDR_FLAG_LOCKED from being updated in certain cases.
This is accomplished by adding two functions to update the answer time and disposition of calls that checks for the proper lock flags. These functions are used in the ast_bridge_call() function so that ForkCDR(A) calls are respected.
This patch also modifies the way ast_bridge_call() chooses the cdr record to base the bridged_cdr on. Previously the first unlocked cdr record would be chosen, now instead the first cdr record is chosen and forked cdr records are moved to the bridge_cdr. This allows the original cdr record and any forked cdr records to be properly updated with answer and end times.
(closes issue #13797)
Reported by: sh0t
Tested by: sh0t
(closes issue #14744)
Reported by: deepesh
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@195892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r195369 | eliel | 2009-05-18 16:49:20 -0400 (Mon, 18 May 2009) | 8 lines
Fix the CLI command 'manager show command' documentation and functionality.
The CLI command 'manager show command' supports passing multiple action names in
the same line, but it was not allowing that because of a incorrect check in the
argumentes counter. Also the documentation was updated to show that this usage
of the command is possible.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@195429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
