- From: Tony Herre via GitHub <sysbot+gh@w3.org>
- Date: Mon, 03 Jun 2024 07:23:43 +0000
- To: public-webrtc-logs@w3.org
Considering usecases, UC1's "custom packetizer" usecase doesn't need app control over seq numbers at all (hence #22), so the UA can control it entirely. Assuming pacing and padding is being done by the UA, it's required to control the seq numbers so it can insert padding packets itself. UC2 when taken to the point of app-controlled pacing, padding, prioritization etc for everything could control sequence numbers, but the UA could also control them entirely afaict, just set based on the ultimate send order. Would be much simpler to require that for both app and UA implementor. The answer is the opposite if we want to go as far as @Philipel-WebRTC's #40 and support near arbitrary packet sending with far less guardrails. That would require arbitrary values, but potentially with a UA-supplied initial number? Not sure how the app would get told about it though? I would guess the app-set value would have to be the exact value sent on the wire, to enable out-of-band communication which refers to specific packets. -- GitHub Notification of comment by tonyherre Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/43#issuecomment-2144461047 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 3 June 2024 07:23:44 UTC