This patch added new global pjsip option 'disable_multi_domain'.
Disabling Multi Domain can improve Realtime performance by reducing
number of database requests.

ASTERISK-25930 #close

Change-Id: I2e7160f3aae68475d52742107949a799aa2c7dc7

The unload process currently tells each TCP/TLS to terminate but
does not wait for them to do so. This introduces a race condition
where the container holding the threads may be destroyed before
the threads are able to remove themselves from it. When they
finally do the container is invalid and can't be used causing a
crash.

A previous change existed which waited a bit to wait for any
stranglers to finish. This change extends this and waits longer.

ASTERISK-25961 #close

Change-Id: Idc6262b670ca49ede32061159e323b7b63c6f3c6

When unloading the app_queue module the members in each queue are
destroyed and as part of this they are removed from the pending
members container. Unfortunately a crash would occur as the container
was destroyed before the members were removed.

This change tweaks ordering so the container destruction occurs
after the members are destroyed.

ASTERISK-16115

Change-Id: I48c728668c55aee3d05b751a5d450fb57e87f44b

* changes:
  test_message.c: Wait longer in case dialplan also processes the test message.
  Manager: Short circuit AMI message processing.
  manager.c: Eliminate most RAII_VAR usage.

ASTERISK-25954 #close
Reported by: Javier Acosta

Change-Id: I00be83d45cc7e8385de2523012bd196aafeeb256
(cherry picked from commit c0688a63)

It was possible for a queue member that is a member of at least 2 or more
queues to receive mulitiple calls at the same time. This happened because
of a race between when a member was being rung and when the device state
notified the other queue(s) member object of the state change.

This patch makes it so when a queue member is being rung it gets added to
a global pool of queue members. If that same member is tried again, e.g.
from another queue, and it is found to already exist in the pending member
container then it will not ring that member.

ASTERISK-16115 #close

Change-Id: I546dd474776d158c2b6be44205353dee5bac7e48

The run_agi function is eating control frames when it shouldn't be. This is
causing issues when an AGI is run from CONNECTED_LINE_SEND_SUB in a blond
transfer.

Alice calls Bob. Bob attended transfers to Charlie but hangs up before Charlie
answers.

Alice gets the COLP UPDATE indicating Charlie but Charlie never gets an UPDATE
and is left thinking he's connected to Bob.

In this case, when CONNECTED_LINE_SEND_SUB runs on Alice's channel and it calls
an AGI, the extra eaten frames prevent CONNECTED_LINE_SEND_SUB from running on
Charlie's channel.

The fix was to accumulate deferrable frames in the "forever" loop instead of
dropping them, and re-queue them just before running the actual agi command
or exiting.

ASTERISK-25951 #close

Change-Id: I0f4bbfd72fc1126c2aaba41da3233a33d0433645

Bumped the wait from 1 second to 5 seconds.  The test message was hitting my
default call handler and failing the test because it took longer.

Change-Id: I3a03737f25e92983de00548fcc7bbc50dd7544ba

An earlier allocation failure failed to create a channel snapshot for the
AMI HangupRequest/SoftHangupRequest event which resulted in a crash in
channel_hangup_request_cb().  Where the stasis message gets generated
cannot tell if the NULL snapshot returned was because of an allocation
failure or the channel was a dummy channel.

* Made channel_hangup_request_cb() check if the channel blob has a
snapshot and exit if it doesn't.

* Eliminated the RAII_VAR usage in channel_hangup_request_cb().

Change-Id: I0b6a1c4e95cbb7d80b2a7054c6eadecc169dfd24

You cannot reference the passed in features struct after calling
ast_bridge_impart().  Even if the call fails.

Change-Id: I902b88ba0d5d39520e670fb635078a367268ea21

softmix_bridge_join() failed because of an allocation failure.  To address
this, the softmix bridge technology now checks if the channel failed to
join softmix successfully.  In addition, the bridge now begins the process
of kicking the channel out of the bridge so we don't have channels
partially in the bridge for very long.

* Fix the test_channel_feature_hooks.c unit tests.  The test channel must
have a valid codec to join the simple_bridge technology.  This patch makes
joining a bridge more strict by not allowing partially joined channels to
remain in the bridge.

Change-Id: I97e2ade6a2bcd1214f24fb839fda948825b61a2b

Improve AMI message processing performance if there are no consumers
listening for the messages.  We now skip creating the AMI event message
text strings.

Change-Id: I7b22fc5ec4e500d00635c1a467aa8ea68a1bb2b3

* Made ast_manager_event_blob_create() not allocate the ao2 event object
with a lock as it is not needed.

Change-Id: I8e11bfedd22c21316012e0b9dd79f5918f644b7c

res_odbc was changed in Asterisk 13.8.0 to remove connection management,
opting instead to let unixodbc maintain open connections and return
those to Asterisk as requested.

This was a boon for realtime, since it meant that multiple threads could
potentially run parallel queries since they could each be using their
own database connections.

However, on the user-facing side, func_odbc, there were some inherent
behaviors being relied on that no longer hold true after the change.
One such reported behavior was that MySQL's LAST_INSERTED_ID() works
per-connection. This means that if Asterisk uses separate connections
for every database operation, whereas before it used one connection for
everything, we have broken expectations and functionality.

The fix provided in this patch is to make func_odbc use a single
database connection per DSN. This way, user-facing database usage will
have the same behavior as it did pre-13.8.0. However, realtime, which is
the real workhorse of database interaction, will continue to let
unixodbc manage connections.

ASTERISK-25938 #close
Reported by Edwin Vandamme

Change-Id: Iac961fe79154c6211569afcdfec843c0c24c46dc

Option was removed in commit 7f883ef4

ASTERISK-25927 #close

Change-Id: I92f9b0196d9fc41d1d58354c07340c465ef1fcf8

*lt is NULL if t->tracking == 0

ASTERISK-25948 #close

Change-Id: I4a81af28f9c82a74aa82413d772a7dc8fa6f45ba

We lose the fact that there is a swap channel if there is one.  We
currently wind up rejoining the stasis bridge as a normal join after the
swap channel has already been kicked from the bridge.

This patch preserves the swap channel so the AMI/ARI events can note that
the channel joining the bridge is swapping with another channel.  Another
benefit to swaqpping in one operation is if there are any channels that
get lonely (MOH, bridge playback, and bridge record channels).  The lonely
channels won't leave before the joining channel has a chance to come back
in under stasis if the swap channel is the only reason the lonely channels
are staying in the bridge.

ASTERISK-25947 #close
Reported by: Richard Mudgett

ASTERISK-24649
Reported by: John Bigelow

ASTERISK-24782
Reported by: John Bigelow

Change-Id: If37ea508831d1fed6dbfac2f191c638fc0a850ee

An earlier patch blocked the ast_bridge_impart() call until the channel
either entered the target bridge or it failed.  Unfortuantely, if the
target bridge is stasis and the imprted channel is not a stasis channel,
stasis bounces the channel out of the bridge to come back into the bridge
as a proper stasis channel.  When the channel is bounced out, that
released the block on ast_bridge_impart() to continue.  If the impart was
a result of a transfer, then it became a race to see if the swap channel
would get hung up before the imparted channel could come back into the
stasis bridge.  If the imparted channel won then everything is fine.  If
the swap channel gets hung up first then the transfer will fail because
the swap channel is leaving the bridge.

* Allow a chain of ast_bridge_impart()'s to happen before any are
unblocked to prevent the race condition described above.  When the channel
finally joins the bridge or completely fails to join the bridge then the
ast_bridge_impart() instances are unblocked.

ASTERISK-25947
Reported by: Richard Mudgett

ASTERISK-24649
Reported by: John Bigelow

ASTERISK-24782
Reported by: John Bigelow

Change-Id: I8fef369171f295f580024ab4971e95c799d0dde1

When create_new_id_hdr creates a new RPID or PAI header, it starts by cloning
the From header, then it overwrites the display name and uri from the channel's
connected.id.  If the connected.id.name wasn't valid, create_new_id_hdr was
leaving the display name from the From header in the new RPID or PAI header.
On an attended transfer where the originator had a caller id number set but not
a display name, the re-INVITE to the final transferee had the number of the
originator but the display name of the transferer.

Added a check to clear out the display name in the new header if
connected.id.name was invalid.

ASTERISK-25942 #close

Change-Id: I60b4bf7a7ece9b7425eba74151c0b4969cd2738b

This module is used as part of testsuite tests to confirm
stuff works. I'm accordingly marking it as core as it is
required by those tests.

Change-Id: I558e7af7679b22b8ed641d7dd37ee4ca35b11e88

The PJSIP parsing functions provide a nice concise way to check the
length of a hostname in a SIP URI. The problem is that in order to use
those parsing functions, it's required to use them from a thread that
has registered with PJLib.

On startup, when parsing AOR configuration, the permanent URI handler
may not be run from a PJLib-registered thread. Specifically, this could
happen when Asterisk was started in daemon mode rather than
console-mode. If PJProject were compiled with assertions enabled, then
this would cause Asterisk to crash on startup.

The solution presented here is to do our own parsing of the contact URI
in order to ensure that the hostname in the URI is not too long. The
parsing does not attempt to perform a full SIP URI parse/validation,
since the hostname in the URI is what is important.

ASTERISK-25928 #close
Reported by Joshua Colp

Change-Id: Ic3d6c20ff3502507c17244a8b7e2ca761dc7fb60

Recent changes to the PJSIP registrar resulted in tests failing due to
missing AOR_CONTACT_ADDED test events. The reason for this was that the
user_agent string had junk values in it, resulting in being unable to
generate the event.

I'm going to be honest here, I have no idea why this was happening. Here
are the steps needed for the user_agent variable to get messed up:
* REGISTER is received
* First contact in the REGISTER results in a contact being removed
* Second contact in the REGISTER results in a contact being added
* The contact, AOR, expiration, and user agent all have to be passed as
  format parameters to the creation of a string. Any subset of those
  parameters would not be enough to cause the problem.

Looking into what was happening, the thing that struck me as odd was
that the user_agent variable was meant to be set to the value of the
User-Agent SIP header in the incoming REGISTER. However, when removing a
contact, the user_agent variable would be set (via ast_strdupa inside a
loop) to the stored contact's user_agent. This means that the
user_agent's value would be incorrect when attempting to process further
contacts in the incoming REGISTER.

The fix here is to use a different variable for the stored user agent
when removing a contact. Correcting the behavior to be correct also
means the memory usage is less weird, and the issue no longer occurs.

ASTERISK-25929 #close
Reported by Joshua Colp

Change-Id: I7cd24c86a38dec69ebcc94150614bc25f46b8c08