Fix SDP for inactive rids

[logist322]

This PR adds ability to receive offer with simulcast including some inactive rids (marked with "~" prefix) and to generate correct answer.

[algesten]

Hi! Welcome to str0m!

Looking good. I don't actually know the spec that underpins this change, but I will look into it.

[logist322]

@algesten Hi! Seems like this PR is ready. Waiting for your review!

[xnorpx]

~ is libwebrtc specific?

[lolgesten]

I'm curious too. Can @pthatcher shed some light?

The ~ prefix on the RID seems to indicate that the stream might be paused using "CCM TMMBR and TMMBN" RTCP messages. Following the links to https://datatracker.ietf.org/doc/html/rfc5104 – which largely seems to concern H271.

@logist322 could you maybe describe how you encountered these ~?

[logist322]

@algesten Sure! I have faced it after adding a video transceiver with several RTCRtpEncodingParameters some of them have active: false. That's the way how Chrome and Safari works (@xnorpx in pure libWebRTC too).
You can reproduce it with this simple code in Chrome or Safari:

(async () => {
    let pc = new RTCPeerConnection();
    await pc.addTransceiver("video", {
        direction: "sendrecv",
        sendEncodings: [{
            rid: "h",
            active: true
        }, {
            rid: "m",
            active: false
        }, {
            rid: "l",
            active: false
        }]
    });
    let offer = await pc.createOffer();
    console.log(offer.sdp);
})();

You should see a=simulcast:send h;~m;~l line in the printed sdp.

[algesten]

@logist322 thanks!

It sounds like ~ means a RID starts paused, but that might change later without SDP negotiation (whether there are RTCP ways for us to discover when something becomes unpaused, I don't know). We already have a paused state on the receive streams here: https://github.com/algesten/str0m/blob/main/src/streams/receive.rs#L95-L99

Does it sound right that this ~ state should have an effect for a newly created StreamRx?

[pthatcher]

That's accurate. It just means that the stream starts as if an TMMBR pause message had been received at the same time. Nothing should be sent until a TMMBR unpause is sent. Honestly, I would do all of this over a data channel and not use RTCP, but maybe someone would want to use RTCP for this. But I also don't think anyone should use SDP :).

…

On Wed, Nov 15, 2023, 6:59 AM Martin Algesten ***@***.***> wrote: @logist322 <https://github.com/logist322> thanks! It sounds like ~ means a RID starts paused, but that might change later *without SDP negotiation* (whether there are RTCP ways for us to discover when something becomes unpaused, I don't know). We already have a paused state on the receive streams here: https://github.com/algesten/str0m/blob/main/src/streams/receive.rs#L95-L99 Does it sound right that this ~ state should have an effect for a newly created StreamRx? — Reply to this email directly, view it on GitHub <#399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABC7RIAIKUJHKPE7S4CFBTYETKF3AVCNFSM6AAAAAA7JJEOCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSGY4TMNBWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[logist322]

It sounds like ~ means a RID starts paused, but that might change later without SDP negotiation (whether there are RTCP ways for us to discover when something becomes unpaused, I don't know). We already have a paused state on the receive streams here: https://github.com/algesten/str0m/blob/main/src/streams/receive.rs#L95-L99

@algesten You are absolutely right! We do use it for changing RTCRtpEncodingParameters dynamically without SDP negotiation.

Does it sound right that this ~ state should have an effect for a newly created StreamRx?

I don't think so. Especially, if newly created StreamRxs already have paused: true.

[algesten]

Alright. Let's merge it. At this point the ~ has no implication for str0m. This PR will fix so it doesn't fall over.