Sender preference for flexfec over RTX

[aboba]

Fix for Issue #694

[ibc]

Summarizing the text in the PR:

If when send(parameters) is called, "flexfec" is specified in parameters.encodings[j].fec.mechanism and parameters.encodings[j].rtx is set or "rtx" is included in parameters.codecs[k].name, then "flexfec" is used for retransmission of encoding j.

IMHO the preference of "or" over the former "and" is a bit unclear.

Said that, I don't fully understand how this works. If FLEXFEC is in use, which should be the value of the ssrc fields in both encoding.rtx and encoding.fec? The same value?

[aboba]

@ibc For "flexfec" the value in fec.mechanism would be "flexfec" and I'd suggest that fec.ssrc should used for all packets, whether they are doing forward error correction or retransmission. rtx.ssrc would therefore only apply to the "rtx" codec. I think this permits a receiver to enable both "flexfec" and "rtx" with or without explicit SSRCs.

[ibc]

For "flexfec" the value in fec.mechanism would be "flexfec" and I'd suggest that fec.ssrc should used for all packets, whether they are doing forward error correction or retransmission.

Sure, that's how FLEXFEC works.

rtx.ssrc would therefore only apply to the "rtx" codec. I think this permits a receiver to enable both "flexfec" and "rtx" with or without explicit SSRCs.

Complex, but it may work. This is, both FLEXFEC and RTX packets (with same or different SSRCs) may be used at the same time.

Today fec.ssrc and rtx.ssrc are typically the same but I think they could conceivably be different, no?

I don't fully follow you here. Today FEC is used by encapsulating UPLFEC into RED packets, and using RTX in a different SSRC.

Anyhow, the text says:

If when send(parameters) is called, "flexfec" is specified in parameters.encodings[j].fec.mechanism and parameters.encodings[j].rtx is set or "rtx" is included in parameters.codecs[k].name, then "flexfec" is used for retransmission of encoding j.

By reading it it seems that, in order to use FLEXFEC retransmission, encoding.rtx must be set. But at the same time you say:

rtx.ssrc would therefore only apply to the "rtx" codec.

So I'm confused. How to signal that I want to use FLEXFEC for (also) retransmission and, at the same time, I don't want to use RTX?

[vr000m]

rtx.ssrc would therefore only apply to the "rtx" codec.

So I'm confused. How to signal that I want to use FLEXFEC for (also) retransmission and, at the same time, I don't want to use RTX?

I dont think the endpoints need an explicit signaling/indication for enabling RTX in FLEXFEC, the sender would send FLEXFEC packets with a single protected packet.

[ibc]

I dont think the endpoints need an explicit signaling/indication for enabling RETX in FLEXFEC, the sender would send FLEXFEC packets with a single protected packet.

Agreed, but then the text above does not seem correct IMHO:

If when send(parameters) is called, "flexfec" is specified in parameters.encodings[j].fec.mechanism and parameters.encodings[j].rtx is set or "rtx" is included in parameters.codecs[k].name, then "flexfec" is used for retransmission of encoding j.

By reading that it seems that, in order to use FLEXFEC (also) for retransmission, encoding.rtx must be set or "rtx" must be included in codecs. But the fact is that we don't need encoding.rtx to be set neither "rtx" included in codecs, am I wrong?

[aboba]

@ibc There is no setting to turn off retransmission support in "flexfec". That seems to suggest that retransmission support and use is required in "flexec". So setting fec.ssrc and fec.mechanism is enough. All we're trying to do here is clarify what happens if "rtx" is added to codecs[] and encodings[].rtx is set in addition, to make it clear that "rtx" settings are ignored.

[ibc]

All we're trying to do here is clarify what happens if "rtx" is added to codecs[] and encodings[].rtx is set in addition,

Fine then.

to make it clear that "rtx" settings are ignored.

But we still want to be able to receive RTX packets and process, right?

[aboba]

On reflection, this is really an issue relating to legal values of encodings.fec and encodings.rtx. Closing.