Forwarding NTP timestamp from source

mediasoup libraries
1

I have one RTP Mediasoup producer. It sends RTP and RTCP packets with an NTP timestamp to the Mediasoup. However, the timestamp is not directly forwarded. Currently, the Mediasoup fills into RTCP sender report custom timestamp (different from the producer). But I need to have absolute capture time in the RTP stream for all consumers. I read the Mediasoup source code probably that is not currently possible. The Mediasoup also discards an absolute send time RTP header extension and fills a custom timestamp.

The knowledge of a capture time of video frame is essential for my application. Is it possible to do or implement it somehow? This feature would be, also useful for synchronization across multiple Mediasoup servers and video sources.

1 Like
2

The RTP timestamp has a random value, it must not be used as absolute time reference.

The abs send time extension is removed by mediasoup as per spec:

https://webrtc.googlesource.com/src/+/refs/heads/main/docs/native-code/rtp-hdrext/abs-send-time

3

Thanks for quick response. Do you know some way to distribute absolute timestamp to consumers? And why RTCP packets do not use producer NTP timestamp from RTCP sender report?

I ment docs/native-code/rtp-hdrext/abs-capture-time - src - Git at Google (googlesource.com), but I dont know what is status of this extension, if it is being used.

4

mediasoup does not relay RTCP packets, it consumes/terminates and produces its own ones as any proper SFU. RTCP protocol is hop by hop, not end to end. This is how things are and how things must be.

5

Ok I understand now. But abs-capture-time can solve this. Can mediasoup just pass this RTP header extension from producer to consumer? Because right now all RTP extensions are deleted and added a new one. I would even create pull request for that feature (for keeping abs-capture-time RTP header extension). Thanks

1 Like
6

Can you create a feature request in GH and include that header spec in there? You can of course write a PR but if so please include tests for 1 byte and 2 bytes header extensions (see TestRtpPacket.cpp).

7

Ok in a few days I will create PR. Thanks

8

i also want the capture time of the packets were you able to solve this problem

9

Hi, could you please explain to me why does the RTCP must not be end to end? It would be rational to me since the GCC algorithm is an end-to-end congestion algorithm.