Hi Richard-
Thanks very much for your reply. Please allow me to answer in reverse order - first in the Wireshark screencap (see link below) the two red arrows are pointing at media packets, not SID. The sequence number advances by 1 but the RTP timestamp advances 640 (should be 320 for AMR-WB).
Second, the stream is not transcoded, but I'm trying to narrow down whether there may be "rate correction" happening, and if so where it's occurring. The carrier says they are not sending media packets with non-matching sequence number and RTP timestamp increments, at least not on a regular basis (i.e. 10 to 15% of a 2 hour call).
-Jeff
Quoting Richard Fuchs via sr-users sr-users@lists.kamailio.org:
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 -----