Latching in SST-MS #138

Closed
aboba opened this Issue Jul 29, 2014 · 6 comments

Projects

None yet

3 participants

@aboba
Contributor
aboba commented Jul 29, 2014

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
Contributor
aboba commented Jul 29, 2014

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
Contributor

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
Contributor
aboba commented Jul 29, 2014

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).

@robin-raymond robin-raymond added the 1.1 label Aug 8, 2014
@aboba
Contributor
aboba commented Aug 18, 2014

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. .

@aboba aboba closed this Aug 18, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014
Robin Raymond Clarification of the ICE restart issue, as noted in:
w3c#93

Clarified onerror usage in sender and receiver objects, as noted in:
w3c#95

Clarified SST-MS capability issue noted in:
w3c#108

Clarification of send() and receive() usage as noted in:
w3c#119

Changed ICE state diagram as noted in:
w3c#122

Removed getParameters methods and changed send() method as noted in:
w3c#136

Changed definition of framerateScale and resolutionScale as noted in:
w3c#137

Substituted "muxId" for the "receiverId" as noted in:
w3c#138
w3c#140

Clarified the setting of track.kind as described in:
w3c#141

Added SSRC conflict event to the RTCRtpSender, as described in:
w3c#143

Addressed the "end of candidates" issues noted in:
w3c#142
w3c#144
4916cd5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment