mid vs. receiverId

[aboba]

Within the IETF 90 MMUSIC WG session, Christer Holmberg discussed the future of the "receiver-id" within the BUNDLE draft:
http://www.ietf.org/proceedings/90/slides/slides-90-mmusic-0.pdf

The recommendation (which appeared to have consensus) was to "Use existing SDP mid attribute value as receiver-id" within SDP, as well as to enable the mid to be sent within an RTP extension.

My understanding (please correct me if this is wrong) is that within the context of "Unified Plan" the mid can function as a "trackID", enabling SVC layers (regardless of whether SST-SS or SST-MS is being used) to be steered to an RTCRtpReceiver object. As a result, mid essentially takes the place of the "receiverId".

If that is true, then it would appear to me that references to "receiverId" should be replaced by "mid" in the following places in the document:

Section 8.4
Section 9.1
Section 9.5

Also, the reference in Section A.2 to [APPID] should be replaced by a reference in Section A.1 to an appropriate mid RTP extension draft.

[aboba]

[Peter Thatcher] http://lists.w3.org/Archives/Public/public-ortc/2014Aug/0002.html

"I agree that we can switch to using the MID header extension from the
APPID header extension, but I'd prefer not to have "MID" in the ORTC
spec. Can we keep calling it "receiverId"? It makes so much more
sense in the context of ORTC. I'd also be happy with "trackId", with
a note along the lines of "the IETF likes to call it MID, but it's 1:1
with a track."

[Emil Ivov] http://lists.w3.org/Archives/Public/public-ortc/2014Aug/0003.html

"Bernard referred to it as a "track ID" earlier today and I thought
this was very natural. If we are not going to be using IETF
terminology then I don't really see receiver ID as that natural of a
choice."

[aboba]

One concern. Within the Statistics API, there are several attributes with somewhat similar names:

1. Section 13.4.1: RTCRtpStreamStats,mediaTrackId
2. Section 13.4.4: RTCMediaStreamTrackStats.trackIdentifier
3. Section 13.4.5: RTCMediaStreamStats.trackIds

[aboba]

Assuming that there is no concern about confusion with other terms similar to "trackId", here are the changes that result from using "trackId" instead of "receiverId"

Section 8.4:

To determine whether an RTP stream is configured to be processed by an existing RTCRtpReceiver object, the RTCRtpListener attempts to match the values of an incoming RTP packet's Payload Type and SSRC fields as well as the value of the trackId (if present in the mid RTP extension) against the RTCRtpReceiver.RTCRtpParameters.RTCRtpCodecParameters.payLoadType, RTCRtpReceiver.RTCRtpParameters.RTCRtpEncodingParameters.ssrc, and RTCRtpReceiver.RTCRtpParameters.trackId attributes of configured RTCRtpReceiver objects.

Section 9.1:

partial dictionary RTCRtpUnhandled {
DOMString trackId; // was receiverId
};

Section 9.5

partial dictionary RTCRtpParameters {
DOMString trackId = ""; // was receiverId
};

Section 9.5.1

trackId of type DOMString, defaulting to ""
The trackId assigned to the RTP stream, if any, empty string if unset. In an RTCRtpReceiver or RTCRtpSender object, this corresponds to the mid RTP extension defined in [BUNDLE]. This is a stable identifier that permits the track corresponding to an RTP stream to be identified, rather than relying on an SSRC. An SSRC is randomly generated and can change arbitrarily due to conflicts with other SSRCs, whereas the trackId has a value whose meaning can be defined in advance between RTP sender and receiver, assisting in RTP demultiplexing.

[aboba]

Note that the concept of a track ID is already defined in the W3C Media Source Extensions document:
http://www.w3.org/TR/media-source/#track-description

[robin-raymond]

FYI - It really does need to be an "mid" not a "trackId". If you are sending a simulcast of SST-MS to an SFU, you'll need to identify each encoding "mid" so you can distinguish on SFU which SSRC encodings for MS layers belong to which encoded stream.

[aboba]

In particular, when sending simulcast, the value of the mid is typically different for each outgoing simulcast stream, while being the same for each incoming simulcast stream. This implies that the SFU will rewrite the mid RTP header extension.

[pthatcherg]

Let's step back and remember what we're trying to accomplish here. We want
to be able to allow the JS to do the following so that it can avoid
signalling SSRCs:

1. The JS on the send side says "please put value X in header extension Y
   for all packets coming from Z"
2. The JS on the receive side says "please route all packets with value X
   in header extension Y to Z"

The JS gets to choose X, but we're trying to decide what Y and Z are. I'm
in favor of having Y be the "MID header extension" that the IETF is
currently converging on and having Z be an RtpSender and RtpReceiver,
meaning we'd end up with this meaning:

1. The JS on the send side says "please put value X in the "mid" header
   extension for all packets coming out of this RtpSender".
2. The JS on the receive side says "please route all packets with value X
   in the "mid" header extension to this RtpReceiver".

When the JS sets X, it must do so in RtpParameters. So what do we call
""RtpParameters.X"? Previously, I suggested calling this
"RtpParameters.trackID", but I forgot that a track can be plugged into
multiple RtpSenders, so indeed "RtpParameters.trackID" doesn't make sense.
It also doesn't make sense since you can switch the track that's plugged
into the RtpSender while it's sending it. I'd be happy with either
"RtpParameters.senderId" or "RtpParameters.receiverId" or even
"RtpParameters.muxId". But I'm really hesitant to call it
"RtpParameters.mid", since then when someone asks "what is an MID?", we'll
have to go and say "well, it's this poorly defined thing over in SDP....".
Rather than rely on a poorly defined construct of a poorly defined
format, I think we're better of giving it a different name. And since they
are tied to RtpSenders and RtpReceivers, either "senderId" or "receiverId"
would work. But explaining what it actually does would work to, such as
with "muxId", meaning "the ID used for doing mux and demux".

For simulcast, I think in the normal case, you'll have multiple encodings
in the RtpParameters, but all the encodings would share one
receiverId/senderId/pleaseNotMid/muxId. The JS could, of course, plug
one track into multiple RtpSenders with different
receiverId/senderId/pleaseNotMid/muxId values, but then either you would
end up with multiple RtpReceivers or, as Bernard pointed out, a middle box
rewriting the header extension (either of which the app is free to setup).

So, two questions:

1. Are we all agreed on the semantics, and just deciding on the name?
2. How would you sort (senderId, receiverId, mid, and muxId)?

Currently, I feel like muxId > senderId, receiverId > mid.

On Mon, Aug 4, 2014 at 12:10 PM, aboba notifications@github.com wrote:

In particular, when sending simulcast, the value of the mid is typically
different for each outgoing simulcast stream, while being the same for each
incoming simulcast stream. This implies that the SFU will rewrite the mid
RTP header extension.

—
Reply to this email directly or view it on GitHub
#140 (comment).

[aboba]

I agree with most of the above. Only point which I may disagree with is whether an RTCRtpSender sending simulcast streams will always have the same value for the "mid" RTP extension for each outgoing simulcast stream. IMHO, the "mid" RTP extension could be different for each outgoing simulcast stream (though it would be the same for each incoming simulcast stream). For this reason I don't like the "senderId" term (since it is not necessarily the same for simulcast streams sent by an RTCRtpSender). Could live with "muxId".

Question: Should "muxId" be removed from RTCRtpParameters and instead be in RTCRtpEncodingParameters? If the "muxId" can be different with each outoing simulcast stream, this makes sense.

[aboba]

Proposed resolution is to change "receiverId" to "muxId".

Section 8.4:

To determine whether an RTP stream is configured to be processed by an existing RTCRtpReceiver object, the RTCRtpListener attempts to match the values of an incoming RTP packet's Payload Type and SSRC fields as well as the value of the muxId (if present in the MID RTP extension) against the RTCRtpReceiver.RTCRtpParameters.RTCRtpCodecParameters.payLoadType, RTCRtpReceiver.RTCRtpParameters.RTCRtpEncodingParameters.ssrc, and RTCRtpReceiver.RTCRtpParameters.muxId attributes of configured RTCRtpReceiver objects.

Section 9.1:

partial dictionary RTCRtpUnhandled {
DOMString muxId; // was receiverId
};

Section 9.5

partial dictionary RTCRtpParameters {
DOMString muxId = ""; // was receiverId
};

Section 9.5.1

muxId of type DOMString, defaulting to ""
The muxId assigned to the RTP stream, if any, empty string if unset. In an RTCRtpReceiver or RTCRtpSender object, this corresponds to the MID RTP extension defined in [BUNDLE]. This is a stable identifier that permits the RTCRtpReceiver object corresponding to an RTP stream to be identified, rather than relying on an SSRC. An SSRC is randomly generated and can change arbitrarily due to conflicts with other SSRCs, whereas the muxId has a value whose meaning can be defined in advance between RTP sender and receiver, assisting in RTP demultiplexing.