core/loader: Don't call dlclose in a while loop

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: http://svn.asterisk.org/svn/asterisk/trunk@402290 f38db490-d61c-443f-a65b-d21fe96a405b
Update the conversion script from sip.conf to pjsip.conf

(closes issue ASTERISK-22374)
Reported by Matt Jordan

Review: https://reviewboard.asterisk.org/r/2846
........

Merged revisions 402327 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@402328 f38db490-d61c-443f-a65b-d21fe96a405b
res_stasis: Ensure the channel is always departed from the bridge when it leaves.

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: http://svn.asterisk.org/svn/asterisk/trunk@402337 f38db490-d61c-443f-a65b-d21fe96a405b
res_ari_channels: Fix a deadlock when originating multiple channels close to eachother.

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: http://svn.asterisk.org/svn/asterisk/trunk@402347 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Fix RTCP port for SRFLX ICE candidates

This corrects one-way audio between Asterisk and Chrome/jssip as a
result of Asterisk inserting the incorrect RTCP port into RTCP SRFLX
ICE candidates. This also exposes an ICE component enumeration to
extract further details from candidates.

(closes issue ASTERISK-21383)
Reported by: Shaun Clark
Review: https://reviewboard.asterisk.org/r/2967/
........

Merged revisions 402345 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 402348 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@402349 f38db490-d61c-443f-a65b-d21fe96a405b
res_ari_channels: Add ring operation, dtmf operation, hangup reasons, and tweak early media.

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: http://svn.asterisk.org/svn/asterisk/trunk@402359 f38db490-d61c-443f-a65b-d21fe96a405b
ari wiki docs: add notes about allowMultiple parameters.

This patch adds a note to any parameter that has 'allowMultiple' set in
the Swagger documentation.

(closes issue ASTERISK-22704)
........

Merged revisions 402367 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@402368 f38db490-d61c-443f-a65b-d21fe96a405b
Manager: Add equivalent AMI actions for the bridge CLI commands.

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: http://svn.asterisk.org/svn/asterisk/trunk@402388 f38db490-d61c-443f-a65b-d21fe96a405b
app_confbridge: Make the CONFBRIDGE function be able to create dynamic menus

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: http://svn.asterisk.org/svn/asterisk/trunk@402397 f38db490-d61c-443f-a65b-d21fe96a405b
voicemail: Simplify callback pointer declarations and add doxygen.

* 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: http://svn.asterisk.org/svn/asterisk/trunk@402406 f38db490-d61c-443f-a65b-d21fe96a405b
config: Allow ConfBridge DTMF menus to have '#' as the first digit.

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: http://svn.asterisk.org/svn/asterisk/trunk@402417 f38db490-d61c-443f-a65b-d21fe96a405b
confbridge: Separate user muting from system muting overrides.

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: http://svn.asterisk.org/svn/asterisk/trunk@402428 f38db490-d61c-443f-a65b-d21fe96a405b
vector: Update API to be more flexible.

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: http://svn.asterisk.org/svn/asterisk/trunk@402430 f38db490-d61c-443f-a65b-d21fe96a405b
vector: Uppercase API to follow C convention.

C does not support templates like C++.
........

Merged revisions 402438 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@402439 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: notify dialog info ignores presentation indicator in callerid

The presentation indicator in a callerid (e.g. set by dialplan function
Set(CALLERID(name-pres)= ...)) is not checked when SIP Dialog Info Notifies
are generated during extension monitoring.  Added a check to make sure the
name and/or number presentations on the callee (remote identity) are set to
allow.  If they are restricted then "anonymous" is used instead.

(closes issue AST-1175)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2976/
........

Merged revisions 402450 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 402452 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@402453 f38db490-d61c-443f-a65b-d21fe96a405b
stasis_channels: Don't give preference to ANI info in channel snapshots

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: http://svn.asterisk.org/svn/asterisk/trunk@402502 f38db490-d61c-443f-a65b-d21fe96a405b
netsock2: Define AST_AF_* enum constants to their AF_* equivalents

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: http://svn.asterisk.org/svn/asterisk/trunk@402504 f38db490-d61c-443f-a65b-d21fe96a405b
chan_iax2: Fix incorrect usage of ast_get_ip involving uninitialized struct

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: http://svn.asterisk.org/svn/asterisk/trunk@402506 f38db490-d61c-443f-a65b-d21fe96a405b
chan_sip: Use AST_AF* defined constant when calling ast_get_ip

While the structure passed to ast_get_ip should be set memset to 0, thus
initializing the ss_family member to 0, explicitly setting it to AST_AF_UNSPEC
is more portable.
........

Merged revisions 402507 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@402508 f38db490-d61c-443f-a65b-d21fe96a405b
app_queue: crash if first agent is "busy"

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: http://svn.asterisk.org/svn/asterisk/trunk@402518 f38db490-d61c-443f-a65b-d21fe96a405b