[Moq] Re: Request Synchronization Use Case

[Cullen Fluffy Jennings <[e-mail]>]

> On Jun 3, 2026, at 12:14 PM, Alan Frindell <[e-mail]> wrote:
> 
> Circling back to the use cases here -- I copied them into issue #1519 last month and there has been some discussion there, but I'd like additional input ahead of next week in case folks have missed it.
> 
> > 3) a stream being paused and unpaused in rapid succession and requests reorders on the wire resulting in the opposite of the desired state.
> 
> Since REQUEST_UPDATEs are serialized on the subscription stream, I believe this use case is already met.  Please correct me if I'm missing something?

Agree  

> 
> > 1) Swap tracks. In a video conference, a subscriber is subscribe to track for Alice and Bob’s video and is watching Alice with Bob paused, but wants to pause Alice and unpause the track with Bob. It’s pretty common to want to ensure to pause the current one before unpausing the new track to not have congestion.
> 
> I just want to clarify -- is this scoped to a single pair of tracks or many pairs (eg Alice's Audio + Video and Bob's Audio + Video), or something that's not even pairwise (Swap Alice's Video for Bob *and* Cindy's)?

Both cases happen but when switching from Alice to Bob & Cindy, if you switch to Bob then put in a separate subscribe update to change Cindy forward to true, it does result with Cindy delayed an bit but this all gets masked a bit as the windows change size. I think we could live with having a bit of delay in that case. 

I’m mostly concerned with the Alice to Bob case. 


> 
> > 2) client side ABR
> 
> Ian added some questions in the issue, but i think it reduces to essentially the same problem as above, except it's Alice's low-quality for Alice's high-quality video.

Agree this is same as Alice to Bob case above. 

> 
> I guess the direction I'm heading in -- is there a possible unification with a slightly simpler SWITCH.  If we reduce SWITCH to only swapping the forward state on two tracks with existing subscriptions (no more SWITCH->PUBLISH), and make "min group" an option, would this meet all our ordering requirements?  This presumes some way to effect a join, which #1642 offers.
> 

I’ll send a review of the PR - I agree something in that direction could work -  thanks. 

> Thanks
> 
> -Alan