[Home]

Summary:ASTERISK-29937: res_rtp_asterisk: Resending of NACK requested packet sends different packet
Reporter:Erik Bergschöld (Bergschold)Labels:webrtc
Date Opened:2022-02-25 05:23:03.000-0600Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Resources/res_rtp_asterisk
Versions:18.8.0 Frequency of
Occurrence
Related
Issues:
Environment:Asterisk running on Alma linux 8 and WebRTC on Google chrome Version 98.0.4758.109 Mac OS 12.2Attachments:( 0) asterisk_full
( 1) clientrtpdump.pcap
( 2) serverrtpdump.pcap
Description:I'm testing a 1 to 1 video call with WebRTC to WebRTC through Asterisk. The network has sporadic packetloss, but most often a single package in a few seconds. The package lost causes a freeze for about 2 seconds until the video starts working again. I guess this should not happen if NACK was working? So I've looked at wireshark on both client side and server side and I can see that Webrtc is sending a NACK to Asterisk and asterisk is responding by sending the package again with the right seqnumber and I can see the package arriving at the client side, but Chrome WebRTC does not seem to accept the package because after that Chrome sends the same NACK over and over again for 2 seconds while asterisk is responding with the same package.

By looking at wireshark I can see that the first package sent by Asterisk (The package that was lost) is 10 bytes larger than the package sent as a response to the NACK message. There is also a diff when comparing the payload. Shouldn't the payload be the same for the same package?

This happens everytime there is a single packetloss and is causing the video to freeze alot. I can provide wireshark traces and examples if necessary
Comments:By: Asterisk Team (asteriskteam) 2022-02-25 05:23:05.064-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Asterisk Team (asteriskteam) 2022-02-25 05:23:05.281-0600

We appreciate the difficulties you are facing, however information request type issues would be better served in a different forum.

The Asterisk community provides support over IRC, mailing lists, and forums as described at http://asterisk.org/community. The Asterisk issue tracker is used specifically to track issues concerning bugs and documentation errors.

If this issue is actually a bug please use the Bug issue type instead.

Please see the Asterisk Issue Guidelines [1] for instruction on the intended use of the Asterisk issue tracker.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
By: Asterisk Team (asteriskteam) 2022-02-25 05:27:19.945-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: Joshua C. Colp (jcolp) 2022-02-25 05:30:49.951-0600

The payload can be different because some data changes upon retransmission. You can attach the packet captures and such as well as a debug log[1], but you would also likely need to investigate the browser itself to see if it provides any information as to why it does not like the resent packet.

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Erik Bergschöld (Bergschold) 2022-02-25 06:35:46.132-0600

I've attached 3 files and I've been looking at the stream with SSRC 0x7cf28f5f. That is the stream that is sent to the client that clientrtpdump.pcap was done. There you can see that the client actually receives the packages.

An example package is sequence number = 26019

Let me know if you need more data
By: Erik Bergschöld (Bergschold) 2022-02-25 06:38:56.155-0600

Regarding the payload I've noticed that it's only the first package payload (The lost package) that differs from the rest. All other packages sent after that with the same sequence number are all the same in payload and size
By: Joshua C. Colp (jcolp) 2022-02-25 06:45:17.454-0600

Looking at the packet capture I don't see anything out of the ordinary within the retransmitted packet you've provided. The actual payload itself is the same, what is changing in the packet is the absolute send time - which is expected. That is updated to when the packet was sent on the wire, and is used for bandwidth congestion control. The Asterisk log also shows things working properly.

You'd need to examine browser level debugging to determine what it dislikes about the packets. In the past I've used the debug flags on this gist[1] to do so, but I have not investigated browser level in a few years now.

[1] https://gist.github.com/ibc/3a10b27812d99c8abd1b
By: Joshua C. Colp (jcolp) 2022-02-25 06:47:51.268-0600

That packet doesn't appear in the clientrtpdump packet capture, so I didn't see it. How was it captured?
By: Joshua C. Colp (jcolp) 2022-02-25 06:59:09.833-0600

Oh, duh, because it had been lost. Yeah, something does seem to be going on.
By: Erik Bergschöld (Bergschold) 2022-02-25 07:15:50.260-0600

Okey thanks for the help. I will try to debug the browser. I do have native webrtc clients as well I can test with.

Just to clearify regarding the payload. It could of course be my lack of knowledge regarding payload size and content, but if you look in serverrtpdump.pcap at package No 6019 with sequence number 26019 and compare the payload with No 6037 which is the first retransmitted package with that sequence number. The payload in these two packages do not come out as the same to me, but they do come out the same if you compare all retransmitted packages to eachother. And should the size of the package change because the of the time? Then shouldn't the rest of the restransmitted packages change as well if that was the case?

See example below. These are RTP lines copied from wireshark including payload for each package. Where the first line is the lost package followed by retransmissions

6019 18.130038 0.000275 94.254.89.24 14738 212.247.4.149 49174 RTP 1219 PT=DynamicRTP-Type-98, SSRC=0x7CF28F5F, Seq=26019, Time=2187756447, Mark 2022-02-25 13:19:01.110297
Payload=f73a8671511c2519af2c75c0ca1a3b7e39f6fe74f5d211569a28ea7efbb28d97551ca57d7cf5032ede2a35cfb33211bdd23b9c6f5317508cb927841d6149269e716f232f4d3235551addcf1cf22701d9e82a4b325bfe1c11695564e5dc3da52a1aa24604836cee27f12de3cbc6f2b62601925599b713c3ce3fe65128df9cc5e3b4d9674783a147cb50dc4ff6ad118c0f4fce67570106bafa8b320bfa04f61609bf710d6ff5dd7b46f43488d31c874e2e5a720a1a30d7766914e6d26edc09cf75a5e6390de0eedabb8b279df24d72a84c373530ad6a5d95dcd422e1abc6dcfbbb9c68c380e3814e183e361534f44139aaef26d68306e9e4326ae4a649972cfd7d1605f5adec79b72ab453a2c9ca858392fb7d6d352d5b22bd06e5ac4d84cb65eca6132024ce907d2f49b7950dfaddf794ab9a691b332c1f9ca91d6c63d3a1b97c0372b59c7cd088cc753a02827aec4cf35f0b00339be063aec4ab1d4f2974e06a4789c84c5b88fc0c3cf2599dddf7d9401b0b12c465304ff704e1a234bc37e2763a623914703e3bbfbbd6cd77f603ea96d56f18e3f39ee49cd1a9c3678fbf221007eeb29d19b07866db7c0fbea7c73605a9be903e89f93e05561c39f77a55b5bf801799d2d5b802b8c6ed61d1ada70e56faa9de2d185c894fbfe5ba623e3b3bdbe7104c93925bbb0b95f44e9e1d58b5acadaf4ea8ba3d6d7c9966e38c34858c7995390d95a88d35ca25dced4281432f5afc498b4e0f540d9a7da6e76acbb63940c743ebdf8c5b3bcb26feb9d819dd8d17329fef13735a96f9a998e8b4f250aafbb68303484faa3808c01741b025967aee823ed9656160f9f34c6455ea9faa8900fd79333c6e4f9572489bc3bf5e6e4dcab7bd664a5e2772f07423799c51a043ee49616c113bfa2230abdf70fad4cdeee4175c410e254b5c188c5f51418820ec6d87600f141e9c279d0244b7bd83676905a6d1dbd13ef624ccb237a2891633192490d16d46d2660ec2d912d65834639feef826455d0371a56a2da07596798c90b22c4c46db71a6c8b7564d3c1f2f7dcb8627e122c211fc56dbca98d1afba236d55d3104e103b0eb9a2354e053d8bf7fd6a944913d710dcdeb45cfc4b4d0f45257ed1990357d65eedfac4e21ba9c6d21e3e78bb92142049279a0b9e24ff15496c380367a9f27ad817ae5e96f32af85028d722bb4d65221180bef336e208e17dcd63404767bc5e88b8a05d1bf530b6d99ec16ba84d258351d4b739d458802d120d4f99b2883d2bc6b31a04cc29ccd8169320c7afdb8ee81ece1e83c7571abfdc9ac6f18cf7c3c211ac3bbbc9735386b68c57e5d6d1bfff0beb976fc7465d99fbdb1abc71566e64a1d4ac568c2eb3ee971f6ec6b6bb65909c1fb16c58323ceb6b1f9bcc6d7d489f6427b57e5d6c04eee1506f537243c70e48b5a87bd17be52c96d902b5bb0db584faac335f1ffd643d45a6d32dfab1b18b4ffc001f47172fea07397776d14848fb065c6ae9097889538f649a9bda5345a774bd046bdc29a264d03caf94b044b4bafc1f8ff19d3e9876ca81e1a6ad48247e088310417f93f8ece0fd7d8f8ff412554176813b0c01c7763b0c3fef259ea30404c7cf52393e8089c28b6ca94e35e437

6037 18.149442 0.000151 94.254.89.24 14738 212.247.4.149 49174 RTP 1209 PT=DynamicRTP-Type-98, SSRC=0x7CF28F5F, Seq=26019, Time=2187756447, Mark 2022-02-25 13:19:01.129701
Payload=c5ed74716bf0c70652235d732d5de8cdca034d6d36823ed514594cd52abe0176125de65db187b7c0fcc57eb029e3254a8e5af576f5aff7d747e46ea1b5dbab1682b74ba74779296e45219491faefd9f6146318c6aefc9caaca35837f398e3dd8fa3bbf307b8f2e735ffe5a63bdcb5ba347c328f8ac6c9238fdd734a5b9647b8df6620e882a796dc7d3a90358181d863294b144257bd5d468a3061780d3ae9b00eeca2158cca68dd8508755274226afef188700630fbf84a0228c1a9d530cf0035e63c140fabd1a9df067ffb5814542bd7901597e5cbe708b18781496416c2e81b1800a03c607c44b2144c96caac5851838a6cfcfb97e0b8bc5952b7fed2ee052cd280d63c64ba9391962967e1391d0eaa31e3822c3ba15dddb358d3adbffc250ade68225a78d707304a118761f6b14aa55c3b3008b49ad50861f6311a9069a543a4ca561b89c5239b2c9ebe7ceda6f429388ccb862a47a62ccefb580081d1c72c1962c52cd947a97560d24db4aff1f68671fc22a959816a1da0cdfe7457d12fd54cf9ac4e5cad820a4809b62845e8dd0e711c3d77067072971e6e72ff937f547180a89124b6817f69416fc7e0114130208e8535f60977c673fd33a20a1a5695c287fbc844d0c4a70d4b505aa0f983ee161b863034e50c3a9964cb437c2d9e3af8751eab30ccc2c14ad5eed2e54165340eb9ee2d509201785aec60a0105d4ff45357330f1208fbc7d55e3eb483ee1f3a15ae726bb5400ffcc991dde0797c596403f862166e44641f8ba4b55c0860e54d852a84ba65c00acea8ab92e7aa70831b0233ef5cc0172c278864deb3ddcfc9c2fab1a701006ca932b290ca2113210a46bb7e62cf33fcafdb57e7adc95603e2c70a19a9b5cf40c01c5eedc423236266f3af600ff5826695aeddb11cfa31ce4c408942fe0dd3261df440dc39fa5bc20b95c40ed3fcfc8dcd01ea110fd98f63696d86cdef924d6a6c21b601527c1a3f13f125dfdc3d95b1f875f2aa70d7c6462b2115cd7c02f3766c4085dcca52ae90c1decfa9924e4a87f0fae534546aafc333740fe7887b94af79a24a1e46f1bca3fd92809c3f5d249262b352ec2a53c21b71ddc0049b08351b543332b8f4765d25d682863d065268b7431013ffc9d563b55bf0ef5a3b603f339f3f6e9a72e715b04bb1799a639bfd51329662b4b28a2a6f95bff89d2b89b6cb66eb9b8e2c11fde8fb9ce6a3c8657d7755d46207c4ba1f1c5029bb38fceb4eecbb892233e637a9f4a4fb9d8ed84500e4604fd8191ce4abf818d91a0fda6f6b0468d708ded5936ebfb1efee43b2961722860956f8b4de34d29f3750b4b45f4e77bb9a5d454f6fd272a3fd664835f9b5aabc6cda91690f70499280bef89e988487bca4b0c8f1c1355ceef102d45738b1f48d3e65029807a12810d13a2026909111587fbad158c00caf788372d2c9d2c705f19c81d85cf47aecf34e02c2a7b019c0d8986d1331ba4382dd1c121bbcc0e6db2e631d66df84a1296aec819c277c5754fa046c0d995f1ecc3062ff2319c5bd0f5df3ac85a1bee5e201ecb1b4ba9a0d30b96a54a90be1b0477432f8a43be40fe2171d919ef68b323167604571d7ffe610bfd4e1eee00

6045 18.155670 0.000542 94.254.89.24 14738 212.247.4.149 49174 RTP 1209 PT=DynamicRTP-Type-98, SSRC=0x7CF28F5F, Seq=26019, Time=2187756447, Mark 2022-02-25 13:19:01.135929
Payload=c5ed74716bf0c70652235d732d5de8cdca034d6d36823ed514594cd52abe0176125de65db187b7c0fcc57eb029e3254a8e5af576f5aff7d747e46ea1b5dbab1682b74ba74779296e45219491faefd9f6146318c6aefc9caaca35837f398e3dd8fa3bbf307b8f2e735ffe5a63bdcb5ba347c328f8ac6c9238fdd734a5b9647b8df6620e882a796dc7d3a90358181d863294b144257bd5d468a3061780d3ae9b00eeca2158cca68dd8508755274226afef188700630fbf84a0228c1a9d530cf0035e63c140fabd1a9df067ffb5814542bd7901597e5cbe708b18781496416c2e81b1800a03c607c44b2144c96caac5851838a6cfcfb97e0b8bc5952b7fed2ee052cd280d63c64ba9391962967e1391d0eaa31e3822c3ba15dddb358d3adbffc250ade68225a78d707304a118761f6b14aa55c3b3008b49ad50861f6311a9069a543a4ca561b89c5239b2c9ebe7ceda6f429388ccb862a47a62ccefb580081d1c72c1962c52cd947a97560d24db4aff1f68671fc22a959816a1da0cdfe7457d12fd54cf9ac4e5cad820a4809b62845e8dd0e711c3d77067072971e6e72ff937f547180a89124b6817f69416fc7e0114130208e8535f60977c673fd33a20a1a5695c287fbc844d0c4a70d4b505aa0f983ee161b863034e50c3a9964cb437c2d9e3af8751eab30ccc2c14ad5eed2e54165340eb9ee2d509201785aec60a0105d4ff45357330f1208fbc7d55e3eb483ee1f3a15ae726bb5400ffcc991dde0797c596403f862166e44641f8ba4b55c0860e54d852a84ba65c00acea8ab92e7aa70831b0233ef5cc0172c278864deb3ddcfc9c2fab1a701006ca932b290ca2113210a46bb7e62cf33fcafdb57e7adc95603e2c70a19a9b5cf40c01c5eedc423236266f3af600ff5826695aeddb11cfa31ce4c408942fe0dd3261df440dc39fa5bc20b95c40ed3fcfc8dcd01ea110fd98f63696d86cdef924d6a6c21b601527c1a3f13f125dfdc3d95b1f875f2aa70d7c6462b2115cd7c02f3766c4085dcca52ae90c1decfa9924e4a87f0fae534546aafc333740fe7887b94af79a24a1e46f1bca3fd92809c3f5d249262b352ec2a53c21b71ddc0049b08351b543332b8f4765d25d682863d065268b7431013ffc9d563b55bf0ef5a3b603f339f3f6e9a72e715b04bb1799a639bfd51329662b4b28a2a6f95bff89d2b89b6cb66eb9b8e2c11fde8fb9ce6a3c8657d7755d46207c4ba1f1c5029bb38fceb4eecbb892233e637a9f4a4fb9d8ed84500e4604fd8191ce4abf818d91a0fda6f6b0468d708ded5936ebfb1efee43b2961722860956f8b4de34d29f3750b4b45f4e77bb9a5d454f6fd272a3fd664835f9b5aabc6cda91690f70499280bef89e988487bca4b0c8f1c1355ceef102d45738b1f48d3e65029807a12810d13a2026909111587fbad158c00caf788372d2c9d2c705f19c81d85cf47aecf34e02c2a7b019c0d8986d1331ba4382dd1c121bbcc0e6db2e631d66df84a1296aec819c277c5754fa046c0d995f1ecc3062ff2319c5bd0f5df3ac85a1bee5e201ecb1b4ba9a0d30b96a54a90be1b0477432f8a43be40fe2171d919ef68b323167604571d7ffe610bfd4e1eee00

6060 18.174963 0.000047 94.254.89.24 14738 212.247.4.149 49174 RTP 1209 PT=DynamicRTP-Type-98, SSRC=0x7CF28F5F, Seq=26019, Time=2187756447, Mark 2022-02-25 13:19:01.155222
Payload=Same as above

6071 18.195598 0.000233 94.254.89.24 14738 212.247.4.149 49174 RTP 1209 PT=DynamicRTP-Type-98, SSRC=0x7CF28F5F, Seq=26019, Time=2187756447, Mark 2022-02-25 13:19:01.175857
Payload=Same as above
By: Joshua C. Colp (jcolp) 2022-02-25 07:28:48.128-0600

I would expect them to based on the available information, which is why I've opened this issue.
By: Erik Bergschöld (Bergschold) 2022-03-01 02:55:45.462-0600

I've been looking in to this issue more in detail and as an update if someone else is working on it... when testing the code and comparing the RTP payload in res_rtp_asterisk.c I see that the issue lies in that the first packet (The packet that is lost) is getting encrypted while the retransmitted packets are not. I guess that's why they are 10 bytes smaller and why the webrtc client is not accepting the restransmission.

Specifically in __rtp_sendto(struct ast_rtp_instance *instance, void *buf, size_t size, int flags, struct ast_sockaddr *sa, int rtcp, int *via_ice, int use_srtp)
for the first packet the bytes of param temp changes after res_srtp->protect(srtp, &temp, &len, rtcp)

for the retransmitted packets it does not.
By: Erik Bergschöld (Bergschold) 2022-03-01 09:10:41.989-0600

Update again... I found this line in res_srtp.c
if ((res = rtcp ? srtp_protect_rtcp(srtp->session, localbuf, len) : srtp_protect(srtp->session, localbuf, len)) != err_status_ok && res != err_status_replay_fail) {

This means that "err_status_replay_fail" from srtp is ignored and an unencrypted packet will be sent instead. This doesn't seem like a very good behaviour?

And I'm not sure how this NACK function is supposed to work if you can't encrypt another packet with the same sequence number again? Because if I remove res != err_status_replay_fail then asterisk will throw WARNING[2879428][C-621e3327]: res_srtp.c:535 ast_srtp_protect: SRTP protect: replay check failed (bad index)

Any idea how this i s supposed to work?
By: Joshua C. Colp (jcolp) 2022-03-01 09:14:55.025-0600

If I recall correctly you can encrypt again, to a point. At least you could when the NACK code was originally written and used with libsrtp, it's possible that more recent versions of libsrtp have changed things.
By: Erik Bergschöld (Bergschold) 2022-03-01 09:41:39.614-0600

Not in the version I'm using, but maybe it's possible to patch libsrtp for this.

Otherwise I found this discussion group saying the "right" way is to follow the spec now, signaling the RTX stream and ssrc number and payload type, and on the wire the RTX packets are basically their own separate stream (multiplexed) with its on SSRC value (assigned in SDP) and its own sequence number space

to signal the spec-compliant format (rfc4588), make sure sdp contains at these lines related to the video:

m=video 9 UDP/TLS/RTP/SAVPF 100 96     // these are payload types, 100 for video and 96 for the RTX
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtpmap:96 rtx/90000  // these are to signal the rfc4588 RTX packet transmission format
a=fmtp:96 apt=100        // this ties togetehr the two saying that packets with PT 96 are for the PT 100 stream

a=ssrc-group:FID 4069523937 476665172  // this is what says that  '476665172 ' is the ssrc repair identifier for the '4069523937'  stream
a=ssrc:4069523937 cname:mKSXF68N+X61D4OT
a=ssrc:4069523937 msid:zN9qFKoJrs4jTUm39bsSdA8KAI6jL7Q0gj4T 32db7cba-bd60-4022-8a20-b83c8b93be9f
a=ssrc:4069523937 mslabel:zN9qFKoJrs4jTUm39bsSdA8KAI6jL7Q0gj4T
a=ssrc:4069523937 label:32db7cba-bd60-4022-8a20-b83c8b93be9f
a=ssrc:476665172 cname:mKSXF68N+X61D4OT
a=ssrc:476665172 msid:zN9qFKoJrs4jTUm39bsSdA8KAI6jL7Q0gj4T 32db7cba-bd60-4022-8a20-b83c8b93be9f
a=ssrc:476665172 mslabel:zN9qFKoJrs4jTUm39bsSdA8KAI6jL7Q0gj4T
a=ssrc:476665172 label:32db7cba-bd60-4022-8a20-b83c8b93be9f


if you leave this out and your signalling looks like this instead:
m=video 9 UDP/TLS/RTP/SAVPF 100
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=ssrc:4069523937 cname:mKSXF68N+X61D4OT
a=ssrc:4069523937 msid:zN9qFKoJrs4jTUm39bsSdA8KAI6jL7Q0gj4T 32db7cba-bd60-4022-8a20-b83c8b93be9f
a=ssrc:4069523937 mslabel:zN9qFKoJrs4jTUm39bsSdA8KAI6jL7Q0gj4T
a=ssrc:4069523937 label:32db7cba-bd60-4022-8a20-b83c8b93be9f
then the stack is going to send the OLD (bad) format which your SRTP decrypter is going to fail with replay attack errors.


Found in this link https://groups.google.com/g/discuss-webrtc/c/Gx0yUGeAYIQ?pli=1
By: Joshua C. Colp (jcolp) 2022-03-01 09:46:44.817-0600

Yes, there's a specification for doing it. It's not currently implemented or supported.
By: Erik Bergschöld (Bergschold) 2022-03-01 09:54:04.326-0600

Yes I thought so, but shared it anyway if there might be an interest implementing it in the future. Well thanks for the help anyway I will try to turn off the replay protection for now and hope that the webrtc implementations supports it for a while
By: Erik Bergschöld (Bergschold) 2022-03-02 02:33:39.879-0600

Got it to work by adding

policy->sp.allow_repeat_tx = 1;

in res_srtp.c

static int ast_srtp_add_stream(struct ast_srtp *srtp, struct ast_srtp_policy *policy)
{
   struct ast_srtp_policy *match;

   /* For existing streams, replace if its an SSRC stream, or bail if its a wildcard */
   if ((match = find_policy(srtp, &policy->sp, OBJ_POINTER))) {
       if (policy->sp.ssrc.type != ssrc_specific) {
           ast_log(AST_LOG_WARNING, "Cannot replace an existing wildcard policy\n");
           ao2_t_ref(match, -1, "Unreffing already existing policy");
           return -1;
       } else {
           if (srtp_remove_stream(srtp->session, match->sp.ssrc.value) != err_status_ok) {
               ast_log(AST_LOG_WARNING, "Failed to remove SRTP stream for SSRC %u\n", match->sp.ssrc.value);
           }
           ao2_t_unlink(srtp->policies, match, "Remove existing match policy");
           ao2_t_ref(match, -1, "Unreffing already existing policy");
       }
   }

   policy->sp.allow_repeat_tx = 1; //Solution for RTP retransmission

   ast_debug(3, "Adding new policy for %s %u\n",
       policy->sp.ssrc.type == ssrc_specific ? "SSRC" : "type",
       policy->sp.ssrc.type == ssrc_specific ? policy->sp.ssrc.value : policy->sp.ssrc.type);
   if (srtp_add_stream(srtp->session, &policy->sp) != err_status_ok) {
       ast_log(AST_LOG_WARNING, "Failed to add SRTP stream for %s %u\n",
           policy->sp.ssrc.type == ssrc_specific ? "SSRC" : "type",
           policy->sp.ssrc.type == ssrc_specific ? policy->sp.ssrc.value : policy->sp.ssrc.type);
       return -1;
   }

   ao2_t_link(srtp->policies, policy, "Added additional stream");

   return 0;
}

I'm unsure of the security risks with this solution though. This is a note from libsrtp
int        allow_repeat_tx;  /**< Whether retransmissions of
*   packets with the same sequence number
*   are allowed.  (Note that such repeated
*   transmissions must have the same RTP
*   payload, or a severe security weakness
*   is introduced!)                      */

This could of course be added as a conf setting. I found the rtp.conf setting "srtpreplayprotection", but it did not work in my case since it's only used in decrypt and by looking at the description and implementation it's seems that it creates a new srtp instance everytime and that is probably not suitable for NACK retransmissions since they can occur often
By: Erik Bergschöld (Bergschold) 2023-01-17 13:59:46.628-0600

Just wanted to add that we have run this fix together with https://issues.asterisk.org/jira/browse/ASTERISK-29963?filter=-2 for a couple of months now and it has considerably enhanced the video quality in our tests and for our customers. Do you want me to upload the 2 patches we made?