# Forwarding NTP timestamp from source

**URL:** <https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427>\
**Category:** mediasoup libraries\
**Created:** [October 14, 2021, 8:59am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427 "2021-10-14T08:59:02Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![oto313](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/oto313/32/1254_2.png) [@oto313](https://mediasoup.discourse.group/u/oto313)\
**Post date:** [October 14, 2021, 8:59am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/1 "2021-10-14T08:59:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [October 14, 2021, 9:38am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/2 "2021-10-14T09:38:39Z")

</div>

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](https://webrtc.googlesource.com/src/+/refs/heads/main/docs/native-code/rtp-hdrext/abs-send-time)

---

<div class="post-metadata">

**Author:** ![oto313](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/oto313/32/1254_2.png) [@oto313](https://mediasoup.discourse.group/u/oto313)\
**Post date:** [October 14, 2021, 9:43am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/3 "2021-10-14T09:43:48Z")

</div>

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)](https://webrtc.googlesource.com/src/+/refs/heads/main/docs/native-code/rtp-hdrext/abs-capture-time), but I dont know what is status of this extension, if it is being used.

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [October 14, 2021, 10:36am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/4 "2021-10-14T10:36:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![oto313](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/oto313/32/1254_2.png) [@oto313](https://mediasoup.discourse.group/u/oto313)\
**Post date:** [October 14, 2021, 11:49am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/5 "2021-10-14T11:49:51Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [October 16, 2021, 9:41am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/6 "2021-10-16T09:41:44Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![oto313](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/oto313/32/1254_2.png) [@oto313](https://mediasoup.discourse.group/u/oto313)\
**Post date:** [October 20, 2021, 7:11am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/7 "2021-10-20T07:11:47Z")

</div>

Ok in a few days I will create PR. Thanks

---

<div class="post-metadata">

**Author:** ![usama](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/usama/32/1163_2.png) [@usama](https://mediasoup.discourse.group/u/usama)\
**Post date:** [February 28, 2022, 2:30pm UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/8 "2022-02-28T14:30:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![wzrf](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/wzrf/32/1837_2.png) [@wzrf](https://mediasoup.discourse.group/u/wzrf)\
**Post date:** [November 18, 2022, 2:41am UTC](https://mediasoup.discourse.group/t/forwarding-ntp-timestamp-from-source/3427/9 "2022-11-18T02:41:04Z")

</div>

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.
