If an SSL socket parent/listener was destroyed during the handshake,
depending on timing, it was possible for the handling callback to
attempt access of it after the fact thus causing a crash.
ASTERISK-29415 #close
Change-Id: I105dacdcd130ea7fdd4cf2010ccf35b5eaf1432d
If chan_iax2 received a packet with an unsupported media format, for
example vp9, then it would set the frame's format to NULL. This could
then result in a crash later when an attempt was made to access the
format.
This patch makes it so chan_iax2 now ignores/drops frames received
with unsupported media format types.
ASTERISK-29392 #close
Change-Id: Ifa869a90dafe33eed8fd9463574fe6f1c0ad3eb1
When Asterisk sends a reinvite negotiating T38 faxing, it's possible a
crash can occur if the response contains a m=image and zero port. The
reinvite callback code now checks session_media to see if it is null or
not before trying to access the udptl variable on it.
ASTERISK-29305
Change-Id: I1dfc51c5fa586e38579ede4bc228edee213ccaa9
(cherry picked from commit 17f177ce06)
When an endpoint requests to re-negotiate for fax and the incoming
re-invite is received prior to Asterisk sending out the 200 OK for
the initial invite the re-invite gets delayed. When Asterisk does
finally send the re-inivite the SDP includes streams for both audio
and T.38.
This happens because when the pending topology and active topologies
differ (pending stream is not in the active) in the delayed scenario
the pending stream is appended to the active topology. However, in
the fax case the pending stream should replace the active.
This patch makes it so when a delay occurs during fax negotiation,
to or from, the audio stream is replaced by the T.38 stream, or vice
versa instead of being appended.
Further when Asterisk sent the re-invite with both audio and T.38,
and the endpoint responded with a declined T.38 stream then Asterisk
would crash when attempting to change the T.38 state.
This patch also puts in a check that ensures the media state has a
valid fax session (associated udptl object) before changing the
T.38 state internally.
ASTERISK-29203 #close
Change-Id: I407f4fa58651255b6a9030d34fd6578cf65ccf09
New responses sent within a PJSIP sessions are based on those that were
sent before. Therefore, adding/modifying a header once causes it to be
sent on all responses that follow.
Sending 181 Call Is Being Forwarded many times first adds "histinfo"
duplicated more and more, and eventually overflows past the array
boundary.
This commit adds a check preventing adding "histinfo" more than once,
and skipping it if there is no more space in the header.
Similar overflow situations can also occur in res_pjsip_path and
res_pjsip_outbound_registration so those were also modified to
check the bounds and suppress duplicate Supported values.
ASTERISK-29227
Reported by: Ivan Poddubny
Change-Id: Id43704a1f1a0293e35cc7f844026f0b04f2ac322
If a remote side is broken and sends an SDP that can not be
negotiated the call will be torn down but there is a window
where a second 183 Session Progress or 200 OK that is forked
can be received that also attempts to negotiate SDP. Since
the code marked the SDP negotiation as being done and complete
prior to this it assumes that there is an active local and remote
SDP which it can modify, while in fact there is not as the SDP
did not successfully negotiate. Since there is no local or remote
SDP a crash occurs.
This patch changes the pjmedia_sdp_neg_modify_local_offer2
function to no longer assume that a previous SDP negotiation
was successful.
ASTERISK-29196
Change-Id: I22de45916d3b05fdc2a67da92b3a38271ee5949e
Add a check to see if the URI is a Tel URI and prevent crashing on
trying to retrieve the reason parameter.
ASTERISK-29191
ASTERISK-29219
Change-Id: I0320aa205f22cda511d60a2edf2b037e8fd6cc37
pjproject returns the dialog locked and with a reference. However,
in Asterisk the method that handles this decrements the reference
and removes the lock prior to returning. This makes it possible,
under some circumstances, for another thread to free said dialog
before the thread that created it attempts to use it again. Of
course when the thread that created it tries to use a freed dialog
a crash can occur.
This patch makes it so Asterisk now returns the newly created
dialog both locked, and with an added reference. This allows the
caller to de-reference, and unlock the dialog when it is safe to
do so.
In the case of a new SIP Invite the lock, and reference are now
held for the entirety of the new invite handling process.
Otherwise it's possible for the dialog, or its dependent objects,
like the transaction, to disappear. For example if there is a TCP
transport error.
ASTERISK-29057 #close
Change-Id: I5ef645a47829596f402cf383dc02c629c618969e
If Asterisk sends out an INVITE and receives a challenge with a
different nonce value each time, it will continuously send out INVITEs,
even if the call is hung up. The endpoint must be configured for
outbound authentication for this to occur. A limit has been set on
outbound INVITEs so that, once reached, Asterisk will stop sending
INVITEs and the transaction will terminate.
ASTERISK-29013
Change-Id: I2d001ca745b00ca8aa12030f2240cd72363b46f7
RFC 8760 added new digest-access-authentication schemes. Testing
revealed that chan_sip does not pick MD5 if several schemes are offered
by the User Agent Server (UAS). This change does not implement any of
the new schemes like SHA-256. This change makes sure, MD5 is picked so
UAS with SHA-2 enabled, like the service www.linphone.org/freesip, can
still be used. This should have worked since day one because SIP/2.0
already envisioned several schemes (see RFC 3261 and its augmented BNF
for 'algorithm' which includes 'token' as third alternative; note: if
'algorithm' was not present, MD5 is still assumed even in RFC 7616).
Change-Id: I61ca0b1f74b5ec2b5f3062c2d661cafeaf597fcd
Version: gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Warning:
say.c:2371:24: error: ‘%d’ directive output may be truncated writing
between 1 and 11 bytes into a region of size 10
[-Werror=format-truncation=]
2371 | snprintf(buf, 10, "%d", num);
say.c:2371:23: note: directive argument in the range [-2147483648, 9]
That's not possible though, as the if() starts out checking for (num < 0),
making this Warning a false positive.
(Also replaced some else<TAB>if with else<SP>if while in the vicinity.)
Change-Id: Ic7a70120188c9aa525a6d70289385bfce878438a
This patch initializes a couple of local variables to some default values.
Interestingly, in the 'pj_status_t dlg_status' case the value not being
initialized caused memory to grow, and not be recovered, in the off nominal
path (at least on my machine).
Change-Id: I22ee65e1e1bff8efacea8a167c6c8428898523f7
Ubuntu 20.10 does not come with GMime 2.6. Ubuntu 16.04 LTS does not
come with GMime 3.0. aptitude ignores any missing package. Therefore,
it installs the correct package(s). However, in Ubuntu 18.04 LTS and
Ubuntu 20.04 LTS, both versions are installed alongside although only
one is really needed.
Change-Id: Ic58aa9f2e131d94671f286f17dbd61e1ccbabcb7
Note to maintainers: Lua 5.4, Lua 5.3, and Lua 5.2 have not been tested
at runtime with pbx_lua. Until then, use the lowest available version
of Lua, if you enabled the module pbx_lua at all.
Change-Id: Ie5270448b11fcb4e2a53d899e4fe7fea793ce7e0
Commit 44bb0858cb ("debugging: Add enough
to choke a mule") accidentally removed calls to
ast_sip_message_apply_transport when it was attempting to just add
debugging code.
The kiss of death was saying that there were no functional changes in
the commit comment.
This makes outbound calls that use the 'flow' transport mechanism fail,
since this call is used to relay headers into the outbound INVITE
requests.
ASTERISK-29124 #close
Change-Id: I0f3e32c2e8ac415e30b1d29966d75a1546f0526a
This change outputs a message at startup and when a remote
console is connected stating that this branch is no longer
receiving bug fixes and to consult the Asterisk Versions wiki
page for status information.
Change-Id: I6b8a77d33e338a3e52dd65f998d8a07e4d16aa2e
When handling a send_message request to a non-existing endpoint, the response's
body is overriden and not properly freed.
ASTERISK-29108
Change-Id: Ie1d3d70065f80793445b60f5e4a7eb31b4b9c5c8
In the event that the desired extension already exists,
ast_add_extension2_lockopt() will free the 'data' it is passed before
returning an error, so we should not be freeing it ourselves.
Additionally, there were two places where ast_add_extension2_lockopt()
could return an error without also freeing the 'data' pointer, so we
add that.
ASTERISK-29097 #close
Change-Id: I904707aae55169feda050a5ed7c6793b53fe6eae
app_confbridge now has the ability to set the estimated bitrate on an
SFU bridge. To use it, set a bridge profile's remb_behavior to "force"
and set remb_estimated_bitrate to a rate in bits per second. The
remb_estimated_bitrate parameter is ignored if remb_behavior is something
other than "force".
Change-Id: Idce6464ff014a37ea3b82944452e56cc4d75ab0a
Stop advertising RFC2833 support on the rtp_engine when DTMF mode is
auto but no tel_event was found inside SDP file.
On an incoming call create_rtp will be called and when session->dtmf is
set to AST_SIP_DTMF_AUTO, the AST_RTP_PROPERTY_DTMF will be set without
looking at the SDP file.
Once get_codecs gets called we move the DTMF mode from RFC2833 to INBAND
but continued to advertise RFC2833 support.
This meant the native_rtp bridge would falsely consider the two channels
as compatible. In addition to changing the DTMF mode we now set or
remove the AST_RTP_PROPERTY_DTMF.
The property is checked in ast_rtp_dtmf_compatible and called by
native_rtp_bridge_compatible.
ASTERISK-29051 #close
Change-Id: I1e0c1e324598a437932c0b7836bcb626aba8e287
Arming response to both AST_SIP_SESSION_BEFORE_REDIRECTING and
AST_SIP_SESSION_BEFORE_MEDIA causes 302 to to be handled twice,
resulting in to 181 being generated.
Change-Id: I866e5461564644ffb8a5e12b6f1330b50a7b63ab
When constructing a stream name based on the media type
and position the allocated name was not being freed
causing a leak.
Change-Id: I52510863b24a2f531f0a55b440bb2c81844029de
Because we use shared thread-local cURL instances, we need to ensure
that the state of the cURL instance is correct before each invocation.
In the case of custom headers, we were not resetting cURL's internal
HTTP header pointer which could result in a crash if subsequent
requests do not configure custom headers.
ASTERISK-29085 #close
Change-Id: I8b4ab34038156dfba613030a45f10e932d2e992d
Only track our sample offset if we are playing a non-announcement file,
otherwise we will skip that number of samples when we start playing the
first MoH file.
ASTERISK-24329 #close
Change-Id: Ib6b3c84fcaa1063889ab38ba7e7fc50050a3ccfc
The ast_sip_dialog_get_session function returns the session
with reference count increased. This was not taken into
account and was causing sessions to remain around when they
should not be.
ASTERISK-29089
Change-Id: I430fa721b0a824311a59effec6056e9ec528e3e8
Sometimes not play MOH on bridge.
ASTERISK-29081
Reported-by: Michal Hajek <michal.hajek@daktela.com>
Change-Id: I760c73e0c9be1d340303b5d1c18a00c4759e8232
ast_trace() was always emitting messages when it's level was set to -1
because it was ignoring scope_level.
Change-Id: I849c8f4f4613899c37f82be0202024e7d117e506
When a channel joins a bridge, we do topology change requests on all
existing channels to add the new participant to them. However the
announcer channel will return an error because it doesn't support
topology in the first place. Unfortunately, there doesn't seem to be a
reliable way to tell if the error is expected or not so the error is
ignored for all channels. If the request fails on a "real" channel,
that channel just won't get the new participant's video.
Change-Id: Ic95db4683f27d224c1869fe887795d6b9fdea4f0
Implemention of History-Info capable of interworking with Diversion
Header following RFC7544
ASTERISK-29027 #close
Change-Id: I2296369582d4b295c5ea1e60bec391dd1d318fa6
The recent 491 changes introduced a check to determine if the active
and pending topologies were equal and to suppress the re-invite if they
were. When a re-invite is sent for a COLP-only change, the pending
topology is NULL so that check doesn't happen and the re-invite is
correctly sent. Of course, sending the re-invite sets the pending
topology. If a 491 is received, when we resend the re-invite, the
pending topology is set and since we didn't request a change to the
topology in the first place, pending and active topologies are equal so
the topologies-equal check causes the re-invite to be erroneously
suppressed.
This change checks if the topologies are equal before we run the media
state resolver (which recreates the pending topology) so that when we
do the final topologies-equal check we know if this was a topology
change request. If it wasn't a change request, we don't suppress
the re-invite even though the topologies are equal.
ASTERISK-29014
Change-Id: Iffd7dd0500301156a566119ebde528d1a9573314
Asterisk Development Team
Kevin Harwell
Ben Ford
Alexander Traud
Ivan Poddubnyi
Sean Bright
Joshua C. Colp
Torrey Searle
Walter Doekes
Kevin Harwell
Nick French
Andrew Siplas
Jean Aunis
George Joseph
Jasper van der Neut
lvl
Holger Hans Peter Freyther
Michal Hajek