[FR] Change Packet Timestamping in non-live Configuration

[maxsharabayko]

As of now in the live configuration of SRT the timestamp field of a data packet reflects the time the payload was submitted to SRT for sending or the source time for the payload provided by the app.

In other configurations (essentially when TSBPD is disabled), the timestamp field of a data packet reflects the time the packet is being sent over a UDP socket. It also means each retransmitted packet has a different value of the timestamp field.
The latter conflicts with the AEAD mode. The timestamp field is included in the associated data. A packet is expected to be encrypted only once, while the timestamp field will change if a packet is retransmitted.

TSBPD off, AES-GCM on configuration is forbidden by #2573. Hence only live configuration is allowed to use AEAD.

However, there is not much sense in preserving the existing timestamping behavior.
In the non-live configuration, the timestamp field is not used by the receiver. Could be used to estimate transmission delays though.

However, having a unified logic regardless of the configuration makes a lot more sense. It simplifies the code, simplifies the protocol, and allows using AEAD in non-live configurations.

[ethouris]

Note also that transmission delays could be still estimated the same way, just retransmitted packets should not be used for this. It is possible to discard them thanks to the existence of the R flag.

[maxsharabayko]

Not that accurate, because the time between packet submission to the sender buffer of SRT, and actual sending would be unknown. Furthermore, the source time may be supplied by the app.

[ethouris]

Then the only use of it could be by the application. There might be also an alternative way of flattening the jitter by having TSBPD off, but it will be application's work to deliver packets to the splitter at the right time ("zero latency").

[maxsharabayko]

Right, this would allow #2460.

[teshrim]

However, having a unified logic regardless of the configuration makes a lot more sense. It simplifies the code, simplifies the protocol, and allows using AEAD in non-live configurations.

Might this cause folks to simply use AES-CTR for both live and non-live configurations, to avoid the headache/hassle of conditional encryption logic?

[maxsharabayko]

@teshrim

Might this cause folks to simply use AES-CTR for both live and non-live configurations, to avoid the headache/hassle of conditional encryption logic?

Depends on the security requirements.