- with AST_DEVMODE, building codecs/lpc10 fails because of lots
of warnings, and the configure step in editline fails as well.
Fix this by removing the -Werror in these steps.
- on FreeBSD (but probably on other platforms as well), the final
link of asterisk fails because AST_LIBS was not exported to the
subdirs Makefiles. Add a proper fix in the top-level Makefile
(a possible alternative way is to add "export AST_LIBS" near
the beginning of the file).
With this fix, i believe that some of the platform-specific
conditionals in main/Makefile are redundant (because they should
be already dealt with in the top level Makefile) but i don't
have a platform to check.
Merging to head will happen in a moment.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@44080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Issue #7928 - Don't send both 404 and 503. Fix by phsultan with
a small fix by me, myself or I. Thanks, Philippe!
(This was caused by my changes to the transaction handling)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@44078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1.0, Linksys PAP2 firmware 3.1.9(LSc)) which sends ACK not on OK
message only (when remote party answers) but on RINGING message
too, so when we send 200 OK message, we get unidentified ACK
message (because INVITE acknowledged on RINGING message already),
so 200 OK retransmits within its retransmission interval then
call gets dropped.
If someone else knows how to provide workaround for such cases,
please, fix it in correct way.
Thanks to ssh from #asteriskru for provide access to his box to
study and fix this case.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@44068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
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
