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
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
Replace usage of ao2_container_alloc with ao2_container_alloc_hash or
ao2_container_alloc_list. Remove ao2_container_alloc macro.
Change-Id: I0907d78bc66efc775672df37c8faad00f2f6c088
* The dependency ensures that res_pjproject cannot be manually unloaded
before res_rtp_asterisk.
* The dependency allows startup loading errors to report that
res_rtp_asterisk depends upon res_pjproject.
Change-Id: Icf5e7581f4ddd6189929f6174c74dd951f887377
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
ast_rtp_new free'd rtp upon failure, but rtp_engine.c would also call
the destroy callback. Remove call to ast_free from ast_rtp_new, leave
it to rtp_engine.c to initiate the full cleanup. Add error detection
for the ssrc_mapping vector initialization. In rtp_allocate_transport
set rtp->s = -1 in the failure path where we close that FD to ensure we
don't try closing it twice.
ASTERISK-27854 #close
Change-Id: Ie02aecbb46228ca804e24b19cec2bb6f7b94e451
'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
Compiling without SRTP support installed resulted in some unused variable
warnings. These warnings also showed that the srtp variable was obtained
and passed around some functions but not really used even when a system
has SRTP installed.
Change-Id: I6daad34be3e89b19adef6e2fbe738018975155fc
When a conference contained a mixture of audio/video and audio-only
users, a NOTICE message would pop up stating there are no joint
capabilities between streams. This happens because streams can never be
removed, but they can be in a REMOVED state. If we have the scenario
where user A joins with audio/video, user B joins with audio-only, and
user C joins with audio/video, then user A leaves, the message would
be triggered. That removed stream is still in the SDP, but Asterisk
would pass it through, causing it to be seen as a ulaw stream. A check
has been added for removed streams, setting their status to REMOVED when
handling negotiated SDPs.
Also addressed an issue where user A joins, then user B joins but does
not receive video until much later. Full frames were not being sent,
causing some PLI from the browser. Because the video was flowing in one
direction, the browser sets the SSRC to 1, but Asterisk was dropping the
PLI because of that. Added a check to see if the SSRC is 1 or not, which
sends full frames and allows video to flow between user A and user B.
This should only happen when dealing with PSFB or FUR, and in the case
of PSFB, only for PLI.
ASTERISK-27398
Change-Id: I26e7c6f101bc119549eeca406b5bcd25ad8ebc5e
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
Support has been added for receiving a NACK request and handling it.
Now, Asterisk can detect when a NACK request should be sent and knows
how to construct one based on the packets we've received from the remote
end. A buffer has been added that will store out of order packets until
we receive the packet we are expecting. Then, these packets are handled
like normal and frames are queued to the core like normal. Asterisk
knows which packets to request in the NACK request using a vector
which stores the sequence numbers of the packets we are currently missing.
If a missing packet is received, cycle through the buffer until we reach
another packet we have not received yet. If the buffer reaches a certain
size, send a NACK request. If the buffer reaches its max size, queue all
frames to the core and wipe the buffer and vector.
According to RFC3711, the NACK request must be sent out in a compound
packet. All compound packets must start with a sender or receiver
report, so some work was done to refactor the current sender / receiver
code to allow it to be used without having to also include sdes
information and automatically send the report.
Also added additional functionality to ast_data_buffer, along with some
testing.
For more information, refer to the wiki page:
https://wiki.asterisk.org/wiki/display/AST/WebRTC+User+Experience+Improvements
ASTERISK-27810 #close
Change-Id: Idab644b08a1593659c92cda64132ccc203fe991d
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
When RTP was originally created it had the ability to place a single
extension in an RTP packet. In practice people wanted to potentially
put multiple extensions in one and so RFC 5285 (obsoleted by RFC
8285) came into existence. This allows RTP extensions to be negotiated
with a unique identifier to be used in the RTP packet, allowing
multiple extensions to be present in the packet.
This change extends the RTP engine API to add support for this. A
user of it can enable extensions and the API provides the ability to
retrieve the information (to construct SDP for example) and to provide
negotiated information (from SDP). The end result is that the RTP
engine can then query to see if the extension has been negotiated and
what unique identifier is to be used. It is then up to the RTP engine
implementation to construct the packet appropriately.
The first extension to use this support is abs-send-time which is
defined in the REMB draft[1] and is a second timestamp placed in an
RTP packet which is for when the packet has left the sending system.
It is used to more accurately determine the available bandwidth.
ASTERISK-27831
[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
Change-Id: I508deac557867b1e27fc7339be890c8018171588
When the local SSRC changes we need to update the SRTP information
so that the proper key is used. This is commonly done as a result
of bridging two channels together. Previously we only updated
the SRTP information if media had already flowed, but in practice
the channel driver may have already performed SRTP negotiation and
set up the previous SSRC. We now always do it on a local SSRC
change.
ASTERISK-27795
ASTERISK-27800
Change-Id: Ia7c8e74c28841388b5244ac0b8fd6c1dc6ee4c10
Adds the ability to receive and handle incoming NACK requests if
retransmissions are enabled. If retransmissions are enabled, a data
buffer is allocated that stores packets being sent. If a NACK request
is received, the packet requested for retransmission is sent if it is
still in the buffer. In the same request, if any of the following 16
packets are marked as not received, those will be sent as well if
available, as outlined in RFC4585.
Also changes RTCP RR and SR to use media source SSRC instead of packet
source SSRC when determining which instance to use for RTCP reports.
For more information, refer to the wiki page:
https://wiki.asterisk.org/wiki/display/AST/WebRTC+User+Experience+Improvements
ASTERISK-27806 #close
Change-Id: I7f7f124af3b9d5d2fd9cffc6ba8cb48a6fff06ec
This change allows chan_pjsip to be given an AST_FRAME_RTCP
containing REMB feedback and pass it to res_rtp_asterisk.
Once res_rtp_asterisk receives the frame a REMB RTCP feedback
packet is constructed with the appropriate contents and sent
to the remote endpoint.
ASTERISK-27776
Change-Id: Ic53f821c1560d8924907ad82c4d9c0bc322b38cd
The previous payload specific feedback handling was very single
minded in that it just assumed everything should trigger a video
update. This was changed but the handling of picture loss indication
was not added. The result was that video may not flow. This change
adds it explicitly in.
Change-Id: I1894be02e39ee10a0af841b5a1dca5f0ec7d60b6
This change extends the existing AST_FRAME_RTCP frame type to be
able to contain additional RTCP message types, such as feedback
messages. The payload type is contained in the subclass which allows
knowing what is in the frame itself.
The RTCP feedback message type is now handled and REMB[1] messages
are raised with their containing information.
This also fixes a bug where all feedback messages were triggering
video updates instead of just FIR and FUR.
Finally RTCP frames are now passed up through the Asterisk core to
what is handling the channel, mapped appropriately in the case of
bridging, and written to an outgoing stream. Since RTCP frames are
on a per-stream basis this is only done on multistream capable
channels.
[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
ASTERISK-27758
ASTERISK-26366
Change-Id: I680da0ad8d5059d5e9655d896fb9d92e9da8491e
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
This mimics the behavior of Chrome and Firefox and creates an ephemeral
X.509 certificate for each DTLS session.
Currently, the only supported key type is ECDSA because of its faster
generation time, but other key types can be added in the future as
necessary.
ASTERISK-27395
Change-Id: I5122e5f4b83c6320cc17407a187fcf491daf30b4
