Add time sync protocol on data channel #709
Conversation
|
| @@ -223,8 +223,10 @@ message DataPacket { | |||
| ActiveSpeakerUpdate speaker = 3 [deprecated=true]; | |||
| SipDTMF sip_dtmf = 6; | |||
| Transcription transcription = 7; | |||
| TimeSyncRequest time_sync_request = 8; | |||
There was a problem hiding this comment.
I'm wondering if we could omit the request and always send NTP time when the data channel is first established?
There was a problem hiding this comment.
The client needs to estimate the round trip time, which is easier with a requrest/response flow.
|
|
||
| message TimeSyncResponse { | ||
| string id = 1; | ||
| uint64 ntp_time = 2; |
There was a problem hiding this comment.
we've talked about ways to better distinguish request and response timings of the RTT from the client's perspective. You mentioned the NTP protocol as an example of that. Are we ditching that idea?
There was a problem hiding this comment.
NTP distinguishes between the time the request got into the the server, and the time the response leaves the server. In this case, since the handler does nothing else than get the current time and write it into the response, these 2 times would be the same. We can add an extra field in the future if extra processing is needed on the server.
Either way, we are not able to distinguish between the time spent in either part of the round trip of the synchronization call.
The wikipedia article on this topic mentions:
Accurate synchronization is achieved when both the incoming and outgoing routes between the client and
the server have symmetrical nominal delay. If the routes do not have a common nominal delay, a
[systematic bias](https://en.wikipedia.org/wiki/Systematic_bias) exists of half the difference between
the forward and backward travel times. A number of approaches have been proposed to measure asymmetry,
[[39]](https://en.wikipedia.org/wiki/Network_Time_Protocol#cite_note-iL6pp-41) but among practical
implementations only chrony seems to have one included.[[40]](https://en.wikipedia.org/wiki/Network_Time_Protocol#cite_note-Ocilw-42)[[41]](https://en.wikipedia.org/wiki/Network_Time_Protocol#cite_note-43)
I don't think out synchronization requirements justify implementing these heuristics.
There was a problem hiding this comment.
makes sense, thanks for the explanation!
No description provided.