aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2008-08-25This patch reverts the changes made via 139347, and 139635, as usersmurf2-48/+0
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.4@139764 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22I found some problems with the code I committed earlier, whenmurf1-0/+8
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.4@139635 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22(closes issue #13359)jpeeler1-1/+1
Reported by: Laureano Patches: originate_channel_check.patch uploaded by Laureano (license 265) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139621 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22Fix compilation when DEBUG_THREAD_LOCALS is selectedmmichelson1-1/+1
(closes issue #13298) Reported by: snuffy Patches: bug13298_20080822.diff uploaded by snuffy (license 35) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139553 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22Remove show_frame_stats_deprecated since it is notmmichelson1-17/+0
used anywhere and causes build errors if building under dev-mode with TRACE_FRAMES selected in menuselect. (closes issue #13362) Reported by: snuffy git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139521 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22Fix the build. Thanks, mvanbaak!mmichelson1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139466 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22Prevent a deadlock in chan_iax2 resulting frommmichelson1-1/+4
incorrect locking order between iax2_pvt and ast_channel structures. AST-13 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139456 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-21Fixes loop that could possibly never exit in the event of a channel never ↵jpeeler1-1/+3
being able to be opened or specify after a restart. (closes issue #11017) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139387 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-21(closes issue #13251)murf2-0/+40
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! git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139347 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-21Apply fix for issue #13310 to branch 1.4, too.phsultan1-0/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139283 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-20Fix a crash in the ChanSpy application. The issue here is that if you callrussell1-2/+2
ChanSpy and specify a spy group, and sit in the application long enough looping through the channel list, you will eventually run out of stack space and the application with exit with a seg fault. The backtrace was always inside of a harmless snprintf() call, so it was tricky to track down. However, it turned out that the call to snprintf() was just the biggest stack consumer in this code path, so it would always be the first one to hit the boundary. (closes issue #13338) Reported by: ruddy git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139213 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-20Fix bug where the samples were not accurate when in G723 mode, which would sruffell1-6/+16
cause the timestamp field of the RTP header to be invalid. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139151 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-20Backport support for Zaptel/DAHDI channel-level alarms from trunk/1.6, ↵kpfleming4-4/+147
because not doing so just makes it difficult for people with channels that are in alarm when Asterisk starts up to get them going once the alarm is cleared (closes issue #12160) Reported by: tzafrir Patches: asterisk-chanalarms_14.patch uploaded by tzafrir (license 46) Tested by: tzafrir git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139145 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-20(closes issue #13263)murf1-4/+7
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.4@139074 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-20sip_read should properly handle a NULL return from sip_rtp_read.mmichelson1-1/+1
(closes issue #13257) Reported by: travishein git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139015 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-19add DAHDI_POLICY_WHEN_FULL compatability define for Zapteljpeeler1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138949 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-19Reset agent_pvt variables back to the values in agents.confmmichelson1-1/+9
(from what the corresponding channel variables were set to) when the agent logs out. (closes issue #13098) Reported by: davidw Patches: 20080731__issue13098_agent_ackcall_not_reset.diff uploaded by bbryant (license 36) Tested by: davidw git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138942 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-19Add configuration option to chan_dahdi.conf to allow buffering policy and ↵jpeeler1-17/+38
number of buffers to be configured per channel. Syntax: buffers=<num of buffers>,<policy> Where the number of buffers is some non-negative integer and the policy is either "full", "half", or "immediate". git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138938 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-19Add a lock and unlock prior to the destruction of the chanspy_dsmmichelson1-0/+2
lock to ensure that no other threads still have it locked. While this should not happen under normal circumstances, it appears that if the spyer and spyee hang up at nearly the same time, the following may occur. 1. ast_channel_free is called on the spyee's channel. 2. The chanspy datastore is removed from the spyee's channel in ast_channel_free. 3. In the spyer's thread, the spyer attempts to remove and destroy the datastore from the spyee channel, but the datastore has already been removed in step 2, so the spyer continues in the code. 4. The spyee's thread continues and calls the datastore's destroy callback, chanspy_ds_destroy. This involves locking the chanspy_ds. 5. Now the spyer attempts to destroy the chanspy_ds lock. The problem is that in step 4, the spyee has locked this lock, meaning that the spyer is attempting to destroy a lock which is currently locked by another thread. The backtrace provided in issue #12969 supports the idea that this is possible (and has even occurred). This commit does not close the issue, but should help in preventing one type of crash associated with the use of app_chanspy. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138886 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-18Change the inequalities used in app_queue with regardsmmichelson1-9/+9
to timeouts from being strict to non-strict for more accuracy. (closes issue #13239) Reported by: atis Patches: app_queue_timeouts_v2.patch uploaded by atis (license 242) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138685 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-18look for transcoder in proper place based on build against Zaptel or DAHDIkpfleming1-2/+16
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138663 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-18You know what's awesome? Code that compiles... ;)seanbright1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138569 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-18fix compilation warningsjpeeler1-1/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138516 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-16fixes use count to properly decrement if an active dahdi channel is ↵jpeeler1-0/+1
destroyed allowing module to be unloaded git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138360 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15add forgotten locks around ss_thread_count in ss_thread for dahdi restartjpeeler1-0/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138309 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15More fixes for realtime peers.tilghman2-31/+44
(closes issue #12921) Reported by: Nuitari Patches: 20080804__bug12921.diff.txt uploaded by Corydon76 (license 14) 20080815__bug12921.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138258 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15initialize condition variable ss_thread_complete using ast_cond_initjpeeler1-1/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138238 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15declared static mutexes using AST_MUTEX_DEFINE_STATIC macrojpeeler1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138151 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15Fixes the dahdi restart functionality. Dahdi restart allows one to restart ↵jpeeler1-62/+234
all DAHDI channels, even if they are currently in use. This is different from unloading and then loading the module since unloading requires the use count to be zero. Reloading the module is different in that the signalling is not changed from what it was originally configured. Also, this fixes not closing all the file descriptors for D-channels upon module unload (which would prevent loading the module afterwards). (closes issue #11017) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138119 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15Ensure that when a hangup occurs in autoservice, that a hangup frame getsrussell1-9/+5
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.4@138027 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-15Additional check for more string specifiers than arguments.tilghman1-4/+15
(closes issue #13299) Reported by: adomjan Patches: 20080813__bug13299.diff.txt uploaded by Corydon76 (license 14) func_strings.c-sprintf.patch uploaded by adomjan (license 487) Tested by: adomjan git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138023 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-14Oops, wrong directiontilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137850 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-14When creating the secondary subchannel name, it is necessary to compare totilghman1-1/+1
the existing channel name without the "Zap/" or "DAHDI/" prefix, since our test string is also without that prefix. (closes issue #13027) Reported by: dferrer Patches: chan_zap-1.4.21.1_fix2.patch uploaded by dferrer (license 525) (Slightly modified by me, to compensate for both names) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137847 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-14Comments in this config file were aligned only if your tab size was set to 8.russell1-334/+334
So, convert tabs to spaces so that things should be aligned regardless of what tab size you use in your editor. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137731 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-14forgot one module name that changedkpfleming1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137679 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-14add support for Zaptel versions that contain the new transcoder interfacekpfleming6-14/+90
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137677 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-13Register DAHDISendKeypadFacility application if dahdi_chan_mode is set to ↵jpeeler1-3/+27
DAHDI + Zap. Mark ZapSendKeypadFacility application as deprecated on usage. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137580 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-13add document describing what users will need to be aware of when upgrading ↵kpfleming1-0/+104
to this version and using DAHDI git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137530 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-13remove some more chan_zap referenceskpfleming1-4/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137529 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-13document dahdichanname option in doc/asterisk-conf.txtkpfleming2-9/+22
make chan_dahdi read its configuration from zapata.conf if dahdichanname has been set to 'no' git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137527 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-13Update docs to reflect the change to cdr_tdsseanbright1-1/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137405 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-13Bring cdr_tds in line with the other CDR backends and have it try to storeseanbright1-74/+175
CDR(userfield) if it is set. The new behavior is to check for the userfield column on module load, and if it exists, we will store CDR(userfield) when CDRs are written. A similar patch already went into trunk and 1.6.0. (closes issue #13290) Reported by: falves11 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137348 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-11convert this module to be able to handle DAHDI or Zaptel (reported on ↵kpfleming1-15/+22
asterisk-users, don't know how this got missed before) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137188 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-11Deallocate database connection handle on disconnect, as we allocate anothertilghman1-3/+14
one on connect. (closes issue #13271) Reported by: dveiga git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@137138 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-09Ensure PBX_DAHDI_TRANSCODE will evaluate to 0 if not found instead of empty.russell2-1/+3
pointed out by tzafrir on #asterisk-dev git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136999 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-09Merged revisions 136945 via svnmerge from tilghman2-0/+3
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r136945 | tilghman | 2008-08-09 10:24:36 -0500 (Sat, 09 Aug 2008) | 2 lines Regression fixes for Solaris ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136946 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-08(closes issue #13236)murf6-322/+640
Reported by: korihor Wow, this one was a challenge! I regrouped and ran a new strategy for setting the ~~MACRO~~ value; I set it once per extension, up near the top. It is only set if there is a switch in the extension. So, I had to put in a chunk of code to detect a switch in the pval tree. I moved the code to insert the set of ~~exten~~ up to the beginning of the gen_prios routine, instead of down in the switch code. I learned that I have to push the detection of the switches down into the code, so everywhere I create a new exten in gen_prios, I make sure to pass onto it the values of the mother_exten first, and the exten next. I had to add a couple fields to the exten struct to accomplish this, in the ael_structs.h file. The checked field makes it so we don't repeat the switch search if it's been done. I also updated the regressions. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136726 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-07change the required dependency for codec_dahdi to only be satisfied by DAHDI ↵kpfleming3-90/+8
and not Zaptel, as the new transcoder interface is only in DAHDI git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136560 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-07Updated codec_dahdi to use the new transcoder interface in the first DAHDIsruffell1-123/+80
release. Codec dahdi no longer functions with the transcoder interface in zaptel at this time (which the last zaptel release was 1.4.11). NOTE: Still needs an update to the configure script to make sure that codec_dahdi is only built if the new transcoder interface is present in the drivers. (Issue: DAHDI-42) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136544 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-07Update persistent state on all exit conditions.tilghman1-0/+2
(closes issue #12916) Reported by: sgenyuk Patches: app_queue.patch.txt uploaded by neutrino88 (license 297) Tested by: sgenyuk, aragon git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136488 f38db490-d61c-443f-a65b-d21fe96a405b