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

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

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

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

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