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 https://github.com/w3c/webrtc-pc/issues/2114#issuecomment-470254852 using your GitHub account

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