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/[email protected]/latest?count=200).
The Wireshark screencap that demonstrates the issue is uploaded at:
https://www.signalogic.com/images/rtpengine_wireshark_capture_timestamp_jump.png
all other info remains the same.
Thanks, Jeff
----- Forwarded message from Jeff Brower <[email protected]> -----
Date: Fri, 17 May 2024 17:10:10 +0000
From: Jeff Brower <[email protected]>
Subject: Fwd: [SR-Users] rtpengine timestamp jumps
To: [email protected]
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 <[email protected]> -----
Date: Thu, 09 May 2024 05:32:27 +0000
From: Jeff Brower <[email protected]>
Subject: [SR-Users] rtpengine timestamp jumps
To: [email protected]
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 -----
