| Age | Commit message (Collapse) | Author |
|---|
|
The receipt of a SIP MESSAGE may occur over any transport including TCP
and TLS. When the message is received, the original URI is added to the
message in the field PJSIP_RECVADDR, but this is insufficient to ensure
a reply message can reach the originating endpoint. This patch adds the
PJSIP_TRANSPORT field populated with the transport type.
ASTERISK-26132 #close
Change-Id: I28c4b1e40d573a056c81deb213ecf53e968f725e
|
|
Some configure scripts used both AC_HELP_STRING and its replacement
AS_HELP_STRING. For consistency and to avoid obsolete warnings, those were
changed to AS_HELP_STRING.
ASTERISK-26046
Change-Id: I8aad4fd2bdee40aa2a31ce3339a1eb33ff4f5b0f
|
|
|
|
|
|
When shutting down res_pjsip_session will get unloaded before res_pjsip.
The act of unloading unregisters all the PJSIP services and sets
their module IDs to -1. In some cases it is possible for a timer to
occur after this happens which calls into res_pjsip_session. The
res_pjsip_session module can then try to get the session from the
INVITE session using the module ID. Since the module ID is now -1
this fails.
This change stores a copy of the module ID and uses it for the timer
callback scenario. If the module ID is -1 the callback immediately
returns but if the module ID is valid then it continues as normal.
This works as the original ID of the module is guaranteed to still
be valid when used with the INVITE session.
ASTERISK-26127 #close
Change-Id: I88df72525c4e9ef9f19c13aedddd3ac4a335c573
|
|
Fix compile error introduced by the patch for
ASTERISK-26045
Change-Id: I5b02876266f2824f4cec2b54d6ff4db5de5778d3
|
|
ASTERISK-26119 #close
Change-Id: Iecbf7d0f360a021147344c4e83ab242fd1e7512c
|
|
|
|
|
|
Announcer channels were not being destroyed because the
stasis_app_control structure that referenced them was not being
destroyed. The control structure was not being destroyed because it was
not being unlinked from its container. It was not being unlinked from
its container because the after bridge callback for the announcer
channel was not being run. The after bridge callback was not being run
because the after bridge datastore was not being removed from the
channel on destruction. The channel was not being destroyed because the
hangup that used to destroy the channel was now only reducing the
reference count to one. The reference count of the channel was only
being reduced to one because the stasis_app_control structure was
holding the final reference...
The control structure used to not keep a reference to the channel, so
that loop described above did not happen.
The solution is to manually remove the control structure from its
container when the playback on a bridge is complete.
ASTERISK-26083 #close
Reported by Joshua Colp
Change-Id: I0ddc0f64484ea0016245800b409b567dfe85cfb4
|
|
The internal HTTP/WebSocket server supports both TCP and TLS, which can be
activated separately via the file http.conf. The source code intends to re-use
the TCP parameter 'bindaddr' for TLS, even if 'tlsbindaddr' is not specified
explicitly. This did not work because of a typo. This change resolves this typo.
ASTERISK-26126 #close
Change-Id: I5efb0409ae12044dfb3495b6b97b6d40a8c9c51f
|
|
|
|
Currently chan_sip can give weird messages if the contacts don't
fit in the From: or To: headers. This fix changes the from,to and
invite variables to use ast_str, allocates and deallocates them and
resizes them if needed.
ASTERISK-26069 #close
Change-Id: I1b68fcbddca6f6cc7d7a92fe1cb0d5430282b2b3
|
|
* In unload_module(), reordered destroying things to minimize the window
that the global transports container could be used by other threads on
shutdown. When shutting down you need to stop things in the opposite
order of creation.
* Put the global transports container into an AO2_GLOBAL_OBJ_STATIC to
eliminate the crash potential by other threads using the container on
shutdown.
* Made struct monitored_transport.sip_received not use
ast_atomic_fetchadd_int() since it is used as a boolean value that is only
set TRUE. It was previously incremented for every received SIP message
and could theoretically overflow.
* In monitored_transport_state_callback(), allocated the monitored
transport object without a lock since the lock was unused.
* In keepalive_global_loaded(), removed releasing the transports container
if the keepalive_thread could not be started. I set it up to be tried
again if the user reloads the configuration.
Change-Id: I8d12d16ef564290fa6d25a32334bb5ce8fdf87ff
|
|
Change-Id: Iabaa2e5dccf0762c258101ea0eb1487cf6959ad1
|
|
|
|
Change-Id: Ic9928208b9957e09866abe3d9649030942ec52b3
|
|
|
|
|
|
Change-Id: I68a2128bcba4830985d2d441e70dfd1ac5bd712b
|
|
* Deprecate chan_multicast_rtp.
Change-Id: Ib5a45e58c75ee8abd0b4f9575379b5321feb853e
|
|
Change-Id: I1119b53f2152ab1cbec74b5be7ea44844dbda8ef
|
|
With CLI "core show settings", simply the parameter maxfiles of the file
asterisk.conf was shown. If that parameter was not set, nothing was displayed
although the environment might have set a default number itself. Or if maxfiles
were not granted (completely), still maxfiles was shown. Now, the maximum number
of possible file descriptors in the environment is shown.
ASTERISK-26097
Change-Id: I2df5c58863b5007b34b77adbe28b885dfcdf7e0b
|
|
|
|
into 13
|
|
|
|
|
|
|
|
into 13
|
|
serializer." into 13
|
|
subscriptions." into 13
|
|
into 13
|
|
|
|
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
|
|
|
|
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
|
|
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
|
|
descriptors." into 13
|
|
|
|
into 13
|
|
|
|
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
|
|
With menuselect "DEBUG_FD_LEAKS" and CLI "core show fd", the maximum size of a
single file was shown. Now, the maximum number of possible file descriptors is
shown.
ASTERISK-26097
Change-Id: Icf98d145774b38cac144ca76d19eaef42ce659a3
|
|
into 13
|
|
POSIX defines poll.h, sys/poll.h should not be used at is c-library
internal header which may or may not exist. Notable in musl it
generates warning of being incorrect. And add explict include of
sys/cdefs.h where needed.
Change-Id: I142930df53fe7585a06b854b6faddc5301e024be
|
|
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
|
