fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@110335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tyler
Do not force channel format changes when a generator is present. The generator may have changed the formats itself and changing them back would cause issues.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@76653 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: homesick
Patches:
rpid_1.4_75840.patch uploaded by homesick (license 91)
Accept Remote Party ID on guest calls.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@76560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: fkasumovic
Patches:
chan_sip.patch uploaded by fkasumovic (license #101)
Drop any peer realm authentication entries when reloading so multiple entries do not get added to the peer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@76080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
deciding whether or not we need to request retransmissions by sending a VNAK.
This code could cause VNAKs to be sent erroneously in some cases, and to not
be sent in other cases when it should have been.
(closes issue #10237, reported and patched by mihai)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@75927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
receiving a VNAK, handle sequence number wraparound so that all frames that
should be retransmitted actually do get retransmitted.
(issue #10227, reported and patched by mihai)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@75757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the size of the destination buffer is known in the iax_frame so that code
won't write past the end of the allocated buffer when sending outgoing frames.
(ASA-2007-014)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@75444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
What triggered this investigation was an IRC chat where some people's quiet flags were
set while others' weren't even though none of them had specified the q option.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@75066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
class is not done at the same time as any of the other operations on this list
to prevent list corruption. Using the global moh_data lock for this is not
ideal, but it is what is used to protect these lists everywhere else in the
module, and I am only changing what is necessary to fix the bug.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@75059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mmacvicar
Patches submitted by: bbryant, russell
Tested by: mmacvicar, marco, arcivanov, jmhunter, explidous
When using a TDM400P (and probably other analog cards) there was a chance that
you could hang up and pick the phone back up where it has been long enough to
be not considered a flash hook, but too soon such that the device reports that
it is busy and the person on the phone will only hear silence. This patch
makes chan_zap more tolerant of this and gives the device a couple of seconds
to succeed so the person on the phone happily gets their dialtone.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@75052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
number. Fix the uses of this function to handle this instead of treating it
as the new call number. This would cause a deadlock and memory corruption.
(possible cause of issue #9614 and others, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@74766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Between the time recalc_holdtime and update_queue was called, it was possible that the call could have been hungup.
Move both additions to the same place, so this won't happen.
Issue 10158, initial patch by makoto, modified by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@74427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
