Attempting to dial PJSIP/endpoint when the endpoint doesn't exist and
disable_multi_domain=no results in a misleading empty endpoint name
message.  The message should say the endpoint was not found.

* Added missing endpoint not found message.

* Added more information to the empty endpoint name msgs if available.

* Eliminated RAII_VAR in request().

Change-Id: I21da85ebd62dcc32115b2ffcb5157416ebae51e4

When adding shutdown refs for OPTIONAL_API components I accidentally
added it to the unload_module function in res_smdi.  Move it to
load_module.

Change-Id: I2b9da38fbc11ef78ea23dbb2df92b684be7f647c

res_hep_pjsip.so and res_hep_rtcp.so will still load and do a lot of
unnecessary work even if 'enabled' is set to 'no' in hep.conf.

Change-Id: I3eddfeea09c6b5bc7c641952ee0ae487fd09b64b

This protects the module loader itself against crashing if dlopen is
called on a module from outside loader.c.

* Expand scope of lock inside ast_module_register to include reading of
  resource_being_loaded.
* NULL check resource_being_loaded.
* Set resource_being_loaded NULL as soon as dlopen returns.  This fixes
  some error paths where it was not NULL'ed.
* Create module_destroy function to deduplicate code from
  ast_module_unregister and modules_shutdown.
* Resolve leak that occured if a module did not successfully register.
* Simplify checking for successful registration.

Change-Id: I40f07a315e55b92df4fc7faf525ed6d4f396e7d2

Never ignore contents of line when generating completion options.

Change-Id: I74389efdfea154019d3b56a9f381610614c044c8

We should not do flood detection on video RTP streams.  Video RTP streams
are very bursty by nature.  They send out a burst of packets to update the
video frame then wait for the next video frame update.  Really only audio
streams can be checked for flooding.  The others are either bursty or
don't have a set rate.

* Added code to selectively disable packet flood detection for video RTP
streams.

ASTERISK-27440

Change-Id: I78031491a6e75c2d4b1e9c2462dc498fe9880a70

add_crypto_to_stream wasn't checking for a NULL
session->inv_session->neg before calling pjmedia_sdp_neg_get_state.
This was causing a crash if the negotiation hadn't already been
completed and asterisk was compiled with --enable-dev-mode.

Change-Id: I57c6229954a38145da9810fc18657bfcc4d9d0c9

Reset the samples counter to zero when we are done playing an
announcement so that we don't skip into the middle of the first file in
the playlist.

Also add the selected annoucement to the output of 'moh show classes.'

ASTERISK-24329 #close
Reported by: Thomas Frederiksen

Change-Id: I2a5f986a31279c981592f49391409ebf38d6f6d0

ASTERISK-19657 #close
Reported by: Matt Jordan III, Esq.

Change-Id: I59a5e6ef3e7d9e848bec1f4b40cb73321bc7956a

This no longer appears to exist, so no sense in causing confusion.

ASTERISK-27175 #close
Reported by: Tzafrir Cohen

Change-Id: Idde967924c69f6a741dc9a5ab7dacb44d22cf100

Added links to the wiki to replace references to outdated
tex docs.

ASTERISK-27430
Reported by: Corey Farrell

Change-Id: I5007e732b30bc7b63d124c530ae8857c89991209

Currently, to figure out specified voicemail's status, there's only one
way to do it, which is use a VoicemailUserEntry AMI message.
But it consumed it too much resource(it check everything).
So, added new AMI action.

ASTERISK-27470

Change-Id: Ie4eba1424a142e5fbd1d9fb1821a3fc1a1e238b7

When the RTCP code was transitioned over to Stasis a code change
was made to keep track of how many reports are present. This count
controlled where report blocks were placed in the RTCP report.

If a compound RTCP packet was received this logic would incorrectly
place a report block in the wrong location resulting in a write
to an invalid location.

This change removes this counting logic and always places the report
block at the first position. If in the future multiple reports are
supported the logic can be extended but for now keeping a count
serves no purpose.

ASTERISK-27382
ASTERISK-27429

Change-Id: Iad6c8a9985c4b608ef493e19c421211615485116

When a connected line update is sent to an endpoint we do not request
a specific stream topology to be used. Previously this resulted in the
configured stream topology being used which may actually differ from the
currently negotiated topology. PJSIP is helpful in this regard in that
it will fill in any missing streams with removed ones. This results in
our own state not matching the SDP, though, and we do not apply the
negotiated SDP.

This change tweaks the code to use the actively negotiated stream
topology if it is present with a fallback to the configured one. This
results in the SDP and the state having matching information and the
world is happy.

ASTERISK*27397

Change-Id: I7a57117f0183479e6884b7bf3a53bb8c7464f604

When we fail over to a new target we create a new transaction
and it becomes the current INVITE transaction. This does not
prevent the previous transaction from raising state changes
and causing the session to be prematurely disconnected if a
transport error occurs immediately.

This change backports a fix from PJSIP that eliminates the
incorrect state change and reduces when they would be raised
in the first place.

ASTERISK-27408

Change-Id: Id22d087591782eee31311753d11e7eca4b95ef34

A patch for sending in-dialog SIP NOTIFY message
with "SIPnotify" AMI action.

ASTERISK-27461

Change-Id: I5797ded4752acd966db6b13971284db684cc5ab4

The approach with having a single global subscription to all extension
state changes has one issue: dynamically created hints don't have any
watchers and are therefore garbage collected on the first dialplan
reload.

This change creates a state subscription for every queue member with a
hint as state_interface, thus increasing the count of watches for
hints, so they are not destroyed prematurely anymore.

There are 2 side effects:
1. The state change callback in app_queue is not executed when
   there are no members referring to the extension.
2. The callback is called multiple times for the same hint if it's
   associated with more than one queue member.

Reported by: Steven T. Wheeler

ASTERISK-18411 #close

Change-Id: I4956af2136ea2a7f110ac9272eae5f6e676d8f89