ARI was recently outfitted with operations to create and dial channels.
This leads to the ability to try funny stuff. You could create a channel
and then immediately try to play back media on it. You could create a
channel, dial it, and while it is ringing attempt to make it continue in
the dialplan.

This commit attempts to fix this by adding a channel state check to
operations that should not be able to operate on outbound channels that
have not yet answered. If a channel is in an invalid state, we will send
a 412 response.

ASTERISK-26047 #close
Reported by Mark Michelson

Change-Id: I2ca51bf9ef2b44a1dc5a73f2d2de35c62c37dfd8

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

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

The send request callback function currently assumes that it
will only ever be called on transaction state changes. This is
not always true. If our own timer callback occurs we will call
the callback with a timer event instead of a transaction state
change event. In this case the transaction on the event is
invalid and accessing it will result in a crash.

ASTERISK-26049 #close

Change-Id: I623211c8533eb73056b0250b4580b49ad4174dfc

The characters 0x80-0xFF were trimmed as well as 0x00-0x20 because of
a signed comparison.

ASTERISK-25669 #close
Reported by: Jesper
patches:
  strings.curl.trim.patch submitted by Jesper (License 5518)

Change-Id: Ia51e169f24e3252a7ebbaab3728630138ec6f60a

* Fixed NULL crash potential if parameters are missing.

* Reordered some operations so further diagnostic messages can be
more helpful.

Change-Id: Ibbdc67a2496508cbfbfef0cf19c35177ae2fbd70

ASTERISK-26029

Change-Id: I2db14d102a48d3224010e6d1c69e856373cc1260

func_odbc was changed in Asterisk 13.9.0
to make func_odbc use a single database connection per DSN
because of reported bug ASTERISK-25938
with MySQL/MariaDB LAST_INSERT_ID().

This is drawback in performance when func_odbc is used
very often in dialplan.

Single database connection should be optional.

ASTERISK-26010

Change-Id: I7091783a7150252de8eeb455115bd00514dfe843

When receiving an incoming response to a dialog-starting INVITE, we were
not matching the response to the INVITE dialog. Since we had not
recorded the to-tag to the dialog structure, the PJSIP-provided method
to find the dialog did not match.

Most of the time, this was not a problem, because there is a fall-back
that makes the response get routed to the same serializer that the
request was sent on. However, in cases where an asynchronous DNS lookup
occurs in the PJSIP core, the thread that sends the INVITE is not
actually a threadpool serializer thread. This means we are unable to
record a serializer to handle the incoming response.

Now, imagine what happens when an INVITE is sent on a non-serialized
thread, and an error response (such as a 486) arrives. The 486 ends up
getting put on some random threadpool thread. Eventually, a hangup task
gets queued on the INVITE dialog serializer. Since the 486 is being
handled on a different thread, the hangup task can execute at the same
time that the 486 is being handled. The hangup task assumes that it is
the sole owner of the INVITE session and channel, so it ends up
potentially freeing the channel and NULLing the session's channel
pointer. The thread handling the 486 can crash as a result.

This change has the incoming response match the INVITE transaction, and
then get the dialog from that transaction. It's the same method we had
been using for matching incoming CANCEL requests. By doing this, we get
the INVITE dialog and can ensure that the 486 response ends up being
handled by the same thread as the hangup, ensuring that the hangup runs
after the 486 has been completely handled.

ASTERISK-25941 #close
Reported by Javier Riveros

Change-Id: I0d4cc5d07e2a8d03e9db704d34bdef2ba60794a0

This patch adds a new feature to ARI that allows a client to download
the media associated with a stored recording. The new route is
/recordings/stored/{name}/file, and transmits the underlying binary file
using Asterisk's HTTP server's underlying file transfer facilities.

Because this REST route returns non-JSON, a few small enhancements had
to be made to the Python Swagger generation code, as well as the
mustache templates that generate the ARI bindings.

ASTERISK-26042 #close

Change-Id: I49ec5c4afdec30bb665d9c977ab423b5387e0181

This change introduces the same filtering that is done in res_sorcery_realtime
to the res_sorcery_astdb module. This allows persisted sorcery objects
that may contain unknown fields to still be read in from the AstDB
and used. This is particularly useful when switching between different
versions of Asterisk that may have introduced additional fields.

ASTERISK-26014 #close

Change-Id: Ib655130485a3ccfd635b7ed5546010ca14690fb2