`ssrc` in `RTCRtpEncodingParameters` is inconsistent with ORTC #1174
Bernard: ssrcs, fec, rtx were
listed as read-only, at the same level ax rid, max*Rate
... we removed ssrc, rtx and fec in June 2017
... this led to new problems, so we resolved in April 2018 to
bring them back
... this didn't get implemented as a new proposal emerged to
keep that information only at the SDP level and not exposed in
objects
... we're re-opening this now as implementations have emerged
that don't integrate ssrcs in the SDP either
... which creates issues for teleconferencing systems - they're
represented today (Jitsi, Teams, FreeSwitch, MeetEcho,
MediaSoup)
Amit: for clarification, this is only in the new Simulcast API
Bernard: originally, the object
model would have applied to everything
... but this discussion is indeed specifically for the
simulcast case where this has the most impact
... opening the floor to SFU devs
Emil_Ivov_Jitsi: what we agreed on last year still sounds like to easiest way to go - i.e. having ssrcs in the SDP
Bernard: no specific benefit in having it exposed in objects?
Emil: it's a nice-to-have, not a
must-have
... we need to have it somewhere, and SDP is the lowest
friction approach
... there were suggestions that we would migrate our systems to
the new RID-system - but this is a lot more complicated than
just updating clients
Inaki: ssrc lines in SDP are not
needed for me; RID signaling is the right way to go, and the
server needs to be ready to react to it
... the problem I see in not having ssrcs in SDP is that we
don't have the CNAMEs - they're signaled in the ssrcs
lines
... it's not a big issue since CNAMEs are not used for
synchronization in libwebrtc (msid are used for that)
... Chrome with Simulcast doesn't even signal the cname in the
parameters
Bernard: do you support RID routing today?
Inaki: yes, it works fine
Anthony_Minessole: we've only been a few months into simulcast implementation; my priority is getting the API available
Siva: our implementation is based on SSRCs; migrating to RID/MID would be quite a bit of work
Bernard: so moving to Unified Plan in the back-end would be difficult; but not so much in the front-end
Lorenzo_(MeetEcho): we have partial support for both MID and RID; it's kind of a working, but having SSRCs in place remains the easiest way forward
scribe: it would also help
conflict resolution
... but in principle, MID/RID can be used for that
Inaki: one problem of just using
MID and RID, you need to negotiate it at the SDP level
... for sending, that's not a problem
... but when sending and receiving, that's more difficult for
some servers
... that means you must also the MID into the RTP packets that
the SFU sends to the client on that PeerConnection
... the source of video may not have support for the MID, so
the SFU would need mangling RTP packets
... so support for MID/RID may not be that easy to support
Lorenzo: +1; it's a lot more work to handle this on the SFU side than just modifying ssrcs
Bernard: so it's tricky to fully
implement MID routing, and there are potentially performance
issues
... so far, I've not heard arguing it needs to be exposed at
the object level
... the argument is about having it in the SDP
Jan-Ivar: Firefox has ssrcs in
the SDP; but as a long term solution, we want people to be able
to use RID and MID
... this is a legacy feature from our perspective
... some concerns that people will never move away from
SSRCs
Bernard: we're hearing some
performance issues linked to this transition
... so there may be structural issues in addition to the more
transitional ones
Amit: I removed ssrcs from
chrome, because they conflict with the RID identifiers
... we would need a solution to map between them, taking into
account they can change over time
Bernard: traditionally, ssrc
conflicts were swept under the rug
... there were no promise that ssrcs would not change
Amit: there is never problems
with SSRC in Unified Plan, because there is only one ssrc per
media section, and the MID will not change
... Unified Plan semantics are not supposed to signal
RIDs
... we're only removing ssrcs from that specific scenario
Emil: you're saying that because there is no mapping between ssrcs and rids in sdp, you've removed ssrcs
Amit: correct; I documented a few
scenarios where this could get messed up
... The broader question is whether there is clear commitment
toward migrating to RID/MID in the end
Bernard: we've heard that there are structural issues in that migration
Amit: if you are writing your own SFU and clients, you can make some assumptions (e.g. fixed lengths MID) that would help overcome some of the issues
Emil: the entire support of
Unified Plan becomes one huge inseparable amount of work if you
have to combine it with MID/RID
... it's easier if you can split client / server work in this
space
... that said, there is a valid question about the actual value
of this migration
Bernard: re mapping ssrc/rid,
you're right this is not solved in the SDP Amit
... but is this lack of mapping an issue for developers?
Emil: I don't think so
Amit: but the mapping tells you which stream is which - how do you identify low/high quality stream?
Emil: order-based would be fine
Amit: but that's not how it
happens
... Simulcast layers can be dropped
Emil: I meant order-based in SDP
Bernard: the browser can stop sending a layer, but all the ssrcs remain in the sdp and in their order
Amit: if layers get dropped,
there is no way to communicate which stream is which; the RID
we know how to communicate
... the application logic can make use of the RID to associate
semantic to the streams
... with ssrcs, there is no way to relay that information
... we should move away from ssrcs as part of unified plan
Bernard: is this a problem not being able to map ssrcs to specific characteristics?
Lorenzo: that's indeed a problem;
in general, we're still able to derive implicitly ssrcs
... it's hard for me to figure this out because I haven't been
able to test the new simulcast in Chrome M74 as I wasn't able
to get the RIDs in the RTP packets
Amit: please get in touch with me offline on your issue with M74
Emil: in Plan B, the SSRCs were ordered in the order of resolution, and that was good enough
Bernard: if the ssrcs were in the order of the encoding parameters, you could map them
Amit: I fear that this is
slippery slope - this won't be enough
... the next questions will be about msids, etc
Inaki: in Simulcast, there is no
order of layers
... you can't derive information from that order
Bernard: we did have to add ordering in the encoding parameters
Amit: ordering is linked to
preference, not the characteristics of the streams
... i.e. linked to the priority of the streams
Bernard: Amit brought up the
complicating factor of linking to FEC, RTX - this used to be in
the object model, is not any more
... is this a problem?
Emil: I think it would be, but would have to check
Brian_B: definitely would be
Amit: if we start signaling this,
we're moving back to the old format
... the new format is an improvement
<vr000m> flexible fec requires signaling the SSRCs. https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-18#section-5.2
Inaki: @@@missed
Bernard: ssrcs have always been
part of the API from the beginning
... this was linked to this transition issue that was
described
... to help separate issue servers / clients
... we need to get that overall issue solved by the end of our
Charter March 2020
Amit: what would be the problem if SFU-without-RID-MID continue to due munging in their apps, and new clients move to the new API
Bernard: from a W3C perspective, we would not be able to demonstrate support for unified plan
<vr000m> FLEXIBLE FEC says:
<vr000m> The RTP Stream Identifier Source Description [I-D.ietf-avtext-rid] is a format that can be used to identify a single RTP source stream along with an associated repair stream. However, this specification already defines a method of source and repair stream identification that can enable protection of multiple source streams with a single repair stream. Therefore the RTP Stream Idenfifer Source Description SHOULD NOT be used for the Flexi[CUT]
Jan-Ivar: ssrcs are still returned in stats fyi
Bernard: but that doesn't help with signalling since they're not available at offer time
Lorenzo: we support Simulcast in
Chrome and Firefox which uses two different approaches
... when we have the SSRCs available, we can route them
accordingly
... it is indeed mixing different things, but it works
Amit: but in the new scenarios
when we're signaling RID and simulcast, the response need to
signal the right stuff
... if not, only the first layer will be sent as per the
fallback behavior defined in the spec
Emil: the munging can happen in the client, before the SDP reaches the server
Amit: there is no way to signal-me back the simulcast line if the SFU doesn't support it without munging
Bernard: I'm hearing everyone
will change their client to Unified Plan
... but the client will adjust the SDP before interacting with
the SFU
... it's not munging in the sense of modifying the SDP between
create/setRemote
... that means not having to change the server-side in the
short term
Amit: the semantics of signaling support for RID extension may have other consequences
Emil: can you think of bad consequences?
Amit: can ssrcs change?
Bernard: they can always change; although they almost never do
Amit: they only change on conflict?
Bernard: it just doesn't happen in practice
Henrik: why doesn't listing to order of srrcs suffice?
Bernard: because we would need
also rtx, fec, etc
... the proposal on the table is to keep ssrcs in the SDP, and
I'm hearing this would be good enough
Jan-Ivar: one question is whether
this is legacy or spec
... it's not clear we would ever be able to remove them
Amit: but are we really going to demonstrate interop if all the testing relies on wrong server-side implementations?
Dom: can we test interop with a SFU that would be compliant with unified plan? even a mock one?
Bernard: not obvious such a thing exists
Amit: not that RID is not needed in unified plan
Inaki: my conclusion is that with the new API, ssrcs are not needed, neither in Object model or in SDP (except maybe for CNAMEs)
Sergio: I agree
Bernard: the WG never agreed to remove ssrcs from the API; the only question is whether they're in the SDP or in the object model, and there is no push to the object model
Amit: putting them in the object model would clarify the responsibility of who ignores the ssrcs
Inaki: the semantics of the encodings are application-specific and signaled out of band
Amit: I don't think knowing the
mapping is needed to demonstrate interop
... there is no reason to even assume that the different layers
are scaled versions one of another
... we need to demonstrate that one source put in the peer
connection gets transmitted multiple times to the SFU
Bernard: we'll bring to the list
Jan-Ivar: is interop with legacy servers a requirement for 1.0?
Bernard: currently, it's hard to demonstrate interop at all, which would mean removing Simulcast from 1.0
Dom: maybe we should re-focus the issue on interop specifically, rather than spec'd behavior
Amit: can we get at least one SFU to support unified plan?
Sergio: mediasoup supports MID/RID
Bernard: but only in one direction?
Sergio: we send MIDs
Bernard: is receiving MID supported in browsers
Amit: I believe so
Lorenzo: the problem of performance of Unified Plan remains, in particular when it comes to non-browser clients integration
Amit: but these legacy systems don't need to be part of the interop scenarios
Dom: issues with Unified Plan
performances seems out of scope from W3C based on what I've
heard so far
... and it looks like we have a way out for testing interop
with some of the specific SFUs
Henrik: sounds like we can test
e.g. in send-only cases
... if we're relying on SFUs that reject some of the WebRTC 1.0
features, we haven't fully tested interop
Inaki: maybe we should simplify
the question into a single-encoding question
... ssrcs aren't exposed in the object model in
single-encoding
Amit: we need to be able to show
taht if you only stick to the spec (don't signal ssrcs, limit
to mid/rid), everything will still work
... with at least browser A <-> SFU <-> browser
B
Bernard: JSEP requires parsing correctly ssrcs if you transmit them
Amit: but it should also work without ssrcs
Inaki: it would be useful to have
the ability to set the mid extension only for sending
... that would help mitigate the problem of bidirectional
mid
Lorenzo: or the ability to support mid in recv-only cases
Bernard: we've run out of time
Amit: we should schedule another meeting to go through this
Bernard: I think we'll need more
preps on the testing / interop before we do that
... thanks to the developers who joined us to chime in