In say_date_generic the timezonename parameter is passed but never
used. Fix it by passing it to the ast_localtime function.

ASTERISK-27124

Change-Id: I63106b8db10426d417d7275f22554a616e92fae4

By default, when res_musiconhold reloads or unloads, it sends a HUP
signal to custom applications (and all descendants), waits 100ms,
then sends a TERM signal, waits 100ms, then finally sends a KILL
signal.  An application which is interacting with an external
device and/or spawns children of its own may not be able to exit
cleanly in the default times, expecially if sent a KILL signal, or
if it's children are getting signals directly from
res_musiconhoild.

* To allow extra time, the 'kill_escalation_delay'
  class option can be used to set the number of milliseconds
  res_musiconhold waits before escalating kill signals, with the
  default being the current 100ms.

* To control to whom the signals are sent, the "kill_method" class
  option can be set to "process_group" (the default, existing
  behavior), which sends signals to the application and its
  descendants directly, or "process" which sends signals only to the
  application itself.

Change-Id: Iff70a1a9405685a9021a68416830c0db5158603b

When performing the "Queues" action via AMI, it outputs the same
text that the Asterisk CLI outputs when running a "queue show"
command, which does not conform with the AMI spec. "QueueStatus"
already does what the "Queues" action should do, so instead of
correcting the output, the "Queues" action will be removed and
"QueueStatus" should be used instead.

ASTERISK-27073 #close
Reported by: Brian

Change-Id: Id11743859758255b69cc3a557750d7a56c6d16f8

Setting maxfiles (maximum number of open files) has no practical
effect on a remote asterisk (rasterisk, rasterisk -x).

It has an ill effect of printing an extra message, which
may be annoying in case of -x.

ASTERISK-27105 #close

Change-Id: Iaf9eb344e4b4b517df91b736b27ec55f6a6921a2

Messages like "fwrite() failed: Connection reset by peer" are no
help whatsoever, especially since they can be caused simply by a
client disconnecting.

* Make those WARNINGs DEBUGs.
* Check the return from ast_iostream_printf of headers.

Change-Id: I17bd5f3621514152a7b2b263c801324c5e96568b

If the from_user field contains certain characters (like @, {, ^, etc.),
PJSIP will return a null value for the URI when attempting to parse it.
This causes a crash when trying to dial out through a trunk that contains
these invalid characters in its from_user field.

This change checks the configuration and ensures that an endpoint will
not be created if the from_user contains an invalid character. It also
adds a null check to the PJSIP URI parsing as a backup.

ASTERISK-27036 #close
Reported by: Maxim Vasilev

Change-Id: I0396fdb5080604e0bdf1277464d5c8a85db913d0

Change-Id: I9020ff9f2b3749904317c0c173f47a1bbed6f929

When a message is received on the TURN socket, the code processing the
message needs to call into the ICE/STUN session for further processing.
This code path locks the TURN group lock then the ICE/STUN group lock.  In
another thread an ICE/STUN timer can fire off to send a keep alive message
over the TURN socket.  In this code path, the ICE/STUN group lock is
obtained then the TURN group lock is obtained to send the packet.  A
classic deadlock case if the group locks are not the same.

* Made TURN get created using the ICE/STUN session's group lock.

NOTE: I was originally concerned that the ICE/STUN session can get
recreated by ice_reset_session() for an event like RTCP multiplexing
causing a change during SDP negotiation.  In this case the TURN group lock
would become different.  However, TURN is also recreated as part of the
ICE/STUN recreation in ice_create() when all known ICE candidates are
added to the new ICE session.  While the ICE/STUN and TURN sessions are
being recreated there is a period where the group locks could be
different.

ASTERISK-27023 #close
Patches:
    res_rtp_asterisk-turn-deadlock-fix.patch (license #6502)
        patch uploaded by Michael Walton (modified)

Change-Id: Ic870edb99ce4988a8c8eb6e678ca7f19da1432b9

Change-Id: I04f607f084bda9b1b7f626e8e9735c37dc751187

The video stream was using the audio stream RTP instance addresses to
check if the video RTP gets directed to an allowed direct media Access
Control List (ACL) address.  There is no guarantee that the video RTP
instance uses the same addresses as the audio RTP instance.

This looks like it has been a bug since v11 when direct media ACL was
first added to chan_sip and then faithfully reproduced through a couple
code refactorings into the new bridging architecture.

Change-Id: I8ddd56320e0eea769f3ceed3fa5b6bdfb51d681a

This API was not actively maintained, was not added to new modules
(such as res_pjsip), and there exist better alternatives to acquire the
same information, such as the ARI.

Change-Id: I4b2185a83aeb74798b4ad43ff8f89f971096aa83

When sip.conf contained tcpenable=yes and autodomain=yes, the TCP domain was
added in any case, because of a local Boolean-negation error of the return value
of ast_sockaddr_cmp. After fixing this error for TCP and TLS, the TLS domain was
still always added with tlsenable=yes, because the domains were not compared
just on the address but also on the port – and TLS is always on a different port
than UDP/TCP.

ASTERISK-27106

Change-Id: I14fe9e319e238320b094016980445ef3a5b3337c

Because of a copy-and-paste error when the struct ast_sockaddr changed,
tlsbindaddr was not added, when sip.conf contained autodomain=yes; see
"show sip domains" on the command-line interface (CLI) of Asterisk.

ASTERISK-27106

Change-Id: I3d0957150017c223136968ef1266f275d0d6695e

The primary focus of this patch is adding a missing call to
ast_odbc_release_obj(), but is also a general cleanup of the ODBC
related code in app_voicemail.

ASTERISK-27093 #close

Change-Id: I8e285142eaeb3146b4287a928276b70db76c902b

Clear channel flag AST_FLAG_END_DTMF_ONLY in ast_waitfordigit_full when
ast_read returns NULL.

ASTERISK-27100 #close

Change-Id: Id3039e9a4e74e0cb359f636c9fd0c9740ebf7d9d

When a SIP message comes in on a transport, pjproject obtains the lock on
the transport and pulls the data out of the socket.  Unlike UDP, the TCP
transport does not allow concurrent access.  Without concurrency the
transport lock is not released when the transport's message complete
callback is called.  The processing continues and eventually Asterisk
starts processing the SIP message.  The first thing Asterisk tries to do
is determine the associated dialog of the message to determine the
associated serializer.  To get the associated serializer safely requires
us to get the dialog lock.

To send a request or response message for a dialog, pjproject obtains the
dialog lock and then obtains the transport lock.  Deadlock can result
because of the opposite order the locks are obtained.

* Fix the deadlock by obtaining the serializer associated with the dialog
another way that doesn't involve obtaining the dialog lock.  In this case,
we use an ao2 container to hold the associated endpoint and serializer.
The new locks are held a brief time and won't overlap other existing lock
times.

ASTERISK-27090 #close

Change-Id: I9ed63f4da9649e9db6ed4be29c360968917a89bd

The OBJ_SEARCH_xxx defines should not be used as if they were individual
bits.  They represent a multi-bit enumeration value field.

Change-Id: I32abc9a475396dab02402a7014357dd94284e17b