[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=258246#comment-258246 ] 

Erik Bergschöld commented on ASTERISK-29937:
--------------------------------------------

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

> 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)