Fix logic on read second part of H.225 packet. There was infinite loop on
wrong connections due to read before poll.
Change-Id: I42b4bf75c46e4a5c5df5c5ca1f0bd74b8944e7ff
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r333961 | may | 2011-08-31 01:21:53 +0400 (Wed, 31 Aug 2011) | 11 lines
Merged revisions 333947 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r333947 | may | 2011-08-31 01:16:30 +0400 (Wed, 31 Aug 2011) | 5 lines
cleanups in ACF/ARJ GK replies processing
fixed long (24 sec) pause if acf/arj proccessed
before ast_cond_wait called to wait this
........
................
r333962 | may | 2011-08-31 01:53:42 +0400 (Wed, 31 Aug 2011) | 3 lines
security fix. really drop call if signalling addr is not same as socket
addr
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@333963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r321528 | may | 2011-06-01 14:40:19 +0400 (Wed, 01 Jun 2011) | 14 lines
Fix double alerting, add forced alerting before answer
Fix double alerting (it wasn't fixed here by issue #18542)
Add forced alerting before connect (if it wasn't before)
Try to send all packets from outgoing queue rather than one only
Call goes into clearing state when disconnect command is received
(closes issue #19361)
Reported by: vmikhelson
Patches:
issue19361-3.patch uploaded by may213 (license 454)
Tested by: vmikhelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
IPv6 support for ooh323,
bindaddr, peers and users ip can be IPv4 or IPv6 addr
correction for multi-homed mode (0.0.0.0 or :: bindaddr)
can work in dual 6/4 mode with :: bindaddr
gatekeeper mode isn't supported in v6 mode while
(issue #18278)
Reported by: may213
Patches:
ipv6-ooh323.patch uploaded by may213 (license 454)
Review: https://reviewboard.asterisk.org/r/1004/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
small fixes.
Interpret remote side H.225 version.
Corrections for H.323v2 endpoints:
don't start TCS and MSD before connect,
don't start TCS and MSD by accepting H.245 connection,
start TCS and MSD by StartH245 facility message.
Other fixes:
fix non zeroended remoteDisplayName issue, small fixes in call clearing
by closing H.245 connection, tcp keepalive introduced on TCP
connections (now is hardcoded, will be configurable in the future),
don't force H.245tunneling if FastStart is active, don't send Alerting
singal more than once per call.
(closes issue #18542)
Reported by: vmikhelson
Patches:
issue18542-final-3.patch uploaded by may213 (license 454)
Tested by: vmikhelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change order of sending Terminal Capability Set and MasterSlave
Determination packets, MSD send when TCS exchange procedure is done
(we send tcs ack to remote and we have remote tcs ack already
or we receive tcs ack from remote and we have send our tcs ack to
remote already). Some endpoints can work in this sequence only,
i suggest they can't work with both (tcs and msd) exchange procedures
simultaneously.
Also changed StartH245 facility message sending. It send on
incoming calls only due to some endpoints can't proccess properly
this facility messages on their incoming calls.
(closes issue #18433)
Reported by: MrHanMan
Patches:
tcs-msd-h245-3.patch uploaded by may213 (license 454)
Tested by: MrHanMan, may213
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now that these files are in the tree, they should prefer the tree's local
copy of all Asterisk headers over any that may be installed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254931 65c4cc65-6c06-0410-ace0-fbb531ad65f3
incorrect q.931 message order filtered on incoming calls (first msg must be setup,
next must be not setup)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@242645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when we decode received q931 packet we must do callbacks and
when we print sended q931 packet we must not.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@239037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Many architectural and functional changes.
Main changes are threading model chanes (many thread in ooh323 stack
instead of one), modifications and improvements in signalling part,
additional codecs support (726, speex), t38 mode support.
This module tested and used in production environment.
(closes issue #15285)
Reported by: may213
Tested by: sles, c0w, OrNix
Review: https://reviewboard.asterisk.org/r/324/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227898 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?". After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
perfectly fine.
For more information about why a module goes in addons, see README-addons.txt.
chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
