[asterisk-bugs] [JIRA] (ASTERISK-29937) res_rtp_asterisk: Chrome WebRTC does not accept resent packages after NACK message

[Joshua C. Colp (JIRA)]

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

Joshua C. Colp commented on ASTERISK-29937:
-------------------------------------------

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

> res_rtp_asterisk: Chrome WebRTC does not accept resent packages after NACK message
> ----------------------------------------------------------------------------------
>
>                 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)