app_confbridge now has the ability to set the estimated bitrate on an
SFU bridge.  To use it, set a bridge profile's remb_behavior to "force"
and set remb_estimated_bitrate to a rate in bits per second.  The
remb_estimated_bitrate parameter is ignored if remb_behavior is something
other than "force".

Change-Id: Idce6464ff014a37ea3b82944452e56cc4d75ab0a

When a channel joins a bridge, we do topology change requests on all
existing channels to add the new participant to them.  However the
announcer channel will return an error because it doesn't support
topology in the first place.  Unfortunately, there doesn't seem to be a
reliable way to tell if the error is expected or not so the error is
ignored for all channels.  If the request fails on a "real" channel,
that channel just won't get the new participant's video.

Change-Id: Ic95db4683f27d224c1869fe887795d6b9fdea4f0

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

When both Asterisk and a UA send re-invites at the same time, both
send 491 "Transaction in progress" responses to each other and back
off a specified amount of time before retrying. When Asterisk
prepares to send its re-invite, it sets up the session's pending
media state with the new topology it wants, then sends the
re-invite.  Unfortunately, when it received the re-invite from the
UA, it partially processed the media in the re-invite and reset
the pending media state before sending the 491 losing the state it
set in its own re-invite.

Asterisk also was not tracking re-invites received while an existing
re-invite was queued resulting in sending stale SDP with missing
or duplicated streams, or no re-invite at all because we erroneously
determined that a re-invite wasn't needed.

There was also an issue in bridge_softmix where we were using a stream
from the wrong topology to determine if a stream was added.  This also
caused us to erroneously determine that a re-invite wasn't needed.

Regardless of how the delayed re-invite was triggered, we need to
reconcile the topology that was active at the time the delayed
request was queued, the pending topology of the queued request,
and the topology currently active on the session.  To do this we
need a topology resolver AND we need to make stream named unique
so we can accurately tell what a stream has been added or removed
and if we can re-use a slot in the topology.

Summary of changes:

 * bridge_softmix:
   * We no longer reset the stream name to "removed" in
     remove_all_original_streams().  That was causing  multiple streams
     to have the same name and wrecked the checks for duplicate streams.

   * softmix_bridge_stream_sources_update() was checking the old_stream
     to see if it had the softmix prefix and not considering the stream
     as "new" if it did.  If the stream in that slot has something in it
     because another re-invite happened, then that slot in old might
     have a softmix stream but the same stream in new might actually
     be a new one.  Now we check the new_stream's name instead of
     the old_stream's.

 * stream:
   * Instead of using plain media type name ("audio", "video", etc) as
     the default stream name, we now append the stream position to it
     to make it unique.  We need to do this so we can distinguish multiple
     streams of the same type from each other.

   * When we set a stream's state to REMOVED, we no longer reset its
     name to "removed" or destroy its metadata.  Again, we need to
     do this so we can distinguish multiple streams of the same
     type from each other.

 * res_pjsip_session:
   * Added resolve_refresh_media_states() that takes in 3 media states
     and creates an up-to-date pending media state that includes the changes
     that might have happened while a delayed session refresh was in the
     delayed queue.

   * Added is_media_state_valid() that checks the consistency of
     a media state and returns a true/false value. A valid state has:
     * The same number of stream entries as media session entries.
         Some media session entries can be NULL however.
     * No duplicate streams.
     * A valid stream for each non-NULL media session.
     * A stream that matches each media session's stream_num
       and media type.

   * Updated handle_incoming_sdp() to set the stream name to include the
     stream position number in the name to make it unique.

   * Updated the ast_sip_session_delayed_request structure to include both
     the pending and active media states and updated the associated delay
     functions to process them.

   * Updated sip_session_refresh() to accept both the pending and active
     media states that were in effect when the request was originally queued
     and to pass them on should the request need to be delayed again.

   * Updated sip_session_refresh() to call resolve_refresh_media_states()
     and substitute its results for the pending state passed in.

   * Updated sip_session_refresh() with additional debugging.

   * Updated session_reinvite_on_rx_request() to simply return PJ_FALSE
     to pjproject if a transaction is in progress.  This stops us from
     creating a partial pending media state that would be invalid later on.

   * Updated reschedule_reinvite() to clone both the current pending and
     active media states and pass them to delay_request() so the resolver
     can tell what the original intention of the re-invite was.

   * Added a large unit test for the resolver.

ASTERISK-29014

Change-Id: Id3440972943c611a15f652c6c569fa0e4536bfcb

There are three states that an old stream can be in to allow
becoming a source stream in a new stream:

1. Removed
2. Inactive
3. Sendonly

This change adds the two missing ones, inactive and sendonly,
so if a stream transitions from those to a state where they are
providing video to Asterisk we properly re-negotiate the other
participants.

ASTERISK-28944

Change-Id: Id8256b9b254b403411586284bbaedbf50452de01

When bridging channels we were trying to match the audio
formats of both sides in combination with the configured
formats. While this is allowed in SDP in practice this
causes extra reinvites and problems. This change ensures
that audio streams use the formats of the first existing
active audio stream. It is only when other stream types
(like video) exist that this will result in re-negotiation
occurring for those streams only.

ASTERISK-28871

Change-Id: I22f5a3e7db29e00c165e74d05d10856f6086fe47

When receiving audio from a channel we determine if it
is talking or silence based on a threshold value. If
this threshold is met we always mix the audio into the
conference bridge. If this threshold is not met we also
mix the audio into the conference bridge UNLESS the
drop silence option is enabled.

The code that removed the audio from the mixed frame
assumed that it was always not present if it did not
meet the threshold to be considered talking. This is
incorrect. If it has been stated that the audio was
mixed into the mixed frame then it has been mixed into
the mixed frame. By not removing audio that was
considered non-talking it was possible for a channel
to receive a slight echo of audio of itself at times.

This change ensures that the audio is always removed
from the mixed frame going back to the channel so it
no longer receives the slight echo.

ASTERISK-28898

Change-Id: I7b1b582cc1bcdb318ecc60c9d2e3d87ae31d55cb

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

This change adds support to bridge_softmix to allow the addition
and removal of additional video source streams. When such a change
occurs each participant is renegotiated as needed to reflect the
update. If another video source is added then each participant
gets another source. If a video source is removed then it is
removed from each participant. This functionality allows you to
have both your webcam and screenshare providing video if you
desire, or even more streams. Mapping has been changed to use
the topology index on the source channel as a unique identifier
for outgoing participant streams, this will never change and
provides an easy way to establish the mapping.

The bridge_simple and bridge_native_rtp modules have also been
updated to renegotiate when the stream topology of a party changes
allowing the same behavior to occur as added to bridge_softmix.
If a screen share is added then the opposite party is renegotiated.
If that screen share is removed then the opposite party is
renegotiated again.

Some additional fixes are also included in here. Stream state is
now conveyed in SDP so sendonly/recvonly/inactive streams can
be requested. Removed streams now also remove previous state
from themselves so consumers don't get confused.

ASTERISK-28733

Change-Id: I93f41fb41b85646bef71408111c17ccea30cb0c5

ConfBridge has the ability to move between different sample
rates for mixing the conference bridge. Up until now there has
only been the ability to set the conference bridge to mix at
a specific sample rate, or to let it move between sample rates
as necessary. This change adds the ability to configure a
conference bridge with a maximum sample rate so it can move
between sample rates but only up to the configured maximum.

ASTERISK-28658

Change-Id: Idff80896ccfb8a58a816e4ce9ac4ebde785963ee

During capabilities selection (joint capabilities of us and peer,
configured capability for this peer, or general configured
capabilities), if sip_new() does not keep framing information,
then directmedia activation will fail for any framing different
from default framing.

ASTERISK-28637

Change-Id: I99257502788653c2816fc991cac7946453082466

MOH continues to play to a channel if that channel was on hold prior to
entering a softmix bridge. MOH will not stop even if the original "holder"
attempts an unhold.

For the most part a softmix bridge ignores holds, so a participating channel
shouldn't join while on hold. This patch checks to see if the channel joining
the softmix bridge is currently on hold. If so then it indicates an unhold.

ASTERISK-28618

Change-Id: I66ccd4efc80f5b4c3dd68186b379eb442916392b

When producing a combined REMB value the normal behavior
is to have a REMB value which is unique for each sender
based on all of their receivers. This can result in one
sender having low bitrate while all the rest are high.

This change adds "all" variants which produces a bridge
level REMB value instead. All REMB reports are combined
together into a single REMB value that is the same for
each sender.

ASTERISK-28401

Change-Id: I883e6cc26003b497c8180b346111c79a131ba88c

REMB's exponent is 6-bits (0..63) and has a mantissa of 18-bits. We were using
an unsigned integer to represent the bitrate. However, that type is not large
enough to hold all potential bitrate values. If the bitrate is large enough
bits were being shifted off the "front" of the mantissa, which caused the
wrong value to be sent to the browser.

This patch makes it so it now uses a float type to hold the bitrate. Using a
float allows for all bitrate values to be correctly represented.

ASTERISK-28255

Change-Id: Ice00fdd16693b16b41230664be5d9f0e465b239e

To avoid the stream name collide if there're more than one video track
in one client. If client has multi video tracks, the name of ast_stream
which represents each video track may be the same. Use the MSID:LABEL
here because it's identifiable.

ASTERISK-28196 #close
Reported-by: xiemchen

Change-Id: Ib62b2886e8d3a30e481d94616b0ceaeab68a870b

This is how features behaved up through Asterisk 11, but was changed
when the new bridging framework was implemented in Asterisk 12.

Reported by rrittgarn in #asterisk.

Change-Id: I72cf86223947a8118c75f46e2c603dbc11e3125b

ASTERISK-28110 #close

Change-Id: Ic64b8fc6a140a93fbdb2f97550a40d0ff334e607

Adding the "label" attribute used for participant info correlation
was previously done in app_confbridge but it wasn't working
correctly because it didn't have knowledge about which video
streams belonged to which channel.  Only bridge_softmix has that
data so now it's set when the bridge topology is changed.

ASTERISK-28107

Change-Id: Ieddeca5799d710cad083af3fcc3e677fa2a2a499

ASTERISK-27939

Change-Id: Ice5640e08385a64a0a6555deaccd91e86bca154f

* Fix several instances where we were bumping a ref in the parameter and
then unrefing the object if it failed.  The way the AST_VECTOR_APPEND()
and AST_VECTOR_REPLACE() macros are implemented means if it fails the new
value was never evaluated.

Change-Id: I2847872a455b11ea7e5b7ce697c0a455a1d0ac9a

Made release the media_types vector in
softmix_bridge_stream_topology_changed().

Change-Id: Ide3f47e379b614879220dfeeb13843f9f2b177b5

The stream topology has no lock of its own resulting in
another lock protecting it in some way (for example the
channel lock). If multiple channels are being juggled at
the same time this can be problematic. This change makes
the topology a reference counted object instead which
guarantees it will remain valid even without the channel
lock being held.

Change-Id: I4f4d3dd856a033ed55fe218c3a4fab364afedb03

When an externally initiated renegotiation occurred it was
possible for video streams to be incorrectly remapped,
resulting in no video flowing to some receivers.

This change ensures that only the video source sets up
mappings and also that removed streams do not have mappings
set up.

Change-Id: Iab05f2254df3606670774844bb0935f833d3a9b0

This change fixes a bug where a REMB collector may be
freed twice, and also tweaks REMB combining such that if
there is no bitrate from anyone (or there are no sources)
we report 0 instead of using an old bitrate.

ASTERISK-27804

Change-Id: Ia9dc9c150043890ee7ff85e9cdec007f1a77fcfd

ASTERISK-27820

Change-Id: I310896143e94d65da1c2be3bb448204a8b86d557

This change adds the ability for multiple REMB reports in
bridge_softmix to be combined according to a configured
behavior into a single report. This single report is sent
back to the sender of video, which adjusts the encoding bitrate
to be at or below the bitrate of the report. The available
behaviors are: lowest, highest, and average. Lowest uses the
lowest received bitrate. Highest uses the highest received
bitrate. Average goes through the received bitrates adding
them to the previous average and creates a new average.

Other behaviors can be added in the future and the existing
average one may be adjusted, but this provides the foundation
to do so.

Support for configuring which behavior to use has been
added to app_confbridge.

ASTERISK-27804

Change-Id: I9eafe4e7c1f72d67074a8d6acb26bfcf19322b66

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

This patch clears the talking flag from the channel (if already set), and
notifies listeners when that channel is put on hold. Note however, if the
endpoint continues to send audio frames and these are received by the bridge
then that channel will be put back into a "talking" state even though they
are on hold.

ASTERISK-27755 #close

Change-Id: I930e16c4662810f9f02043d69062f88173c5e2ef

The handling of stream topologies was not protected by channel locks in
simple_bridge_request_stream_topology_change().

* Fixed topology handling to be protected by channel locks where needed in
simple_bridge_request_stream_topology_change().

ASTERISK-27692

Change-Id: Ica5d78a6c7ecf4f0b95fb16de28d3889b32c4776

Currently in app_confbridge if someone mutes a channel while that channel
is talking, the talk detection code is suspended while the channel is
muted.  As far an an external observer is concerned, the muted channel's
talk status is still "talking" even though the channel is not contributing
audio to the conference bridge.  When the channel is later unmuted, it
takes the usual 'dsp_silence_threshold' option time to clear the talking
status even though the channel may have stopped talking while the channel
was muted.

* In bridge_softmix.c, clear the talking status and report talking stopped
if the channel was talking when the channel is muted.  When the channel is
unmuted and the channel is still talking then report the channel as
talking since it is contributing audio to the bridge again.

ASTERISK-27647

Change-Id: Ie4fdbc05a0bc7343c2972bab012e2567917b3d4e

The dsp_talking_threshold does not represent time in milliseconds.  It
represents the average magnitude per sample in the audio packets.  This is
what the DSP uses to determine if a packet is silence or talking/noise.

Change-Id: If6f939c100eb92a5ac6c21236559018eeaf58443

I've audited all modules that include any header which includes
asterisk/optional_api.h.  All modules which use OPTIONAL_API now declare
those dependencies in AST_MODULE_INFO using requires or optional_modules
as appropriate.

In addition ARI dependency declarations have been reworked.  Instead of
declaring additional required modules in res/ari/resource_*.c we now add
them to an optional array "requiresModules" in api-docs for each module.
This allows the AST_MODULE_INFO dependencies to include those missing
modules.

Change-Id: Ia0c70571f5566784f63605e78e1ceccb4f79c606

* validate_stream: zero result from ast_format_cap_identical indicates
  they are not identical, rather than non-zero indicating an error.
* validate_original_streams: use num_streams instead of
  ARRAY_LEN(params).
* Fix declaration of alice_dest_stream and bob_dest_stream.

Change-Id: I6b1dd8bed10439d3c7406f033eb1896b6c419147

Found as a result of the function being passed an uninitalized variable by
clang.

ASTERISK-27550

Change-Id: I8af3bd84656b685a956d498459f8db3613f68954

If two channels enter different native rtp bridges at the same time it is
possible that the framehook interface data pointer can be corrupted
because the struct variable was declared static.

* Fixed the reentrancy corruption by changing the framehook interface
struct static variable to a stack local variable.

* Moved the hook.data assignment outside of the channel lock.  It did not
need the lock's protection.  It probably was giving a false sense of
security.

The testsuite
channels/pjsip/basic_calls/two_parties/nominal/alice_initiated/bob_hangs_up
test caught this with MALLOC_DEBUG and DO_CRASH enabled.

Change-Id: If9e35b97d19209b0f984941c1d8eb5f7c55eea91

Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0

The return value of remove_destination_streams() now means we removed a
stream from the topology by making it a dead stream.  Now we won't try to
request a topology change if we didn't remove any streams.

Change-Id: Icd91571d856a1d04299a24c411e325c1d9d5c61d

* Made is_video_source() and is_video_dest() not match dead streams.

* Optimized is_video_dest() to reduce duplicated code.

Change-Id: I4e7ab762c7ee98395e78e6516399f57a2609b9a1

Change-Id: Ifaf3e93b398595d21d07f535330fef77ff15a80c

This appeared in my audit of ast_stream_topology_set_stream callers
not checking for errors but in this situation the call cannot fail.
Add comment so this can be ignored in the future.

Change-Id: I91d25704859efbe50b8b82cfe1cd3c40ba177c9f