........
r380671 | qwell | 2013-01-31 12:59:28 -0600 (Thu, 31 Jan 2013) | 4 lines
Remove a cross-compile workaround.
ar and ranlib can be easily detected with autoconf.
........
r380672 | qwell | 2013-01-31 13:00:38 -0600 (Thu, 31 Jan 2013) | 2 lines
Always check for libm, regardless of configure options.
........
r380673 | qwell | 2013-01-31 13:03:03 -0600 (Thu, 31 Jan 2013) | 7 lines
Add support for parallel builds of pjproject.
Also adds proper dependency checking, and direct .a file targets. We don't
take advantage of this currently, but we will soon.
(issue ASTERISK-20815)
........
Merged revisions 380671-380673 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380674 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ICalendar module had a systemic memory leak on each fetch of data from
the ICalendar source. The previous fetched data was not being properly
disposed. This patch makes it so that before each fetch of data, we dispose
of the previously fetched data.
(closes issue ASTERISK-21012)
Reported by: Joel Vandal
Tested by: Joel Vandal
........
Merged revisions 380451 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 380452 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sorcery is a unifying data access layer which provides a pluggable mechanism to allow
object creation, retrieval, updating, and deletion using different backends (or wizards).
This is a fancy way of saying "one interface to rule them all" where them is configuration,
realtime, and anything else that comes along.
Review: https://reviewboard.asterisk.org/r/2259/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes the problem, but the issue includes a test which is still
being considered for the automated test suite.
(issue ASTERISK-20919)
Reported by: NITESH BANSAL
Patches:
patch_ast_fax_spandsp.patch uploaded by NITESH BANSAL (license 6418)
........
Merged revisions 379949 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the capability for asynchronous manipulation of audio being
played back to a channel though a new AMI action "ControlPlayback". The
ControlPlayback action supports a number of operations, the availability of
which depend on the application being used to send audio to the channel.
When the audio playback was initiated using the ControlPlayback application
or CONTROL STREAM FILE AGI command, the audio can be paused, stopped,
restarted, reversed, or skipped forward. When initiated by other mechanisms
(such as the Playback application), the audio can be stopped, reversed, or
skipped forward.
Review: https://reviewboard.asterisk.org/r/2265/
(closes issue ASTERISK-20882)
Reported by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Again, since res_jabber/res_xmpp have duplicate APIs, their documentation ref
links have to specify which reference they're referring to. The various
documentation parsers can interpret the module attribute however they want
in order to construct the appropriate links.
........
Merged revisions 379228 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r379209 | mjordan | 2013-01-16 09:27:44 -0600 (Wed, 16 Jan 2013) | 8 lines
Add module tags to documentation for res_jabber/res_xmpp
Since res_jabber/res_xmpp provide the same APIs (app/func/manager/etc.),
the XML documentation for each needs to call out which module is providing
the documentation. The module attribute has been added to the various XML
fragments for this purpose.
........
r379210 | mjordan | 2013-01-16 09:30:20 -0600 (Wed, 16 Jan 2013) | 4 lines
Update the dtd to actually *support* the module attribute in all elements
Mea culpa.
........
Merged revisions 379209-379210 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r370252 for ASTERISK-18404, Asterisk's handling of RTP was modified to
better account for out of order RTP packets. This was accomplished by using the
RTP timestamp and sequence number to check for out of order packets. However,
when a SSRC change occurs, the timestamp and sequence number will no longer
have any relation to the previously received packets. The variables tracking
the timestamp and sequence number therefore have to be reset.
(closes issue ASTERISK-20906)
Reported by: Eelco Brolman
patches:
dtmf_on_hold.patch uploaded by Eelco Brolman (license #6442)
........
Merged revisions 378967 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378984 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously if an XMPP client reconnected any filters added by an external module were lost.
This issue exhibited itself with chan_motif not receiving and reacting to Jingle signaling.
(closes issue ASTERISK-20916)
Reported by: kuj
........
Merged revisions 378917 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This provides a JSON API by pulling in and wrapping the Jansson JSON
library[1]. The Asterisk API basically mirrors the Jansson
functionality, with a few minor tweaks.
* Some names have been asteriskified to protect the innocent.
* Jansson provides both reference-stealing and reference-borrowing
versions of several API's. The Asterisk API is exclusively
reference-stealing for operations that put elements into arrays and
objects.
* No support for doubles, since we usually don't need that.
* Coming along for the ride is the ast_test_validate macro, which made
the unit tests much easier to write.
[1]: http://www.digip.org/jansson/
(issue ASTERISK-20887)
(closes issue ASTERISK-20888)
Review: https://reviewboard.asterisk.org/r/2264/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Under some circumstances, libsrtp's srtp_create function deallocates memory that
it wasn't initially responsible for allocating. Because we weren't initially
aware of this behavior, this memory was still used in spite of being unallocated
during the course of the srtp_unprotect function. A while back I made a patch
which would set this value to NULL, but that exposed a possible condition where
we would then try to check a member of the struct which would cause a segfault.
In order to address these problems, ast_srtp_unprotect will now set an error value
when it ends without a valid SRTP session which will result in the caller of
srtp_unprotect observing this error and hanging up the relevant channel instead of
trying to keep using the invalid session address.
(closes issue ASTERISK-20499)
Reported by: Tootai
Review: https://reviewboard.asterisk.org/r/2228/diff/#index_header
........
Merged revisions 378591 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378592 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On a fresh checkout of Asterisk 11, running make before ./configure
could cause the pjproject subdirectory to get in an odd state that
would prevent compilation. This patch by Tilghman prevents that from
occurring.
(closes issue ASTERISK-20681)
Reported by: Dinesh Ramjuttun
Tested by: danilo borges, Steve Lang
patches:
20121208__ccar_solved.diff.txt uploaded by Tilghman Lesher (license 5003)
........
Merged revisions 378582 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to r378287, res_xmpp was marshaling data read from an external source
onto the stack. For a sufficiently large message, this could cause a stack
overflow. This patch modifies res_xmpp in a similar fashion to res_jabber by
removing the stack allocation, as it was unnecessary.
(issue ASTERISK-20658)
Reported by: wdoekes
........
Merged revisions 378409 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
........
Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk had several places where messages received over various network
transports may be copied in a single stack allocation. In the case of TCP,
since multiple packets in a stream may be concatenated together, this can
lead to large allocations that overflow the stack.
This patch modifies those portions of Asterisk using TCP to either
favor heap allocations or use an upper bound to ensure that the stack will not
overflow:
* For SIP, the allocation now has an upper limit
* For HTTP, the allocation is now a heap allocation instead of a stack
allocation
* For XMPP (in res_jabber), the allocation has been eliminated since it was
unnecesary.
Note that the HTTP portion of this issue was independently found by Brandon
Edwards of Exodus Intelligence.
(issue ASTERISK-20658)
Reported by: wdoekes, Brandon Edwards
Tested by: mmichelson, wdoekes
patches:
ASTERISK-20658_res_jabber.c.patch uploaded by mmichelson (license 5049)
issueA20658_http_postvars_use_malloc2.patch uploaded by wdoekes (license 5674)
issueA20658_limit_sip_packet_size3.patch uploaded by wdoekes (license 5674)
........
Merged revisions 378269 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378286 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378287 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I changed this code earlier to return NULL if it wasn't able to generate a UUID,
whereas the earlier code would always return the ast_str that was passed in.
Switch back to returning the ast_str, only set it to the empty string instead if
UUID generation fails. We still do a validity check later which will catch this
and blow up if necessary.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently the res_calendar_exchange module uses its own method of generating
UUIDs using ast_random(). Now that we have a UUID API we should use that
instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This provides a common API for dealing with unique identifiers.
The API provides methods to create, parse, copy, and stringify UUIDs.
An accompanying unit test is provided that tests all operations.
(closes issue ASTERISK-20726)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2217
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377846 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A recent memory leak fix in main/cli.c causes an ast_cli_entry's command
field to be freed and NULLed if ast_cli_register() fails. res_clialiases
was ignoring the return value of ast_cli_register() and was then passing
the NULL command off to a a hash function. This resulted in a crash.
The fix is not to ignore the erroneous return value. If ast_cli_register()
fails, then we do not continue trying to process the current alias.
........
Merged revisions 377840 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 377842 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 377843 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With ICE support enabled in chan_sip and a large number of interfaces on the system it was
possible for the produced SDP to be truncated due to some fixed size buffers. These buffers
have now been changed so they will dynamically grow as needed.
ICE support is now also enabled by default in res_rtp_asterisk to provide a smoother experience
for chan_motif users where it is required. To maintain the previous behavior in chan_sip it is
no longer enabled by default there.
(closes issue ASTERISK-20643)
Reported by: coopvr
........
Merged revisions 376130 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r375993 | mmichelson | 2012-11-07 11:01:13 -0600 (Wed, 07 Nov 2012) | 30 lines
Fix misuses of timeouts throughout the code.
Prior to this change, a common method for determining if a timeout
was reached was to call a function such as ast_waitfor_n() and inspect
the out parameter that told how many milliseconds were left, then use
that as the input to ast_waitfor_n() on the next go-around.
The problem with this is that in some cases, submillisecond timeouts
can occur, resulting in the out parameter not decreasing any. When this
happens thousands of times, the result is that the timeout takes much
longer than intended to be reached. As an example, I had a situation where
a 3 second timeout took multiple days to finally end since most wakeups
from ast_waitfor_n() were under a millisecond.
This patch seeks to fix this pattern throughout the code. Now we log the
time when an operation began and find the difference in wall clock time
between now and when the event started. This means that sub-millisecond timeouts
now cannot play havoc when trying to determine if something has timed out.
Part of this fix also includes changing the function ast_waitfor() so that it
is possible for it to return less than zero when a negative timeout is given
to it. This makes it actually possible to detect errors in ast_waitfor() when
there is no timeout.
(closes issue ASTERISK-20414)
reported by David M. Lee
Review: https://reviewboard.asterisk.org/r/2135/
........
r375994 | mmichelson | 2012-11-07 11:08:44 -0600 (Wed, 07 Nov 2012) | 3 lines
Remove some debugging that accidentally made it in the last commit.
........
Merged revisions 375993-375994 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375995 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376014 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, if an acknowledgement of a timer fails Asterisk will not realize
that a serious error occurred and will continue attempting to use the timer's
file descriptor. This can lead to situations where errors stream to the
CLI/log file. This consumes significant resources, masks the actual problem
that occurred (whatever caused the timer to fail in the first place), and
can leave channels in odd states.
This patch propagates the errors in the timing resource modules up through
the timer core, and makes users of these timers handle acknowledgement
failures. It also adds some defensive coding around the use of timers
to prevent using bad file descriptors in off nominal code paths.
Note that the patch created by the issue reporter was modified slightly for
this commit and backported to 1.8, as it was originally written for
Asterisk 10.
Review: https://reviewboard.asterisk.org/r/2178/
(issue ASTERISK-20032)
Reported by: Jeremiah Gowdy
patches:
jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358)
........
Merged revisions 375893 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375894 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375895 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On some systems the optional API support uses the GCC compiler attribute "weakref" to provide its
functionality. This code changes the function names and prefixes "__" to the front. The
res_http_websocket exports file did not take this into account, thereby not allowing those functions
to be global and ultimately found.
(closes issue ASTERISK-20631)
Reported by: danjenkins
........
Merged revisions 375559 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unlike all other calendar modules, res_calendar_ews fails to extract the Body
information for a calendar item. This is due, in part, to a quirk in the
schema in the XML - not only does a CalendarItem contain a Body element, but
the CalendarItem exists as a descendant of a different Body element. The neon
parser was erroneously skipping all Body elements.
This patch fixes that by bypassing Body elements that are not a child of
CalendarItem, and parsing the Body element out if it is a child.
Note that the original patch by Terry Wilson only needed slight modifications
to make it properly pull the Body information out; as such, while I've linked
to the patch that I uploaded for Dmitry, I've attributed the patch to Terry.
(closes issue ASTERISK-19738)
Reported by: Dmitry Burilov
Tested by: Dmitry Burilov
patches:
calendar_ews_body_2012_10_29.diff uploaded by Terry Wilson (license 6283)
........
Merged revisions 375528 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375531 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375532 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Remove the "RTP Read too short" warning for RTP keepalives. Remove the
the warning about the application delimiter switch from pipe to comma.
(You should've done this by now.) Make cdr_odbc report more when an
insert fails. Make chan_sip warn less when the peer wants SRTP (and we
don't) or sends a zero port to disable a media type.
Review: https://reviewboard.asterisk.org/r/2167
(closes issue ASTERISK-20538)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update and extend the configuration_file group and enable linking to the resource. Update title that was left behind many years ago.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since there are a number of legacy devices out there that fail to handle ICE
candidates properly (which is a nice way of saying something much uglier),
disable it by default.
Support for ICE candidates can be enabled in rtp.conf using the icesupport
setting.
........
Merged revisions 374676 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pjproject, in order to solve build problems on Windows [1], undefines s_addr in
one of it's headers that is included in res_rtp_asterisk.c. On Solaris s_addr
is not a structure member, but defined to map to the real strucuture member,
therefore when building on Solaris it's possible to get build errors like:
[CC] res_rtp_asterisk.c -> res_rtp_asterisk.o
In file included from /export/home/admin/asterisk-11-svn/include/asterisk/stun.h:29,
from res_rtp_asterisk.c:51:
/export/home/admin/asterisk-11-svn/include/asterisk/network.h: In function `inaddrcmp':
/export/home/admin/asterisk-11-svn/include/asterisk/network.h:92: error: structure has no member named `s_addr'
/export/home/admin/asterisk-11-svn/include/asterisk/network.h:92: error: structure has no member named `s_addr'
res_rtp_asterisk.c: In function `ast_rtp_on_ice_tx_pkt':
res_rtp_asterisk.c:706: warning: dereferencing type-punned pointer will break strict-aliasing rules
res_rtp_asterisk.c:710: warning: dereferencing type-punned pointer will break strict-aliasing rules
res_rtp_asterisk.c: In function `rtp_add_candidates_to_ice':
res_rtp_asterisk.c:1085: error: structure has no member named `s_addr'
make[2]: *** [res_rtp_asterisk.o] Error 1
make[1]: *** [res] Error 2
make[1]: Leaving directory `/export/home/admin/asterisk-11-svn'
gmake: *** [_cleantest_all] Error 2
Unfortunately, in order to make this work, I also had to make sure pjproject
only used the typdef pj_in_addr and not the struct pj_in_addr so that when
building Asterisk I could "typedef struct in_addr pj_in_addr". It's possible
then that the library and users of those interfaces in Asterisk have a different
idea about the type of the argument, while on the surface it looks like they are
all 32 bit big endian values.
[1] http://trac.pjsip.org/repos/changeset/484
(issues ASTERISK-20366)
Reported by: Ben Klang
Tested by: Ben Klang, mjordan
patches:
0001-pjproject-Fix-for-Solaris-builds.-Do-not-undef-s.patch uploaded by Shaun Ruffell (license 5417)
........
Merged revisions 374642 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While XEP-0115 states that the node and ver attributes are both required, some
devices fail to provide either field. Prior to this patch, failure to provide
the node or ver attribute would cause a crash in res_xmpp. While failing to
provide the node or ver attribute is technically invalid, since this
information is not utilized by Asterisk except for reporting purposes, for
interoperability reasons, we continue to process the capability stanza anyways.
(closes issue ASTERISK-20495)
Reported by: Martin W
Tested by: Martin W
patches:
20495.patch uploaded by Martin W (license #6434)
........
Merged revisions 374622 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the channel technology agnostic application/AMI command MessageSend,
the "From" field is technically optional for the SIP channel driver. However,
if being sent by the XMPP resource module (either res_xmpp or res_jabber), the
"From" field is necessary, and must correspond to a defined account. This
patch updates the documentation for this application/AMI command to reflect
this.
(closes issue ASTERISK-20405)
Reported by: Leif Madsen
........
Merged revisions 374611 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI DBDelTree command will return Success/Key tree deleted successfully even
if the given key does not exist. The CLI command 'database deltree' had a
similar problem, but was saved because it actually responded with '0 database
entries removed'. AGI had a slightly different error, where it would return
success if the database was unavailable.
This came from confusion about the ast_db_deltree retval, which is -1 in the
event of a database error, or number of entries deleted (including 0 for
deleting nothing).
* Changed some poorly named res variables to num_deleted
* Specified specific errors when calling ast_db_deltree (database unavailable
vs. entry not found vs. success)
* Fixed similar bug in AGI database deltree, where 'Database unavailable'
results in successful result
(closes issue AST-967)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2138/
........
Merged revisions 374426 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374427 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374428 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_jabber resource module uses the ASTOBJ library for managing its ref
counted objects. After calling ASTOBJ_CONTAINER_FIND to locate a buddy object,
the pointer to the object has to be checked to see if the buddy existed.
Prior to this patch, the buddy object was not checked for NULL; with this patch
in both aji_client_info_handler and aji_dinfo_handler the pointer is checked
before used and, if no buddy object was found, the handlers return an error
code.
This patch does not take the approach that our JID can be used to log in from
another resource. If that approach is desired, an improvement could be made to
this patch to create the buddy on the fly. This patch seeks only to prevent
Asterisk from crashing.
FYI: In Asterisk 11+, you really should be using res_xmpp. It does not have
this problem, as it moved to the astobj2 library.
Note that multiple people have proposed patches for this issue; the patch being
committed here is based on those.
(closes issue ASTERISK-19532)
Reported by: Karsten Wemheuer
Tested by: Byron Clark
patches:
fix-jabber uploaded by Karsten Wemheuer (license #5930)
xmpp_no_crash_with_ejabberd.patch uploaded by Byron Clark (license #6157)
(closes issue ASTERISK-19557)
Reported by: ulugutz
........
Merged revisions 374335 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374336 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374337 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added AMI event documentation for AsyncAGI and AGIExec events.
(closes issue ASTERISK-20318)
Reported by: Dan Cropp
Patches:
res_agi_patch.txt (license #6422) patch uploaded by Dan Cropp
modified for trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374075 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch changes get_agi_cmd so that the return can be checked
to differentiate between an empty list success and something that
triggered an error. This in turn allows launch_asyncagi to detect
these errors and break free from the command processing loop so
that the async agi can be ended more cleanly
(closes issue ASTERISK-20109)
Reported by: Jeremiah Gowdy
Patches: jgowdy-7-9-2012.diff uploaded by Jeremiah Gowdy (license 6358)
(Modified by me to fix some logical issues and apply to trunk)
Review: https://reviewboard.asterisk.org/r/2117/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When sending RTP packets via multicast the amount of data sent is stored in a variable and returned
from the write function. This is incorrect as any non-zero value returned is considered a failure while
a return value of 0 is success. For callers (such as ast_streamfile) that checked the return value
they would have considered it a failure when in reality nothing went wrong and it was actually a success.
The write function for the multicast RTP engine now returns -1 on failure and 0 on success, as it should.
(closes issue ASTERISK-17254)
Reported by: wybecom
........
Merged revisions 373550 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373551 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373552 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The H.264 format attribute module compares two format attribute structures to determine if they are
compatible or not. In some instances it was possible for this check to determine that both structures
were incompatible when they actually should be considered compatible. This check has now been made even
more permissive by assuming that if no attribute information is available the two structures are compatible.
If both structures contain attribute information a base level comparison of the H.264 IDC value is done to
see if they are compatible or not.
The above issue uncovered a secondary issue in chan_sip where the SDP being produced would be incorrect if
the formats were considered incompatible. This has now been fixed by checking that all information required
to produce the SDP is available instead of assuming it is.
(closes issue ASTERISK-20464)
Reported by: Leif Madsen
........
Merged revisions 373413 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes the turnport configuration property and changes the
turnaddr property to be a combined host[:port] configuration string. The
patch also modifies the documentation in the example configuration to
reflect the property changes and adds some additional text indicating how
the STUN port is configured.
(closes issue ASTERISK-20344)
Reported by: beagles
Tested by: beagles
Review: https://reviewboard.asterisk.org/r/2111/
........
Merged revisions 373403 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Whitespace, doc-blocks, spelling, case, missing and incorrect tags.
* Add cleanup to Makefile for the Doxygen configuration update
* Start updating Doxygen configuration for cleaner output
* Enable inclusion of configuration files into documentation
* remove mantisworkflow...
* update documentation README
* Add markup to Tilghman's email and talk with him about updating his email, he knows...
* no code changes on this commit other than the mentioned Makefile change
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Doxygen updates including mistakes, misspellings, missing parameters, updates for Doxygen style. Some missing txt file links are removed but their content or essense will be included in some later updates. A majority of the txt files were removed in the 1.6 era but never noted. The HR and EXTREF are simple changes that make the documentation more compatable with more versions of Doxygen.
Further updates coming.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As mentioned on the review for this, WebRTC has moved towards choosing
DTLS-SRTP as the mechanism for key exchange for SRTP. This commit adds
support for this but makes it available for normal SIP clients as well.
Testing has been done to ensure that this introduces no regressions with
existing behavior and also that it functions as expected.
Review: https://reviewboard.asterisk.org/r/2113/
........
Merged revisions 373229 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Before this, attempting to unload res_curl.so would warn you about the first
module it found that was dependent. We now warn about all of the loaded modules
instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Removes "res_rtp_asterisk.c:706: warning: dereferencing type-punned pointer
will break strict-aliasing rules" warning from the build on 32-bit platforms.
The problem is that 'size' was referenced aliased to both (pj_size_t *) and
(pj_ssize_t *). Now just make a copy of size that is the right type so there
isn't any pointer aliasing happening.
It also adds comments and asserts regarding what looks like an inappropriate
use of pj_sock_sendto, but is actually totally fine.
(closes issue ASTERISK-20368)
Reported by: Shaun Ruffell
Tested by: Michael L. Young
Patches:
0001-res_rtp_asterisk-Eliminate-type-punned-pointer-build.patch uploaded by Shaun Ruffell (license 5417)
slightly modified by David M. Lee.
........
Merged revisions 372777 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes a build regression introduced in r369517 "Add support for ICE/STUN/TURN
in res_rtp_asterisk and chan_sip." [1].
[1] http://svnview.digium.com/svn/asterisk?view=revision&revision=369517
When compiling asterisk in parallel like:
$ make -j 10
It's possible to get errors like the following:
.pjlib-util-test-x86_64-unknown-linux-gnu.depend:120: *** missing separator. Stop.
make[4]: *** [depend] Error 2
make[3]: *** [dep] Error 1
make[2]: *** [/home/sruffell/asterisk-working/res/pjproject/pjnath/lib/libpjnath-x86_64-unknown-linux-gnu.a] Error 2
make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
This is because the build system is trying to build each of the libraries in
pjproject in parallel. Now the build will build pjproject in a single job and
link the results into res_asterisk_rtp.
Parallel builds, on one test system, saves ~1.5 minutes from a default Asterisk
build:
Single job:
$ git clean -fdx >/dev/null && time ( ./configure >/dev/null 2>&1 && make >/dev/null 2>&1 )
real 2m34.529s
user 1m41.810s
sys 0m15.970s
Parallel make:
$ git clean -fdx >/dev/null && time ( ./configure >/dev/null 2>&1 && make -j10 >/dev/null 2>&1 )
real 1m2.353s
user 2m39.120s
sys 0m18.850s
(closes issue ASTERISK-20362)
Reported by: Shaun Ruffel
Patches:
0001-res_asterisk_rtp-Fix-build-error-when-using-parallel.patch uploaded by Shaun Ruffel (License #5417)
........
Merged revisions 372609 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372610 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous fix still would look in the static_RTP_PT table, which
is inappropriate since we specifically want to find a codec that has
been negotiated.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
Patches:
codec_negotiation.patch Uploaded by NITESH BANSAL (License #6418)
........
Merged revisions 372311 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 1.4+, a fix was put in place to increment the sequence number for
retransmitted DTMF end packets. With the introduction of the RTP engine API in
1.8, the sequence number was no longer being incremented. This patch fixes this
regression as well as cleans up a few lines that were not doing anything.
(closes issue ASTERISK-20295)
Reported by: Nitesh Bansal
Tested by: Michael L. Young
Patches:
01_rtp_event_seq_num.patch uploaded by Nitesh Bansal (license 6418)
asterisk-20295-dtmf-fix-cleanup.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2083/
........
Merged revisions 372185 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372198 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372199 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A change for Asterisk 11 caused a check for failure to incorrectly check the return
value. This resulted in the possibility of transmitting media that a party had not
negotiated. If this media happened to be G.729, then this could potentially result
in one-way audio if no G.729 translators are installed.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
........
Merged revisions 372118 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pj_thread_register() takes a parameter of type pj_thread_desc.
It was assumed that pj_thread_register either used this item
temporarily or made a copy of it. Unfortunately, all it does is
keep a pointer to the structure in thread-local storage. This
means that if our pj_thread_desc goes out of scope, then pjlib
will be referencing bogus data quite often, most commonly on
operations involving a pj_mutex_t.
In our case, our pj_thread_desc was on the stack and went out
of scope very shortly after registering our thread with pjlib.
With this change, the pj_thread_desc is stored in thread-local
storage so the pointer that pjlib keeps in thread-local storage
will reference legitimate memory.
(closes issue ASTERISK-20237)
reported by Jeremy Pepper
Patches:
ASTERISK-20237.patch uploaded by Mark Michelson (license #5049)
Tested by Jeremy Pepper
........
Merged revisions 371571 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371572 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some core support modules and compiler options were no longer tagged with a
module support level. This patch adds 'core' back to those options.
Note that this patch modifies a few of the patches provided by Andrew Latham
slightly. res_curl and res_fax are both 'core' supported modules.
(closes issue ASTERISK-20215)
Reported by: Andrew Latham
Tested by: mjordan
Patches:
astcanary.diff (license #5985) uploaded by Andrew Latham
cflagsxml.diff (license #5985) uploaded by Andrew Latham
curl_fax.diff (license #5985) uploaded by Andrew Latham
soundsxml.diff (license #5985) uploaded by Andrew Latham
........
Merged revisions 371507 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While building up a new install to test chan_motif, I ran into a failure
due to icesupport being disabled. This was due to me not having an
rtp.conf. It was intended in the code for it to be enabled by default,
but it was only applied if rtp.conf existed.
This patch updates res_rtp_asterisk to be consistent in how it handles
defaults. A few options didn't have their default values set globally,
including icesupport. They are now set and icesupport is enabled by
default, even if you do not have an rtp.conf.
........
Merged revisions 371425 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is based on the work done by Olle Johansson on review board.
The idea is that the channel specified in an AMI originate or call
file is typically not connected to the outgoing extension until the
channel has been answered. With this change, an EarlyMedia header can
be specified for AMI originates and an early_media option can
be specified in call files. With this option set, once early media is
received on a channel, it will be connected with the outgoing extension.
(closes issue ASTERISK-18644)
Reported by Olle Johansson
Review: https://reviewboard.asterisk.org/r/1472
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new CLI command to the res_corosync module. It is primarily
used as a debugging tool. It lets you fire off an event which will cause
res_corosync on other nodes in the cluster to place messages into the logger if
everything is working ok. It verifies that the corosync communication is
working as expected.
I didn't put anything in the CHANGES file for this, because this module is new
in Asterisk 11. There is already a generic "res_corosync new module" entry in
there so I figure that covers it just fine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The while loop responsible for reading AGI messages from a fastAGI service
can end up looping indefinitely when an AGI script fails to indicate the end
of a message with a \n character. This patch adds an indication that we are
expecting a \n character to end the message to make it more clear to users
that this is necessary if they are receiving this warning over and over.
(issue ASTERISK-20061)
Reported by: Eike Kuiper
........
Merged revisions 370494 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370495 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A number of applications/AMI commands in Asterisk have specific behavioral
differences depending on the resource or channel technology those
applications are executed on. For example, the MessageSend application/
command is technology agnostic, but how the channel drivers that support
that functionality behave is dependant on the protocols and channel
driver implementation. Prior to this patch, those details were either
documented in the application/command documentation itself, or were left
undocumented.
This patch adds a new element to the documentation schema, <info/>. An info
node is essentially a piece of technology specific reference information that
can be included by any top level XML documentation node. For example, the
MessageSend application can now include XMPP/SIP specific information, where
that technology specific information can be defined in chan_motif/res_xmpp/
chan_sip. Likewise, that information can also be included in the MessageSend
AMI command.
Review: https://reviewboard.asterisk.org/r/2049
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The current implementation of RFC 2833 DTMF handling in res_rtp_asterisk will,
if a packet arrives out of order, drop the packet. This is to prevent
duplicate ton generation in the Asterisk core. Since the RTP layer does not
buffer data itself, this is the only option the RTP layer currently has for
handling packets that arrive out of order.
For the most part, this doesn't matter. For a particular digit, so long as a
BEGIN packet arrives before the first END packet, the digit will be produced.
If subsequent BEGIN packets arrive interleaved with the ENDs, they will be
dropped; likewise, if the BEGIN or END packets themselves are out of order,
those packets are dropped but sufficient information is conveyed to the
Asterisk core to produce the appropriate digit.
For certain sequences of DTMF packets - most notably when, for a particular
digit, an END packet arrives before any BEGIN packet for that digit - this
is a real problem. When an END arrives before any BEGINs, the END packet is
dropped - but at the same time, it causes subsequent BEGIN packets for that
digit to be ignored. When the next in order END packet arrives, it too is
dropped - Asterisk believes that there was no initial BEGIN.
The solution this patch provides is to trust the END packet to convey the
information needed for the Asterisk core to produce the DTMF digit. If we
receive an END packet, and it:
* Has a timestamp greater then the last timestamp received from an END
packet
* Does not have the same sequence number as the last received sequence
number (and is thus not an END packet retransmission)
Then we send the END frame up to the Asterisk core. It contains enough
DTMF information for Asterisk to produce the digit.
On the other hand, if we receive a BEGIN or continuation packet that occurs
with a timestamp equal to or less then the last END timestamp, then we've
received something out of order - but we already have received enough
information to produce the digit. These packets are dropped.
Much thanks goes to Olle Johansson (oej) for providing the idea for this
solution.
Review: https://reviewboard.asterisk.org/r/2033/
(closes issue ASTERISK-18404)
Reported by: Stephane Chazelas
Tested by: Matt Jordan
........
Merged revisions 370252 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370271 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The initial ICE connectivity check is scheduled as a timer item that is to be executed immediately. It is possible for this timer item to start executing while the ICE session it is working on is destroyed. To reduce the chance of this any timer items that need to be immediately executed will be executed within the thread that has started the initial ICE connectivity check.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370177 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pubsub code did not attempt to remove subscriptions at all. This has now changed so that if a client is being disconnected it will unsubscribe. It will also unsubscribe at connection time so if it unexpectedly disconnected duplicate subscriptions will not occur.
(closes issue ASTERISK-19882)
Reported by: mattvryan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The MWI and device state propagation code wrongly assumes that an XMPP client connection will remain established at all times. This fix corrects that by making the lifetime of the subscription the same as the lifetime of the connection itself. As the connection is established and disconnected the subscription itself is created and destroyed.
(closes issue ASTERISK-18078)
Reported by: elguero
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370152 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A server sending a service discovery request to us may or may not put a from attribute in the message. If the from attribute is present use it in the to attribute for the result. If the from attribute is not present do not add a to attribute.
(issue ASTERISK-16203)
Reported by: wubbla
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Jason Parker
Matthew Jordan
Joshua Colp
Jonathan Rose
David M. Lee
Kinsey Moore
Andrew Latham
Sean Bright
Mark Michelson
Olle Johansson
Walter Doekes
Richard Mudgett
Brent Eagles
Michael L. Young
Russell Bryant
Kevin P. Fleming