https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r65172 | murf | 2007-05-18 14:56:20 -0600 (Fri, 18 May 2007) | 1 line
This update will fix the situation that occurs as described by 9717, where when several targets are specified for a dial, if any one them reports FAIL, the whole call gets FAIL, even though others were ringing OK. I rearranged the priorities, so that a new disposition, NULL, is at the lowest level, and the disposition get init'd to NULL. Then, next up is FAIL, and next up is BUSY, then NOANSWER, then ANSWERED. All the related set routines will only do so if the disposition value to be set to is greater than what's already there. This gives the intended effect. So, if all the targets are busy, you'd get BUSY for the call disposition. If all get BUSY, but one, and that one rings is not answered, you get NOANSWER. If by some freak of nature, the NULL value doesn't get overridden, then the disp2str routine will report NOANSWER as before.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@65200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r65075 | oej | 2007-05-18 17:12:09 +0200 (Fri, 18 May 2007) | 5 lines
Issue 9235 - part of the problem, maybe not all. Please retry with this patch (and no
other patch) if you have problems with hanging SIP channels. Thank you.
A special Thank You to WeBRainstorm that gave me access to his system.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@65076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- In order to not duplicate code, I restructured some of the code for putting calls on/off hold.
Thanks DEA for reminding me. This fix has been asleep in the videocaps branch until now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@65041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
unregister its device state monitoring callback in unload_module(). So, this
would make Asterisk crash on the first device state change after you
unload the module.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@64868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
------
Merged revisions 64514 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r64514 | oej | 2007-05-16 10:25:56 +0200 (Wed, 16 May 2007) | 6 lines
Issue #9726 - rlister - Better logging for ACL denials
While at it, also added better logging and handling of peers that are not supposed to register.
My patch, stole the issue report from Russell. My apologies, Russell :-)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@64516 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r64513 | crichter | 2007-05-16 10:23:42 +0200 (Mi, 16 Mai 2007) | 1 line
in the case immediate=yes, we directly jump into the dialplan, where people can use PlayTones to indicate a Dialtone, so we don't need to to that by ourself. also we should not do a dialtone_indicate for incoming calls on a TE port in overlapdialmode.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@64515 65c4cc65-6c06-0410-ace0-fbb531ad65f3
calls to hosts or qualify (OPTION) messages will fail quicker if the TCP/IP stack tells us
that there is an issue.
Since this is an unconnected UDP socket, we will not get error messages directly
in most cases, but maybe on the second and third try.
This is already implemented in trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@64280 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I realize that there are other ways to get this,
but we really don't need to just show it in plain text so easily.
Issue 9273, patch by junky
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
either because the Challenge action was never issued, or some other reason,
give a proper error message and return an error instead of claiming that the
user wasn't found.
(reported by jsmith on IRC)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
code in that if a channel does not have a send_digit_begin() callback, it only
cares about DTMF END events. (pointed out by Michael Neuhauser on the
asterisk-dev list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
send_digit_begin() callback. Checking the END_DTMF_ONLY flag was the
wrong thing to do, because that flag indicates that a *bridged* channel
only wants DTMF END events coming from this channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
