Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@211526 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73349 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
happens. (issue #9699 reported by dimas)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@69986 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@68682 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
counting. (issue #9657 reported by ramonpeek)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@63285 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
driver. (issue #8390 reported by hselasky)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@48161 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
work correctly
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@47910 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Davies on asterisk-dev list)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@47802 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@47274 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@42452 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@41691 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
PCadach)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@41690 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- 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
|
|
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
|
|
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
|
|
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
|
|
variable
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38903 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38347 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the correct format
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@38310 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@37361 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
(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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@22113 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@22112 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@12072 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@12036 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ast_call (issue #6569)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@11250 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
any reason (issue #6546)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@11058 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@9581 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@8632 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
start indications
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@8588 f38db490-d61c-443f-a65b-d21fe96a405b
|