........
r43924 | file | 2006-09-28 14:00:30 -0400 (Thu, 28 Sep 2006) | 2 lines
Put in missing \ns on the end of ast_logs (issue #7936 reported by wojtekka)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43897 | bweschke | 2006-09-28 12:37:15 -0400 (Thu, 28 Sep 2006) | 3 lines
app_queue is comparing the device names incorrectly while checking their statuses. It's internal list of interfaces includes the dial string, while the argument passed to this function does not have the dial string (/n for a local channel). This causes it to ignore the device state changes because it thinks it belongs to none of its members. (#8040 reported and patch by tim_ringenbach)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix a minor issue, to make it use the filenames that were parsed, instead of the entire argument string.
Fix Background() to return -1 like Playback(), if no args are specified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43778 | russell | 2006-09-27 12:54:30 -0400 (Wed, 27 Sep 2006) | 42 lines
Fix a problem that occurred if a user entered a digit that matched a bridge
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.4@43779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
mm_login to close bug 8038, as well as addresses some formatting and coding
guidelines issues in passing.
Originally, I did not commit this to 1.4 since it is not necessarily fixing a
bug. However, since the IMAP storage code is brand new, I decided it would
be better to make the change here as well, in case someone has to work on this
code to address issues in the very near future. I don't want to make
unnecessary merge problems going to the trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Merged revisions 43708 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43708 | russell | 2006-09-26 16:49:21 -0400 (Tue, 26 Sep 2006) | 7 lines
Back in revision 4798, this message was changed from using ast_cli() to directly
calling write(). During this change, checking if this was a remote console was
removed. This caused this message about using "exit" or "quit" to exit an
Asterisk console to come up in times where it did not make sense. This change
restores the check to see if this is a remote console before printing the
message. (fixes BE-4)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43699 | russell | 2006-09-26 16:23:15 -0400 (Tue, 26 Sep 2006) | 6 lines
When parsing the sections of voicemail.conf that contain mailbox definitions,
don't introduce a length limit on the definition by using a 256 byte temporary
storage buffer. Instead, make the temporary buffer just as big as it needs
to be to hold the entire mailbox definition.
(fixes BE-68)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is technically a "new feature", but there are justifications for it.
I found a bug with the recent rtp packetization changes, which caused the media setup to
fail under certain circumstances, particularly when using allow=all, or having no allow=
statements (globally or on the device).
I could have either removed the rtp packetization features, or I could add proper codec
support (which, without, I think most people would consider to be a bug anyways).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43650 65c4cc65-6c06-0410-ace0-fbb531ad65f3
