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: https://origsvn.digium.com/svn/asterisk/branches/1.2@69347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.2@67715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.2@51843 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.2@43778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- 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: https://origsvn.digium.com/svn/asterisk/branches/1.2@40994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.2@38982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
