Implementation listing endpoints by technology returned an empty array if no
matching endpoints were found. Fixed so a "404 Not Found" will be returned
instead.
(closes issue ASTERISK-22803)
Reported by: David M. Lee
........
Merged revisions 402787 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Two variables were being checked for NULLity immediately
after being declared NULL. I moved the NULL check until
after the variables are allocated.
This allows for the "channelvars" option in manager.conf
to work as intended again.
........
Merged revisions 402767 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Both res_pjsip_messaging and res_pjsip_header_funcs were causing asterisk to
crash because they were trying to dereference a NULL pointer.
In the case of res_pjsip_messaging it was attempting to "print" a contact
header that did not exist. In fact contact headers should not be part of
a SIP MESSAGE, so the offending code was simply removed.
In the case of res_pjsip_header_funcs a null private channel tech was being
passed to the function and then later dereferenced. Added null checks (and
error logging) to the read/write function handlers to guard against crashing.
(closes issue ASTERISK-22821)
Reported by: Anthony Messina
........
Merged revisions 402757 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk will sometimes core dump during caller id read on analog
channels due to a negative return value from the read() in
my_get_callerid that slips through as a negative length argument to
callerid_feed() if the errno returned by DAHDI is ELAST. This change
ensures that the negative return is treated properly even when it is
ELAST.
(closes issue ASTERISK-22746)
Reported by: Michael Walton
Patches:
chan_dahdi_cid_crash_fix.r401410.patch uploaded by Michael Walton (License 6502)
........
Merged revisions 402708 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402709 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402710 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402711 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For outbound register requests the tag on the From line was
updated every 20 seconds prior to a successful registration
and also once for each registration renewal. That behavior
can possibly cause the registration to be denied because of
the different tag, and is not aligned with the intention of
RFC 3261 8.1.3.5 "... request constitutes a new transaction
and SHOULD have the same value of the Call-ID, To, and From
of the previous request...". This updates chan_sip to have
a field to keep the local tag in the registration structure
and use that tag for registration requests where the callid
is also unchanged.
(closes issue ASTERISK-12117)
Reported by: Pawel Pierscionek
Review: https://reviewboard.asterisk.org/r/2988/
........
Merged revisions 402604 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402605 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402606 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402607 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix unlinking from the app_bridges_moh container in remove_bridge_moh()
without a lock under normal circumstances.
* Made check ast_bridge_set_after_callback() return value in
bridge_moh_create() to handle failure.
* Fixed SCOPED_AO2LOCK() locking over too much scope in
stasis_app_bridge_moh_channel() and stasis_app_bridge_moh_stop().
* Fixed unusual usage of ao2_unlink_flag() in control_unlink().
* Fixed orphaned bridge from off nominal path in
stasis_app_bridge_create().
* Fixed strange construct in stasis_app_unsubscribe(). From a bad merge?
* Made load_module() cleanup on failure.
Review: https://reviewboard.asterisk.org/r/2962/
........
Merged revisions 402593 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ARI POST calls only accept parameters via the URL's query string.
While this works, it's atypical for HTTP API's in general, and
specifically frowned upon with RESTful API's.
This patch adds parsing for application/x-www-form-urlencoded request
bodies if they are sent in with the request. Any variables parsed this
way are prepended to the variable list supplied by the query string.
(closes issue ASTERISK-22743)
Review: https://reviewboard.asterisk.org/r/2986/
........
Merged revisions 402555 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several places in the code were using wait4 while other places were using
waitpid. This change makes all places use waitpid in order to make things
more consistent and since the 'rusage' object passed in/out of wait4 was
never used.
(closes issue ASTERISK-22557)
Reported by: YvesGael
Patches:
asterisk-11.5.1-wait4.patch uploaded by hurdman (license 6537)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, regardless of whether failure to authenticate was due to
lacking any authentication or actually failing authentication, the
Digest Authenticator would simply return that a challenge was still
needed. It will continue to do that when no authentication information
is in the received SIP digest, but when authentication information
is present and does not pass authentication, that will be treated as
an authentication error. This is to ensure that PJSIP will issue
security events indicated failed auths.
........
Merged revisions 402537 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While working on building client libraries from the Swagger API, I
noticed a problem with the nicknames.
channel.deleteChannel()
channel.answerChannel()
channel.muteChannel()
Etc. We put the object name in the nickname (since we were generating C
code), but it makes OO generators redundant.
This patch makes the nicknames more OO friendly. This resulted in a lot
of name changing within the res_ari_*.so modules, but not much else.
There were a couple of other fixed I made in the process.
* When reversible operations (POST /hold, POST /unhold) were made more
RESTful (POST /hold, DELETE /unhold), the path for the second operation
was left in the API declaration. This worked, but really the two
operations should have been on the same API.
* The POST /unmute operation had still not been REST-ified.
Review: https://reviewboard.asterisk.org/r/2940/
........
Merged revisions 402528 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the first agent/member (via CLI "queue show") in a queue is "busy" (dnd,
circuit busy, etc...) and no agents answered then app_queue would crash.
This occurred because while the calling of agent(s) remained valid the channel
on "busy" agent would be set to NULL and then later dereferenced upon a second
"rna" function call. The original intention of the code is to have only valid
"call attempt" objects (channels != NULL) checked while attempting to call
agent(s). It does this by building a "call_next" list of valid "call attempt"
objects. In the case of the "busy" agent subsequent builds of the valid "call
attempt" list would sometimes include (the case mentioned above) an invalid
"call attempt" object.
The fix was to make sure the "call attempt" list was appropriately built on
every iteration. A NULL sanity check was also added at the original offending
spot of the crash just in case another one slipped by somehow.
(closes issue ASTERISK-22644)
Reported by: Marco Signorini
Review: https://reviewboard.asterisk.org/r/2983/
........
Merged revisions 402517 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402518 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This started off as a fix for the failing IAX2 acl_call test in the Asterisk
Test Suite. When inspecting why that test was failing, it became clear that all
attempts to bind to any local loopback address was failing:
[Nov 2 15:56:28] VERBOSE[15787] chan_iax2.c: == Binding IAX2 to address
127.0.0.1:4569
[Nov 2 15:56:28] DEBUG[15787] netsock2.c: Splitting '127.0.0.1' into...
[Nov 2 15:56:28] DEBUG[15787] netsock2.c: ...host '127.0.0.1' and port ''.
[Nov 2 15:56:28] ERROR[15787] netsock2.c: getaddrinfo("127.0.0.1", "(null)",
...): ai_family not supported
[Nov 2 15:56:28] WARNING[15787] acl.c: Unable to lookup '127.0.0.1'
While there's conceivably other ways for getaddrino to return EAI_FAMILY, the
most common way is if AF_INET, AF_INET6, or AF_UNSPEC is not provided as the
desired family. The culprit was the call to ast_get_ip, defined in acl.h. This
function uses the family from the passed in addr object (which it will also
populate when it returns!) when it eventually calls getaddrinfo.
This patch fixes the use of ast_get_ip that were not specifying the family in
chan_iax2. This prevents uninitialized use of the structure, so that the
addresses resolve correctly.
Review: https://reviewboard.asterisk.org/r/2991
........
Merged revisions 402505 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch explicitly defines AST_AF_* enum constants to their sys/socket.h
defined equivalents. It is certainly unclear why these constants actually have
to exist, given that netsock2.h includes sys/socket.h; however, since the code
base is already liberally sprinkled with the usage of AST_AF_* (as well as with
direct calls to AF_*), this will at least keep the semantics consistent between
their usage across systems.
........
Merged revisions 402503 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When publishing channel snapshots, we currently compute the caller ID name and
number by giving preference first to ani.{name|number}, then to
id.{name|number}. However, when a channel driver (such as chan_sip) updates the
caller ID, it typically only updates the caller ID stored in id.{name|number}.
This means that we are currently giving preference to stale information.
When looking at the rest of the code base, the only other place where we appear
to use this same logic is in app_amd. Everywhere else, we treat the party
information in ani as being separate to the party information in id.
This patch publishes only the caller ID name and number in the snapshot field
for caller_name and caller_num. Note that the information in ANI is still
available in caller_ani.
Review: https://reviewboard.asterisk.org/r/2992/
........
Merged revisions 402501 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Made the vector macro API be more like linked lists.
1) Added a name parameter to ast_vector() to name the vector struct.
2) Made the API take a pointer to the vector struct instead of the struct
itself.
3) Added an element cleanup macro/function parameter when removing an
element from the vector for ast_vector_remove_cmp_unordered() and
ast_vector_remove_elem_unordered().
4) Added ast_vector_get_addr() in case the vector element is not a simple
pointer.
* Converted an inline vector usage in stasis_message_router to use the
vector API. It needed the API improvements so it could be converted.
* Fixed topic reference leak in router_dtor() when the
stasis_message_router is destroyed.
* Fixed deadlock potential in stasis_forward_all() and
stasis_forward_cancel(). Locking two topics at the same time requires
deadlock avoidance.
* Made internal_stasis_subscribe() tolerant of a NULL topic.
* Made stasis_message_router_add(),
stasis_message_router_add_cache_update(), stasis_message_router_remove(),
and stasis_message_router_remove_cache_update() tolerant of a NULL
message_type.
* Promoted a LOG_DEBUG message to LOG_ERROR as intended in
dispatch_message().
Review: https://reviewboard.asterisk.org/r/2903/
........
Merged revisions 402429 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The system overrides the user muting requests when MOH is playing or a
waitmarked user is waiting for a marked user to join. System muting
overrides interfere with what the user may wish the muting to be when the
system override ends.
* User muting requests are now independent of the system muting overrides.
The effective muting is now the logical or of the user request and system
override.
* Added a Muted flag to the CLI "confbridge list <conference>" command.
* Added a Muted header to the AMI ConfbridgeList action ConfbridgeList
event.
(closes issue AST-1102)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2960/
........
Merged revisions 402425 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402427 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ConfBridge allows custom DTMF menus to be created in the confbridge.conf
file by assigning a DTMF key sequence to a sequence of actions as follows:
DTMF-sequence = action,action...
Unfortunately, the normal config file processing code interprets an
initial '#' character as starting a directive such as #include.
* Add the ability to escape the first non-blank character in a config line
so the '#' character can be used without triggering the directive
processing code.
(closes issue AFS-2)
(closes issue ASTERISK-22478)
Reported by: Nicolas Tanski
Patches:
jira_asterisk_22478_v11.patch (license #5621) patch uploaded by rmudgett (modified)
Review: https://reviewboard.asterisk.org/r/2969/
........
Merged revisions 402407 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402416 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Typedefed and added doxegen for the voicemail callback functions.
* Simplified the prototypes for ast_install_vm_functions() and
ast_install_vm_test_functions() to use the new function typedefs.
* Simplified the voicemail callback function pointer variable declarations
to use the new function typedefs.
........
Merged revisions 402398 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also adds the ability to clear all profile items and makes behavior more
consistent with documentation as when choosing whether to use CONFBRIDGE
datastore profiles or the application arguments to the confbridge application.
(closes issue ASTERISK-22760)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2971/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds the following AMI events, closely following their CLI counterparts:
BridgeDestroy
BridgeKick
BridgeTechnologyList
BridgeTechnologySuspend
BridgeTechnologyUnsuspend
BridgeDestroy kicks an entire bridge, where BridgeKick kicks just one
channel off the bridge. When kicking a channel, specifying the bridge
also (optional) insures it is not removed from the wrong bridge. The
BridgeTechnology events allow viewing and changing suspension status,
which affects only subsequent not active bridging.
(closes ASTERISK-22356)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2973/
........
Merged revisions 402387 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ring operation sends ringing to the specified channel it is invoked on.
The dtmf operation can be used to send DTMF digits to the specified channel
of a specific length with a wait time in between. Finally hangup reasons
allow you to specify why a channel is being hung up (busy, congestion).
Early media behavior has also been tweaked slightly. When playing media to a channel
it will no longer automatically answer. If it has not been answered a progress indication
is sent instead.
(closes issue ASTERISK-22701)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2916/
........
Merged revisions 402358 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a Stasis application is specified an implicit subscription is done on the originated
channel. This was previously done with the channel lock held which is dangerous as the
underlying code locks the container and iterates items. This change releases the lock
on the originated channel before subscribing occurs.
(closes issue ASTERISK-22768)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2979/
........
Merged revisions 402346 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds a command to the command queue to explicitly depart the channel
from the bridge when it is told it has left. If the channel has already been departed
or has entered a different bridge this command will become a no-op.
(closes issue ASTERISK-22703)
Reported by: John Bigelow
(closes issue ASTERISK-22634)
Reported by: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/2965/
........
Merged revisions 402336 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For awhile now, we've noticed continuous integration builds hanging on CentOS 6
64-bit build agents. After resolving a number of problems with symbols, strange
locks, and other shenanigans, the problem has persisted. In all cases, gdb
shows the Asterisk process stuck in loader.c on one of the infinite while loops
that calls dlclose repeatedly until success.
The documentation of dlclose states that it returns 0 on success; any other
value on error. It does not state that repeatedly calling it will eventually
clear those errors. Most likely, the repeated calls to dlclose was to force a
close by exhausting the references on the library; however, that will never
succeed if:
(a) There is some fundamental error at work in the loaded library that
precludes unloading it
(b) Some other loaded module is referencing a symbol in the currently loaded
module
This results in Asterisk sitting forever.
Since we have matching pairs of dlopen/dlclose, this patch opts to only call
dlclose once, and log out as an ERROR if dlclose fails to return success. If
nothing else, this might help to determine why on the CentOS 6 64-bit build agent
things are not closing successfully.
Review: https://reviewboard.asterisk.org/r/2970
........
Merged revisions 402287 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402288 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402289 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Based on feedback from ipengineer in #asterisk, when the media indexer
cannot access a sound file on the system (or otherwise fails) Asterisk
displays a "Cannot frob file" error but fails to tell you why. This is
especially problematic as the media_indexer failing will rpevent Asterisk
from starting, as it is in the core.
We now display the errno error messages so folks can figure out what they've
done wrong.
........
Merged revisions 402285 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Debug messages aren't free. Even when the debug level is sufficiently low such
that the messages are never evaluated, there is a cost to having to parse
Asterisk logs that contain debug messages that (a) fail to convey sufficient
information or (b) occur so frequently as to be next to meaningless. Based on
having to stare at lots of DEBUG messages, this patch makes the following
changes:
* channel.c: When copying variables from a parent channel to a child channel,
specify the channels involved. Do not log anything for a variable that is not
inherited; the fact that it doesn't have an _ or __ already signifies that it
won't be inherited.
* pbx.c: Specify what function evaluation has occurred that created the result.
* translate.c: Bump up the translator path messages to 10. I've never once had
to use these debug messages, and for each format that is registered (on
startup) and unregistered (on shutdown) the entire f^2 matrix is logged out.
For short tests in the Asterisk Test Suite, this should make finding the
actual test much easier.
* xmldoc.c: The debug message that 'blah' is not found in the tree is expected.
Often, description elements - which are not required - are not provided.
This debug message adds no additional value, as it is not indicative of an
error or helpful in debugging which element did not contain a 'blah' element
as a child. If an element is supposed to contain a child element, then that
XML tree should have failed validation in the first place.
Review: https://reviewboard.asterisk.org/r/2966/
........
Merged revisions 402150 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402151 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402154 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402155 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bridge transitions away from one tech to another, the tech going
away is provided a dummy bridge with no channels in it to tear down.
Currently this means that the teardown code exits prematurely and does
not tear anything down. This change tears down RTP bridging for the
channel provided in the leave bridge tech callback.
This also reverts the majority of r400403 since it is now redundant.
(closes issue ASTERISK-22628)
(closes issue ASTERISK-22676)
Reported by: John Bigelow
Reported by: Kevin Harwell
Tested by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2905/
Patches:
native_rtp_fix.diff uploaded by Kinsey Moore (License 6273)
........
Merged revisions 402148 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402149 65c4cc65-6c06-0410-ace0-fbb531ad65f3
