Currently, when the Asterisk calculates rtp statistics, it uses
sample_count as a unsigned integer parameter. This would be fine
for most of cases, but in case of large enough number of sample_count,
this might be causing the divide by zero error.
ASTERISK-28321
Change-Id: If7e0629abaceddd2166eb012456c53033ea26249
Delivery timeval in the smoother object will fall behind while a DTMF is
being generated. This can eventually lead to invalid rtp timestamps.
To prevent this from happening the smoother needs to be reset after every
DTMF to keep the timing up to date.
ASTERISK-28303 #close
Change-Id: Iaba3f7b428ebd72a4caa90e13b829ab4f088310f
p2p_write updates txformat but doesn't require a smoother. If a smoother
was created by another bridge type the smoother could fall out of date causing
one way audio issues. To prevent this the smoother is now destroyed on the
start of native bridge.
ASTERISK-28284 #close
Change-Id: I84e67f144963787fff9b4d79ac500514fb40cdc6
The remote side may start a new stream when renegotiating RTP.
Need to reset the DTMF last sequence number and the timestamp
of the last END packet on RTP renegotiation.
If the new time stamp is lower then the timestamp of the last DTMF END packet
the asterisk drops all DTMF frames as out of order.
This bug was caught using Cisco ip-phone SPA5XX and codec g722.
On SIP session update the SPA50X resets stream and a new timestamp is twice
smaller then the previous.
ASTERISK-28162 #close
Change-Id: Ic72b4497e74d801b27a635559c1cf29c16c95254
All of the fields that were removed were no longer referenced except for
'lastrxts' and 'rxseqno' which were only ever written to.
Change-Id: I5a5d31eb33e97663843698f58d0d97f22a76627c
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
The marker bit set on the voice packet indicates the start
of a new stream and a new time stamp.
Need to reset the DTMF last sequence number and the timestamp
of the last END packet.
If the new time stamp is lower then the timestamp of the last DTMF END packet
the asterisk drops all DTMF frames as out of order.
This bug was caught using Cisco ip-phone SPA50X and codec g722.
On SIP session update the SPA50X resets stream indicating it with market bit
and a new timestamp is twice smaller then the previous.
ASTERISK-28162 #close
Change-Id: If9c5742158fa836ad549713a9814d46a5d2b1620
When networks experience disruptions, there can be large gaps of time
between receiving packets. When strictrtp is enabled, this created
issues where a flood of packets could come in and be seen as an attack.
Another option - seqno - has been added to the strictrtp option that
ignores the time interval and goes strictly by sequence number for
validity.
Change-Id: I8a42b8d193673899c8fc22fe7f98ea87df89be71
This change raises a testsuite event to provide what port
Asterisk has actually allocated for RTP. This ensures that
testsuite tests can remove any assumption of ports and instead
use the actual port in use.
ASTERISK-28070
Change-Id: I91bd45782e84284e01c89acf4b2da352e14ae044
'rtpchecksums' and 'rtcpinterval' are not being reset to their defaults
if they are not present in the updated configuration file.
Change-Id: I1162e40199314d46cf3225d5e1271c4c81176670
The realtime text timer pops regularly and sends text frames even if
the buffer is empty. This causes a lot of unecessary debug logging.
* Made red_write() test if we need to send a frame before calling
ast_rtp_write()
ASTERISK-28002
Reported by: Emmanuel BUU
Tested by: Emmanuel BUU
Change-Id: Icf81310c3b8080b615a42060afc02ab41f9523dd
OpenSSL is an optional external library and should stay optional even when
Developer Mode is configured.
ASTERISK-27990
Change-Id: Ia68a4cd5474b26d45e0f43b04032ad598022853b
When realtime text packets are to be sent, the text is accumulated in a
buffer and sent regularly by a timer. It can happen that commands such as
a backspace, CR, or LF get merged with regular text. This breaks some
UAs.
The proposed change:
* We test if the current packet contains a command. If so we send the
buffer immediately.
* We test if the buffer contained a command. If so we send the buffer
immediately.
* We accumulate the text (or the command) in the buffer.
ASTERISK-27970
Change-Id: Ifbe993311410fa855cb8aa4a12084db75f413462
Previously, Asterisk used its script ./configure, to test whether OpenSSL was
built with no-srtp (or was simply too old). However, the header file
<openssl/opensslconf.h> is the preferred way to detect the local configuration
of OpenSSL.
As a positive side-effect the script ./configure does not interleave the
detection of the Open Settlement Protocol Toolkit (OSPTK) with the detection of
individual features of OpenSSL anymore.
Change-Id: I3c77c7b00b2ffa2e935632097fa057b9fdf480c0
Furthermore, allow OpenSSL configured with no-dh. Additionally, this change
allows auto-negotiation of the elliptic curve/group for servers, not only with
OpenSSL 1.0.2 but also with OpenSSL 1.1.0 and newer. This enables X25519
(since OpenSSL 1.1.0) and X448 (since OpenSSL 1.1.1) as a side-effect.
ASTERISK-27910
Change-Id: I5b0dd47c5194ee17f830f869d629d7ef212cf537
Certain race conditions between changing bridge types and DTMF can
cause the current FLAG_NEED_MARKER_BIT to send the marker bit before
the actual first packet of native bridging.
This logic keeps track of the ssrc the bridge is currently sending
and will correctly ensure the marker bit is set if SSRC as changed
from the previous sent packet.
ASTERISK-27845
Change-Id: I01858bd0235f1e5e629e20de71b422b16f55759b
Checking option_debug directly is incorrect as it ignores file/module
specific debug settings. This system-wide change replaces nearly all
direct checks for option_debug with the DEBUG_ATLEAST macro.
Change-Id: Ic342d4799a945dbc40ac085ac142681094a4ebf0
The pool cache gets in the way of finding use after free errors of memory
pool contents. Tools like valgrind and MALLOC_DEBUG don't know when a
pool is released because it gets put into the cache instead of being
freed.
* Added the "cache_pools" option to pjproject.conf. Disabling the option
helps track down pool content mismanagement when using valgrind or
MALLOC_DEBUG. The cache gets in the way of determining if the pool
contents are used after free and who freed it.
To disable the pool caching simply disable the cache_pools option in
pjproject.conf and restart Asterisk.
Sample pjproject.conf setting:
[startup]
cache_pools=no
* Made current users of the caching pool factory initialization and
destruction calls call common routines to create and destroy cached pools.
ASTERISK-27704
Change-Id: I64d5befbaeed2532f93aa027a51eb52347d2b828
If the ICE role is not set right away, we might have a role conflict
that stays undetected and ICE finishing with successful tests and no
candidate nominated. This was introduced by ASTERISK-27088.
To avoid this, we set the role as soon as before but only if the ICE
state permits it: still checking and not yet nominating candidates or
completed.
ASTERISK-27646
Change-Id: I5dbc69ad63cacbb067922850fbb113d479bd729c
When RTCP-MUX enabled. rtp->s is the same as rtcp->s, check this before
close the file descriptor. Close the FD twice will hangs the asterisk
under heavy load.
ASTERISK-27299 #close
Reported-by: Aaron An
Tested-by: AaronAn
Change-Id: I870a072d73fd207463ac116ef97100addbc0820a
We should not do flood detection on video RTP streams. Video RTP streams
are very bursty by nature. They send out a burst of packets to update the
video frame then wait for the next video frame update. Really only audio
streams can be checked for flooding. The others are either bursty or
don't have a set rate.
* Added code to selectively disable packet flood detection for video RTP
streams.
ASTERISK-27440
Change-Id: I78031491a6e75c2d4b1e9c2462dc498fe9880a70
When the RTCP code was transitioned over to Stasis a code change
was made to keep track of how many reports are present. This count
controlled where report blocks were placed in the RTCP report.
If a compound RTCP packet was received this logic would incorrectly
place a report block in the wrong location resulting in a write
to an invalid location.
This change removes this counting logic and always places the report
block at the first position. If in the future multiple reports are
supported the logic can be extended but for now keeping a count
serves no purpose.
ASTERISK-27382
ASTERISK-27429
Change-Id: Iad6c8a9985c4b608ef493e19c421211615485116
There are many places in the code base where we ignore the return value
of fcntl() when getting/setting file descriptior flags. This patch
introduces a convenience function that allows setting or clearing file
descriptor flags and will also log an error on failure for later
analysis.
Change-Id: I8b81901e1b1bd537ca632567cdb408931c6eded7
More complicated direct media reinvite negotiations can result in longer
delays before direct media flows. The strictrtp learning timeout time
was too short. One log showed that the first RTP packet came in just
after three seconds.
* Increase the strictrtp learning timeout time from 1.5 to 5 seconds.
ASTERISK-27453
Change-Id: Ic5e711164cbb91b4d1c1e40c83697755640f138c
Previously, Asterisk sent srflx only when configured exclusively for IPv4. Now,
srflx is gathered and sent via SDP, even when Asterisk is enabled for
Dual Stack (IPv4+IPv6) and an IPv4 interface is available/used.
ASTERISK-27437
Change-Id: Ie07d8e2bfa7b6fe06fcdc73d390a7a9a4d8c0bc1
Some clients do not send rtp packets every ptime ms. This can lead to
situations in which the rtp source learning algorithm will never learn
the address of the client. This has been discovered on a Mac mini with
a pjsip based softphone after updating to Sierra: as soon as USB
headsets are involved, the softphone will send the second packet 30ms
after the first, the third 30ms after the second and the fourth 1ms
after the third. So in the old implmentation the rtp source learning
algorithm was repeatedly reset on the fourth packet.
The patch changes the algorithm in a way that doesn't take the arrival
time between two consecutive packets into account but the time between
the first and the last packet of a learning sequence.
The patch also fixes a second problem: when a user was using a wrong
value for the probation setting there was a LOG_WARNING output stating
that the value had been set to the default value instead. However
the code for setting the value back to defaults was missing.
ASTERISK-27421 #close
Change-Id: If778fe07678a6fd2041eaca7cd78267d0ef4fc6c
The bridge_p2p_rtp_write() has potential reentrancy problems.
* Accessing the bridged RTP members must be done with the instance1 lock
held. The DTMF and asymmetric codec checks must be split to be done with
the correct RTP instance struct locked. i.e., They must be done when
working on the appropriate side of the point to point bridge.
* Forcing the RTP mark bit was referencing the wrong side of the point to
point bridge. The set mark bit is used everywhere else to set the mark
bit when sending not receiving.
The patches for ASTERISK_26745 and ASTERISK_27158 did not take into
account that not everything carried by RTP uses a codec. The telephony
DTMF events are not exchanged with a codec. As a result when
RFC2833/RFC4733 sent digits you would crash if "core set debug 1" is
enabled, the DTMF digits would always get passed to the core even though
the local native RTP bridge is active, and the DTMF digits would go out
using the wrong SSRC id.
* Add protection for non-format payload types like DTMF when updating the
lastrxformat and lasttxformat. Also protect against non-format payload
types when checking for asymmetric codecs.
ASTERISK-27292
Change-Id: I6344ab7de21e26f84503c4d1fca1a41579364186
Validate RTCP packets before processing them.
* Validate that the received packet is of a minimum length and apply the
RFC3550 RTCP packet validation checks.
* Fixed potentially reading garbage beyond the received RTCP record data.
* Fixed rtp->themssrc only being set once when the remote could change
the SSRC. We would effectively stop handling the RTCP statistic records.
* Fixed rtp->themssrc to not treat a zero value as special by adding
rtp->themssrc_valid to indicate if rtp->themssrc is available.
ASTERISK-27274
Make strict RTP learning more flexible.
Direct media can cause strict RTP to attempt to learn a remote address
again before it has had a chance to learn the remote address the first
time. Because of the rapid relearn requests, strict RTP could latch onto
the first remote address and fail to latch onto the direct media remote
address. As a result, you have one way audio until the call is placed on
and off hold.
The new algorithm learns remote addresses for a set time (1.5 seconds)
before locking the remote address. In addition, we must see a configured
number of remote packets from the same address in a row before switching.
* Fixed strict RTP learning from always accepting the first new address
packet as the new stream.
* Fixed strict RTP to initialize the expected sequence number with the
last received sequence number instead of the last transmitted sequence
number.
* Fixed the predicted next sequence number calculation in
rtp_learning_rtp_seq_update() to handle overflow.
ASTERISK-27252
Change-Id: Ia2d3aa6e0f22906c25971e74f10027d96525f31c
This change moves the logic which learns a new source address
for RTP so it only occurs in the learning state. The learning
state is entered on initial allocation of RTP or if we are
told that the remote address for the media has changed. While
in the learning state if we continue to receive media from
the original source we restart the learning process. It is
only once we receive a sufficient number of RTP packets from
the new source that we will switch to it. Once this is done
the closed state is entered where all packets that do not
originate from the expected source are dropped.
The learning process has also been improved to take into
account the time between received packets so a flood of them
while in the learning state does not cause media to be switched.
Finally RTCP now drops packets which are not for the learned
SSRC if strict RTP is enabled.
ASTERISK-27013
Change-Id: I56a96e993700906355e79bc880ad9d4ad3ab129c
Asterisk wasn't generating or forwarding RTCP packets when native
bridge was activated. Also the stats weren't available via
CHANNEL(qos). Now the RTCP stats are always calculated.
ASTERISK-27158 #close
Change-Id: I46fb8f61c95e836b9d2dda6054b0cf205c16037b
Introduce a new property to rtp-engine to make it aware of
the desire for assymetric codecs or not. If asymmetric codecs
is not allowed, the bridge will compare read/write formats
and shut down the p2p bridge if needed
ASTERISK-26745 #close
Change-Id: I0d9c83e5356df81661e58d40a8db565833501a6f
This change makes it so that if an RTCP packet is being sent
the RTP ICE component is used for sending if RTCP-MUX is in use.
ASTERISK-27133
Change-Id: I6200f611ede709602ee9b89501720c29545ed68b
When a message is received on the TURN socket, the code processing the
message needs to call into the ICE/STUN session for further processing.
This code path locks the TURN group lock then the ICE/STUN group lock. In
another thread an ICE/STUN timer can fire off to send a keep alive message
over the TURN socket. In this code path, the ICE/STUN group lock is
obtained then the TURN group lock is obtained to send the packet. A
classic deadlock case if the group locks are not the same.
* Made TURN get created using the ICE/STUN session's group lock.
NOTE: I was originally concerned that the ICE/STUN session can get
recreated by ice_reset_session() for an event like RTCP multiplexing
causing a change during SDP negotiation. In this case the TURN group lock
would become different. However, TURN is also recreated as part of the
ICE/STUN recreation in ice_create() when all known ICE candidates are
added to the new ICE session. While the ICE/STUN and TURN sessions are
being recreated there is a period where the group locks could be
different.
ASTERISK-27023 #close
Patches:
res_rtp_asterisk-turn-deadlock-fix.patch (license #6502)
patch uploaded by Michael Walton (modified)
Change-Id: Ic870edb99ce4988a8c8eb6e678ca7f19da1432b9
When re-inviting to add more streams it is possible for
the role of existing ICE sessions to be changed to the
incorrect value. This results in subsequent refreshes
within the sessions getting a role conflict and the ICE
session breaking down. This change only sets the role to
be the new value if an ICE renegotiation is actually
going to happen, otherwise the existing role is preserved.
As well if we encounter a situation where a unidirectional
ICE negotiation happens and the other side does not send us
candidates we will not store any information for sending
traffic, even though we know where they are reachable. This
change fixes this by using the source of the ICE traffic
itself as the target if no candidates are known and we
receive some ICE traffic.
ASTERISK-27088
Change-Id: I71228181e358917fcefc3100fad21b2fc02a59a9
It looks like there was a copy/paste error in ast_rtp_change_source
where if there was a rtcp srtp instance, instead of updating its
ssrc we were updating the srtp instance ssrc twice.
ASTERISK-27022 #close
Reported-by: Michael Walton
Change-Id: Ic88f3aee7227b401c58745ac265ff92c19620095
In review 4843 (ASTERISK-24858), we added a hack that forced a smoother
creation when sending signed linear so that the byte order was adjusted
during transmission. This was needed because smoother flags were lost
during the new format work that was done in Asterisk 13.
Rather than rolling that same hack into res_rtp_multicast, re-introduce
smoother flags so that formats can dictate their own options.
Change-Id: I77b835fba0e539c6ce50014a984766f63cab2c16
When using rtcp mux if an rtcp payload came in it would still use the srtp
unprotect algorithm instead of the srtp unprotect rtcp method. Since rtcp
data was being passed to the rtp unprotect method this would result in an
error.
This patch ensures that the correct unprotect method is chosen by making
sure the passed in rtcp flag is appropriately set when rtcp mux is enabled
and an rtcp payload is received.
ASTERISK-26979 #close
Change-Id: Ic5409f9d1a267f1d4785fc5aed867daaecca6241
