365 Commits

Author SHA1 Message Date
Ben Ford
adde97bff3 res_rtp_asterisk: Don't send RTP before DTLS has negotiated.
There was no check in __rtp_sendto that prevented Asterisk from sending
RTP before DTLS had finished negotiating. This patch adds logic to do
so.

Fixes: #1260
2025-08-14 15:22:26 +00:00
Sean Bright
777cd31d22 res_rtp_asterisk.c: Don't truncate spec-compliant ice-ufrag or ice-pwd.
RFC 8839[1] indicates that the `ice-ufrag` and `ice-pwd` attributes
can be up to 256 bytes long. While we don't generate values of that
size, we should be able to accomodate them without truncating.

1. https://www.rfc-editor.org/rfc/rfc8839#name-ice-ufrag-and-ice-pwd-attri
2025-03-13 13:14:02 +00:00
Maximilian Fridrich
e02de88e4e Revert "res_rtp_asterisk.c: Set Mark on rtp when timestamp skew is too big"
This reverts commit f30ad96b3f.

The original change was not RFC compliant and caused issues because it
set the RTP marker bit in cases when it shouldn't be set. See the
linked issue #1135 for a detailed explanation.

Fixes: #1135.
2025-03-03 19:29:51 +00:00
Sean Bright
9665903d4b res_rtp_asterisk.c: Use correct timeout value for T.140 RED timer.
Found while reviewing #1128
2025-03-03 14:11:59 +00:00
Viktor Litvinov
f30ad96b3f res_rtp_asterisk.c: Set Mark on rtp when timestamp skew is too big
Set Mark bit in rtp stream when timestamp skew is bigger than MAX_TIMESTAMP_SKEW.

Fixes: #927
2024-12-02 12:58:56 +00:00
Alexey Vasilyev
dc64d485d7 res_rtp_asterisk.c: Fix bridged_payload matching with sample rate for DTMF
Fixes #1004
2024-12-02 12:56:19 +00:00
Sean Bright
c13ef65f21 Revert "res_rtp_asterisk: Count a roll-over of the sequence number even on lost packets."
This reverts commit cb5e3445be.

The original change from 16 to 15 bit sequence numbers was predicated
on the following from the now-defunct libSRTP FAQ on sourceforge.net:

> *Q6. The use of implicit synchronization via ROC seems
> dangerous. Can senders and receivers lose ROC synchronization?*
>
> **A.** It is possible to lose ROC synchronization between sender and
> receiver(s), though it is not likely in practice, and practical
> steps can be taken to avoid it. A burst loss of 2^16 packets or more
> will always break synchronization. For example, a conversational
> voice codec that sends 50 packets per second will have its ROC
> increment about every 22 minutes. A network with a burst of packet
> loss that long has problems other than ROC synchronization.
>
> There is a higher sensitivity to loss at the very outset of an SRTP
> stream. If the sender's initial sequence number is close to the
> maximum value of 2^16-1, and all packets are lost from the initial
> packet until the sequence number cycles back to zero, the sender
> will increment its ROC, but the receiver will not. The receiver
> cannot determine that the initial packets were lost and that
> sequence-number rollover has occurred. In this case, the receiver's
> ROC would be zero whereas the sender's ROC would be one, while their
> sequence numbers would be so close that the ROC-guessing algorithm
> could not detect this fact.
>
> There is a simple solution to this problem: the SRTP sender should
> randomly select an initial sequence number that is always less than
> 2^15. This ensures correct SRTP operation so long as fewer than 2^15
> initial packets are lost in succession, which is within the maximum
> tolerance of SRTP packet-index determination (see Appendix A and
> page 14, first paragraph of RFC 3711). An SRTP receiver should
> carefully implement the index-guessing algorithm. A naive
> implementation can unintentionally guess the value of
> 0xffffffffffffLL whenever the SEQ in the packet is greater than 2^15
> and the locally stored SEQ and ROC are zero. (This can happen when
> the implementation fails to treat those zero values as a special
> case.)
>
> When ROC synchronization is lost, the receiver will not be able to
> properly process the packets. If anti-replay protection is turned
> on, then the desynchronization will appear as a burst of replay
> check failures. Otherwise, if authentication is being checked, then
> it will appear as a burst of authentication failures. Otherwise, if
> encryption is being used, the desynchronization may not be detected
> by the SRTP layer, and the packets may be improperly decrypted.

However, modern libSRTP (as of 1.0.1[1]) now mentions the following in
their README.md[2]:

> The sequence number in the rtp packet is used as the low 16 bits of
> the sender's local packet index. Note that RTP will start its
> sequence number in a random place, and the SRTP layer just jumps
> forward to that number at its first invocation. An earlier version
> of this library used initial sequence numbers that are less than
> 32,768; this trick is no longer required as the
> rdbx_estimate_index(...) function has been made smarter.

So truncating our initial sequence number to 15 bit is no longer
necessary.

1. 0eb007f0dc/CHANGES (L271-L289)
2. 2de20dd9e9/README.md (implementation-notes)
2024-10-17 16:30:03 +00:00
George Joseph
5d978ffcce res_rtp_asterisk: Fix dtls timer issues causing FRACKs and SEGVs
In dtls_srtp_handle_timeout(), when DTLSv1_get_timeout() returned
success but with a timeout of 0, we were stopping the timer and
decrementing the refcount on instance but not resetting the
timeout_timer to -1.  When dtls_srtp_stop_timeout_timer()
was later called, it was atempting to stop a stale timer and could
decrement the refcount on instance again which would then cause
the instance destructor to run early.  This would result in either
a FRACK or a SEGV when ast_rtp_stop(0 was called.

According to the OpenSSL docs, we shouldn't have been stopping the
timer when DTLSv1_get_timeout() returned success and the new timeout
was 0 anyway.  We should have been calling DTLSv1_handle_timeout()
again immediately so we now reschedule the timer callback for
1ms (almost immediately).

Additionally, instead of scheduling the timer callback at a fixed
interval returned by the initial call to DTLSv1_get_timeout()
(usually 999 ms), we now reschedule the next callback based on
the last call to DTLSv1_get_timeout().

Resolves: #487
2024-10-01 14:22:48 +00:00
Mike Bradeen
055031dfcb res_pjsip_sdp_rtp: Use negotiated DTMF Payload types on bitrate mismatch
When Asterisk sends an offer to Bob that includes 48K and 8K codecs with
matching 4733 offers, Bob may want to use the 48K audio codec but can not
accept 48K digits and so negotiates for a mixed set.

Asterisk will now check Bob's offer to make sure Bob has indicated this is
acceptible and if not, will use Bob's preference.

Fixes: #847
2024-09-03 15:29:40 +00:00
Mike Bradeen
52bdfe09ab res_pjsip_sdp_rtp: Add support for default/mismatched 8K RFC 4733/2833 digits
After change made in 624f509 to add support for non 8K RFC 4733/2833 digits,
Asterisk would only accept RFC 4733/2833 offers that matched the sample rate of
the negotiated codec(s).

This change allows Asterisk to accept 8K RFC 4733/2833 offers if the UAC
offfers 8K RFC 4733/2833 but negotiates for a non 8K bitrate codec.

A number of corresponding tests in tests/channels/pjsip/dtmf_sdp also needed to
be re-written to allow for these scenarios.

Fixes: #776
2024-07-10 16:50:47 +00:00
Mike Bradeen
3b4d2a6506 rtp_engine: add support for multirate RFC2833 digits
Add RFC2833 DTMF support for 16K, 24K, and 32K bitrate codecs.

Asterisk currently treats RFC2833 Digits as a single rtp payload type
with a fixed bitrate of 8K.  This change would expand that to 8, 16,
24 and 32K.

This requires checking the offered rtp types for any of these bitrates
and then adding an offer for each (if configured for RFC2833.)  DTMF
generation must also be changed in order to look at the current outbound
codec in order to generate appropriately timed rtp.

For cases where no outgoing audio has yet been sent prior to digit
generation, Asterisk now has a concept of a 'preferred' codec based on
offer order.

On inbound calls Asterisk will mimic the payload types of the RFC2833
digits.

On outbound calls Asterisk will choose the next free payload types starting
with 101.

UserNote: No change in configuration is required in order to enable this
feature. Endpoints configured to use RFC2833 will automatically have this
enabled. If the endpoint does not support this, it should not include it in
the SDP offer/response.

Resolves: #699
2024-05-14 13:35:40 +00:00
romryz
162c920f90 res_rtp_asterisk.c: Correct coefficient in MOS calculation.
Media Experience Score relies on incorrect pseudo_mos variable
calculation. According to forming an opinion section of the
documentation, calculation relies on ITU-T G.107 standard:

    https://docs.asterisk.org/Deployment/Media-Experience-Score/#forming-an-opinion

ITU-T G.107 Annex B suggests to calculate MOS with a coefficient
"seven times ten to the power of negative six", 7 * 10^(-6). which
would mean 6 digits after the decimal point. Current implementation
has 7 digits after the decimal point, which downrates the calls.

Fixes: #597
2024-02-14 15:05:40 +00:00
George Joseph
8c3ececb12 res_rtp_asterisk: Fix regression issues with DTLS client check
* 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: #500
Resolves: #503
Resolves: #505
2023-12-20 14:02:33 +00:00
George Joseph
d7d7764cb0 res_rtp_asterisk.c: Check DTLS packets against ICE candidate list
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
2023-12-14 18:48:17 +00:00
Sean Bright
83636e4b92 res_rtp_asterisk.c: Update for OpenSSL 3+.
In 5ac5c2b0 we defined `OPENSSL_SUPPRESS_DEPRECATED` to silence
deprecation warnings. This commit switches over to using
non-deprecated API.
2023-11-28 19:54:59 +00:00
Brad Smith
6ec59e1e04 res_rtp_asterisk.c: Fix runtime issue with LibreSSL
The module will fail to load. Use proper function DTLS_method() with LibreSSL.
2023-11-07 12:42:16 +00:00
Sean Bright
99527745eb res_rtp_asterisk.c: Fix memory leak in ephemeral certificate creation.
Fixes #386
2023-10-27 15:53:36 +00:00
Vitezslav Novy
8079e5eec4 res_rtp_asterisk: fix wrong counter management in ioqueue objects
In function  rtp_ioqueue_thread_remove counter in ioqueue object is not decreased
which prevents unused ICE TURN threads from being removed.

Resolves: #301
2023-09-20 15:03:17 +00:00
zhengsh
d3c4f93ca6 res_rtp_asterisk: Move ast_rtp_rtcp_report_alloc using rtp->themssrc_valid into the scope of the rtp_instance lock.
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
2023-07-12 15:56:24 +00:00
Sean Bright
c85fc1278f doxygen: Fix doxygen errors.
Change-Id: Ic50e95b4fc10f74ab15416d908e8a87ee8ec2f85
2023-01-31 11:23:11 -06:00
George Joseph
91415a83d1 res_rtp_asterisk: Don't use double math to generate timestamps
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
2023-01-12 07:01:21 -06:00
George Joseph
7dc8773178 res_rtp_asterisk: Asterisk Media Experience Score (MES)
-----------------

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
2023-01-09 11:40:58 -06:00
George Joseph
3a3d6c7dcb Revert "res_rtp_asterisk: Asterisk Media Experience Score (MES)"
This reverts commit e66c5da145.

Reason for revert: Issue when transcoding to/from g722

Change-Id: I12853c5b1d3a77f5b9200f41908fd238a17159dc
2023-01-09 08:20:22 -06:00
George Joseph
e66c5da145 res_rtp_asterisk: Asterisk Media Experience Score (MES)
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
2023-01-03 07:54:51 -06:00
Sean Bright
5ac5c2b0ab openssl: Supress deprecation warnings from OpenSSL 3.0
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
2022-03-28 12:19:42 -05:00
Torrey Searle
7b15ced930 res/res_rtp_asterisk: fix skip in rtp sequence numbers after dtmf
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
2022-01-31 07:52:30 -06:00
Naveen Albert
d35e292ae4 res_rtp_asterisk: Fix typo in flag test/set
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
2022-01-19 08:50:45 -06:00
Mike Bradeen
59fcd1e7e2 res_rtp_asterisk: Addressing possible rtp range issues
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
2021-12-06 10:05:07 -06:00
Alexander Traud
a85f2bf34d res: Fix for Doxygen.
These are the remaining issues found in /res.

ASTERISK-29761

Change-Id: I572e6019c422780dde5ce8448b6c85c77af6046d
2021-12-03 10:38:39 -06:00
Josh Soref
9ae9893c63 res: Spelling fixes
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
2021-11-15 16:37:34 -06:00
Jean Aunis
6bc747b639 res_rtp_asterisk: fix memory leak
Add missing reference decrement in rtp_deallocate_transport()

ASTERISK-29671

Change-Id: I8d22dbedb90e8dade0829b7a28372f404b07caa9
2021-09-29 09:51:13 -05:00
Guido Falsi
29ad5b18f1 res_rtp_asterisk.c: Fix build failure when not building with pjproject.
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
2021-09-20 15:49:24 -05:00
Sebastien Duthil
6fbf55ac11 res_rtp_asterisk: Automatically refresh stunaddr from DNS
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
2021-09-01 10:29:39 -05:00
Alexander Traud
63d27af3ca res_rtp_asterisk: sqrt(.) requires the header math.h.
ASTERISK-29616

Change-Id: I6c01623926bf10ccac32612687a50fdab3ba0900
2021-08-25 18:04:36 -05:00
Joshua C. Colp
a985e5069c res_rtp_asterisk: Set correct raddr port on RTCP srflx candidates.
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
2021-05-26 10:35:44 -05:00
Jeremy Lainé
d162789c4d res_rtp_asterisk: make it possible to remove SOFTWARE attribute
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
2021-05-21 10:37:23 -05:00
Sean Bright
b1807d440e res_rtp_asterisk: More robust timestamp checking
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
2021-04-30 09:03:39 -05:00
Kevin Harwell
0fc906a5e1 res_rtp_asterisk: Fix standard deviation calculation
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
2021-04-01 08:43:20 -05:00
Kevin Harwell
c4a376aac2 res_rtp_asterisk: Don't count 0 as a minimum lost packets
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
2021-03-31 15:09:39 -05:00
Kevin Harwell
65b68fd060 res_rtp_asterisk: Statically declare rtp_drop_packets_data object
This patch makes the drop_packets_data object static.

Change-Id: If4f9b21fa0c47d41a35b6b05941d978efb4da87b
2021-03-31 14:09:01 -06:00
Joshua C. Colp
8bd13a995a res_rtp_asterisk: Only raise flash control frame on end.
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
2021-03-31 11:55:12 -05:00
Kevin Harwell
b86f1ef54c res_rtp_asterisk: Add a DEVMODE RTP drop packets CLI command
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
2021-03-31 11:54:17 -05:00
Joshua C. Colp
cce5ee5b7a res_rtp_asterisk: Force resync on SSRC change.
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
2021-03-17 11:43:35 -06:00
Torrey Searle
8c247e2a94 res/res_rtp_asterisk: generate new SSRC on native bridge end
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
2021-03-08 08:14:34 -06:00
Salah Ahmed
5d42dd2e6a res_rtp_asterisk: Check remote ICE reset and reset local ice attrb
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
2021-03-03 09:53:59 -06:00
Kevin Harwell
e5e49d7ecd res_rtp_asterisk: Add packet subtype during RTCP debug when relevant
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
2021-02-26 08:06:28 -06:00
Alexander Traud
389b8b0774 rtp: Enable srtp replay protection
Add option "srtpreplayprotection" rtp.conf to enable srtp
replay protection.

ASTERISK-29260
Reported by: Alexander Traud

Change-Id: I5cd346e3c6b6812039d1901aa4b7be688173b458
2021-02-18 10:36:22 -06:00
Sean Bright
e7b13df394 res_rtp_asterisk.c: Fix signed mismatch that leads to overflow
ASTERISK-29205 #close

Change-Id: Ib7aa65644e8df76e2378d7613ee7cf751b9d0bea
2021-02-18 10:33:12 -06:00
Kevin Harwell
56028426de Logging: Add debug logging categories
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
2020-10-02 12:58:18 -05:00
Joshua C. Colp
c84d962eae res_rtp_asterisk: Don't assume setting retrans props means to enable.
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
2020-06-11 18:04:24 -05:00