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
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
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
GCC documentation states that when __attribute__((malloc)) is used it
should not return storage which contains any valid pointers. It
specifically mentions that realloc functions should not have the malloc
attribute, but this also means that complex initializers which could
contain initialized pointers should not use this attribute.
Change-Id: If507f33ffb3ca3b83b702196eb0e8215d27fc7d2
Clear channel flag AST_FLAG_END_DTMF_ONLY in ast_waitfordigit_full when
ast_read returns NULL.
ASTERISK-27100 #close
Change-Id: Id3039e9a4e74e0cb359f636c9fd0c9740ebf7d9d
When a stasis channel is stolen by another app, the control
structure is unreffed but never unlinked from the app_controls
container. This causes the channel reference to leak.
Added OBJ_UNLINK to the callback in channel_stolen_cb.
Also added some additional channel lifecycle debug messages to
channel.c.
ASTERISK-27059 #close
Repoorted-by: George Joseph
Change-Id: Ib820936cd49453f20156971785e7f4f182c56e14
The ast_channel_suppress function wrongly decremented the
reference count of the underlying structure used to keep
track of what should be suppressed on a channel if the
function was called multiple times on the same channel.
This change cleans up the reference counting a bit so
this no longer occurs.
ASTERISK-27016
Change-Id: I2eed4077cb4916e6626f9f120b63b963acc5c136
ASTERISK-26419 introduced a bug when calling ast_audiohook_write_list in
ast_write. It would free the frame given to ast_write if the frame returned
by ast_audiohook_write_list was different than the given one. The frame
give to ast_write should never be freed within that function. It is the
caller's resposibility to free the frame after writing (or when it its done
with it). By freeing it within ast_write this of course led to some memory
corruption problems.
This patch makes it so the frame given to ast_write is no longer freed within
the function. The frame returned by ast_audiohook_write_list is now subsequently
used in ast_write and is freed later. It is freed either after translate if the
frame returned by translate is different, or near the end of ast_write prior
to function exit.
ASTERISK-26973 #close
Change-Id: I463d4ac3b736ced95de986ee74a489c7c7ab103b
When manipulating flags on a channel the channel has to be
locked to guarantee that nothing else is also manipulating
the flags. This change introduces locking where necessary to
guarantee this. It also adds helper functions that manipulate
channel flags and lock to reduce repeated code.
ASTERISK-26789
Change-Id: I489280662dba0f4c50981bfc5b5a7073fef2db10
When using the Bridge AMI action on the same channel multiple times
it was possible for the channel to return to the wrong location in
the dialplan if the other party hung up. This happened because the
priority of the channel was not preserved across each action
invocation and it would fail to move on to the next priority in
other cases.
This change makes it so that the priority of a channel is preserved
when taking control of it from another thread and it is incremented
as appropriate such that the priority reflects where the channel
should next be executed in the dialplan, not where it may or may not
currently be.
The Bridge AMI action was also changed to ensure that it too
starts the channels at the next location in the dialplan.
ASTERISK-24529
Change-Id: I52406669cf64208aef7252a65b63ade31fbf7a5a
The ast_waitfor_nandfds operation will manipulate the flags
of channels passed in. This was previously done without
the channel lock being held. This could result in incorrect
values existing for the flags if another thread manipulated
the flags at the same time.
This change locks the channel during flag manipulation.
ASTERISK-26788
Change-Id: I2c5c8edec17c9bdad4a93291576838cb552ca5ed
We shouldn't unlock the channel after starting a snapshot staging because
another thread may interfere and do its own snapshot staging.
* app_dial.c:dial_exec_full() made hold the channel lock while setting up
the outgoing channel staging. Made hold the channel lock after the called
party answers while updating the caller channel staging.
* chan_sip.c:sip_new() completed the channel staging on off-nominal exit.
Also we need to use ast_hangup() instead of ast_channel_unref() at that
location.
* channel.c:__ast_channel_alloc_ap() added a comment about not needing to
complete the channel snapshot staging on off-nominal exit paths.
* rtp_engine.c:ast_rtp_instance_set_stats_vars() made hold the channel
locks while staging the channels for the stats channel variables.
Change-Id: Iefb6336893163f6447bad65568722ad5d5d8212a
Using the timerfd timing module can cause channel freezing, lingering, or
deadlock issues. The problem is because this is the only timing module
that uses an associated alert-pipe. When the alert-pipe becomes
unbalanced with respect to the number of frames in the read queue bad
things can happen. If the alert-pipe has fewer alerts queued than the
read queue then nothing might wake up the thread to handle received frames
from the channel driver. For local channels this is the only way to wake
up the thread to handle received frames. Being unbalanced in the other
direction is less of an issue as it will cause unnecessary reads into the
channel driver.
ASTERISK-26716 is an example of this deadlock which was indirectly fixed
by the change that found the need for this patch.
* In channel.c:__ast_queue_frame(): Adding frame lists to the read queue
did not add the same number of alerts to the alert-pipe. Correspondingly,
when there is an exceptionally long queue event, any removed frames did
not also remove the corresponding number of alerts from the alert-pipe.
ASTERISK-26632 #close
Change-Id: Ia98137c5bf6e9d6d202ce0eb36441851875863f6
A dialplan intercept routine is equivalent to an interrupt routine. As
such, the routine must be done quickly and you do not have access to the
media stream. These restrictions are necessary because the media stream
is the responsibility of some other code and interfering with or delaying
that processing is bad. A possible future dialplan processing
architecture change may allow the interception routine to run in a
different thread from the main thread handling the media and remove the
execution time restriction.
* Made res_agi.c:run_agi() running an AGI in an interception routine run
in DeadAGI mode. No touchy channel frames.
ASTERISK-25951
ASTERISK-26343
ASTERISK-26716
Change-Id: I638f147ca7a7f2590d7194a8ef4090eb191e4e43
There are several issues with deferring frames that are caused by the
refactoring.
1) The code deferring frames mishandles adding a deferred frame to the
deferred queue. As a result the deferred queue can only be one frame
long.
2) Deferrable frames can come directly from the channel driver as well as
the read queue. These frames need to be added to the deferred queue.
3) Whoever is deferring frames is really only doing the __ast_read() to
collect deferred frames and doesn't care about the returned frames except
to detect a hangup event. When frame deferral is completed we must make
the normal frame processing see the hangup as a frame anyway. As such,
there is no need to have varying hangup frame deferral methods. We also
need to be aware of the AST_SOFTHANGUP_ASYNCGOTO hangup that isn't real.
That fake hangup is to cause the PBX thread to break out of loops to go
execute a new dialplan location.
4) To properly deal with deferrable frames from the channel driver as
pointed out by (2) above, means that it is possible to process a dialplan
interception routine while frames are deferred because of the
AST_CONTROL_READ_ACTION control frame. Deferring frames is not
implemented as a re-entrant operation so you could have the unsupported
case of two sections of code thinking they have control of the media
stream.
A worse problem is because of the bad implementation of the AMI PlayDTMF
action. It can cause two threads to be deferring frames on the same
channel at the same time. (ASTERISK_25940)
* Rather than fix all these problems simply revert the API refactoring as
there is going to be only autoservice and safe_sleep deferring frames
anyway.
ASTERISK-26343
ASTERISK-26716 #close
Change-Id: I45069c779aa3a35b6c863f65245a6df2c7865496
* channel.c:ast_sendtext(): Fix T.140 SendText memory leak.
* format_compatibility.c: T.140 RED and T.140 were swapped.
* res_rtp_asterisk.c:rtp_red_init(): Fix ast_format_t140_red ref leak.
* res_rtp_asterisk.c:rtp_red_init(): Fix data race after starting periodic
scheduled red_write().
* res_rtp_asterisk.c: Some other minor misc tweaks.
Change-Id: Ifa27a2e0f8a966b1cf628607c86fc4374b0b88cb
It was possible for a frame to be re-inserted into a jitter buffer after it
had been removed from it. A case when this happened was if a frame was read
out of the jitterbuffer, passed to the translation core, and then multiple
frames were returned from said translation core. Upon multiple frames being
returned the first is passed on, but sebsequently "chained" frames are put
back into the read queue. Thus it was possible for a frame to go back into
the jitter buffer where this would cause problems.
This patch adds a flag to frames that are inserted into the channel's read
queue after translation. The abstract jitter buffer code then checks for this
flag and ignores any frames marked as such.
Change-Id: I276c44edc9dcff61e606242f71274265c7779587
The recent change that made frame deferral into an API had a behavior
change to it. When frame deferral was completed, we would take all of
the deferred frames and queue them all onto the channel in one call to
ast_queue_frame_head(). Before frame deferral was API-ized, places that
performed manual frame deferral would actually take each deferred frame
and queue them onto the channel.
This change in behavior caused the confbridge_recording test to start
failing consistently. Without going too crazily deep into the details,
a channel was getting "stuck" in an ast_safe_sleep(). An AMI redirect
was attempting to break it out of the sleep, but because there were more
frames in the channel read queue than expected, the channel ended up
being unable to break from its sleep loop.
By restoring the behavior of individual frame queuing after deferral,
the test starts passing again.
Note, this points to a potential underlying issue pointing to an
"unbalance" that can occur when queuing multiple frames at once,
and so a follow-up issue is being created to investigate that
possibility.
Change-Id: Ied5dacacda06d343dea751ed5814a03364fe5a7d
The sending codec is switched to the receiving codec and then
is switched back to the best native codec on EVERY receiving RTP packets.
This is because after call of ast_channel_set_rawwriteformat there is call
of ast_set_write_format which calls set_format which sets rawwriteformat
to the best native format.
This patch adds a new function ast_set_write_format_path which set
specific write path on channel and uses this function to switch
the sending codec.
ASTERISK-26603 #close
Change-Id: I5b7d098f8b254ce8f45546e6c36e5d324737f71d
There are several places in Asterisk that have duplicated logic
for deferring important frames until later.
This commit adds a couple of API calls to facilitate this automatically.
ast_channel_start_defer_frames(): Future reads of deferrable frames on
this channel will be deferred until later.
ast_channel_stop_defer_frames(): Any frames that have been deferred get
requeued onto the channel.
ASTERISK-26343
Change-Id: I3e1b87bc6796f222442fa6f7d1b6a4706fb33641
ARI and AMI allow for an explicit channel ID to be specified
when originating channels. Unfortunately, there is nothing in
place to prevent someone from using the same ID for multiple
channels. Further complicating things, adding ID validation to channel
allocation makes it impossible for ARI to discern why channel allocation
failed, resulting in a vague error code being returned.
The fix for this is to institute a new method for channel errors to be
discerned. The method mirrors errno, in that when an error occurs, the
caller can consult the channel errno value to determine what the error
was. This initial iteration of the feature only introduces "unknown" and
"channel ID exists" errors. However, it's possible to add more errors as
needed.
ARI uses this feature to determine why channel allocation failed and can
return a 409 error during origination to show that a channel with the
given ID already exists.
ASTERISK-26421
Change-Id: Ibba7ae68842dab6df0c2e9c45559208bc89d3d06
The main frame read and write handlers in main/channel.c don't use the
optimum placement in the processing flow for calling audiohooks
callbacks, as far as codec translation is concerned. This change places
the audiohooks callback code:
* After the channel read translation if the frame is not linear before
the translation, thereby increasing the chance that the frame is linear
as required by audiohooks
* Before the channel write translation if the frame is linear at this
point
This prevents the audiohooks code from instantiating additional
translation paths to/from linear where a linear frame format is already
available, saving valuable CPU cycles
ASTERISK-26419
Change-Id: I6edd5771f0740e758e7eb42558b953f046c01f8f
