Age | Commit message (Collapse) | Author | Files | Lines |
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r140749 | murf | 2008-09-02 17:44:04 -0600 (Tue, 02 Sep 2008) | 11 lines
Merged revisions 140747 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140747 | murf | 2008-09-02 17:36:56 -0600 (Tue, 02 Sep 2008) | 1 line
I am turning the warnings generated in ast_cdr_free and post_cdr into verbose level 2 messages. Really, they matter little to end users. You either get the CDR's you wanted, or you don't, and it is a bug.
For trunk, I am going one step further. These messages were pretty worthless even for debug, so I'm completely removing them.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@140827 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r140692 | murf | 2008-09-02 16:55:12 -0600 (Tue, 02 Sep 2008) | 13 lines
Merged revisions 140690 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140690 | murf | 2008-09-02 16:40:13 -0600 (Tue, 02 Sep 2008) | 1 line
After reconsidering, with respect to 13409, ast_cdr_detach should be OK, better in fact, than ast_cdr_free, which generates lots of useless warnings that will undoubtably generate complaints.
Hmmm. It doesn't hush the useless warnings, but it does allow control of posting via the detach and post routines, for those possible situations,
where you'd want to post single-channel cdrs.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@140826 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r140691 | murf | 2008-09-02 16:50:59 -0600 (Tue, 02 Sep 2008) | 22 lines
Merged revisions 140670 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140670 | murf | 2008-09-02 16:15:57 -0600 (Tue, 02 Sep 2008) | 14 lines
(closes issue #13409)
Reported by: tomaso
Patches:
asterisk-1.6.0-rc2-cdrmemleak.patch uploaded by tomaso (license 564)
I basically spent the day, verifying that this patch
solves the problem, and doesn't hurt in non-problem
cases. Why valgrind did not plainly reveal this leak
absolutely mystifies and stuns me.
Many, many thanks to tomaso for finding and providing the fix.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@140825 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r140817 | russell | 2008-09-03 08:26:43 -0500 (Wed, 03 Sep 2008) | 12 lines
Merged revisions 140816 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140816 | russell | 2008-09-03 08:24:35 -0500 (Wed, 03 Sep 2008) | 4 lines
Don't freak out if the poll emulation receives NULL for the pollfds array
(closes issue #13307)
Reported by: jcovert
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@140818 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r139770 | murf | 2008-08-25 09:54:18 -0600 (Mon, 25 Aug 2008) | 17 lines
Merged revisions 139764 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139764 | murf | 2008-08-25 09:33:14 -0600 (Mon, 25 Aug 2008) | 9 lines
This patch reverts the changes made via 139347, and 139635, as users
are seeing adverse difference.
I will un-close 13251.
Back to the drawing board/ concept/ beginning/ whatever!
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@139774 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r139662 | murf | 2008-08-22 16:32:35 -0600 (Fri, 22 Aug 2008) | 14 lines
Merged revisions 139635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139635 | murf | 2008-08-22 16:24:02 -0600 (Fri, 22 Aug 2008) | 6 lines
I found some problems with the code I committed earlier, when
I merged them into trunk, so I'm coming back to clean up.
And, in the process, I found an error in the code I added
to trunk and 1.6.x, that I'll fix using this patch also.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@139671 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r139627 | murf | 2008-08-22 16:03:13 -0600 (Fri, 22 Aug 2008) | 59 lines
Merged revisions 139347 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines
(closes issue #13251)
Reported by: sergee
Tested by: murf
THis is a bold move for a static release fix, but I wouldn't have
made it if I didn't feel confident (at least a *bit* confident)
that it wouldn't mess everyone up.
The reasoning goes something like this:
1. We simply cannot do anything with CDR's at the current point
(in pbx.c, after the __ast_pbx_run loop). It's way too late to
have any affect on the CDRs. The CDR is already posted and gone,
and the remnants have been cleared.
2. I was very much afraid that moving the running of the 'h'
extension down into the bridge code (where it would be now
practical to do it), would result in a lot more calls to the
'h' exten, so I implemented it as another exten under another
name, but found, to my pleasant surprise, that there was a
1:1 correspondence to the running of the 'h' exten in the
pbx_run loop, and the new spot at the end of the bridge.
So, I ifdef'd out the current 'h' loop, and moved it into
the bridge code. The only difference I can see is the stuff
about the AST_PBX_KEEPALIVE, and hopefully, if this
is still an important decision point, I can replicate it
if there are complaints. To be perfectly honest,
the KEEPALIVE situation is not totally clear to me,
and how it relates to a post-bridge situation is less
clear. I suspect the users will point out everything
in total clarity if this steps on anyone's toes!
3. I temporarily swap the bridge_cdr into the channel
before running the 'h' exten, which makes it possible
for users to edit the cdr before it goes out the door.
And, of course, with the endbeforehexten config var set,
the users can also get at the billsec/duration vals.
After the h exten finishes, the cdr is swapped back
and processing continues as normal.
Please, all who deal with CDR's, please test this version
of Asterisk, and file bug reports as appropriate!
........
I also made a little fix to the app_dial's 'e' option,
that is related to my updates.
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@139628 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r139083 | murf | 2008-08-20 11:25:07 -0600 (Wed, 20 Aug 2008) | 20 lines
Merged revisions 139074 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139074 | murf | 2008-08-20 11:14:55 -0600 (Wed, 20 Aug 2008) | 12 lines
(closes issue #13263)
Reported by: brainy
Tested by: murf
The specialized reset routine is tromping on the
flags field of the CDR. I made a change to not
reset the DISABLED bit. This should get rid of this
problem.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@139104 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r138815 | murf | 2008-08-19 09:59:12 -0600 (Tue, 19 Aug 2008) | 19 lines
These changes are in regards to bug 13249, where users are being surprised by the changes made
to the Set app in trunk/1.6.x, as they come from the 1.4 world. They are only bitten if
they write their AEL dialplan in the 1.4 world, and then carry it over to a trunk/1.6.x
installation where a "make samples" was executed, or where they hand-edited the
asterisk.conf file and added the [compat] category with app_set = 1.6 (or higher).
(this commit does not totally solve 13249, at least not yet)
The change involves issueing a single warning while the AEL file is loading, if:
1. app_set is present in the config file, and set to 1.6 or higher.
2. there are double quotes in an assignment statement (eg x = "hi there";)
3. the warning was not already issued.
The standalone app, aelparse, does not (yet) issue this warning. I'd have to
have it read in the asterisk.conf file, and that's a bit of hassle. I'll add
it if users request it, tho.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138846 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r138482 | seanbright | 2008-08-17 10:12:11 -0400 (Sun, 17 Aug 2008) | 6 lines
Move Uniqueid to the end of the event for those that rely on the position
of the name/value pairs, pointed out by snuffy-home on #asterisk-commits.
For those of you who rely on the position of name/value pairs in manager
events... stop... that is why associative arrays were invented.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138483 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r138479 | seanbright | 2008-08-17 09:51:08 -0400 (Sun, 17 Aug 2008) | 7 lines
Add Uniqueid header to ParkedCall manager event.
(closes issue #13323)
Reported by: srt
Patches:
13323_unique_id_for_parkedcalls_event.diff uploaded by srt (license 378)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138480 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r138476 | seanbright | 2008-08-17 09:40:36 -0400 (Sun, 17 Aug 2008) | 7 lines
Add missing colons to RTCPReceived and RTCPSent manager events.
(closes issue #13319)
Reported by: srt
Patches:
13319_rtcp_manager_event_headers.diff uploaded by srt (license 378)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138477 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r138206 | tilghman | 2008-08-15 15:35:24 -0500 (Fri, 15 Aug 2008) | 4 lines
Remove deprecated syntax from sample config file
(closes issue #13314)
Reported by: kue
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138207 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r138028 | russell | 2008-08-15 10:09:46 -0500 (Fri, 15 Aug 2008) | 17 lines
Merged revisions 138027 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138027 | russell | 2008-08-15 10:07:16 -0500 (Fri, 15 Aug 2008) | 9 lines
Ensure that when a hangup occurs in autoservice, that a hangup frame gets
properly deferred to be read from the channel owner when it gets taken out
of autoservice.
(closes issue #12874)
Reported by: dimas
Patches:
v1-12874.patch uploaded by dimas (license 88)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@138029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r136660 | mmichelson | 2008-08-07 15:25:43 -0500 (Thu, 07 Aug 2008) | 4 lines
Bump a LOG_NOTICE message to LOG_DEBUG since it appears
once for every bridged call
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@136663 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r136635 | mmichelson | 2008-08-07 14:58:32 -0500 (Thu, 07 Aug 2008) | 5 lines
Don't allow Answer() to accept a negative argument.
Negative argument means an infinite delay and we
don't want that.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@136636 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r136633 | mmichelson | 2008-08-07 14:54:27 -0500 (Thu, 07 Aug 2008) | 7 lines
Fix a calculation error I had made in the poll. The poll
would reset to 500 ms every time a non-voice frame
was received. The total time we poll should be 500 ms, so
now we save the amount of time left after the poll returned
and use that as our argument for the next call to poll
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@136634 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r136631 | mmichelson | 2008-08-07 14:36:46 -0500 (Thu, 07 Aug 2008) | 13 lines
Scrap the 500 ms delay when Asterisk auto-answers a channel.
Instead, poll the channel until receiving a voice frame. The
cap on this poll is 500 ms.
The optional delay is still allowable in the Answer() application,
but the delay has been moved back to its original position, after
the call to the channel's answer callback. The poll for the voice
frame will not happen if a delay is specified when calling Answer().
(closes issue #12708)
Reported by: kactus
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@136632 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r136063 | mmichelson | 2008-08-06 10:59:29 -0500 (Wed, 06 Aug 2008) | 24 lines
Merged revisions 136062 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r136062 | mmichelson | 2008-08-06 10:58:40 -0500 (Wed, 06 Aug 2008) | 16 lines
Since adding the AST_CONTROL_SRCUPDATE frame type,
there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@136064 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r135950 | tilghman | 2008-08-05 22:55:49 -0500 (Tue, 05 Aug 2008) | 12 lines
Merged revisions 135949 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135949 | tilghman | 2008-08-05 22:53:36 -0500 (Tue, 05 Aug 2008) | 4 lines
Fix a longstanding bug in channel walking logic, and fix the explanation to
make sense.
(Closes issue #13124)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135951 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r135938 | tilghman | 2008-08-05 22:29:42 -0500 (Tue, 05 Aug 2008) | 12 lines
Merged revisions 135915 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135915 | tilghman | 2008-08-05 22:24:56 -0500 (Tue, 05 Aug 2008) | 4 lines
Since powerof() can return an error condition, it's foolhardy not to detect and
deal with that condition.
(Related to issue #13240)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135942 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r135851 | mmichelson | 2008-08-05 19:30:53 -0500 (Tue, 05 Aug 2008) | 48 lines
Merged revisions 135841,135847,135850 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135841 | mmichelson | 2008-08-05 19:25:10 -0500 (Tue, 05 Aug 2008) | 27 lines
Merging the issue11259 branch.
The purpose of this branch was to take into account
"burps" which could cause jitterbuffers to misbehave.
One such example is if the L option to Dial() were used
to inject audio into a bridged conversation at regular
intervals. Since the audio here was not passed through
the jitterbuffer, it would cause a gap in the jitterbuffer's
timestamps which would cause a frames to be dropped for a
brief period.
Now ast_generic_bridge will empty and reset the jitterbuffer
each time it is called. This causes injected audio to be handled
properly.
ast_generic_bridge also will empty and reset the jitterbuffer
if it receives an AST_CONTROL_SRCUPDATE frame since the change
in audio source could negatively affect the jitterbuffer.
All of this was made possible by adding a new public API call
to the abstract_jb called ast_jb_empty_and_reset.
(closes issue #11259)
Reported by: plack
Tested by: putnopvut
........
r135847 | mmichelson | 2008-08-05 19:27:54 -0500 (Tue, 05 Aug 2008) | 4 lines
Revert inadvertent changes to app_skel that occurred when
I was testing for a memory leak
........
r135850 | mmichelson | 2008-08-05 19:29:54 -0500 (Tue, 05 Aug 2008) | 3 lines
Remove properties that should not be here
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135852 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r135821 | murf | 2008-08-05 17:45:32 -0600 (Tue, 05 Aug 2008) | 42 lines
Merged revisions 135799 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135822 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r135598 | seanbright | 2008-08-05 09:26:34 -0400 (Tue, 05 Aug 2008) | 9 lines
Merged revisions 135597 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135597 | seanbright | 2008-08-05 09:25:00 -0400 (Tue, 05 Aug 2008) | 1 line
Use PATH_MAX for filenames
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135599 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r135265 | murf | 2008-08-01 22:51:29 -0600 (Fri, 01 Aug 2008) | 31 lines
(closes issue #13202)
Reported by: falves11
Tested by: murf
falves11 ==
The changes I introduce here seem to clear up the problem
for me. However, if they do not for you, please reopen this
bug, and we'll keep digging.
The root of this problem seems to be a subtle memory corruption
introduced when creating an extension with an empty extension
name. While valgrind cannot detect it outside of DEBUG_MALLOC
mode, when compiled with DEBUG_MALLOC, this is certain death.
The code in main/features.c is a puzzle to me. On the initial
module load, the code is attempting to add the parking extension
before the features.conf file has even been opened!
I just wrapped the offending call with an if() that will not
try to add the extension if the extension name is empty. THis
seems to solve the corruption, and let the "memory show allocations"
work as one would expect.
But, really, adding an extension with an empty name is a seriously
bad thing to allow, as it will mess up all the pattern matching
algorithms, etc. So, I added a statement to the add_extension2 code to return
a -1 if this is attempted.
in 1.6.0, the changes to only main/pbx.c were applicable,
as apparently the code added to main/features by jpeeler
were not included in 1.6.0.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135266 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r135016 | kpfleming | 2008-07-31 17:28:42 -0500 (Thu, 31 Jul 2008) | 11 lines
Merged revisions 134983 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134983 | kpfleming | 2008-07-31 17:18:11 -0500 (Thu, 31 Jul 2008) | 3 lines
accomodate users who seem to lack a sense of humor :-)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@135034 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r134980 | tilghman | 2008-07-31 16:55:42 -0500 (Thu, 31 Jul 2008) | 16 lines
Blocked revisions 134976 via svnmerge
........
r134976 | tilghman | 2008-07-31 16:53:19 -0500 (Thu, 31 Jul 2008) | 9 lines
Specify codecs in callfiles and manager, to allow video calls to be set up
from callfiles and AMI.
(closes issue #9531)
Reported by: Geisj
Patches:
20080715__bug9531__1.4.diff.txt uploaded by Corydon76 (license 14)
20080715__bug9531__1.6.0.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@134981 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@134923 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r134703 | tilghman | 2008-07-30 17:38:58 -0500 (Wed, 30 Jul 2008) | 2 lines
Oops, wrong define
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@134706 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r134476 | mmichelson | 2008-07-30 13:33:12 -0500 (Wed, 30 Jul 2008) | 12 lines
Merged revisions 134475 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134475 | mmichelson | 2008-07-30 13:31:47 -0500 (Wed, 30 Jul 2008) | 4 lines
Fix a spot where a function could return without bringing
a channel out of autoservice.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@134477 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@134126 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r134086 | kpfleming | 2008-07-28 11:42:00 -0500 (Mon, 28 Jul 2008) | 3 lines
remove remaining Zaptel references in various places
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@134087 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r134050 | mmichelson | 2008-07-28 11:00:19 -0500 (Mon, 28 Jul 2008) | 3 lines
merging the zap_and_dahdi_trunk branch up to trunk
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@134052 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
trunk,
and 1.6.0.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@133982 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@133947 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to replace the + with a space.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@133804 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r133665 | tilghman | 2008-07-25 12:24:43 -0500 (Fri, 25 Jul 2008) | 16 lines
Merged revisions 133649 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133649 | tilghman | 2008-07-25 12:19:39 -0500 (Fri, 25 Jul 2008) | 8 lines
Fix some errant device states by making the devicestate API more strict in
terms of the device argument (only without the unique identifier appended).
(closes issue #12771)
Reported by: davidw
Patches:
20080717__bug12771.diff.txt uploaded by Corydon76 (license 14)
Tested by: davidw, jvandal, murf
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@133671 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r133448 | mmichelson | 2008-07-24 14:53:37 -0500 (Thu, 24 Jul 2008) | 12 lines
Print the correct PID in log messages. Prior to
this commit, only the logger thread's PID would
be printed.
(closes issue #13150)
Reported by: atis
Patches:
log_pid.diff uploaded by putnopvut (license 60)
Tested by: eliel
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@133449 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r133299 | murf | 2008-07-23 16:03:48 -0600 (Wed, 23 Jul 2008) | 27 lines
(closes issue #13144)
Reported by: murf
Tested by: murf
For: J. Geis
The 'data' field in the ast_exten struct was being
'moved' from the current dialplan to the replacement
dialplan. This was not good, as the current dialplan
could have problems in the time between the change
and when the new dialplan is swapped in.
So, I modified the merge_and_delete code to strdup
the 'data' field (the args to the app call), and
then it's freed as normal.
I improved a few messages; I added code to limit
the number of calls to the context_merge_incls_swits_igps_other_registrars()
to one per context. I don't think having it called
multiple times per context was doing anything bad,
but it was inefficient.
I hope this fixes the problems Mr. Geiss was noting in
asterisk-users, see
http://lists.digium.com/pipermail/asterisk-users/2008-July/215634.html
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@133300 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r133171 | mmichelson | 2008-07-23 14:48:03 -0500 (Wed, 23 Jul 2008) | 20 lines
Merged revisions 133169 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133169 | mmichelson | 2008-07-23 14:39:47 -0500 (Wed, 23 Jul 2008) | 12 lines
As suggested by seanbright, the PSEUDO_CHAN_LEN in
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@133172 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r132964 | kpfleming | 2008-07-23 11:30:18 -0500 (Wed, 23 Jul 2008) | 10 lines
Merged revisions 132872 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132872 | kpfleming | 2008-07-23 06:52:18 -0500 (Wed, 23 Jul 2008) | 2 lines
minor optimization for stringfields: when a field is being set to a larger value than it currently contains and it happens to be the most recent field allocated from the currentl pool, it is possible to 'grow' it without having to waste the space it is currently using (or potentially even allocate a new pool)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132965 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r132511 | tilghman | 2008-07-21 16:00:47 -0500 (Mon, 21 Jul 2008) | 2 lines
(Step 2 of 2)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132513 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r132510 | tilghman | 2008-07-21 15:59:03 -0500 (Mon, 21 Jul 2008) | 5 lines
Optionally build integer-based routines for FSK tone decoding (but default
to the more accurate float-based routines).
(Closes issue #11679)
(Step 1 of 2)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132512 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r132390 | russell | 2008-07-21 09:47:41 -0500 (Mon, 21 Jul 2008) | 16 lines
Remove libresample from the Asterisk source tree. It is now available in its
own repository, and must be installed like any other library for Asterisk to
use. The two modules that require it are codec_resample and app_jack.
To install libresample:
$ svn co http://svn.digium.com/svn/libresample/trunk libresample
$ cd libresample
$ ./configure
$ make
$ sudo make install
This code is currently in our own repository because the build system did not
include the appropriate targets for building a dynamic library or for installing
the library.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132391 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r132242 | bbryant | 2008-07-18 17:19:56 -0500 (Fri, 18 Jul 2008) | 4 lines
Fixes problem where manager users loaded from users.conf would be
removed early (before the routine to load the configuration was
finished) because a variable wasn't initialized.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132245 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r132113 | tilghman | 2008-07-18 14:09:39 -0500 (Fri, 18 Jul 2008) | 14 lines
Merged revisions 132112 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132112 | tilghman | 2008-07-18 14:06:10 -0500 (Fri, 18 Jul 2008) | 6 lines
Fix for Taiwanese number syntax
(closes issue #12319)
Reported by: CharlesWang
Patches:
saynumber-tw-1.4.18.1.patch uploaded by CharlesWang (license 444)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132114 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r132109 | tilghman | 2008-07-18 13:50:37 -0500 (Fri, 18 Jul 2008) | 14 lines
Merged revisions 132107 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132107 | tilghman | 2008-07-18 13:47:50 -0500 (Fri, 18 Jul 2008) | 6 lines
Textual clarification
(closes issue #13106)
Reported by: flefoll
Patches:
config.c.br14.120173.patch-unknown-directive uploaded by flefoll (license 244)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132110 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r132050 | bbryant | 2008-07-18 12:55:41 -0500 (Fri, 18 Jul 2008) | 8 lines
Fix magic Revision keywords in hashtab.c and change cdr_radius.c to use
the same keyword as the other files (patch by eliel).
(closes issue #13104)
Reported by: eliel
Patches:
revision.patch uploaded by eliel (license 64)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@132051 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r131989 | tilghman | 2008-07-18 12:10:34 -0500 (Fri, 18 Jul 2008) | 10 lines
Merged revisions 131988 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r131988 | tilghman | 2008-07-18 12:10:01 -0500 (Fri, 18 Jul 2008) | 2 lines
Oops
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@131990 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r131986 | tilghman | 2008-07-18 11:48:18 -0500 (Fri, 18 Jul 2008) | 10 lines
Merged revisions 131985 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r131985 | tilghman | 2008-07-18 11:46:23 -0500 (Fri, 18 Jul 2008) | 2 lines
Preserve ABI compatibility with last change
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@131987 f38db490-d61c-443f-a65b-d21fe96a405b
|