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: http://svn.digium.com/svn/asterisk/trunk@254931 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@252277 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@252089 f38db490-d61c-443f-a65b-d21fe96a405b
incorrect q.931 message order filtered on incoming calls (first msg must be setup,
next must be not setup)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@242645 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@239074 f38db490-d61c-443f-a65b-d21fe96a405b
when we decode received q931 packet we must do callbacks and
when we print sended q931 packet we must not.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@239037 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@238014 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@231850 f38db490-d61c-443f-a65b-d21fe96a405b
* 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: http://svn.digium.com/svn/asterisk/trunk@228798 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@228659 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@228658 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@227898 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@217113 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@215212 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207647 | kpfleming | 2009-07-21 08:04:44 -0500 (Tue, 21 Jul 2009) | 12 lines
Ensure that user-provided CFLAGS and LDFLAGS are honored.
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@207680 f38db490-d61c-443f-a65b-d21fe96a405b
Ensure that add-on modules can be embedded, fix up Makefile.moddir_rules
to allow module directory Makefiles to more easily specify the modules to
be built, and explicitly list the addons modules in its Makefile, since
the module names don't follow any pattern.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204415 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@204413 f38db490-d61c-443f-a65b-d21fe96a405b
tzafrir