Testing has shown that our usage of UnixODBC is problematic
due to bugs within UnixODBC itself as well as the heavy weight
cost of connecting and disconnecting database connections, even
when pooling is enabled.

For users of UnixODBC 2.3.1 and earlier crashes would occur due
to insufficient protection of the disconnect operation. This was
fixed in UnixODBC 2.3.2 and above.

For users of UnixODBC 2.3.3 and higher a slow-down would occur
under heavy database use due to repeated connection establishment.
A regression is present where on each connection the database
configuration is cached again, with the cache growing out of
control.

The connection pool implementation present in this change helps
to mitigate these issues by reducing how much we connect and
disconnect database connections. We also solve the issue of
crashes under UnixODBC 2.3.1 by defaulting the maximum number of
connections to 1, returning us to the previous working behavior.
For users who may have a fixed version the maximum concurrent
connection limit can be increased helping with performance.

The connection pool works by keeping a list of active connections.
If the connection limit has not been reached a new connection is
established. If the connection limit has been reached then the
request waits until a connection becomes available before
continuing.

ASTERISK-26074 #close
ASTERISK-26054 #close

Change-Id: I6774bf4bac49a0b30242c76a09c403d2e856ecff

Added a new channel variable FORWARDERNAME which indicates which
channel was responsible for a forwarding requests received on dial attempt.

Fixed a bug in the app_queue: FORWARD_CONTEXT is not used.

ASTERISK-26059 #close

Change-Id: I34e93e8c1b5e17776a77b319703c48c8ca48e7b2

Add Uptime and LastReload to event FullyBooted.

ASTERISK-26058 #close
Reported by: Niklas Larsson

Change-Id: I909b330801c0990d78df9b272ab0adc95aecb15e

The 81b01a191a46_pjsip_add_contact_reg_server.py script was attempting
to use UniqueConstraint and failing. It was not imported and after
importing it also continued to fail.

I've changed the script to use the explicit name of the constraint
instead.

Change-Id: I2438b0be90b7ce583b47dd27983c0c1a02cea5b9

The stringfields refactor to allow adding stringfields to the end of a
structure (f6f4cf45) exposed some
incomplete cleanup code by some stringfield users.

The most noticeable leaker is the logging system where there is a leak for
every log message generated.

ASTERISK-26078 #close
Reported by:  Etienne Lessard
Patches:
      jira_asterisk_26078_v13.patch (license #5621) patch uploaded
      by Richard Mudgett

Change-Id: If6a08b31336b492c3de6f9dfd07c447f8d5a8782

The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.

Change-Id: I4d519385a577f3e9d9193a88125e493cf17fa799

Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended

With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.

AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.

Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.

ASTERISK-25925 #close
Reported by Mark Michelson

Change-Id: I42cbec7730d84640a434d143a0d172a740995543

Re-ordered the body items so Message-Account is second.

Messages-Waiting: no
Message-Account: sip:1571@<IP Removed>:5060
Voice-Message: 0/0 (0/0)

ASTERISK-26065 #close
Reported-by: Ross Beer

Change-Id: If5d35a64656eac98c2dd5e490cc0b2807bed80c3

Although all the patches we had against 2.4.5 were applied by Teluu,
a new bug was introduced preventing re-use of tcp and tls transports
This patch removes all the previous patches against 2.4.5, updates
the version to 2.5, and adds a new patch to correct the transport
re-use problem.

Change-Id: I0dc6c438c3910f7887418a5832ca186aea23d068

Added notes about when you can read or write headers. Specifically
about being able to read on the inbound channel and write on an
outbound channel.

ASTERISK-26063 #close
Reported by: Private Name
Tested by: Rusty Newton

Change-Id: Ibeb64af17d1f6451028b3c29855a3f151a01d8c5

This adds a new parameter to the end of a multicast RTP dialing string.
This parameter defines the following options:

* i: Set the interface from which multicast RTP is sent
* l: Set whether multicast packets are looped back to the sender
* t: Set the TTL for multicast packets
* c: Set the codec to use for RTP

ASTERISK-26068 #close
Reported by Mark Michelson

Change-Id: I033b706b533f0aa635c342eb738e0bcefa07e219

ARI dial had been implemented using the Dial API. This made great sense
when dialing was 100% separate from bridging. However, if a channel were
to be added to a bridge during the dial attempt, there would be a
conflict between the dialing thread and the bridging thread. Each would
be attempting to read frames from the dialed channel and act on them.

The initial attempt to make the two play nice was to have the Dial API
suspend the channel in the bridge and stay in charge of the channel
until the dial was complete. The problem with this was that it was
riddled with potential race conditions. It also was not well-suited for
the case where the channel changed which bridge it was in during the
dial.

This new approach removes the use of the Dial API altogether. Instead,
the channel we are dialing is placed into an invisible ARI dialing
bridge. The bridge channel thread handles incoming frames from the
channel. If the channel is added to a real bridge, it is departed from
the invisible bridge and then added to the real bridge. Similarly, if
the channel is removed from the real bridge, it is automatically added
back to the invisible bridge if the dial attempt is still active.

This approach keeps the threading simple by always having the channel
being handled by bridge channel threads.

ASTERISK-25925

Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb

As res_pjsip_nat rewrites contact's address, only the last Via header
can contain the source address of registered endpoint.
Also Call-Id header may contain the source address of registered
endpoint.

Added "via_addr", "via_port", "call_id" to contact.
Added new fields ViaAddress, CallID to AMI event ContactStatus.

ASTERISK-26011

Change-Id: I36bcc0bf422b3e0623680152d80486aeafe4c576

There are a lot of verbose messages about Endpoint and Contact status
changes if there are many dynamic endpoints.
The patch sets verbose level 2 for Endpoint status changes
and verbose level 3 for Contact status changes.

ASTERISK-26055 #close

Change-Id: Ie64e261ddbbc41bfff0f0190241152cc123fe6d7

Fixed some bugs:
- create dirpath when save downloading message from IMAP storage.
- create IMAP folder if not exists when saving to IMAP storage
- check if file successfully opened before write to it
- some IMAP checks
- remove non-standard flag 'Unseen'
etc

Change to debug IMAP mm_status log instead of verbose.

Remove unused X-Asterisk-VM-Caller-channel message header
for security reason. The clients should not know name of peer/endpoint.

ASTERISK-26045 #close

Change-Id: I7f83d88b69b36934e2539c114b9fb612deed971b

The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.

Change-Id: Iafe8b01242b7deb0ebfdc36685e21374a43936d2

Add the option 'enable_callee_prompt' to followme.conf. Enabled by
default. If disabled, a callee is not prompted to accept or reject
the forwarded call.

ASTERISK-26064 #close

Change-Id: I0a8b19d4cf95c86a07c992813babb9e4a4acfff5
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

worker_start checked for ZOMBIE status without holding a lock.  All
other read/write of worker status are performed with a lock, so this
check should do the same.

ASTERISK-25777 #close

Change-Id: I5e33685a5c26fdb300851989a3b82be8c4e03781

Recent changes to res_pjsip_outbound_publish have introduced a
race condition at shutdown where an outbound publish may be shutdown
twice. In this case the first succeeds as a result of the unpublish.
In the second invocation since it's been unpublished a task is
queued to just destroy the client. This task holds no ref to the
publish and as a result the publish may be destroyed before the
task is run, causing a crash.

This explicit destruction task now holds a reference to the publish
to ensure it remains valid.

ASTERISK-26053 #close

Change-Id: I10789b98add3e50292ee3b33a55a1d9061cec94b

Invisible bridges function the same as normal bridges, but they have the
following restrictions:

* They never show up in CLI, AMI, or ARI queries.
* They do not have Stasis messages published about them.

Invisible bridges' main use is for when use of the bridging system is
desired, but the bridge should not be known to users of the Asterisk
system.

ASTERISK-25925

Change-Id: I804a209d3181d7c54e3d61a60eb462e7ce0e3670