Re: [webrtc-pc] Missing CNAME in RID based simulcast offer (#2114)

@alvestrand I'll properly read your comment later but, for now, just let me tell you a real problem:

* Chrome (at least M72) requires `a=ssrc` lines with `cname` in order to match those SSRCs.
* Using `a=ssrc` lines with any other "attribute" (such as `msid`, `mslabel` or `label`) does not work.

Use case:

* PeerConnection receiving one audio track (Unifien-Plan).
* MID RTP header extension not negotiated by the remote party.
* The remote media section has `a=ssrc` with `msid` "attribute" but there is no `a=ssrc` with `cname` "attribute".
* The video is rendered.
* Then the sender switches off the video.
* We, the receiver, mark the remote m section with `a=inactive`.
* The remote sends a new video track.
* We get a new m= video section as before.
* The new video is NOT rendered.
* I think that the receiver is matching the stream by codec payloadType, so it finds the first m= video section which is "a=inactive" and just drops the RTP packets.

In the very same scenario, if I add `a=ssrc` lines with `cname` "attribute" instead of `msid`, then second video is properly rendered.

What I mean is that Chrome (libwebrtc) **does** use the `a=ssrc` with `cname` for matching SSRC in received packets, so the remote SDP **MUST** have that cname lines. And here we are discussing about not signaling them in the remote offer so the problem above described would happen.

GitHub Notification of comment by ibc
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 6 March 2019 20:01:45 UTC