[webrtc-rtptransport] Packet sender needs to expose a signal about max packet size (#83)

sprangerik has just created a new issue for https://github.com/w3c/webrtc-rtptransport:

== Packet sender needs to expose a signal about max packet size ==
 When a custom encoder and packetizer is used (e.g. [use case 1/scenario 4](https://github.com/w3c/webrtc-rtptransport/blob/main/explainer-use-case-1.md#example-4-send-and-packetize-with-custom-codec-wasm)) the packetizer needs to know the maximum allowed packet size.

It's important to note that this is not a static value - it will likely vary at runtime. For one thing, it's capped by the MTU so might change if the underlying network type is updated (e.g. switching between cell and wifi connections). Even with a fixed MTU the maximum size can vary since we need to leave enough space for header extension that might be added - at least on modes where the user agent can modify the outgoing packets such as by adding abs-send-time or transport-seq extensions for bandwidth estimation purposes.

That necessary overhead for extensions can vary over time too. On example is that the initial packets may have larger overhead requirements due to the MID/RID extensions sending ids as strings.

It might even be desirable to have different limits for first/last/other packets of a frame - as some extensions are only added to the first packet of a frame (e.g. absolute capture time) and some only to the last packet (e.g. video orientation). Though this might be too fine a detail, and using a simpler but overly cautious overhead estimation is good enough.



Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/83 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 13 December 2024 10:17:30 UTC