25 May
2024
25 May
'24
1:05 a.m.
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