[asterisk-bugs] [JIRA] (ASTERISK-29937) res_rtp_asterisk: Resending of NACK requested packet sends different packet

[Erik Bergschöld (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258242#comment-258242 ] 

Erik Bergschöld edited comment on ASTERISK-29937 at 3/1/22 2:56 AM:
--------------------------------------------------------------------

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.


was (Author: bergschold):
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 packages 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.

> res_rtp_asterisk: Resending of NACK requested packet sends different packet
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-29937
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29937
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 18.8.0
>         Environment: Asterisk running on Alma linux 8 and WebRTC on Google chrome Version 98.0.4758.109 Mac OS 12.2
>            Reporter: Erik Bergschöld
>            Assignee: Unassigned
>              Labels: webrtc
>         Attachments: asterisk_full, clientrtpdump.pcap, serverrtpdump.pcap
>
>
> 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



--
This message was sent by Atlassian JIRA
(v6.2#6252)