Video ingestion has extra latency and is awkward

[ianswett]

I believe the intended flow for ingestion today is a client connects, then sends an ANNOUNCE for the namespace it wants to publish to, then the server sends a SUBSCRIBE for a track.

This takes an extra RTT at best over the client just beginning to publish once it connects.

How does the server know which track name(s) to subscribe to?

It seems like a simpler model would be similar to HTTP POST, where the client connects and starts publishing whenever it wants to, and the server can cancel the PUBLISH at any time if it doesn't want to receive the data.

As implied, this requires a new verb, ie: PUBLISH to allow the publisher to initiate publication of a Track.

[afrind]

Individual Comment:

The awkwardness of "publisher speaks first" is not limited to video ingestion either. We are investigating moqt to carry existing relay-to-relay realtime traffic and would likely use something like PUBLISH if it existed.

[gmarzot]

+1 to ingest ease / PUBLISH. making it easy to drive video into the mesh from a lot of different types of sources is a good thing. WHIP/WHEP comes to mind.