Latching in SST-MS

[aboba]

In SST-MS, multiple SSRCs are used to send a single track. The question is how these multiple SSRCs can be associated with a track on the receiver. One of two solutions suggest themselves:

a. Use the receiverId as a "trackId" to enable the receiver to determine if the new SSRC is a layer within an existing track;
b. Allow an "SSRC range" to be specified for existing tracks, to allow them to be distinguished.

Problem description:
If multiple cameras are in use, there is not enough information in the RtpUnhandledEvent for the receiver to tell whether the unhandled RTP packet corresponds to a new layer within an existing track, or a new track.

If a matching RTCRtpReceiver object cannot be found, there is no way for the browser to determine the codec that the incoming SSRC corresponds to, and therefore no way to parse the payload to determine the layerIDs.

If an RTCRtpReceiver was created with a "wildcard" SSRC within RTCRtpEncodingParameters, the codec would be specified (allowing the layerId to be determined), and the new SSRC would "latch".

If the receiverId acts as a "track identifier" it would be possible to determine if the layer was part of an existing track or not. However, if the layer was part of an existing track it would in all likelihood be too late to do anything useful. A new receiver would have already been created with an associated buffer, and once stop() was called on the newly "latched" RTCRtpReceiver object, the packets received by the newly "latched" object would be thrown away.

[aboba]

Therefore the implication is that an RTCRtpReceiver with a wildcard SSRC and a trackId would need to continue to "latch" SSRCs, not just stop after a single one was latched.

[pthatcherg]

I think the receiverId should be per-track, and if multiple SSRCs arrive
with the same receiverId, the should all "latch" to that track, which is I
think what you are saying, so I think we are in agreement.

On Tue, Jul 29, 2014 at 1:29 PM, aboba notifications@github.com wrote:

Therefore the implication is that an RTCRtpReceiver with a wildcard SSRC
and a trackId would need to continue to "latch" SSRCs, not just stop after
a single one was latched.

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

[robin-raymond]

Except "receiverId" in the IETF appears to be going away in favour of MID which is an association to an SDP M-line. Since multiple tracks can be associated to the MID that doesn't solve the issue. Personally I think "receiverId" should be used as a track ID but that's not the direction the IETF appears to be going.

[aboba]

Agree that a track ID is needed, not an m-line ID.

Here is Christer's BUNDLE presentation from MMUSIC which proposes use of mid instead of app-id:
http://www.ietf.org/proceedings/90/slides/slides-90-mmusic-0.pdf (see receiver-id slides).

This left me wondering about the status of draft-even-mmusic-application-token and whether a normative reference to it in the ORTC API specification was still appropriate.

[pthatcherg]

Multiple tracks on the same MID? I don't think that's possible, at least
not with "unified plan". I think there is a 1-to-1 relationship between
track and MID, which is exactly what we want.

But it doesn't really matter except when using ORTC with an SDP shim on
top. If you're using ORTC without SDP shimming, then it doesn't really
matter what the RFC says about how the header extensions maps to SDP,
because we're not using SDP anyway. The real question is: if we map the
header extension to an RtpSender/RtpReceiver, will you still be able to
shim SDP on top of it? And I think the answer is "yes", because there is
only one track per MID in unified plan.

If I am wrong about this, please let me know why.

On Tue, Jul 29, 2014 at 2:37 PM, aboba notifications@github.com wrote:

Agree that a track ID is needed, not an m-line ID.

Here is Christer's BUNDLE presentation from MMUSIC which proposes use of
mid instead of app-id:

http://www.ietf.org/proceedings/90/slides/slides-90-mmusic-0.pdf (see
receiver-id slides).

This left me wondering about the status of
draft-even-mmusic-application-token and whether a normative reference to it
in the ORTC API specification was still appropriate.

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

[aboba]

I believe this is resolved via the use of the "muxId" (pending the definition of the latching rules). In SST-MS, all layers would utilize the same "muxId". If we assume that a "muxId" match on an RTCRtpReceiver will cause all layers to be directed to an RTCRtpReceiver object (regardless of how many SSRCs are involved), then SST-MS should work. There may an issue if simulcast is being used along with scalable video coding, if the RTCRtpReceiver object cannot determine which SSRCs correspond to which simulcast streams. However, there may be ways for the receiver to figure this out (e.g. H.264/SVC layer map),so implementation experience is probably necessary. .