aboutsummaryrefslogtreecommitdiffstats
path: root/channel.c
AgeCommit message (Collapse)AuthorFilesLines
2007-07-05Tweak spy locking. (issue #9951 reported by welles)file1-8/+5
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73349 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-27I may possibly get shot for doing this... but... defer CDR processing until ↵file1-1/+7
after the channel has been dealt with. This should eliminate all of the issues with channels going funky (SIP/PRI) when you are posting CDRs to a database that is either slow or unavailable and do not want to enable batching. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@72256 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-19This fixes 9246, where channel variables are not available in the 'h' exten, ↵murf1-1/+10
on a 'ZOMBIE' channel. The fix is to consolidate the channel variables during a masquerade, and then copy the merged variables back onto the clone, so the zombie has the same vars that the 'original' has. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@70053 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-19Update BRIDGEPEER variable if set to the new channel name when a masquerade ↵file1-0/+6
happens. (issue #9699 reported by dimas) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@69986 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-14Backport rev 69010 from the 1.4 branch ...russell1-0/+5
In ast_channel_make_compatible(), just return if the channels' read and write formats already match up. There are code paths that call this function on a pair of channels multiple times. This made calls fail that were using g729 in some cases. The reason is that codec_g729a will unregister itself from the list of available translators will all licenses are in use. So, the first time the function got called, the right translation path was allocated. However, the second time it got called, the code would not find a translation path to/from g729 and make the call fail, even if the channel actually already had a g729 translation path allocated. (SPD-32) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@69347 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-11Improve deadlock handling of the channel list. (issue #8376 reported by one47)file1-7/+17
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@68682 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-06We have some bug reports showing crashes due to a double free of a channel.russell1-7/+9
Add a sanity check to ast_channel_free() to make sure we don't go on trying to free a channel that wasn't found in the channel list. (issue #8850, and others...) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@67715 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-07Properly handle what happens during a masquerade in relation to group ↵file1-1/+1
counting. (issue #9657 reported by ramonpeek) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@63285 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-25Merge rewritten group counting support. No more storing data on the variable ↵file1-16/+5
list of the channels. That was bad, mmmk? (issue #7497 reported by sabbathbh) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@61804 f38db490-d61c-443f-a65b-d21fe96a405b
2007-02-25Issue 9130 - If prev is the last item on the channel list, then evaluatingtilghman1-1/+5
additional conditions (e.g. name prefix) will cause a NULL dereference. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@56684 f38db490-d61c-443f-a65b-d21fe96a405b
2007-02-22Only change the original or clone channel if it's the channel behind the ↵file1-2/+2
proxy channel, not if it's just a regular bridged channel. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@56230 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-30Don't print a message indicating that we don't know what to do with a proceedingrussell1-1/+1
control frame in ast_request_and_dial(). We just need to ignore it. (reported by JerJer on #asterisk-dev) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@52954 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-24Fix an issue related to synchronization of recordings when using Monitor().russell1-4/+6
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: http://svn.digium.com/svn/asterisk/branches/1.2@51843 f38db490-d61c-443f-a65b-d21fe96a405b
2006-12-13This small patch fixes bug 8541, where the L option to the Dial app wasn't ↵murf1-2/+5
working right. A similar bug (8386) was filed and fixed earlier, but an intervening bug fix to a DTMF problem broke the L() code in a different way. Hopefully, everything is happy now. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@48434 f38db490-d61c-443f-a65b-d21fe96a405b
2006-12-04If the generic bridge tells us not to retry, and we have a frame to spit out ↵file1-0/+2
then break the bridge. Props to markit in #asterisk-bugs for bringing this up. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@48233 f38db490-d61c-443f-a65b-d21fe96a405b
2006-11-30Don't write AST_FRAME_NULL or AST_FRAME_IAX frames out to the channel ↵file1-0/+5
driver. (issue #8390 reported by hselasky) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@48161 f38db490-d61c-443f-a65b-d21fe96a405b
2006-11-22This is the fix for bug 8386, wherein the time-limit args to dial didn't ↵murf1-7/+12
work correctly git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@47910 f38db490-d61c-443f-a65b-d21fe96a405b
2006-11-17backport proper channel_find_locked behavior from 1.4 branch (noted by Steve ↵kpfleming1-30/+21
Davies on asterisk-dev list) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@47802 f38db490-d61c-443f-a65b-d21fe96a405b
2006-11-07This mod for bug_7506, to make the manager code output the proper eventmurf1-1/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@47274 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-27Fix a problem that occurred if a user entered a digit that matched a bridgerussell1-3/+5
feature that was configured using multiple digits, and the digit that was pressed timed out in the feature digit timeout period. For example, if blind transfer is configured as '##', and a user presses just '#'. In this situation, the call would lock up and no longer pass any frames. (issue #7977 reported by festr, and issue #7982 reported by michaels and valuable input provided by mneuhauser and kuj. Fixed by me, with testing help and peer review from Joshua Colp). There are a couple of issues involved in this fix: 1) When ast_generic_bridge determines that there has been a timeout, it returned AST_BRIDGE_RETRY. Then, when ast_channel_bridge gets this result, it calls ast_generic_bridge over again with the same timestamp for the next event. This results in an endless loop of nothing until the call is terminated. This is resolved by simply changing ast_generic_bridge to return AST_BRIDGE_COMPLETE when it sees a timeout. 2) I also changed ast_channel_bridge such that if in the process of calculating the time until the next event, it knows a timeout has already occured, to immediately return AST_BRIDGE_COMPLETE instead of attempting to bridge the channels anyway. 3) In the process of testing the previous two changes, I ran into a problem in res_features where ast_channel_bridge would return because it determined that there was a timeout. However, ast_bridge_call in res_features would then determine by its own calculation that there was still 1 ms before the timeout really occurs. It would then proceed, and since the bridge broke out and did *not* return a frame, it interpreted this as the call was over and hung up the channels. The reason for this was because ast_bridge_call in res_features and ast_channel_bridge in channel.c were using different times for their calculations. channel.c uses the start_time on the bridge config, which is the time that the feature digit was recieved. However, res_features had another time, 'start', which was set right before calling ast_channel_bridge. 'start' will always be slightly after start_time in the bridge config, and sometimes enough to round up to one ms. This is fixed by making ast_bridge_call use the same time as ast_channel_bridge for the timeout calculation. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@43778 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-22Yay another 'round of spy fixes! This fixes a small logic flaw with the ↵file1-1/+1
cleanup function and a memory allocation issue. (issue #7960 reported by jojo & issue #7999 reported by aster1) Special thanks to csum77 for letting me into a box where this issue was happening. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@43509 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-09Only truly consider the channel in the same format if the format matches the ↵file1-1/+1
raw format OR if a translation path already exists to translate between them. (issue #7887 reported by softins & issue #7803 reported by alvaro_palma_aste). Thanks goes to stubert for giving me access to a box and showing me a scenario where this occured. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@42600 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-08Swap spies during masqueradingfile1-0/+23
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@42452 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-05Merge in last round of spy fixes. This should hopefully eliminate all the ↵file1-40/+71
issues people have been seeing by distinctly separating what each component (core/spy) is responsible for. Core is responsible for adding a spy to a channel, feeding frames to the spy, removing the spy from a channel, and telling the spy to stop. Spy is responsible for reading frames in, and cleaning up after itself. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@42054 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-01Finish up the last commit (was worse then originally reported)file1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@41691 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-01Don't treat an unexpected control subclass as voice (issue #7858 reported by ↵file1-0/+1
PCadach) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@41690 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-24Fix a few issues related to the handling of channel variablesrussell1-2/+2
- in pbx_builtin_serialize_variables(), the variable list traversal would stop on a variables with empty name/values, which is not appropriate - When removing the GROUP variables, use AST_LIST_REMOVE_CURRENT instead of AST_LIST_REMOVE - During masquerading, when copying the variables list from one channel to the other, using AST_LIST_INSERT_TAIL is not valid for appending a whole list. It leaves the tail pointer of the list invalid. Introduce a new macro, AST_LIST_APPEND_LIST that appends a list properly. (issue #7802, softins) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@40994 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-17revert bogus change to attempt to fix bug 7506 which actually causes half ofrussell1-1/+2
the channels not to get "Newchannel" events at all (issue #7745) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@40227 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-07Reset our stream and vstream pointers back to NULL so that any generator ↵file1-2/+8
that uses them (file based MOH) will not try to close them again. (issue #7668 reported by jmls) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@39056 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-05Always generate a Newstate event in ast_setstate() instead of making it arussell1-2/+1
Newchannel event if the state was AST_STATE_DOWN. The Newchannel event will always be generated in ast_request(), so this just causes a duplicated Newchannel event in some cases. (issue #7506, repoted by capouch, fixed by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38982 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-05suppress a compiler warning about the usage of a potentially uninitialized ↵russell1-1/+1
variable git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38903 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-01ensure that the 'feature digit timeout' value is taken into account when ↵kpfleming1-4/+11
deciding how long the bridge should run (this fixes a problem report where a digit press that did not invoke a feature is never passed across the bridge) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38686 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-27do a better job avoiding translation path teardown/setup when not neededkpfleming1-4/+7
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38347 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-27don't do useless translation destroy/build when the channel is already in ↵kpfleming1-0/+4
the correct format git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38310 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-10do masquerade-behind-proxy checking with better control over lockskpfleming1-8/+28
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@37361 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-06patch resolves issue with when to decide if its right time mogorman1-1/+2
to native bridge, feature redirect was not being checked. patch from bug #7296 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@37224 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-12Greatly simply the mixmonitor thread, and move channel reference directly to ↵file1-1/+14
spy structure so that the core can modify it. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@33724 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-01handle Zap transfers behind chan_agent properly so the agent doesn't get ↵kpfleming1-0/+8
stuck waiting for the call to hang up git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@31520 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-16don't leak frames when deferring DTMF or dropping duplicate ANSWER frames ↵kpfleming1-0/+2
(issue #7041, slightly different fix, reported/patched by clausf) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@27468 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-21Rolling back change until kpfleming is comfytilghman1-4/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@22113 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-21Bug 7004 - release all threads waiting on a condition prior to freeing ittilghman1-1/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@22112 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-11simplify spy queue flushing logic, and always force a flush when one side ↵kpfleming1-42/+35
gets full, even if the other side is not empty (issue #6457) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@19347 f38db490-d61c-443f-a65b-d21fe96a405b
2006-03-06Revert earlier changeoej1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@12072 f38db490-d61c-443f-a65b-d21fe96a405b
2006-03-06Fix for astmm compilationoej1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@12036 f38db490-d61c-443f-a65b-d21fe96a405b
2006-02-27don't hang up the channel if its state is set to UP before we return from ↵russell1-1/+2
ast_call (issue #6569) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@11250 f38db490-d61c-443f-a65b-d21fe96a405b
2006-02-25ensure that spy frame queueing is able to deal with translation failing for ↵kpfleming1-1/+6
any reason (issue #6546) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@11058 f38db490-d61c-443f-a65b-d21fe96a405b
2006-02-11now that CDR is a loadable module, don't depend on it elsewhere (issue #6460)russell1-0/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@9581 f38db490-d61c-443f-a65b-d21fe96a405b
2006-01-25Issue #6439 - the "timebomb" bug. Patch by Markster over GPRSoej1-5/+8
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@8632 f38db490-d61c-443f-a65b-d21fe96a405b
2006-01-24ensure that channel cannot become zombie after we check but before we try to ↵kpfleming1-2/+4
start indications git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@8588 f38db490-d61c-443f-a65b-d21fe96a405b
2006-01-22fix MixMonitor crash (issue #6321, probably others)russell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@8437 f38db490-d61c-443f-a65b-d21fe96a405b