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

These are the remaining issues found in /res.

ASTERISK-29761

Change-Id: I572e6019c422780dde5ce8448b6c85c77af6046d

Correct typos of the following word families:

identifying
structures
actcount
initializer
attributes
statement
enough
locking
declaration
userevent
provides
unregister
session
execute
searches
verification
suppressed
prepared
passwords
recipients
event
because
brief
unidentified
redundancy
character
the
module
reload
operation
backslashes
accurate
incorrect
collision
initializing
instance
interpreted
buddies
omitted
manually
requires
queries
generator
scheduler
configuration has
owner
resource
performed
masquerade
apparently
routable

ASTERISK-29714

Change-Id: I88485116d2c59b776aa2e1f8b4ce8239a21decda

Add missing reference decrement in rtp_deallocate_transport()

ASTERISK-29671

Change-Id: I8d22dbedb90e8dade0829b7a28372f404b07caa9

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

ASTERISK-29616

Change-Id: I6c01623926bf10ccac32612687a50fdab3ba0900

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

This patch makes the drop_packets_data object static.

Change-Id: If4f9b21fa0c47d41a35b6b05941d978efb4da87b

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

Add option "srtpreplayprotection" rtp.conf to enable srtp
replay protection.

ASTERISK-29260
Reported by: Alexander Traud

Change-Id: I5cd346e3c6b6812039d1901aa4b7be688173b458

ASTERISK-29205 #close

Change-Id: Ib7aa65644e8df76e2378d7613ee7cf751b9d0bea

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
(cherry picked from commit 56028426)

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

Added freeifaddrs() for memory releasing.

ASTERISK-28904

Change-Id: I109403866e85a30659351946903a679de9727a8f

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

When the first DTMF receive in RF2833 codec have TimeStamp at 0
is not processed.

ASTERISK-28812

Change-Id: I3196803a062dd2daee4938c9a778c3810cb7e504

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>

Change-Id: Ifc5059cd867e77b9c92ed9f4b895a9a91200d3ec

ASTERISK-28809

Change-Id: I269731715347c8e5ef7db1b6ffd3f8d15fc04be4

ASTERISK-28790

Change-Id: I10df52f98b19ed62575f25dab36e82d136dccd99

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