26 May
2024
26 May
'24
11:18 p.m.
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(a)sipwise.com>om>:
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