Webrtc-pc: example 14: render before verifying the remote fingerprint?

[fippo]

example 14 says

the offerer may wish to render the media before the answer arrives.

For this to happen, the offerer would have to accept unverified media as the remote fingerprint is not known before SRD (unless we are talking about renegotiation, thanks @alvestrand ). I assume showing unverified media is prohibited somewhere.

When SRD is called this can be done with a track/stream which means there is virtually no advantage in doing "early" media as shown in this example compared to a normal negotiation.

If this example is intended to show a renegotiation that is completly missing.

[alvestrand]

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-7.3 is probably the most worked example.

[alvestrand]

https://tools.ietf.org/html/draft-ietf-mmusic-msid-16#section-3.1 talks about waiting until we're in a stable negotiation state, but that's for a different reason.
I remember discussing the unverified early media thing and agreeing on the language for it (buffer or drop, but do NOT handle), but I'm unable to remember where we put it. @aboba might remember.

[nils-ohlmeier]

Another little thing which appears broken to me in example 14 is that it calls gUM and only ever attaches the stream to the local preview video 'selfView.srcObject'. But since I don't see it ever getting attached to the PeerConnection 'onnegotiationneeded' will never fire.

And yes @alvestrand I remember the same outcome of an earlier discussion.

[stefhak]

Another little thing which appears broken to me in example 14 is that it calls gUM and only ever attaches the stream to the local preview video 'selfView.srcObject'. But since I don't see it ever getting attached to the PeerConnection 'onnegotiationneeded' will never fire.

I opened #1708 for this!

[aboba]

@alvestrand Since the Answer contains both the remote fingerprint and the remote ufrag/password, the Offerer cannot begin to send ICE connectivity checks before applying the Answer. The Offerer also cannot respond to income ICE connectivity checks from the Answerer (who can start to send them), because of the potential for role conflicts. So unless a PR-Answer has previously been applied, enabling bi-directional ICE connectivity checks, early media cannot be supported.

[alvestrand]

The case where it can happen is if a PR-Answer arrives with the fingerprint and ufrag/password but no media, and then an answer arrives with the media configuration.

[aboba]

It's not clear to me what value Example 14 provides. Can we delete it?

[fippo]

bump. I still think the use-case the example aims to solve is very hard to understand that there is very little value in showing a simplified example that isn't wrong.

:+1: on removing it as proposed in #1926 and #2271

[a2sheppy]

I concur with removing this sample, FWIW. While the idea has merit, it's not a necessary example to present within the specification itself. I generally feel the spec should stick to very straightforward samples, with more intricate ones located separately -- ideally a repository or similar resource linked to from within the spec for convenience, since many people will find them useful.