MIDs/RIDs in an SFU scenario

[Brian Baldino]

I've been looking at Unified Plan and MIDs/RIDs and had a question about an asymmetric scenario based on the example in https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-14#section-4. 

Say a client is joining a multi-participant conference via an SFU.  It offers to send simulcast and wants to express that it can receive some number of streams (3, in this case), so it sends something like this:

a=mid:participant4video

a=rid:highc send
a=rid:medc send
a=rid:lowc send
a=rid:participant1 recv
a=rid:participant2 recv
a=rid:participant3 recv
a=simulcast:send highc;medc;lowc recv participant1;participant2;participant3

The intent here being "I have a source for which I'll be sending 3 qualities, and I'm interested in receiving 3 other (participant) streams."

The SFU would respond with an answer looking like:

a=mid:participant4video

a=rid:highc recv

a=rid:medc recv

a=rid:lowc recv

a=rid:participant1 send

a=rid:participant2 send

a=rid:participant3 send

a=simulcast:recv highc;medc;lowc send participant1;participant2;participant3 

The intent here being "Great, I'd like all 3 of your simulcast qualities and I will send you 3 streams with rids participant1, participant2 and participant3" (i.e. the streams of the other participants in the call)

My question is: what MID should the packets for the remote streams forwarded on rids participant1, participant2 & participant3 to this client have?  The MID of the original senders?  Or do they need to have the MID from the mline where the client defined those rids (participant4video)?  Based on the spec it seems like it should use the MID of the mline (participant4video), but that doesn't seem to make much sense since they're not related to the 'source' defined there.  Or maybe I've just got this all wrong and there's a better way to accomplish this?

-brian