With menuselect "DEBUG_FD_LEAKS" and CLI "core show fd", both the maximum max
and current max of possible file descriptors were shown. Both show the same
value always. Not to confuse users, just the current maximum is shown now.
ASTERISK-26097
Change-Id: I49cf7952d73aec9e3f6a88942842c39be18380fa
CEL wrongly assumed that a channel would only have a single dial
event on it. This is incorrect. Particularly in a queue each
call attempt to a member will result in a dial event, adding
a new dial status in CEL without removing the old one. This
would cause the container to grow with only one dial status
being removed when the channel went away. The other dial status
entries would remain leaking memory.
This change fixes the memory leak by ensuring that only one dial
status will only ever exist for each channel.
The behavior during the scenario where multiple events are received
has also been improved. For failure cases the first failure will
be the dial status. If an answer dial status is received, though,
it will take priority and the dial status for the channel will be
answer.
Memory usage has also been decreased by storing the minimal
amount of information and the code has been cleaned up slightly.
ASTERISK-25262 #close
Change-Id: I5944eb923db17b6a0faa7317ff6abc9307c009fe
ARI was recently outfitted with operations to create and dial channels.
This leads to the ability to try funny stuff. You could create a channel
and then immediately try to play back media on it. You could create a
channel, dial it, and while it is ringing attempt to make it continue in
the dialplan.
This commit attempts to fix this by adding a channel state check to
operations that should not be able to operate on outbound channels that
have not yet answered. If a channel is in an invalid state, we will send
a 412 response.
ASTERISK-26047 #close
Reported by Mark Michelson
Change-Id: I2ca51bf9ef2b44a1dc5a73f2d2de35c62c37dfd8
The retrieve_cache_control_directives test has been failing occasionally
in Jenkins. The apparent failure occurs when attempting to validate the
expiration of the retrieved file.
After reproducing, the problem was pretty clear. At the beginning of the
test, the current time is retrieved. The seconds value of this timestamp
is X. When the file is retrieved, res_http_media_cache calculates the
expiration and in doing so retrieves the current time. In most cases,
since the test executes quickly, it will also retrieve a timestamp with
X seconds. However, if the test starts very near to when the timestamp
seconds are set to increment, res_http_media_cache may retrieve a
timestamp with X+1 seconds instead.
The test attempted to account for this by allowing a tolerance of 1
second when validating the expiration. However, the problem was that the
comparisons being used in the validation used > and < operations. This
meant that values that fell within the tolerance (because they equaled
the upper bound of the tolerance) would fail.
The solution is to use >= and <= operators in the expiration validation.
However, I estimated that while the one second tolerance should be
fine on most machines, it would still be possible on a very slow machine
to end up falling outside the one second tolerance. So I have also
relaxed the tolerance of expiration validation to be three seconds
instead.
The final change here is to add a debug message when validating
expiration so that we can see what values are being compared.
ASTERISK-25959 #close
Reported by Joshua Colp
Change-Id: Ic1a0e10722c1c5d276d5a4d6a67136d6ec26c247
Scenario: Caller blonde transfer
Bob calls Charlie who answers.
Bob puts Charlie on hold and calls Alice.
Before Alice answers, Bob transfers Charlie to Alice.
Charlie's channel triggers an assert because he gets an "ANSWERED"
event even though he never dialed anything. With recent changes to dial
events, this is now a valid scenario so the assert needed to be removed.
ASTERISK-26103 #close
Change-Id: I2679b517b696e7952ab7fb29403df9140e7d1de2
bridge_native_rtp can call into an RTP-capable channel driver in order
for the driver to update information about who the channel is
communicating with. For SIP channel drivers, this means deactivating
RTCP and sending a reinvite so that the endpoints can communicate
directly.
bridge_native_rtp does the right thing and has the channel locked when
calling into the channel driver. chan_pjsip can't alter session
properties in this thread, though. chan_pjsip queues a task on the
session serializer in order to update properties there.
The problem is that this queued task was not locking the channel. This
meant that the queued task could attempt to deactivate RTCP at the same
time that the channel thread was attempting to process an incoming RTCP
packet. This could lead to a crash.
This patch fixes the issue by locking the channel in the queued task
when altering RTP properties.
ASTERISK-26092 #close
Reported by Niklas Larsson
Change-Id: I3464e226a3c41f6b915f97891e07fa1599e2a159
This patch fixes a race condition processing received REGISTER requests
and their retransmissions caused by REGISTER requests being processed by
two threads. The "sip_transaction Unable to register REGISTER transaction
(key exists)" message is a notable symptom of this issue.
This issue was more likely to happen before the pjsip/distributor
serializers were created. Instead of steps one and two below placing the
REGISTER messages into the same pjsip/distributor they were placed in
random pjsip/default serializers.
1) REGISTER requests come in and get placed on the pjsip/distributor
serializer.
2) Before the first request is processed a retransmission comes in and is
placed on the same pjsip/distributor serializer.
3) The first request goes up the pjsip stack and is then shunted off to
the pjsip/aor/<aor> serializer.
4) Before the first request is completed processing in the pjsip/aor/<aor>
serializer, the second request goes up the pjsip stack and is also shunted
off to the pjsip/aor/<aor> serializer.
5) The first request completes processing and sends out its response.
6) The second request completes processing and tries to send out its
response but pjlib complains that the REGISTER transaction key already
exists.
7) Sadness ensues.
* The race is eliminated by removing the pjsip/aor/<aor> serializer and
continuing the processing in the pjsip/distributor serializer. Now any
retransmissions queued in the pjsip/distributor serializer will be
processed after the first message is completely processed.
ASTERISK-26088 #close
Reported by: Richard Mudgett
Change-Id: I842d714346088bf717ea27437f1dd85bff0bab5a
Stasis subscriptions and message routers create taskprocessors to process
the event messages. API calls are needed to be able to set the congestion
levels of these taskprocessors for selected subscriptions and message
routers.
* Updated CDR, CEL, and manager's stasis subscription congestion levels
based upon stress testing. Increased the congestion levels to reduce the
potential for bursty call setup/teardown activity from triggering the
taskprocessor overload alert. CDRs in particular need an extra high
congestion level because they can take awhile to process the stasis
messages.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: Id0a716394b4eee746dd158acc63d703902450244
Sorcery creates taskprocessors for object types to process object observer
callbacks. An API call is needed to be able to set the congestion levels
of these taskprocessors for selected object types.
* Updated PJSIP's contact and contact_status sorcery object type observer
default congestion levels based upon stress testing. Increased the
congestion levels to reduce the potential for bursty register/unregister
and subscribe/unsubscribe activity from triggering the taskprocessor
overload alert.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I4542e83b556f0714009bfeff89505c801f1218c6
When taskprocessors get backed up, there is a good chance that we are
being overloaded and need to defer adding new work to the system.
* Implemented a high/low water alert mechanism for modules to check if the
system is being overloaded and take appropriate action. When a
taskprocessor is created it has default congestion levels set. A
taskprocessor can later have those congestion levels altered for specific
needs if stress testing shows that the taskprocessor is a symptom of
overloading or needs to handle bursty activity without triggering an
overload alert.
* Add CLI "core show taskprocessor" low/high water columns.
* Fixed __allocate_taskprocessor() to not use RAII_VAR(). RAII_VAR() was
never a good thing to use when creating a taskprocessor because of the
nature of how its references needed to be cleaned up on a partial
creation.
* Made res_pjsip's distributor check if the taskprocessor overload alert
is active before placing a message representing brand new work onto a
distributor serializer.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I182f1be603529cd665958661c4c05ff9901825fa
We must continue using the serializer that the original INVITE came in on
for the dialog. There may be retransmissions already enqueued in the
original serializer that can result in reentrancy and message sequencing
problems.
Outgoing call legs create the pjsip/outsess/<endpoint> serializers for
their dialogs.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I24d7948749c582b8045d5389ba3f6588508adbbc
* Resolves potential reentrancy problems if system restarted in the middle
of subscription message transactions.
* Fixes memory leak recreating persistent subscriptions when the
subscription resource tree could not be created.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I71e34d7ae8ed35a694f1030e820e2548c48697be
We must continue using the serializer that the original SUBSCRIBE came in
on for the dialog. There may be retransmissions already enqueued in the
original serializer that can result in reentrancy and message sequencing
problems. The "sip_transaction Unable to register SUBSCRIBE transaction
(key exists)" message is a notable symptom of this issue.
Outgoing subscriptions still create the pjsip/pubsub/<endpoint>
serializers for their dialogs.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I18b00bb74a56747b2c8c29543a82440b110bf0b0
Incoming messages that are not part of a dialog or a recognized response
to one of our requests need to be sent to a consistent serializer. Under
load we may be queueing retransmissions before we can process the original
message. We don't need to throw these messages onto random serializers
and cause reentrancy and message sequencing problems.
* Created a pool of pjsip/distributor serializers that get picked by
hashing the call-id and remote tag strings of the received messages.
* Made ast_sip_destroy_distributor() destroy items in the reverse order of
creation.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I2ce769389fc060d9f379977f559026fbcb632407
We should not be processing any incoming messages until we are fully
booted. We may not have dialplan or other needed configuration loaded
yet.
ASTERISK-26089 #close
Reported by: Scott Griepentrog
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I584aefb4f34b885a8927e1f13a2c64babd606264
A change to glibc 2.22 changed the order of the sockadddr_storage
members which caused the places where we do an initialization of
ast_sockaddr with '{ { 0, 0, } }' to fail compilation. Those
initializers (which we shouldn't have been using anyway) have been
replaced with memsets.
Change-Id: Idd1b3b320903d8771bfe221f0b015685de628fa4
POSIX defines signal.h. sys/signal.h should not be used as it is
c-library internal header which may or may not exist. Notably with
musl it generates warning of being incorrect.
Change-Id: Ia56b0aa1d84b5c590114867b1b384a624f39a6fc
A crash can occur in res_hep_pjsip or res_hep_rtcp if res_hep has not
loaded and does not have a configuration file. Previously when this
occurred, checks were put in to see if the configuration was loaded
successfully. While this is a good idea - and has been added to the
offending function in res_hep - the reality is res_hep_pjsip and
res_hep_rtcp have no business running if res_hep isn't also running.
As such, this patch also adds a function to res_hep that returns whether
or not it successfully loaded. Oddly enough, ast_module_check returns
"everything is peachy" even if a module declined its load - so it cannot
be solely relied on. res_hep_pjsip and res_hep_rtcp now also check this
function to see if they should continue to load; if it fails, they
decline their load as well.
ASTERISK-26096 #close
Change-Id: I007e535fcc2e51c2ca48534f48c5fc2ac38935ea
This saves around 100 bytes when G.711, G.722, G.729, and GSM are advertised in
SDP. This reduces the chance to hit the MTU bearer of 1300 bytes for SIP over
UDP, if many codecs are allowed in Asterisk. This new feature is enabled
together with the optional feature compactheaders=yes via the file sip.conf.
ASTERISK-25578 #close
Change-Id: I16491b1937862de26f84fa0ffe679a6bab925044
