The DUNDi weight field is not always converted from network byte order
to host byte order. This can result in incorrect weight values and
incorrect selection of DUNDi destinations.

ASTERISK-18731 #close
Reported by: Peter Racz
Patches:
	dundi_weight.patch (license #6290) patch uploaded by Peter Racz

Change-Id: Iba3e1a700ff539db57211a7bbc26f7b22ea9a1be

* changes:
  Add SDP translator and PJMEDIA implementation.
  Add initial SDP options.

ast_load_realtime_multientry() returns an ast_config structure whose
ast_categorys are keyed with the empty strings. Several modules were
giving semantic meaning to the category names causing problems at
runtime.

* app_directory: Treated the category name as the mailbox name, and
  would fail to direct calls to the appropriate extension after an
  entry was chosen.

* app_queue: Queues, queue members, and queue rules were all affected
  and needed to be updated.

* pbx_realtime: Pattern matching would never succeed because the
  extension entered by the user was always compared to the empty
  string.

Change-Id: Ie7e44986344b0b76ea8f6ddb5879f5040c6ca8a7

All of the realtime backends create artificial ast_categorys to pass
back into the core as query results. These categories have no filename
or line number information associated with them and the backends differ
slightly on how they create them. So create a couple helper macros to
help make things more consistent.

Also updated the call sites to remove redundant error messages about
memory allocation failure.

Note that res_config_ldap sets the category filename to the 'table name'
but that is not read by anything in the core, so I've dropped it.

Change-Id: I3a1fd91e0c807dea1ce3b643b0a6fe5be9002897

On some platforms a multiarch approach is used for libraries.
The build system does not take this into account and still
places libraries into the lib directory if no --libdir is
specified to configure. On initial startup this results in
libasteriskssl.so not being found, as it is not in the multiarch
lib directory.

This change does the minimally invasive thing and executes
ldconfig so that the libraries in the lib directory are found
and their location cached. By doing so Asterisk starts up fine.

If DESTDIR is specified, however, the old logic is executed as
the install process may not have permission to alter the ldconfig
cache.

ASTERISK-26705

Change-Id: If4eca46ac510c6fea5568256280ffdb3888d7bb4

The inbound authentication object is supposed to be immutable when it is
stored in sorcery.  However, the immutable property is violated if the
authentication object does not have a realm set.

The immutable contract violation has a different effect depending upon
what sorcery back end is used.  If it is the config file back end you
would get the same object back until res_pjsip is reloaded.  If it is the
real-time or AstDB back end you would get a new object on each query.  If
it is cached you would get the same object back until it is refreshed from
the database.

Once an inbound authentication object has its realm set it may or may not
get updated again if the default_realm changes.

If the same authentication object is used for inbound and outbound
authentication then the immutable violation can make it very hard to
determine why the outbound authentication now fails.  The only diagnostic
message is a complaint about no realms matching when it had worked
earlier.  It fails because of the difference in behaviour for an empty
realm setting between inbound and outbound authentication objects.

* Fixed the sorcery object immutable violation by creating a new object
and setting the default_realm on it instead.  The new object is a shallow
copy for speed.

* The auth_store thread storage no longer holds an auth ref.  It
interferes with the shallow copy and never needed a ref anyway.

ASTERISK-26799 #close

Change-Id: I2328a52f61b78ed5fbba38180b7f183ee7e08956

There was code attempting to update the artificial authentication object
whenever the default_realm changed.  However, once the artificial
authentication object was created it would never get updated.  The
artificial authentication object would require a system restart for a
change to the default_realm to take effect.

ASTERISK-26799

Change-Id: Id59036e9529c2d3ed728af2ed904dc36e7094802

Using the same auth section for inbound and outbound authentication is not
recommended.  There is a difference in meaning for an empty realm setting
between inbound and outbound authentication uses.

An empty inbound auth realm represents the global section's default_realm
value when the authentication object is used to challenge an incoming
request.  An empty outgoing auth realm is treated as a don't care wildcard
when the authentication object is used to respond to an incoming
authentication challenge.

ASTERISK-26799

Change-Id: Id3952f7cfa1b6683b9954f2c5d2352d2f11059ce

* Re #1945 (misc): Don't trigger SRV complete callback when there is a
parse error.

* srv_resolver.c: Don't try to send query if already considered resolved.

** In resolve_hostnames() don't try to resolve a query that is already
considered resolved.

** In resolve_hostnames() fix DNS typo in comments.

** In build_server_entries() move a common expression assigning to cnt
earlier.

* sip_transport.c: Fix tdata object name to actually contain the pointer.

It helps if the logs referencing a tdata object buffer actually have a
name that includes the correct pointer as part of the name.  Also since
the tdata has its own pool it helps if any logs referencing the pool have
the same name as the tdata object.  This change brings tdata logging in
line with how tsx objects are named.

ASTERISK-26669 #close
ASTERISK-26738 #close

Change-Id: I56af2ded25476b3e870ca586ee69ed6954ef75af

ASTERISK-26669
ASTERISK-26738

Change-Id: Ibae6fc8cae69a1f04df0c577c4c11200499d6fe0

* Removed overloaded unmatched response ignore.  We obviously sent the
request so we shouldn't ignore it because it isn't new work.

ASTERISK-26669
ASTERISK-26738

Change-Id: I55fb5cadc83a8e6699b347c6dc7fa32c5a617d37

vm_authenticate doesn't always set the passed ast_vm_user argument, so
we initialize to 0 before passing it in.

ASTERISK-25893 #close
Reported by: Filip Jenicek

Change-Id: Ia3cc0128f93d352ed9add8d5c2f0f7232c2cbe4a

This reverts commit 8851c3e0.

Change-Id: I124380be5e3bd57da978428a2a93604336ccd0db

When listing a container, we now print the number of objects
in the container at the end of the list.

Change-Id: I791cbc3ee9da9a2af9adc655164b5d32953df812

OpenLDAP will raise an error when we try to delete an LDAP attribute
that doesn't exist. We need to filter out LDAP_MOD_DELETE requests
based on which attributes the current LDAP entry actually has. There
is of course a small window of opportunity for this to still fail,
but it is much less likely now.

Change-Id: I3fe1b04472733e43151563aaf9f8b49980273e6b

Extraneous line numbers were being output in many log messages. These
have been removed.

Change-Id: Ice9efa3d252ee87f37fa8f5ea852fda482675431

The code in update_ldap() and update2_ldap() was using both Asterisk's
memory allocation routines as well as OpenLDAP's. I've changed it so
that everything that is passed to OpenLDAP's functions are allocated
with their routines.

Change-Id: Iafec9c1fd8ea49ccc496d6316769a6a426daa804

The "_general" configuration section allows administrators to provide
both general configuration options (host, port, url, etc.) as well as a
global realtime-to-LDAP-attribute mapping that is a fallback if one of
the later sections do not override it. This neglected to exclude the
general configuration options from the mapping. As an example, during
my testing, chan_sip requested 'port' from realtime, and because I did
not have it defined, it pulled in the 'port' configuration option from
"_general." We now filter those out explicitly.

Change-Id: I1fc61560bf96b8ba623063cfb7e0a49c4690d778