If multiple encodings are given, ssrcs are needed

[ibc]

Once capabilities are negotiated and so on, a browser sends the following to a SFU (simulcast with two audio encodings using different codecs):

rtpSender.send({
    codecs : [
        {
            name        : 'audio/opus',
            payloadType : 101
        },
        {
            name        : 'audio/pcma',
            payloadType : 102
        },
        {
            name        : 'audio/CN',
            payloadType : 96
        }
    ],
    encodings : [
        {
            codecPayloadType : 101
        },
        {
            codecPayloadType : 102
        }
    ]
});

Note that SSRCs are not signaled.

Then, the first packet the browser sends is a CN with ssrc '12345678'. How does the receiver (the SFU) know which encoding it belongs to?

This applies to other use cases (different encodings with same codecPayloadType and unset ssrc, etc).

[pthatcherg]

That's what the encodingId is for.

[ibc]

encodingId is not placed within CN RTP packets, so that does not fix the issue.

[pthatcherg]

Why wouldn't CN packets use the encodingId's header extension?

[ibc]

True, sorry.

So we end with a single RtpSender sending simulcast (multiple encodings). But the MID header is not enough since it just indicates the RtpSender, and hence we end also adding the RID header. Too cool, but it could work.

However, does the spec states somewhere that, in case of simulcast, the sender should indicate the encodingId for each encoding and must place the RID header into RTP packets?

[robin-raymond]

Sure, spec needs to say to add RID / MID header extension if supported. Are they mandatory to support?

[aboba]

Currently a base URN (urn:ietf:params:rtp-hdrext:sdes) is allocated for the "RTP Header Extension for RTCP Source Description Items" (https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext). However, it is not clear to me whether this would actually be included in RTCRtpCapabilities.headerExtensions, or only URNs for individual elements (e.g. MID, RID, etc.) which are not yet allocated. Jonathan's recent post to AVTEXT WG mailing list should help clear this up: https://www.ietf.org/mail-archive/web/avtext/current/msg01244.html

[aboba]

@pthatcherg @ibc Section 9.8.1 says "An RTCRtpSender places the value of encodingId into the RID header extension [RID].". Is that enough?

One thing that isn't in the current spec is a way to specify the RRID (but as I understand it, no browser vendor currently intends to implement the RRID).

[ibc]

However, it is not clear to me whether this would actually be included in RTCRtpCapabilities.headerExtensions, or only URNs for individual elements (e.g. MID, RID, etc.) which are not yet allocated.

BUNDLE draft defines urn:ietf:params:rtp-hdrext:sdes:mid in section 15.2.

[ibc]

Sure, spec needs to say to add RID / MID header extension if supported. Are they mandatory to support?

My point is that, in case of simulcast, RID MUST be signaled, so if there are more than a single encoding, all the entries in encodings MUST have encodingId.

[aboba]

@ibc

Yes, encodingId needs to be present. RID draft needs to allocate a URN, most likely urn:ietf:params:rtp-hdrext:sdes:rid

[robin-raymond]

On sender for simulcast, encodingId is required. On receiver, if encodings[] are specified then the encodingId is required (or it is basically dynamically assigned based on best match).