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
This change introduce a CLI command for the RTP to display the general
configuration.
In the first step add the follow fields of the configurations:
- rtpstart
- rtpend
- dtmftimeout
- rtpchecksum
- strictrtp
- learning_min_sequential
- icesupport
Change-Id: Ibe5450898e2c3e1ed68c10993aa1ac6bf09b821f
The receive buffer will now grow if we end up flushing the
receive queue after not receiving the expected packet in time.
This is done in hopes that if this is encountered again the
extra buffer size will allow more time to pass and any missing
packets to be received.
The send buffer will now grow if we are asked for packets and
can't find them. This is done in hopes that the packets are
from the past and have simply been expired. If so then in
the future with the extra buffer space the packets should be
available.
Sequence number cycling has been handled so that the
correct sequence number is calculated and used in
various places, including for sorting packets and
for determining if a packet is old or not.
NACK sending is now more aggressive. If a substantial number
of missing sequence numbers are added a NACK will be sent
immediately. Afterwards once the receive buffer reaches 25%
a single NACK is sent. If the buffer continues to grow and
reaches 50% or greater a NACK will be sent for each received
future packet to aggressively ask the remote endpoint to
retransmit.
ASTERISK-28764
Change-Id: I97633dfa8a09a7889cef815b2be369f3f0314b41
When handling ICE negotiations, it's possible that there can be a delay
between STUN binding requests which in turn will cause a delay in ICE
completion, preventing media from flowing. It should be possible to send
media when there is at least one valid pair, preventing this scenario
from occurring.
A change was added to PJPROJECT that adds an optional callback
(on_valid_pair) that will be called when the first valid pair is found
during ICE negotiation. Asterisk uses this to start the DTLS handshake,
allowing media to flow. It will only be called once, either on the first
valid pair, or when ICE negotiation is complete.
ASTERISK-28716
Change-Id: Ia7b68c34f06d2a1d91c5ed51627b66fd0363d867
There was a race condition between client initiated DTLS setup, and handling
of server side ice completion that caused the underlying SSL object to get
cleared during DTLS initialization. If this happened Asterisk would be left
in a partial DTLS setup state. RTP packets were sent and received, but were
not being encrypted and decrypted. This resulted in no audio, or static.
Specifically, this occurred when '__rtp_recvfrom' was processing the handshake
sequence from the client to the server, and then 'ast_rtp_on_ice_complete'
gets called from another thread and clears the SSL object when calling the
'dtls_perform_setup' function. The timing had to be just right in the sense
that from the external SSL library perspective SSL initialization completed
(rtp recv), Asterisk clears/resets the SSL object (ice done), and then checks
to see if SSL is intialized (rtp recv). Since it was cleared, Asterisk thinks
it is not finished, thus not completing 'dtls_srtp_setup'.
This patch removes calls to 'dtls_perform_setup', which clears the SSL object,
in 'ast_rtp_on_ice_complete'. When ice completes, there is no reason to clear
the underlying SSL object. If an ice candidate changes a full protocol level
renegotiation occurs. Also, in the case of bundled ICE candidates are reused
when a stream is added. So no real reason to have to clear, and reset in this
instance.
Also, this patch adds a bit of extra logging to aid in diagnosis of any future
problems.
ASTERISK-28742 #close
Change-Id: I34c9e6bad5a39b087164646e2836e3e48fe6892f
The code assumed that when the transport-cc feedback
function was called at least one packet will have been
received. In practice this isn't always true, so now
we just reschedule the sending and do nothing.
Change-Id: Iabe7b358704da446fc3b0596b847bff8b8a0da6a
In Asterisk 16+, there are a few places in ast_rtp_read where we've
allocated a frame list but return a null frame instead of the list.
In these cases, any frames left in the list won't be freed. In the
vast majority of the cases, the list is empty when we return so
there's nothing to free but there have been leaks reported in the
wild that can be traced back to frames left in the list before
returning.
The escape paths now all have logic to free frames left in the
list.
ASTERISK-28609
Reported by: Ted G
Change-Id: Ia1d7075857ebd26b47183c44b1aebb0d8f985f7a
OpenSSL can not tolerate if the packet sent out does not
match the length that it provided to the sender. This change
lies and says that each time the full packet was sent. If
a problem does occur then a retransmission will occur as
appropriate.
ASTERISK-28576
Change-Id: Id42455b15c9dc4eb987c8c023ece6fbf3c22a449
This patch fixes several issues reported by the lgtm code analysis tool:
https://lgtm.com/projects/g/asterisk/asterisk
Not all reported issues were addressed in this patch. This patch mostly fixes
confirmed reported errors, potential problematic code points, and a few other
"low hanging" warnings or recommendations found in core supported modules.
These include, but are not limited to the following:
* innapropriate stack allocation in loops
* buffer overflows
* variable declaration "hiding" another variable declaration
* comparisons results that are always the same
* ambiguously signed bit-field members
* missing header guards
Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25
This change adds support to the JITTERBUFFER dialplan function
for audio and video synchronization. When enabled the RTCP SR
report is used to produce an NTP timestamp for both the audio and
video streams. Using this information the video frames are queued
until their NTP timestamp is equal to or behind the NTP timestamp
of the audio. The audio jitterbuffer acts as the leader deciding
when to shrink/grow the jitterbuffer when adaptive is in use. For
both adaptive and fixed the video buffer follows the size of the
audio jitterbuffer.
ASTERISK-28533
Change-Id: I3fd75160426465e6d46bb2e198c07b9d314a4492
