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.org/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 <jbro...@signalogic.com> -----
Date: Fri, 17 May 2024 17:10:10 +0000
From: Jeff Brower <jbro...@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 <jbro...@signalogic.com> -----
Date: Thu, 09 May 2024 05:32:27 +0000
From: Jeff Brower <jbro...@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-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
