Re: [webrtc-pc] If a preferred codec is filtered out, does it still get assigned a PT? (#2938)

@rshpount this (getting to an SDP-free future) is part of the motivation behind https://github.com/w3c/webrtc-pc/pull/2935 - getting to a description of the codec situation that is SDP-independent.

The API surface for setting a specific sending codec is documented in https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-codec - invoked by SetParameters() on the sender, just as one would expect in an SDP-free environment. It does not trigger "negotiation needed".

The question that this issue is raising is the case where, for codec "S", which we only support for sending, how, in an initial offer, do we allocate a PT for that and request that the responder signal its willingness to accept that codec?

This offer will do it (as long as the responder supports S and hasn't set codec preferences):

m=video .... 94 ....
a=sendrecv
a=rtpmap:94:S

But it ALSO tells the receiver that we're willing to receive S, which is not true.

Stating that this is impossible in SDP and we're OK with that is fine with me; there are worse things in the world.
But it should be an explicit decision to say that this is not possible.







-- 
GitHub Notification of comment by alvestrand
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2938#issuecomment-1953704263 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 20 February 2024 08:30:21 UTC