I don't know if my original reply to this went through to the list or not, so I'm sending it again: Is this stream actually produced by rtpengine (i.e. from transcoding) or just a relay? Because this looks like just regular DTX behaviour from a normal AMR sender, i.e. send a SID frame and then not transmit anything for up to 200 ms or so. Rtpengine itself doesn't produce DTX streams. Cheers On 21/05/2024 12.45, Jeff Brower via sr-users wrote: > 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 -----

On 24/05/2024 15.34, Jeff Brower wrote: If there's no transcoding then it's certainly not rtpengine manipulating either sequence numbers or timestamps. Both of these values are passthrough in non-transcoding cases. Your assumption that RTP timestamp advances must match sequence number advances might be flawed. Sequence numbers should match the sequence of packets, and timestamps should match the times. DTX in particular allows for "gaps" in the timestamp series while not having gaps in the sequencing (as the packets are still in order). AMR is a codec which explicitly allows and supports DTX as a feature. Under DTX it is perfectly allowable to have the sequence number increase by 1 while the timestamp increases by 640 or 960 or 1280 or 2560 or any other non-ptime amount, as long as the actual real timing of the packets (roughly) lines up with the timestamps. Generally the RTP marker bit should be set after one such event to signify that the RTP clock should be resynchronised, and this is what your pcap shows. But again this is not something that rtpengine has anything to do with. Cheers