WebRTC Virtual Interim

13 Mar 2019



Dom, Bernard, Henrik, Amit, Brois_Grozev, Anthony_Minessale, Brian_Baldino, Carine, Emil_Ivov, George_Politis, Hristo_Terezov, Inaki, Jan-Ivar, Karthik, Lennart, Lorenzo_Miniero, Patrick_Rockhill, Saghul, Seth_Hampson, Steve_Anton, Tim_Panton, Varun_Signh, Youenn


Slide deck

Issue 1174

`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

Summary of Action Items

Summary of Resolutions

[End of minutes]