This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
People expressed an interest in having access to the exact length of calls to a finer degree than seconds. See the CHANGES and UPGRADE.txt for usage also updated the sample configs to note the change.
Patch by snuffy.
(closes issue #16559)
Reported by: cianmaher
Tested by: cianmaher, snuffy
Review: https://reviewboard.asterisk.org/r/461/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269153 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
added response to roundtrip delay requests from opposite side
added roundtrip delay request sending to opposite side after answer,
added options for sending request (interval between request and
count of unreplied requests before forced call hangup)
(closes issue #16976)
Reported by: vmikhelson
Patches:
rtdr-1.6.0-2.patch uploaded by may213 (license 454)
Tested by: vmikhelson, may213
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252089 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
Fixes a crash on Solaris.
(closes issue #16572)
Reported by: crjw
Patches:
frame_changes.patch uploaded by crjw (license 963)
Plus several others found and fixed by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@239074 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
There is a bug when using ast_seekstream/ast_tellstream with format_mp3 in that
the file read position is not reset before attempting to read samples. So when
we seek to determine the maximum size of the file (as in res_agi's STREAM FILE)
we weren't then resetting the file pointer so that we could properly read
samples. This patch addresses that (in a similar manner to format_wav.c).
(closes issue #15224)
Reported by: rbd
Patches:
20091230_addons_1.4_issue15224.diff uploaded by seanbright (license 71)
Tested by: rbd, seanbright
Review: https://reviewboard.asterisk.org/r/453
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@238014 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the process of swapping ULAW to a place in the extended codec space, we
found several unhandled cases, where a 32-bit integer was still being used to
handle a codec field. Most of these have been fixed with this commit, although
there is at least one case (codec_dahdi) which depends upon outside headers to
be altered before a conversion can be made.
(Fixes AST-278, SWP-459)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* chan_console accessed pvts after deallocation.
* cdr_mysql stored a pointer that was freed by realloc()
* The module loader did not check usecount on shutdown, which led to chan_iax2
reading a timer that was already unloaded.
* The event subsystem sometimes creates an event with no IEs. Due to a corner
condition, the code would read beyond the memory boundary.
* res_pktccops did not correctly check whether its monitor thread was started.
(closes issue #16062)
Reported by: alexanderheinz
Patches:
20091109__issue16062.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
All addons modules should be disabled by default, requiring the
user to turn them on if desired. After all, these are addons we're
talking about here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228659 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some reason, the code compiles just fine with later versions
of GCC, but this one requires some weird double casting in order
to get rid of all warnings. Whatever.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228658 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
This problem was introduced when the AST_FRIENDLY_OFFSET patch was merged.
I'm surprised that nobody noticed any trouble when testing that patch, but this
fixes the code that fills in the buffer to start filling in after the offset
portion of the buffer.
(closes issue #15850)
Reported by: 99gixxer
Patches:
issue15850.diff1.txt uploaded by russell (license 2)
Tested by: 99gixxer
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
read(). However, it lied. This means that other parts of the code that
attempted to make use of the offset buffer would end up corrupting the fields
in the ast_filestream structure. This resulted in quite a few crashes due to
unexpected values for fields in ast_filestream.
This patch closes out quite a few bugs. However, some of these bugs have been
open for a while and have been an area where more than one bug has been
discussed. So with that said, anyone that is following one of the issues
closed here, if you still have a problem, please open a new bug report for the
specific problem you are still having. If you do, please ensure that the bug
report is based on the newest version of Asterisk, and that this patch is
applied if format_mp3 is in use. Thanks!
(closes issue #15109)
Reported by: jvandal
Tested by: aragon, russell, zerohalo, marhbere, rgj
(closes issue #14958)
Reported by: aragon
(closes issue #15123)
Reported by: axisinternet
(closes issue #15041)
Reported by: maxnuv
(closes issue #15396)
Reported by: aragon
(closes issue #15195)
Reported by: amorsen
Tested by: amorsen
(closes issue #15781)
Reported by: jensvb
(closes issue #15735)
Reported by: thom4fun
(closes issue #15460)
Reported by: marhbere
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
