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 -----
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:
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 -----
On 24/05/2024 15.34, Jeff Brower wrote:
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).
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
Hi Richard-
Thanks again for your reply. The first packet highlighted is after a SID, but not the second. But yes the second does have its market bit set, indicating RTP clock may need resynchronizing, as you point out.
As rtpengine is not altering RTP timestamps in this situation, I'll get back with the carrier and try to find out why they have such a high percentage of RTP timestamp jumps. A few, including large pauses like call-on-hold, are normal but such a high percentage in the middle of non-silence voice is unusual.
-Jeff
Quoting Richard Fuchs rfuchs@sipwise.com:
On 24/05/2024 15.34, Jeff Brower wrote:
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).
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
-
Jeff Brower -
Richard Fuchs