Design and Implement Fetch forwarding from subscriber relay to origin relay

[TimEvens]

MOQT defines that Fetch will need to be sent to the original publisher if content doesn't exist. Subscriber relay needs a way to forward fetch to the original publisher without causing massive churn and problems. The responses also need to handled correctly via peering to the s-relay that made the fetch request.

[TimEvens]

The MOQT protocol requires that control messages, such as new group and fetch requests, be sent from subscribers back to the original publisher. This reverse-forwarding requirement contrasts with the primary fan-out function of relays.

To accommodate this, I am implementing a feedback channel within the relay-to-relay (peering) protocol. This will enable MOQT control messages to be passed from subscriber relays (s-relays) to the origin relay (o-relay).

By engineering this channel to support general, opaque messages at the relay level rather than the track level, the solution will be scalable across any number of tracks and future-proofed for new MOQT parameters. Once established, this feedback mechanism will support all tracks for any current or future control messaging needs.