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

When (v)asprintf() fails, the state of the allocated buffer is undefined.
The library had better not leave an allocated buffer as a result or no one
will know to free it.  The most likely way it can return failure is for an
allocation failure.  If the printf conversion fails then you actually have
a threading problem which is much worse because another thread modified
the parameter values.

* Made __ast_asprintf()/__ast_vasprintf() set the returned buffer to NULL
on failure.  That is much more useful than either an uninitialized pointer
or a pointer that has already been freed.  Many uses won't have to check
for failure to ensure that the buffer won't be double freed or prevent an
attempt to free an uninitialized pointer.

* stasis.c: Fixed memory leak in multi_object_blob_to_ami() allocated by
ast_asprintf().

* ari/resource_bridges.c:ari_bridges_play_helper(): Remove assignment to
the wrong thing which is now not needed even if assigning to the right
thing.

Change-Id: Ib5252fb8850ecf0f78ed0ee2ca0796bda7e91c23

This adds menuselect dependencies for modules that use symbols of other
modules.

ASTERISK-27390

Change-Id: Ia2d2849f5b87a72af7324a82edc3f283eafb5385

As channels join and leave an SFU the bridge_softmix module
needs to renegotiate to add and remove their streams from
the other participants. Previously this was done by constructing
the ideal stream topology every time but in the case of leave
this was incomplete.

This change makes it so bridge_softmix keeps an ideal stream
topology for each channel and uses it when making changes. This
ensures that when we request a renegotiation we are always
certain that we are aiming for the best stream topology
possible. In the case of a channel leaving this ensures that
we try to have an existing participant fill their place if
a participant has a fixed limit on the maximum number of video
streams they allow.

ASTERISK-27354

Change-Id: I58070f421ddeadd2844a33b869b052630cf2e514

When making channels compatible the bridge_simple module
will renegotiate one to better match the other. Some
endpoints incorrectly terminate the call if this process
fails.

To better handle this scenario the audio streams present
on the new requested topology will include any existing
negotiated formats that happen to exist on the first
valid audio stream. This ensures formats are persent that
are known to be acceptable to the remote endpoint.

ASTERISK-27259

Change-Id: I8fc0cc03e8bcfd0be8302f13b9f32d8268977f43

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

When two channels were early bridged in a native_rtp bridge, the RTP description
on one side was not updated when the other side answered.
This patch forbids non-answered channels to enter a native_rtp bridge, and
triggers a bridge reconfiguration when an ANSWER frame is received.

ASTERISK-27257

Change-Id: If1aaee1b4ed9658a1aa91ab715ee0a6413b878df

* Fix framehook to test frame type for control frame.
* Made framehook exit early if frame type is not a control frame.
* Eliminated RAII_VAR in framehook.
* Use switch instead of else-if ladder for control frame handling.

Change-Id: Ia555fc3600bd85470e3c0141147dbe3ad07c1d18

* Fix deadlock in
bridge_softmix.c:softmix_bridge_stream_topology_changed() between
bridge_channel and channel locks.

* The new bridge technology topology change callbacks must be called with
the bridge locked.  The callback references the bridge channel list, the
bridge technology could change, and the bridge stream mapping is updated.

ASTERISK-27212

Change-Id: Ide4360ab853607e738ad471721af3f561ddd83be

Change-Id: I13026cd90954e0265eab94a0faf635a3e11f0e35

Change-Id: I26238df2ff0d0f6dfe95c3aa35da588f1ee71727

This change fixes a few locking issues and some video misrouting.

1. When accessing the stream topology of a channel the channel lock
must be held to guarantee the topology remains valid.

2. When a channel was joined to a bridge the bridge specific
implementation for stream mapping was not invoked, causing video
to be misrouted for a brief period of time.

ASTERISK-27182

Change-Id: I5d2f779248b84d41c5bb3896bf22ba324b336b03

This change does a few things to improve packet loss and renegotiation:

1. On outgoing RTP streams we will now properly reflect out of order
packets and packet loss in the sequence number. This allows the
remote jitterbuffer to better reorder things.

2. Video updates can now be discarded for a period of time
after one has been sent to prevent flooding of clients.

3. For declined and removed streams we will now release any
media session resources associated with them. This was not
previously done and caused an issue where old state was being
used for a new stream.

4. RTP bundling was not actually removing bundled RTP instances
from the parent. This has been resolved by removing based on
the RTP instance itself and not the SSRC.

5. The code did not properly handle explicitly unbundling an
RTP instance from its parent. This now works as expected.

ASTERISK-27143

Change-Id: Ibd91362f0e4990b6129638e712bc8adf0899fd45

When a participant leaves a bridge while operating in SFU mode
their respective stream on every other participant needs to be
removed. Leaving the stream out of the new topology results in
every stream after it being moved and reordered. This causes
problems with clients. Instead simply mark the stream as removed
which leaves it in place in the SDP and doesn't reorder or touch
any other streams.

ASTERISK-27136

Change-Id: I4b3f840adcdf69b83842b0d8a737665ba0ef9cb1

Streams are never truly removed in SDP, they still occupy
a location within the SDP. This location can be reused by
another stream if it so chooses.

This change takes advantage of this such that if a new stream
is needing to be added for a new participant any removed streams
are instead replaced first. This reduces the size of the SDP
and the number of streams.

ASTERISK-27134

Change-Id: I95cdcfd55cf47e02ea52abb5d94008db3fb68b1d