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