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_jump...
all other info remains the same.
Thanks, Jeff
----- Forwarded message from Jeff Brower jbrower@signalogic.com ----- Date: Fri, 17 May 2024 17:10:10 +0000 From: Jeff Brower jbrower@signalogic.com Subject: Fwd: [SR-Users] rtpengine timestamp jumps To: sr-users@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@signalogic.com ----- Date: Thu, 09 May 2024 05:32:27 +0000 From: Jeff Brower jbrower@signalogic.com Subject: [SR-Users] rtpengine timestamp jumps To: sr-users@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 -----
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: