tx-mode

[aboba]

From Jianlin Qiu:

Also would you consider adding a section about "tx-mode"?(https://datatracker.ietf.org/doc/html/rfc7798, section 4.3).

To simplify the implementation, we may opt to support SRST only to avoid multiple AP packet formats that introduces the complexity, and would need extra sprop-max-don-diff which agent don't know how to fill them.

We may suggest ignoring this and assume SRST.

[aboba]

Agree that we should add a section on tx-mode.

SRST is the default if tx-mode is not negotiated. I'd suggest we say that a user-agent SHOULD NOT send tx-mode. However, RFC 7798 mandates that receivers support all modes. So what happens if a non-browser (e.g. a gateway) sends tx-mode = mrst?

[taste1981]

I think that's what IETF needs to define --> how agent should respond when it is offered/answered with tx-mode=mrst.

For sendonly, we expect chrome not sending tx-mode for offering.

[fippo]

I think the parameter MUST be interpreted. An implementation may not implement a particular mode but it should treat an offer with an unsupported tx-mode like it would a codec that it does not implement by not answering it.

What we want to avoid here is answering to an offer with tx-mode=mrst with the codec.

And yes, that is (WPT)-testable ;-)

[aboba]

Are we expecting getCapabilities('video') to return distinct entries for each H.265 profile/level-id and tx-mode combination supported, like this?

{
  "clockRate": 90000,
  "mimeType": "video/H265",
  "sdpFmtpLine": "tx-mode=SRST;profile-level-id=XXXXYYY"

[taste1981]

if we're not doing the similar for h.264 packetization-mode, I don't think it rational having tx-mode checked for h.265. Otherwise, it should be handled.

IIRC, getCapabilities does check packetization mode for H.264.

[fippo]

Are we expecting getCapabilities('video') to return distinct entries for each H.265 profile/level-id and tx-mode combination supported

I'd say "yes" since it does for H264 packetization-modes but I doubt we ever questioned whether that is useful for setCodecPreferences. It doesn't have to be the full sdpFmtpLine (e.g. for rtx we leave out the apt which makes rtx a binary switch) but as long as tx-mode=srst is the only supported one the list won't blow up.

[aboba]

AVTCORE VI slide is here: https://docs.google.com/presentation/d/1I944U1DmQ4C2f5r5_uEJiOm2N9s4x4B0c1-SPTPPuS0/edit#slide=id.g2473a55bcdf_0_55

Anything else we want to add?

[aboba]

@fippo Since the AVTCORE WG was ok with not including tx-mode in Offers or Answers, or supporting MRST or MRMT modes sent to a browser in an Offer, can we get away with not including tx-mode in getCapabilities()?

[fippo]

Yes, I think that will be automatic even!

[aboba]

Closed via PR #18