If during translation a codec could not handle a given frame the translation
core would return NULL, thus not passing along the "missing" frame. Due to this
there was no frame to apply generic plc to, thus rendering it useless.
This patch makes it so the translation core produces an interpolated slin frame
in the cases where an attempt was made to translate to slin, but failed. This
interpolated frame is then passed along and can be used by the generic plc
algorithms to fill in the frame.
ASTERISK-27814 #close
Change-Id: I133d084da87adef913bf2ecc9c9240e3eaf4f40a
Redirect libc allocation functions to use Asterisk functions for
main/ast_expr2f.c and res/ael/ael_lex.c. This will resolve errors
produced by astmm.h when these files are regenerated, though other
issues still remain.
ASTERISK~27813
Change-Id: I7263e9e4217a17bde4ffaa2087a8f8aeb2a8588c
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
Replaces the never used opaque data array.
Updated stream tests to include get/set metadata and
stream clone with metadata.
Added stream metadata dump to "core show channel"
Change-Id: Id7473aa4b374d7ab53046c20e321037ba9a56863
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
Use of extended stringfields is a temporary mechanism to avoid ABI
breakage in released branches without resorting to more inconvienient
methods.
* Collect existing extended stringfields into the parent stringfield
section of the struct.
Change-Id: I8d46d037801b4518837c3ea4b6df95ceadc9436b
There is a problem when an INVITE-with-Replaces transfer targets a channel
in a ConfBridge. The transfer will unconditionally swap out the
ConfBridge channel. Unfortunately, the ConfBridge state will not be aware
of this change. Unexpected behavior will happen as a result since
ConfBridge channels currently can only be replaced by a masquerade and not
normal bridge channel moves.
* We just need to pretend that the channel isn't in a bridge (like other
transfer methods already do) so the transfer channel will masquerade into
the ConfBridge channel.
Change-Id: I209beb0e748fa4f4b92a576f36afa8f495ba4c82
This change adds a configuration option to app_confbridge which can be
used to set the interval at which we will send a combined REMB (remote
estimated maximum bitrate) frame to sources of video. The bridging API
has also been extended slightly to allow setting this so bridge_softmix
can use it.
ASTERISK-27786
Change-Id: I0e49eae60f369c86434414f3cb8278709c793c82
Adds a data buffer with a configurable size that can store different
kinds of packets (like RTP packets for retransmission). Given a number
it will store a data packet at that position relative to the others.
Given a number it will retrieve the given data packet if it is present.
This is purposely a storage of arbitrary things so it can be used not
just for RTP packets but also Asterisk frames in the future if needed.
The API does not internally use a lock, so it will be up to the user of
the API to properly protect the data buffer.
For more information, refer to the wiki page:
https://wiki.asterisk.org/wiki/display/AST/WebRTC+User+Experience+Improvements
Change-Id: Iff13c5d4795d52356959fe2a57360cd57dfade07
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
Setting optind = 0 is forced to 1 in glibc implementation, but
causes option parsing to be flawed in other implementations, for
example on FreeBSD.
ASTERISK-27773 #close
Change-Id: Ia548e69f8302e9754dbbedb6bc451c0700c66f61
This creates a separate source to 'own' symbols related to options.h and
paths.h. This significantly reduces the number of exports created by
main/asterisk.o. This change is required to eventually be able to
link unmodified Asterisk sources to utilities and/or stand-alone tests.
ASTERISK~26245
Change-Id: I5cf184f4757f9363b80c9e678bdc35c477122380
* dahdi_chan_name
* dahdi_chan_name_len
* dahdi_chan_mode
* __manager_event
* dialed_interface_info
Added comment about __progname and environ being needed for FreeBSD to
prevent accidental removal in the future.
Change-Id: I3ae026bc541cd9cb572be2ffa95fc359547642b5
If the two formats on a channel are equal, we don't transcode and since
the generic plc needs slin to work, it doesn't get invoked.
* A new configuration option "genericplc_on_equal_codecs" was added
to the "plc" section of codecs.conf to allow generic packet loss
concealment even if no transcoding was originally needed.
Transcoding via SLIN is forced in this case.
ASTERISK-27743
Change-Id: I0577026a179dea34232e63123254b4e0508378f4
