- From: ilnik via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jul 2017 08:38:29 +0000
- To: public-webrtc-logs@w3.org
@henbos that rtp header extension and timing frames are needed for debugging purposes. The idea is to have detailed history of delays for a certain frame for all components of webrtc. Theoretically, it could be done without the extension - send-side webrtc should report its half, receive-side should report it's side, then peers exchange information via out of band signaling. However, having the extension simplifies implementation and gives more flexibility (e.g. having delay of in-network rtp processors, high granularity reporting). The focus here is not on the E2E delay, but on the full details of all the delays. Considering E2E delay - the requirement is to have RTT estimated via rtcp messages. I don't know all the details, but looks like it was done via RR rtcp messages. Also, if rtrr/dlrr is enabled it also works for sending-only clients. Also, we a currently investigating issue, where many calls have no estimations for E2E delay. What exactly went wrong there, we don't know yet. -- GitHub Notification of comment by ilyanikolaevskiy Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/222#issuecomment-314695811 using your GitHub account
Received on Wednesday, 12 July 2017 08:38:35 UTC