Add channel reference count for PJSIP REFER. The call could be terminated
prior to the result of the transfer. In that scenario, when the SUBSCRIBE/NOTIFY
occurred several minutes later, it would attempt to access a session which was
no longer valid.  Terminate event subscription if pjsip_xfer_initiate() or
pjsip_xfer_send_request() fails in transfer_refer().

ASTERISK-29201 #close
Reported-by: Dan Cropp

Change-Id: I3fd92fd14b4e3844d3d7b0f60fe417a4df5f2435

In some circumstances it was possible for an INVITE
session to be destroyed while we were still using it.
This occurred due to the reference on the INVITE session
being released internally as a result of its state
changing to DISCONNECTED.

This change adds a reference to the INVITE session
which is released when our own session is destroyed,
ensuring that the INVITE session remains valid for
the lifetime of our session.

ASTERISK-29022

Change-Id: I300c6d9005ff0e6efbe1132daefc7e47ca6228c9

Added to:
 * bridges/bridge_softmix.c
 * channels/chan_pjsip.c
 * include/asterisk/res_pjsip_session.h
 * main/channel.c
 * res/res_pjsip_session.c

There NO functional changes in this commit.

Change-Id: I06af034d1ff3ea1feb56596fd7bd6d7939dfdcc3

Prior to making any modifications to the pjsip infrastructure
for ACN, I've added the tracing functions to the existing code.
This should make the final commit easier to review, but we can also
now run a "before and after" trace.

No functional changes were made with this commit.

Change-Id: Ia83a1a2687ccb96f2bc8a2a3928a5214c4be775c

The Streams API becomes the home for the core ACN capabilities.
These include...

 * Parsing and formatting of codec negotation preferences.
 * Resolving pending streams and topologies with those configured
   using configured preferences.
 * Utility functions for creating string representations of
   streams, topologies, and negotiation preferences.

For codec negotiation preferences:
 * Added ast_stream_codec_prefs_parse() which takes a string
   representation of codec negotiation preferences, which
   may come from a pjsip endpoint for example, and populates
   a ast_stream_codec_negotiation_prefs structure.
 * Added ast_stream_codec_prefs_to_str() which does the reverse.
 * Added many functions to parse individual parameter name
   and value strings to their respectrive enum values, and the
   reverse.

For streams:
 * Added ast_stream_create_resolved() which takes a "live" stream
   and resolves it with a configured stream and the negotiation
   preferences to create a new stream.
 * Added ast_stream_to_str() which create a string representation
   of a stream suitable for debug or display purposes.

For topology:
 * Added ast_stream_topology_create_resolved() which takes a "live"
   topology and resolves it, stream by stream, with a configured
   topology stream and the negotiation preferences to create a new
   topology.
 * Added ast_stream_topology_to_str() which create a string
   representation of a topology suitable for debug or display
   purposes.
 * Renamed ast_format_caps_from_topology() to
   ast_stream_topology_get_formats() to be more consistent with
   the existing ast_stream_get_formats().

Additional changes:
 * A new function ast_format_cap_append_names() appends the results
   to the ast_str buffer instead of replacing buffer contents.

Change-Id: I2df77dedd0c72c52deb6e329effe057a8e06cd56

A patch made a reference to the PJSIP_SC_NULL enumeration value, which
was added to pjproject 2.8 and above thus making it so Asterisk would
fail to compile with prior versions of pjproject.

This patch removes the reference, and instead initializes the value
to '0'.

ASTERISK-28886 #close

Change-Id: I68491c80da1a0154b2286c9458440141c98db9d7

When fax_gateway_framehook is called and a gateway hasn't already
been started, the framehook gets the t38 state for both the current
channel and the peer.  That call trickles down to the channel
driver which determines the state.  If either channel is hung up
(or in the process of being hung up), the channel driver's tech_pvt
is going to be NULL which, in the case of chan_pjsip, will cause a
segfault.

* Added a hangup check for both the channel and peer channel
  before starting a fax gateway.

* Added a check for NULL tech_pvt to chan_pjsip_queryoption
  so we don't attempt to reference a tech_pvt that's already
  gone.

ASTERISK-28923
Reported by: Yury Kirsanov

Change-Id: I4e10e63b667bbb68c1c8623f977488f5d807897c

Some places in Asterisk did not treat the formats on a stream
as immutable when they are.

The ast_stream_get_formats function is now const to enforce this
and parts of Asterisk have been updated to take this into account.
Some violations of this were also fixed along the way.

An additional minor tweak is that streams are now allocated with
an empty format capabilities structure removing the need in various
places to check that one is present on the stream.

ASTERISK-28846

Change-Id: I32f29715330db4ff48edd6f1f359090458a9bfbe

If chan_pjsip is configured for DTMF_RFC_4733, and the core triggers a
digit begin before media, or rtp has been setup then it's possible the
outgoing channel will hear a constant DTMF tone upon answering.

This happens because when there is no media, or rtp chan_pjsip notifies
the core to initiate inband DTMF. However, upon digit end if media, and
rtp become available then chan_pjsip does not notify the core to stop
inband DTMF. Thus the tone continues playing.

This patch makes it so chan_pjsip only notifies the core to start
inband DTMF in only the required cases. Now if there is no media, or
rtp availabe upon digit begin chan_pjsip does nothing, but tells the
core it handled it.

ASTERISK-28817 #close

Change-Id: I0dbea9fff444a2595fb18c64b89653e90d2f6eb5

Do not hang up a PJSIP channel on RTP timeout if that channel is in
a direct-media bridge. Also reset the time of the last received RTP packet when
direct-media ends (wait full rtp_timeout period before checking first time after
audio came back to Asterisk).

ASTERISK-28774
Reported-by: Michael Neuhauser

Change-Id: I8b62012be7685849e8fb2b1c5dd39d35313ca2d1

If the SSRC of a received RTP packet differed from the previous SSRC
an SSRC change control frame would be queued ahead of the media
frame. In the case of audio this would result in the format of the
audio frame not being checked, and if it differed or was not allowed
then it could cause the call to drop due to failure to set up a
translation path.

The chan_pjsip module will now no longer assume the first frame
will be the audio frame and instead goes through the complete list
to find it.

ASTERISK-28759

Change-Id: I6d854cc523f343e299a615636fc65bdbd5f809ec

If chan_pjsip receives an RTP packet whose payload differs from the
channel's native format, and asymmetric_rtp_codec is disabled (the
default), Asterisk will switch the channel's native format to match
that of the incoming packet without regard to the negotiated payloads.

We now check that the received frame is in a format we have negotiated
before switching payloads which results in these packets being dropped
instead of causing the session to terminate.

ASTERISK-28139 #close
Reported by: Paul Brooks

Change-Id: Icc3b85cee1772026cee5dc1b68459bf9431c14a3

ASTERISK-28086 #close

Change-Id: Ib3baadc89b9f0477a6f25a63861433812368c5ea

Add a new dialplan function PJSIP_MOH_PASSTHROUGH that allows
the on-hold behavior to be controlled on a per-call basis

ASTERISK-28542 #close

Change-Id: Iebe905b2ad6dbaa87ab330267147180b05a3c3a8

This change adds H.265/HEVC as a known codec and creates a cached
"h265" media format for use.

Note that RFC 7798 section 7.2 also describes additional SDP
parameters. Handling of these is not yet supported.

ASTERISK-28512

Change-Id: I26d262cc4110b4f7e99348a3ddc53bad0d2cd1f2

When fax detection occurs on an outbound PJSIP channel the
redirect operation will result in a masquerade occurring and
the underlying channel on the session changing. The code
incorrectly relocked the new channel instead of the old
channel when returning. This resulted in the new channel
being locked indefinitely. The code now always acts on the
expected channel.

ASTERISK-28538

Change-Id: I2b2e60d07e74383ae7e90d752c036c4b02d6b3a3

Previously, when a Transfer (REFER) was performed, chan_pjsip would set
the TRANSFERSTATUS to SUCCESS when the REFER was queued up.  This did not
reflect a successful/unsuccessful transfer the way chan_sip did.
Added a callback module to process the refer subscription information.

Now depends on res_pjsip_pubsub so call transfer progress can be monitored
and reported

ASTERISK-26968 #close
Reported-by: Dan Cropp

Change-Id: If6c27c757c66f71e8b75e3fe49da53ebe62395dc

We have seen some rare case of segmentation fault in hangup function
and we could notice that channel pointer was NULL.  Debug log shows
that there is a 200 OK answer and SIP timeout at the same time.  It
looks that while the SIP session was being destroyed due to timeout
call hangup due to answer event lead to race condition and channel
is being destroyed from two different places.  The check ensures we
check it not to be NULL before freeing it.

ASTERISK-25371

Change-Id: I19f6566830640625e08f7b87bfe15758ad33a778

The caller endpoint hears dead silence if a callee replies 180 (without SDP)
and the caller already received 183 (with SDP).
It happens because Asterisk sends 180 (WITH SDP) to the caller,
there are not incoming RTP packets from the callee
and Asterisk does not generate inband ringing,
so there are not any outgoing RTP packets to the caller.

This patch replaces 180 by 183 if SDP negotiation has completed,
as if the caller endpoint is configured with "inband_progress=yes".

In this case Asterisk will generate inband ringing untill Asterisk receive
incoming RTP packets from the callee.

ASTERISK-27994 #close

Change-Id: I7450b751083ec30d68d6abffe922215a15ae5a73

When the dtmf_mode on an endpoint is configured as "auto_info"
Asterisk will produce an inband DTMF tone alongside an INFO
message when sending DTMF.

ASTERISK-28371

Change-Id: I1380b82f006e110a1b83fbb50c9873edd13a5d9a

chan_sip will always ignore 183 responses that do not contain SDP
however, chan_pjsip will currently always translate it into a
183 with SDP.  This new flag allows chan_pjsip to have the same
behavior as chan_sip.

ASTERISK-28322 #close

Change-Id: If81cfaa17c11b6ac703e3d71696f259d86c6be4a

When a channel snapshot was created it used to be done
from scratch, copying all data (many strings). This incurs
a cost when doing so.

This change segments the channel snapshot into different
components which can be reused if unchanged from the
previous snapshot creation, reducing the cost. In normal
cases this results in some pointers being copied with
reference count being bumped, some integers being set,
and a string or two copied. The other benefit is that it
is now possible to determine if a channel snapshot update
is redundant and thus stop it before a message is published
to stasis.

The specific segments in the channel snapshot were split up
based on whether they are changed together, how often they
are changed, and their general grouping. In practice only
1 (or 0) of the segments actually get changed in normal
operation.

Invalidation is done by setting a flag on the channel when
the segment source is changed, forcing creation of a new
segment when the channel snapshot is created.

ASTERISK-28119

Change-Id: I5d7ef3df963a88ac47bc187d73c5225c315f8423

Channels no longer use the Stasis cache for channel snapshots. Instead
they are stored in a hash table in stasis_channels which reduces the
number of Stasis messages created and allows better storage.

As a result the following APIs are no longer available since the stasis
cache is no longer used:
ast_channel_topic_cached()
ast_channel_topic_all_cached()

The ast_channel_cache_all() and ast_channel_cache_by_name() functions
now return an ao2_container of ast_channel_snapshots rather than
a container of stasis_messages therefore you can't (and don't need
to) call stasis_cache functions on it.

The ast_channel_topic_all() function now returns a normal topic not
a cached one so you can't use stasis cache functions on it either.

The ast_channel_snapshot_type() stasis message now has the
ast_channel_snapshot_update structure as it's data. It contains the
last snapshot and the new one.

ast_channel_snapshot_get_latest() still returns the latest snapshot.

The latest snapshot is now stored on the channel itself to eliminate
cache hits when Stasis messages that have the snapshot as a payload
are created.

ASTERISK-28102

Change-Id: I9334febff60a82d7c39703e49059fa3a68825786

New dialplan function PJSIP_PARSE_URI added to parse an URI and return
a specified part of the URI.

This is useful when need to get part of the URI instead of cutting it
using a CUT function.

For example to get 'user' part of Remote URI
${PJSIP_PARSE_URI(${CHANNEL(pjsip,remote_uri)},user)}

ASTERISK-28144 #close

Change-Id: I5d828fb87f6803b6c1152bb7b44835f027bb9d5a

This patch adds new options 'trust_connected_line' and 'send_connected_line'
to the endpoint.

The option 'trust_connected_line' is to control if connected line updates
are accepted from this endpoint.

The option 'send_connected_line' is to control if connected line updates
can be sent to this endpoint.

The default value is 'yes' for both options.

Change-Id: I16af967815efd904597ec2f033337e4333d097cd

chan_pjsip wasn't registering for "BEFORE_MEDIA" responses which meant
it was not updating HANGUPCAUSE for 4XX responses.  If the remote end
sent a "180 Ringing", then a "486 Busy", the hangup cause was left at
"180 Normal Clearing".

* Removed chan_pjsip_incoming_response from the original session
  supplement (which was handling only "AFTER MEDIA") and added it to a
  new session supplement which accepts both "BEFORE_MEDIA" and
  "AFTER_MEDIA".

* Also cleaned up some cleanup code in load module.

ASTERISK-27902

Change-Id: If9b860541887aca8ac2c9f2ed51ceb0550fb007a

Core bridging and, more specifically, bridge_softmix have been
enhanced to relay received frames of type TEXT or TEXT_DATA to all
participants in a softmix bridge.  res_pjsip_messaging and
chan_pjsip have been enhanced to take advantage of this so when
res_pjsip_messaging receives an in-dialog MESSAGE message from a
user in a conference call, it's relayed to all other participants
in the call.

res_pjsip_messaging already queues TEXT frames to the channel when
it receives an in-dialog MESSAGE from an endpoint and chan_pjsip
will send an MESSAGE when it gets a TEXT frame.  On a normal
point-to-point call, the frames are forwarded between the two
correctly.  bridge_softmix was not though so messages weren't
getting forwarded to conference bridge participants.  Even if they
were, the bridging code had no way to tell the participants who
sent the message so it would look like it came from the bridge
itself.

* The TEXT frame type doesn't allow storage of any meta data, such
as sender, on the frame so a new TEXT_DATA frame type was added that
uses the new ast_msg_data structure as its payload.  A channel
driver can queue a frame of that type when it receives a message
from outside.  A channel driver can use it for sending messages
by implementing the new send_text_data channel tech callback and
setting the new AST_CHAN_TP_SEND_TEXT_DATA flag in its tech
properties.  If set, the bridging/channel core will use it instead
of the original send_text callback and it will get the ast_msg_data
structure. Channel drivers aren't required to implement this.  Even
if a TEXT_DATA enabled driver uses it for incoming messages, an
outgoing channel driver that doesn't will still have it's send_text
callback called with only the message text just as before.

* res_pjsip_messaging now creates a TEXT_DATA frame for incoming
in-dialog messages and sets the "from" to the display name in the
"From" header, or if that's empty, the caller id name from the
channel.  This allows the chat client user to set a friendly name
for the chat.

* bridge_softmix now forwards TEXT and TEXT_DATA frames to all
participants (except the sender).

* A new function "ast_sendtext_data" was added to channel which
takes an ast_msg_data structure and calls a channel's
send_text_data callback, or if that's not defined, the original
send_text callback.

* bridge_channel now calls ast_sendtext_data for TEXT_DATA frame
types and ast_sendtext for TEXT frame types.

* chan_pjsip now uses the "from" name in the ast_msg_data structure
(if it exists) to set the "From" header display name on outgoing text
messages.

Change-Id: Idacf5900bfd5f22ab8cd235aa56dfad090d18489

ast_sip_push_task_synchronous() did not necessarily execute the passed in
task under the specified serializer.  If the current thread is any
registered pjsip thread then it would execute the task immediately instead
of under the specified serializer.  Reentrancy issues could result if the
task does not execute with the right serializer.

The original reason ast_sip_push_task_synchronous() checked to see if the
current thread was a registered pjsip thread was because of a deadlock
with masquerades and the channel technology's fixup callback
(ASTERISK_22936).  A subsequent masquerade deadlock fix (ASTERISK_24356)
involving call pickups avoided the original deadlock situation entirely.
The PJSIP channel technology's fixup callback no longer needed to call
ast_sip_push_task_synchronous().

However, there are a few places where this unexpected behavior is still
required to avoid deadlocks.  The pjsip monitor thread executes callbacks
that do calls to ast_sip_push_task_synchronous() that would deadlock if
the task were actually pushed to the specified serializer.  I ran into one
dealing with the pubsub subscriptions where an ao2 destructor called
ast_sip_push_task_synchronous().

* Split ast_sip_push_task_synchronous() into
ast_sip_push_task_wait_servant() and ast_sip_push_task_wait_serializer().
ast_sip_push_task_wait_servant() has the old behavior of
ast_sip_push_task_synchronous().  ast_sip_push_task_wait_serializer() has
the new behavior where the task is always executed by the specified
serializer or a picked serializer if one is not passed in.  Both functions
behave the same if the current thread is not a SIP servant.

* Redirected ast_sip_push_task_synchronous() to
ast_sip_push_task_wait_servant() to preserve API for released branches.

ASTERISK_26806

Change-Id: Id040fa42c0e5972f4c8deef380921461d213b9f3

This change allows chan_pjsip to be given an AST_FRAME_RTCP
containing REMB feedback and pass it to res_rtp_asterisk.
Once res_rtp_asterisk receives the frame a REMB RTCP feedback
packet is constructed with the appropriate contents and sent
to the remote endpoint.

ASTERISK-27776

Change-Id: Ic53f821c1560d8924907ad82c4d9c0bc322b38cd

This change extends the existing AST_FRAME_RTCP frame type to be
able to contain additional RTCP message types, such as feedback
messages. The payload type is contained in the subclass which allows
knowing what is in the frame itself.

The RTCP feedback message type is now handled and REMB[1] messages
are raised with their containing information.

This also fixes a bug where all feedback messages were triggering
video updates instead of just FIR and FUR.

Finally RTCP frames are now passed up through the Asterisk core to
what is handling the channel, mapped appropriately in the case of
bridging, and written to an outgoing stream. Since RTCP frames are
on a per-stream basis this is only done on multistream capable
channels.

[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03

ASTERISK-27758
ASTERISK-26366

Change-Id: I680da0ad8d5059d5e9655d896fb9d92e9da8491e

This removes references that are no longer needed due to automatic
references created by module dependencies.

In addition this removes most calls to ast_module_check as they were
checking modules which are listed as dependencies.

Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e

* Declare 'requires' and 'enhances' text fields on module info structure.
* Rename 'nonoptreq' to 'optional_modules'.
* Update doxygen comments.

Still need to investigate dependencies among modules I cannot compile.

Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf

Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0

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

This patch does three things associated with the initial incoming INVITE
request URI.

1) Add access to the full initial incoming INVITE request URI.

2) We were not setting DNID on incoming PJSIP channels.  The DNID is the
user portion of the initial incoming INVITE Request-URI.  The value is
accessed by reading CALLERID(dnid).

3) Fix CHANNEL(pjsip,target_uri) documentation.

* The initial incoming INVITE request URI is now available using
CHANNEL(pjsip,request_uri).

* Set the DNID on PJSIP channel creation so CALLERID(dnid) can return the
initial incoming INVITE request URI user portion.

* CHANNEL(pjsip,target_uri) now correctly documents that the target URI is
the contact URI.

* Refactored print_escaped_uri() out of channel_read_pjsip() to handle
pjsip_uri_print() error condition when the buffer is too small.

ASTERISK-27478

Change-Id: I512e60d1f162395c946451becb37af3333337b33

* Balanced the session->inv_session refs on answer failure.

Change-Id: I33542d639d37e692cb46550b972a5fcfc3b804b8

Change-Id: I3f9dd3c31bd582e54a30381500077de2319d8cc3

Some endpoints do not like a stream being reused for a new
media stream. The frame/jitterbuffer can rely on underlying
attributes of the media stream in order to order the packets.
When a new stream takes its place without any notice the
buffer can get confused and the media ends up getting dropped.

This change uses the SSRC change to determine that a new source
is reusing an existing stream and then bridge_softmix renegotiates
each participant such that they see a new media stream. This
causes the frame/jitterbuffer to start fresh and work as expected.

ASTERISK-27277

Change-Id: I30ccbdba16ca073d7f31e0e59ab778c153afae07

chan_pjsip_indicate was missing a case for the recently added
AST_CONTROL_STREAM_TOPOLOGY_CHANGED condition and was returning an
error and causing the call to be hung up instead of just ignoring
it.

ASTERISK-27260
Reported by: Daniel Heckl

Change-Id: I4fecbb00a0b8a853da85155065c1a6bddf235e80

When rtp_keepalive is on for a PJSIP endpoint dialing to another
Asterisk instance also using PJSIP, Asterisk will continue to print
warning messages about not being able to send frames of a certain
type. This suppresses that warning message.

Change-Id: I0332a05519d7bda9cacfa26d433909ff1909be67