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 -----

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