[SR-Users] Fwd: rtpengine timestamp jumps

Rtpengine support- I am re-posting again, as I noticed on the SR-USERs web page no HTML or inline images are showing (https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…). The Wireshark screencap that demonstrates the issue is uploaded at: https://www.signalogic.com/images/rtpengine_wireshark_capture_timestamp_jum… all other info remains the same. Thanks, Jeff ----- Forwarded message from Jeff Brower <jbrower(a)signalogic.com> ----- Date: Fri, 17 May 2024 17:10:10 +0000 From: Jeff Brower <jbrower(a)signalogic.com> Subject: Fwd: [SR-Users] rtpengine timestamp jumps To: sr-users(a)lists.kamailio.org Reposting this. If there is an issue with HTML format and/or wireshark screen cap and I need to upload that separately somewhere else, please let me know. Thanks. -Jeff ----- Forwarded message from Jeff Brower <jbrower(a)signalogic.com> -----    Date: Thu, 09 May 2024 05:32:27 +0000    From: Jeff Brower <jbrower(a)signalogic.com> Subject: [SR-Users] rtpengine timestamp jumps      To: sr-users(a)lists.kamailio.org Hi rtpengine experts, We have some customers processing long multi-party call pcaps using mediaMin who are reporting large amounts of packets with timestamp jumps but no packet loss (for instance 10% of packets over a 1 hr 45 min call). For example, in the Wireshark excerpt shown below, packets 6 and 8 sent by rtpengine show a timestamp increment of 640, but sequence number increment of 1: [screencap link at https://www.signalogic.com/images/wireshark_capture_timestamp_jump.png] In the mediaMin output packet log we typically see sections similar to:    :    : Seq num 98584              timestamp = 3902252372, rtp pyld len = 33 media-R Seq num 98585              timestamp = 3902252692, rtp pyld len = 33 media Seq num 98586              timestamp = 3902253012, rtp pyld len = 33 media-R Seq num 98587              timestamp = 3902253332, rtp pyld len = 33 media Seq num 98588              timestamp = 3902253652, rtp pyld len = 33 media-R Seq num 98589              timestamp = 3902253972, rtp pyld len = 33 media Seq num 98590              timestamp = 3902254292, rtp pyld len = 33 media Seq num 98591              timestamp = 3902254612, rtp pyld len = 33 media-R Seq num 98592              timestamp = 3902254932, rtp pyld len = 33 media Seq num 98593              timestamp = 3902255252, rtp pyld len = 33 media Seq num 98594              timestamp = 3902255572, rtp pyld len = 33 media-R Seq num 98595              timestamp = 3902255892, rtp pyld len = 33 media Seq num 98596              timestamp = 3902256212, rtp pyld len = 33 media Seq num 98597              timestamp = 3902256532, rtp pyld len = 33 media Seq num 98598              timestamp = 3902256852, rtp pyld len = 33 media-R Seq num 98599              timestamp = 3902257172, rtp pyld len = 33 media Seq num 98600              timestamp = 3902257492, rtp pyld len = 33 media-R Seq num 98601              timestamp = 3902257812, rtp pyld len = 33 media Seq num 98602              timestamp = 3902258132, rtp pyld len = 33 media Seq num 98603              timestamp = 3902258452, rtp pyld len = 33 media Seq num 98604              timestamp = 3902258772, rtp pyld len = 33 media-R Seq num 98605              timestamp = 3902259092, rtp pyld len = 33 media    :    :     where media-R packets are timestamp gap repairs (i.e. frame loss concealment). The behavior tends to be bursty, but once it gets going it goes for a while and seems relatively consistent. Is this expected behavior for rtpengine ? If so is rptengine in turn dealing with some type of "slow packet rate" issue from a remote sender ? Thanks, Jeff ----- End forwarded message ----- ----- End forwarded message -----