https://origsvn.digium.com/svn/asterisk/trunk
................
r134922 | murf | 2008-07-31 13:48:08 -0600 (Thu, 31 Jul 2008) | 63 lines
Merged revisions 134883 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134883 | murf | 2008-07-31 13:23:42 -0600 (Thu, 31 Jul 2008) | 51 lines
(closes issue #11849)
Reported by: greyvoip
Tested by: murf
OK, a few days of debugging, a bunch of instrumentation
in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid
notebook pages of notes later, I have made the small
tweek necc. to get the start time right on the second
CDR when:
A Calls B
B answ.
A hits Xfer button on sip phone,
A dials C and hits the OK button,
A hangs up
C answers ringing phone
B and C converse
B and/or C hangs up
But does not harm the scenario where:
A Calls B
B answ.
B hits xfer button on sip phone,
B dials C and hits the OK button,
B hangs up
C answers ringing phone
A and C converse
A and/or C hangs up
The difference in start times on the second CDR is because
of a Masquerade on the B channel when the xfer number is
sent. It ends up replacing the CDR on the B channel with
a duplicate, which ends up getting tossed out. We keep
a pointer to the first CDR, and update *that* after the
bridge closes. But, only if the CDR has changed.
I hope this change is specific enough not to muck
up any current CDR-based apps. In my defence, I
assert that the previous information was wrong,
and this change fixes it, and possibly other
similar scenarios.
I wonder if I should be doing the same thing
for the channel, as I did for the peer, but
I can't think of a scenario this might affect.
I leave it, then, as an exersize for the users,
to find the scenario where the chan's CDR
changes and loses the proper start time.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@134923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r134919 | tilghman | 2008-07-31 14:43:02 -0500 (Thu, 31 Jul 2008) | 6 lines
Two errors:
1) If a function returns SQLITE_LOCKED, no recovery is possible.
2) An error message can be allocated, even when no error is signalled.
(closes issue #13109)
Reported by: gknispel_proformatique
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@134920 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r134867 | tilghman | 2008-07-31 14:03:41 -0500 (Thu, 31 Jul 2008) | 4 lines
Optimize frame cache by realloc'ing the smallest frame when the cache is full.
This ensures that we don't just keep a cache of tiny frames, continually doing
an alloc/free for each data frame, thus negating the point of having a cache.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@134869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r134759 | mmichelson | 2008-07-31 11:05:12 -0500 (Thu, 31 Jul 2008) | 24 lines
Merged revisions 134758 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134758 | mmichelson | 2008-07-31 10:56:18 -0500 (Thu, 31 Jul 2008) | 16 lines
Add more timeout checks into app_queue, specifically
targeting areas where an unknown and potentially
long time has just elapsed. Also added a check
to try_calling() to return early if the timeout
has elapsed instead of potentially setting a negative
timeout for the call (thus making it have *no* timeout
at all).
(closes issue #13186)
Reported by: miquel_cabrespina
Patches:
13186.diff uploaded by putnopvut (license 60)
Tested by: miquel_cabrespina
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@134760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r134650 | tilghman | 2008-07-30 16:40:08 -0500 (Wed, 30 Jul 2008) | 12 lines
Merged revisions 134649 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134649 | tilghman | 2008-07-30 16:38:50 -0500 (Wed, 30 Jul 2008) | 4 lines
Qwell pointed out, via IRC, that the previous fix only worked when explicitly
set. When nothing is set, and the option is implied, it breaks, because
configure sets the prefix to 'NONE'. Fixing.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@134651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r134401 | tilghman | 2008-07-30 11:40:43 -0500 (Wed, 30 Jul 2008) | 7 lines
Move implementation of an attended-transfer-complete sound from one channel
driver into a common place for multiple channel drivers.
(closes issue #13152)
Reported by: caio1982
Patches:
atxfer_complete_sound3.diff uploaded by caio1982 (license 22)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@134405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r134125 | mmichelson | 2008-07-28 14:53:56 -0500 (Mon, 28 Jul 2008) | 27 lines
This commit compensates for buggy poll(2)
implementations. Asterisk has, for a long time,
had its own implementation of poll(2) which
just used the input arguments to call select(2).
In 1.4, this internal implementation was used
for Darwin systems. This was removed in Asterisk
trunk at some point, but it seems as though this
was not the right move to make.
On Mac OS X, it appears as though the poll used
to gather CLI input does not respond properly
when connecting via a remote Asterisk console.
Reverting to the use of Asterisk's poll fixed
the issue.
Also, there is now an option for the configure
script, --enable-internal-poll, which will allow
for anyone to use Asterisk's internal poll
implementation in case they suspect that their
system's poll implementation is buggy.
closes issue #11928)
Reported by: adriavidal
Patches:
1.6.0-configurev2.patch uploaded by putnopvut (license 60)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@134126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r133945 | russell | 2008-07-26 10:15:14 -0500 (Sat, 26 Jul 2008) | 6 lines
ast_device_state() gets called in two different ways. The first way is when
called from elsewhere in Asterisk to find the current state of a device. In
that case, we want to use the cached value if it exists. The other way is when
processing a device state change. In that case, we do not want to check the
cache because returning the last known state is counter productive.
........
r133946 | russell | 2008-07-26 10:16:20 -0500 (Sat, 26 Jul 2008) | 1 line
actually use the cache_cache argument
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@133947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r133943 | russell | 2008-07-26 09:57:50 -0500 (Sat, 26 Jul 2008) | 2 lines
Re-work comment about how device state changes are processed to be a bit more clear
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@133944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r133941 | russell | 2008-07-26 09:46:13 -0500 (Sat, 26 Jul 2008) | 3 lines
Remove the code that decided when device state changes should be cached or not.
It is no longer needed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@133942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r133575 | russell | 2008-07-25 09:57:11 -0500 (Fri, 25 Jul 2008) | 8 lines
Modify the main page of the doxygen documentation to link to a new page dedicated
to Asterisk licensing information. The licensing page includes the Asterisk license,
as well as a (not yet complete) list of 3rd party libraries that may be used, as well
as what license we receive them under.
Help filling out this list in the format that I have started in doxyref.h would be
much appreciated. :)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@133576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
