* Since ICE candidates are used for the check and pjproject is
required to use ICE, res_rtp_asterisk was failing to compile
when pjproject wasn't available. The check is now wrapped
with an #ifdef HAVE_PJPROJECT.
* The rtp->ice_active_remote_candidates container was being
used to check the address on incoming packets but that
container doesn't contain peer reflexive candidates discovered
during negotiation. This was causing the check to fail
where it shouldn't. We now check against pjproject's
real_ice->rcand array which will contain those candidates.
* Also fixed a bug in ast_sockaddr_from_pj_sockaddr() where
we weren't zeroing out sin->sin_zero before returning. This
was causing ast_sockaddr_cmp() to always return false when
one of the inputs was converted from a pj_sockaddr, even
if both inputs had the same address and port.
Resolves: #500Resolves: #503Resolves: #505
When ICE is in use, we can prevent a possible DOS attack by allowing
DTLS protocol messages (client hello, etc) only from sources that
are in the active remote candidates list.
Resolves: GHSA-hxj9-xwr8-w8pq
In function rtp_ioqueue_thread_remove counter in ioqueue object is not decreased
which prevents unused ICE TURN threads from being removed.
Resolves: #301
From the gdb information, it was found that when calling __ast_free, the size of the
allocated space pointed to by the pointer matches the size created when rtp->themssrc_valid
is equal to 0. However, in reality, when reading the value of rtp->themssrc_valid in gdb,
it is found to be 1.
Within ast_rtcp_write(), the call to ast_rtp_rtcp_report_alloc() uses rtp->themssrc_valid,
which is outside the protection of the rtp_instance lock. However,
ast_rtcp_generate_report(), which is called by ast_rtcp_generate_compound_prefix(), uses
rtp->themssrc_valid within the protection of the rtp_instance lock.
This can lead to the possibility that the value of rtp->themssrc_valid used in the call to
ast_rtp_rtcp_report_alloc() may be different from the value of rtp->themssrc_valid used
within ast_rtcp_generate_report().
Resolves: asterisk#63
Rounding issues with double math were causing rtp timestamp
slips in outgoing packets. We're now back to integer math
and are getting no more slips.
ASTERISK-30391
Change-Id: I6ba992b49ffdf9ebea074581dfa784a188c661a4
-----------------
This commit reinstates MES with some casting fixes to the
functions in time.h that convert between doubles and timeval
structures. The casting issues were causing incorrect
timestamps to be calculated which caused transcoding from/to
G722 to produce bad or no audio.
ASTERISK-30391
-----------------
This module has been updated to provide additional
quality statistics in the form of an Asterisk
Media Experience Score. The score is avilable using
the same mechanisms you'd use to retrieve jitter, loss,
and rtt statistics. For more information about the
score and how to retrieve it, see
https://wiki.asterisk.org/wiki/display/AST/Media+Experience+Score
* Updated chan_pjsip to set quality channel variables when a
call ends.
* Updated channels/pjsip/dialplan_functions.c to add the ability
to retrieve the MES along with the existing rtcp stats when
using the CHANNEL dialplan function.
* Added the ast_debug_rtp_is_allowed and ast_debug_rtcp_is_allowed
checks for debugging purposes.
* Added several function to time.h for manipulating time-in-samples
and times represented as double seconds.
* Updated rtp_engine.c to pass through the MES when stats are
requested. Also debug output that dumps the stats when an
rtp instance is destroyed.
* Updated res_rtp_asterisk.c to implement the calculation of the
MES. In the process, also had to update the calculation of
jitter. Many debugging statements were also changed to be
more informative.
* Added a unit test for internal testing. The test should not be
run during normal operation and is disabled by default.
Change-Id: I4fce265965e68c3fdfeca55e614371ee69c65038
This module has been updated to provide additional
quality statistics in the form of an Asterisk
Media Experience Score. The score is avilable using
the same mechanisms you'd use to retrieve jitter, loss,
and rtt statistics. For more information about the
score and how to retrieve it, see
https://wiki.asterisk.org/wiki/display/AST/Media+Experience+Score
* Updated chan_pjsip to set quality channel variables when a
call ends.
* Updated channels/pjsip/dialplan_functions.c to add the ability
to retrieve the MES along with the existing rtcp stats when
using the CHANNEL dialplan function.
* Added the ast_debug_rtp_is_allowed and ast_debug_rtcp_is_allowed
checks for debugging purposes.
* Added several function to time.h for manipulating time-in-samples
and times represented as double seconds.
* Updated rtp_engine.c to pass through the MES when stats are
requested. Also debug output that dumps the stats when an
rtp instance is destroyed.
* Updated res_rtp_asterisk.c to implement the calculation of the
MES. In the process, also had to update the calculation of
jitter. Many debugging statements were also changed to be
more informative.
* Added a unit test for internal testing. The test should not be
run during normal operation and is disabled by default.
ASTERISK-30280
Change-Id: I458cb9a311e8e5dc1db769b8babbcf2e093f107a
There is work going on to update our OpenSSL usage to avoid the
deprecated functions but in the meantime make it possible to compile
in devmode.
Change-Id: Ib082eb8b3751f0185d8aa8fe127da664c93f0726
When generating dtmfs, asterisk can incorrectly think packet loss
occured during the dtmf generation, resulting in a jump in sequence
numbers when forwarding voice frames resumes. This patch forces
asterisk to re-learn the expected sequence number after each DTMF
to avoid this
ASTERISK-29869 #close
Change-Id: Icc7de3d947b207b82c99d3c327af8095884df853
The code currently checks to see if an RFC3389
warning flag is set, except if it is, it merely
sets the flag again, the logic of which doesn't
make any sense.
This adjusts the if comparison to check if the
flag has NOT been set, and if so, emit a notice
log event and set the flag so that future frames
do not cause an event to be logged.
ASTERISK-29856 #close
Change-Id: Ib7098c947c63537d087a03b4646199fbb963f8e1
res/res_rtp_asterisk.c: Adding 1 to rtpstart if it is deteremined
that rtpstart was configured to be an odd value. Also adding a loop
counter to prevent a possible infinite loop when looking for a free
port.
ASTERISK-27406
Change-Id: I90f07deef0716da4a30206e9f849458b2dbe346b
Some code has been added referencing symbols defined in a block
protected by #ifdef HAVE_PJPROJECT. Protect those code parts in
ifdef blocks too.
ASTERISK-29660
Change-Id: Ib18d4392d51ac80ca5481dabf6e498a4e3e49e6f
This allows the STUN server to change its IP address without having to
reload the res_rtp_asterisk module.
The refresh of the name resolution occurs first when the module is
loaded, then recurringly, slightly after the previous DNS answer TTL
expires.
ASTERISK-29508 #close
Change-Id: I7955a046293f913ba121bbd82153b04439e3465f
RTCP ICE candidates use a base address derived from the RTP
candidate. The port on the base address was not being updated to
the RTCP port.
This change sets the base port to the RTCP port and all is well.
ASTERISK-29433
Change-Id: Ide2d2115b307bfd3c2dfbc4d187515d724519040
By default Asterisk reports the PJSIP version in a SOFTWARE attribute
of every STUN packet it sends. This may not be desired in a production
environment, and RFC5389 recommends making the use of the SOFTWARE
attribute a configurable option:
https://datatracker.ietf.org/doc/html/rfc5389#section-16.1.2
This patch adds a `stun_software_attribute` yes/no option to make it
possible to omit the SOFTWARE attribute from STUN packets.
ASTERISK-29434
Change-Id: Id3f2b1dd9584536ebb3a1d7e8395fd8b3e46860b
We assume that a timestamp value of 0 represents an 'uninitialized'
timestamp, but 0 is a valid value. Add a simple wrapper to be able to
differentiate between whether the value is set or not.
This also removes the fix for ASTERISK~28812 which should not be
needed if we are checking the last timestamp appropriately.
ASTERISK-29030 #close
Change-Id: Ie70d657d580d9a1f2877e25a6ef161c5ad761cf7
For some input to the standard deviation algorithm extremely large,
and wrong numbers were being calculated.
This patch uses a new formula for correctly calculating both the
running mean and standard deviation for the given inputs.
ASTERISK-29364 #close
Change-Id: Ibc6e18be41c28bed3fde06d612607acc3fbd621f
The calculated minimum lost packets represents the lowest number of
lost packets missed during an RTCP report interval. Zero of course
is the lowest, but the idea is that this value contain the lowest
number of lost packets once some have been missed.
This patch checks to make sure the number of lost packets over an
interval is not zero before checking and setting the minimum value.
Also, this patch updates the rtp lost packet test to check for
packet loss over several reports vs one.
Change-Id: I07d6e21cec61e289c2326138d6bcbcb3c3d5e008
Flash in RTP is conveyed the same as DTMF, just with a
specific digit. In Asterisk however we do flash as a
single control frame.
This change makes it so that only on end do we provide
the flash control frame to the core. Previously we would
provide a flash control frame on both begin and end,
causing flash to work improperly.
ASTERISK-29373
Change-Id: I1accd9c6e859811336e670e698bd8bd124f33226
This patch makes it so when Asterisk is compiled in DEVMODE a CLI
command is available that allows someone to drop incoming RTP
packets. The command allows for dropping of packets once, or on a
timed interval (e.g. drop 10 packets every 5 seconds). A user can
also specify to drop packets by IP address.
Change-Id: I25fa7ae9bad6ed68e273bbcccf0ee51cae6e7024
When an SSRC change occurs the timestamps are likely
to change as well. As a result we need to reset the
timestamp mapping done in the calc_rxstamp function
so that they map properly from timestamp to real
time.
This previously occurred but due to packet
retransmission support the explicit setting
of the marker bit was not effective.
ASTERISK-29352
Change-Id: I2d4c8f93ea24abc1030196706de2d70facf05a5a
For RTCP to work, we update the ssrc to be the one corresponding to
the native bridge while active. However when the bridge ends we
should generate a new SSRC as the sequence numbers will not continue
from the native bridge left off.
ASTERISK-29300 #close
Change-Id: I23334b6934d2bf6490bda4bbf6414d96b8d17d10
This change will check is the remote ICE session got reset or not by
checking the offered ufrag and password with session. If the remote ICE
reset session then Asterisk reset its local ufrag and password to reject
binding request with Old ufrag and Password.
ASTERISK-29266
Change-Id: I9c55e79a7af98a8fbb497d336b828ba41bc34eeb
For some RTCP packet types the report count is actually the packet's subtype.
This was not being reflected in the packet debug output.
This patch makes it so for some RTCP packet types a "Packet Subtype" is
now output in the debug replacing the "Reception reports" (i.e count).
Change-Id: Id4f4b77bb37077a4c4f039abd6a069287bfefcb8
Added debug logging categories that allow a user to output debug
information based on a specified category. This lets the user limit,
and filter debug output to data relevant to a particular context,
or topic. For instance the following categories are now available for
debug logging purposes:
dtls, dtls_packet, ice, rtcp, rtcp_packet, rtp, rtp_packet,
stun, stun_packet
These debug categories can be enable/disable via an Asterisk CLI command.
While this overrides, and outputs debug data, core system debugging is
not affected by this patch. Statements still output at their appropriate
debug level. As well backwards compatibility has been maintained with
past debug groups that could be enabled using the CLI (e.g. rtpdebug,
stundebug, etc.).
ASTERISK-29054 #close
Change-Id: I6e6cb247bb1f01dbf34750b2cd98e5b5b41a1849
The "value" passed in when setting an RTP property determines
whether it should be enabled or disabled. The RTP send and
receive retrans props did not examine this to know if the
buffers should be enabled. They assumed they always should be.
This change makes it so that the "value" passed in is
respected.
ASTERISK-28939
Change-Id: I9244cdbdc5fd065c7f6b02cbfa572bc55c7123dc
Recently code accessing nochecksums variable has been added without including #ifdef SO_NO_CHECK protection, while the variable is created only when such constant is defined.
ASTERISK-28852 #close
Change-Id: I381718893b80599ab8635f2b594a10c1000d595e
When the receive buffer was flushed by a received packet while it
already contained a packet with the same sequence number, Asterisk
never left the while loop which tried to order the packets.
This change makes it so if the packet is in the receive buffer it
is retrieved and freed allowing the buffer to empty.
ASTERISK-28827
Change-Id: Idaa376101bc1ac880047c49feb6faee773e718b3
When the ast_data_buffer_put rejects to add a packet, for example because
the buffer already contains a packet with the same sequence number, the
payload will never be freed, resulting in a memory leak.
The data buffer will now return an error if this situation occurs
allowing the caller to free the payload. The res_rtp_asterisk module
has also been updated to do this.
ASTERISK-28826
Change-Id: Ie6c49495d1c921d5f997651c7d0f79646f095cf1
By using pjproject to give us a list of candidates, and then filtering,
if the host has >32 addresses configured, then it is possible that we
end up filtering out all 32 of those, and ending up with no candidates
at all. Instead, get getifaddrs (which pjsip is using underlying
anyway) to retrieve all local addresses, and iterate those, adding the
first 32 addresses not excluded by the ICE ACL.
In our setup at any point in time We've got between 6 and 328 addresses
on any given system. The lower limit is the lower limit but the upper
limit is growing on a near daily basis currently.
Change-Id: I109eaffc3e2b432f00bf958e3caa0f38cacb4edb
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
A pure blacklist is not good enough, we need a whitelist mechanism as
well, and the simplest way to do that is to re-use existing ACL
infrastructure.
This makes it simpler to blacklist say an entire block (/24) except a
smaller block (eg, a /29 or even a /32). Normally you'd need to
recursively split the block, so if you want to blacklist a /24 except
for a /29 you'd end up with a blacklit for a /25, /26, /27 and /28. I
feel that having an ACL instead of a blacklist only is clearer.
Change-Id: Id57a8df51fcfd3bd85ea67c489c85c6c3ecd7b30
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
bridge_p2p_rtp_write will forward rtp to the bridged rtp instance
without modifying the ssrc. However, it is not updating the SSRC
in the bridged rtp. Thus, when SSRC packets are generated, they
have the correct SSRC for the sender.
ASTERISK-28773 #close
Change-Id: I39f923bde28ebb4f0fddc926b92494aed294a478
George Joseph
Sean Bright
Brad Smith
Vitezslav Novy
zhengsh
George Joseph
Sean Bright
Torrey Searle
Naveen Albert
Mike Bradeen
Alexander Traud
Josh Soref
Jean Aunis
Guido Falsi
Sebastien Duthil
Joshua C. Colp
Jeremy Lainé
Kevin Harwell
Salah Ahmed
Kevin Harwell
sungtae kim
Pirmin Walthert
bernard merindol
Jaco Kroon
Torrey Searle