Although there are 10 debugs levels, over time,
many current debug calls have come to use
inappropriately low debug levels. In particular,
a select few debug calls (currently all debug 1)
can result in thousands of debug messages per minute
for a single call.
This can adds a lot of noise to core debug
which dilutes the value in having different
debug levels in the first place, as these
log messages are from the core internals are
are better suited for higher debug levels.
Some debugs levels are thus adjusted so that
debug level 1 is not inappropriately overloaded
with these extremely high-volume and general
debug messages.
ASTERISK-29897 #close
Change-Id: I55a71598993552d3d64a401a35ee99474770d4b4
Adds missing documentation for some channel,
bridge, and queue events.
ASTERISK-24427
ASTERISK-29515
Change-Id: I92b06b88c8cadc0155f95ebe3e870b3e795a8c64
Adds tech-agnostic support for MF signaling by adding
MF sender and receiver applications as well as Dial
integration.
ASTERISK-29496-mf #do-not-close
Change-Id: I61962b359b8ec4cfd05df877ddf9f5b8f71927a4
We know that passing a NULL or empty argument to
ast_channel_get_by_name() will never result in a matching channel and
will always result in an error being emitted, so just short-circuit
out in that case.
ASTERISK-28219 #close
Change-Id: I88eadc748e9c6996fc17467b0a05881bbfd00bce
* Initialize some variables that are never used anyway.
* Use valid pointers instead of integers cast to void pointers when
calling pthread_setspecific().
ASTERISK-29711 #close
ASTERISK-29713 #close
Change-Id: I8728cd6f2f4b28e0e48113c5da450b768c2a6683
Up until now, all of the logic used to translate
arguments to the Say applications has been
directly coupled to playback, preventing other
modules from using this logic.
This refactors code in say.c and adds a SAYFILES
function that can be used to retrieve the file
names that would be played. These can then be
used in other applications or for other purposes.
Additionally, a SayMoney application and a SayOrdinal
application are added. Both SayOrdinal and SayNumber
are also expanded to support integers greater than
one billion.
ASTERISK-29531
Change-Id: If9718c89353b8e153d84add3cc4637b79585db19
When using the Busy() and Congestion() applications the
function ast_safe_sleep is used by wait_for_hangup to safely
wait on the channel. This function may send silence if Asterisk
is configured to do so using the transmit_silence option.
In a scenario where an answered channel dials a Local channel
either directly or through call forwarding and the Busy()
or Congestion() dialplan applications were executed with the
transmit_silence option enabled the busy or congestion
tone would not be heard.
This is because inband generation of tones (such as busy
and congestion) is stopped when other audio is sent to
the channel they are being played to. In the given
scenario the transmit_silence option would result in
silence being sent to the channel, thus stopping the
inband generation.
This change adds a variant of ast_safe_sleep which can be
used when silence should not be played to the channel. The
wait_for_hangup function has been updated to use this
resulting in the tones being generated as expected.
ASTERISK-29485
Change-Id: I066bfc987a3ad6f0ccc88e0af4cd63f6a4729133
Although Asterisk can receive and propogate flash events, it currently
provides no mechanism for doing anything with them itself.
This AMI event allows flash events to be processed by Asterisk.
Additionally, AST_CONTROL_FLASH is included in a switch statement
in channel.c to avoid throwing a warning when we shouldn't.
ASTERISK-29380
Change-Id: Ie17ffe65086e0282c88542e38eed6a461ec79e81
There exists an inconsistency with framehook usage
such that it is only on reads that the frame should
be freed, not on writes as well.
ASTERISK-29071
Change-Id: I5ef918ebe4debac8a469e8d43bf9d6b673e8e472
A frame suppression API exists as part of channels
which allows audio frames to or from a channel to
be dropped. The MuteAudio AMI action uses this
API to perform its job.
This API uses a framehook to intercept flowing
audio and drop it when appropriate. It is the
responsibility of the framehook to free the
frame it is given if it changes the frame. The
suppression API failed to do this resulting in
a leak of audio frames.
This change adds the freeing of these frames.
ASTERISK-29071
Change-Id: Ie50acd454d672d36af914050c327d2e120d8ba7b
When a Transfer/REFER is executed, TRANSFERSTATUSPROTOCOL variable is
0 when no protocl specific error
SIP example of failure, 3xx-6xx for the SIP error code received
This allows applications to perform actions based on the failure
reason.
ASTERISK-29252 #close
Reported-by: Dan Cropp
Change-Id: Ia6a94784b4925628af122409cdd733c9f29abfc4
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
This patch allows a user of AMI to now specify the type of message
content contained within by setting the 'Content-Type' parameter.
Note, the AMI version has been bumped for this change.
ASTERISK-28945 #close
Change-Id: Ibb5315702532c6b954e1498beddc8855fabdf4bb
Add a new "masquarade" channel event, and use it in app_queue to track unique id's.
Testcase is submitted as https://gerrit.asterisk.org/c/testsuite/+/14210
ASTERISK-28829 #close
ASTERISK-25844 #close
Change-Id: Ifc5f9f9fd70903f3c6e49738d3bc632b085d2df6
If a frame handling routine returns a list of frames (vs. a single frame)
those frames are never passed to a tech's write_stream handler even if one is
available. For instance, if a codec translation occurred and that codec
returned multiple frames then those particular frames were always only sent
to the tech's "write" handler. If that tech (pjsip for example) was stream
capable then those frames were essentially ignored. Thus resulting in bad
audio.
This patch makes it so the "write_stream" handler is appropriately called
for all cases, and for all frames if available.
ASTERISK-28795 #close
Change-Id: I868faea0b73a07ed5a32c2b05bb9cf4b586f739d
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
The problem is essentially the same as in ASTERISK~28245. Besides
the direct media scenario we have an additional scenario where a
special client is involved. This device mutes audio by default in
transmit direction (no rtp frames) and activates audio only by a
foot switch. In this situation dtmf input (pin for conferences,
transfer features codes , etc) using SIP INFO mode is not
understood properly especially when SIP INFO messages are sent
quickly.
This patch ensures that SIP INFO frames are properly queued and
processed in the above scenario. The patch also corrects situations
where successive dtmf events are received quicker than the
signalled event duration (plus minimum gap/pause) allows, i.e. DTMF
events have to be buffered in the ast channel read queue and
emulation has to be processed asynchronously at slower speed.
Reported by: Thomas Arimont
patches:
trigger_dtmf_emulation.patch submitted by Thomas Arimont (license 5525)
Change-Id: I309bf61dd065c9978c8e48f5b9a936ab47de64c2
There were still a few places in the code that could overflow when "packing"
a json object with a value outside the base type integer's range. For instance:
unsigned int value = INT_MAX + 1
ast_json_pack("{s: i}", value);
would result in a negative number being "packed". In those situations this patch
alters those values to a ast_json_int_t, which widens the value up to a long or
long long.
ASTERISK-28480
Change-Id: Ied530780d83e6f1772adba0e28d8938ef30c49a1
Added RINGTIME, RINGTIME_MS, PROGRESSTIME, PROGRESSTIME_MS variables filled
at the earliest received PROGRESS or RINGING.
Added millisecond versions of DIALEDTIME and ANSWEREDTIME.
Added millisecond versions of ast_channel_get_up_time and
ast_channel_get_duration in channel.c.
ASTERISK-28363
Change-Id: If95f1a7d8c4acbac740037de0c6e3109ff6620b1
If the Monitor is started with the i option the read_stream will be
NULL. One code path in channel.c checks if write_stream is set but than
uses read_stream instead causing a segfault.
ASTERISK-28249
Change-Id: I1bae9126537be54895c7fea2d08dd9488d8cc525
During Bridging of two channels if masquerade operation is performed on a
channel (clone channel) which was created with endpoint details
(ast_channel_alloc_with_endpoint()) and the original channel which is created
without endpoint details (ast_channel_alloc()) then both the channels must
exchange their endpoint details or else after masquerade when clone channel
is being destroyed the endpoint cleanup callbacks will be destroyed too and
after call completion unique_id of original channel will still be there in
ast_endpoint structure's channel_ids container.
ASTERISK-28197
Change-Id: Ied0451f378a3f2a36acc8c0984959a69895efa17
Replace usage of ao2_container_alloc with ao2_container_alloc_hash or
ao2_container_alloc_list.
ao2_container_alloc is now restricted to modules only and is being
removed from Asterisk 17.
Change-Id: I0907d78bc66efc775672df37c8faad00f2f6c088
These macros have been documented as legacy for a long time but are
still used in new code because they exist. Remove all references to:
* ao2_container_alloc_options
* ao2_t_container_alloc_options
* ao2_t_container_alloc
These macro's are still available for use but only in modules. Only
ao2_container_alloc remains due to it's use in over 100 places.
Change-Id: I1a26258b5bf3deb081aaeed11a0baa175c933c7a
ast_sendtext_data() would create an incorrect T.140 text frame which
length include the null terminator byte. It causes ultimately RTP
packets to be send with this trailing 0. The proposed fix just set the
correct length to the text frame
ASTERISK-28089
Reported by: Emmanuel BUU
Tested by: Emmanuel BUU
Change-Id: I7ab1b9ed1e21683b2b667ea0a59d9aba3c77dd96
does_id_conflict() was passing a pointer to an int to a callback
that expected a pointer to a size_t.
Found by the Address Sanitizer.
Change-Id: I0ff542067eef63a14a60301654d65d34fe2ad503
Generators provide such functionality as tone generation or
silence generation. RTCP frames provide RTCP information and
should not stop generators from operating.
ASTERISK-28005
Change-Id: Ieadada07b068a7aa426e8763f1b73a18e1ac34a9
The AMI action was directly sending the text to the channel driver.
However, this makes two threads attempt to handle media and runs afowl of
CHECK_BLOCKING.
* Queue a read action to make the channel's media handling thread actually
send the text message. This changes the AMI actions success/fail response
to just mean the text was queued to be sent not that the text actually got
sent. The channel driver may not even support sending text messages.
ASTERISK-27943
Change-Id: I9dce343d8fa634ba5a416a1326d8a6340f98c379
In addition to text/* content types, incoming_in_dialog_request now
accepts application/* content types.
Also fixed a length issue when copying the body text. It was one
character short.
ASTERISK-27942
Change-Id: I4e54d8cc6158dc47eb8fdd6ba0108c6fd53f2818
* changes:
channel.c: Make CHECK_BLOCKING() save thread LWP id for messages.
channel.c: Fix usage of CHECK_BLOCKING()
autoservice: Don't start channel autoservice if the thread is a user interface.
There can be one and only one thread handling a channel's media at a time.
Otherwise, we don't know which thread is going to handle the media frames.
ASTERISK-27625
Change-Id: Ia341f1a6f4d54f2022261abec9021fe5b2eb4905
The CHECK_BLOCKING() macro is used to indicate if a channel's handling
thread is about to do a blocking operation (poll, read, or write) of
media. A few operations such as ast_queue_frame(), soft hangup, and
masquerades use the indication to wake up the blocked thread to reevaluate
what is going on.
ASTERISK-27625
Change-Id: I4dfc33e01e60627d962efa29d0a4244cf151a84d
There was no real reason to limit the conteny type to text/plain other
than that's what it was limited to before. Now any text/* content
type will be allowed for channel drivers that don't support enhanced
messaging and any type will be allowed for channel drivers that do
support enhanced messaging.
Change-Id: I94a90cfee98b4bc8e22aa5c0b6afb7b862f979d9
__ast_channel_alloc_ap() had a failure exit path that hadn't setup the fd
descriptors to -1 yet. The destructor would then attempt to close these
fd's that had never been opened.
Change-Id: Icf21093f36c60781e8cf6ee9d586536302af33e3
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 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
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
* acl (named_acl.c)
* cdr
* cel
* ccss
* dnsmgr
* dsp
* enum
* extconfig (config.c)
* features
* http
* indications
* logger
* manager
* plc
* sounds
* udptl
These modules are now loaded at appropriate time by the module loader.
Unlike loadable modules these use AST_MODULE_LOAD_FAILURE on error so
the module loader will abort startup on failure of these modules.
Some of these modules are still initialized or shutdown from outside the
module loader. logger.c is initialized very early and shutdown very
late, manager.c is initialized by the module loader but is shutdown by
the Asterisk core (too much uses it without holding references).
Change-Id: I371a9a45064f20026c492623ea8062d02a1ab97f
