The ufrag-as-routing-key trick is such a clean example of routing on data the protocol already gives you for free instead of bolting on a lookup service.
Curious how they handle ICE restarts mid-session... does a new ufrag trigger the relay to re-resolve the transceiver mapping or does the original mapping just persist for the session's lifetime?
1. How does transceiver level rescheduling happen? Are they not managed by Kubernetes?
Confusing for me...why do all this..it will still consume same number of packets..
To reduce the number of publicly exposed servers which is required to run webRTC and also the scale would explode here.
The ufrag-as-routing-key trick is such a clean example of routing on data the protocol already gives you for free instead of bolting on a lookup service.
Curious how they handle ICE restarts mid-session... does a new ufrag trigger the relay to re-resolve the transceiver mapping or does the original mapping just persist for the session's lifetime?