Open Philipel-WebRTC opened 2 months ago
Aren't we restricting to only the extensions negotiated in SDP? If so, the sender could use that mapping to go from URI to ID (in the same way the receiver would).
The problem right now is that the SDP negotiation in WebRTC will throw away any extension it doesn't know about. So for example, If I call sendRtp
and one of the extensions specified in RtpHeaderExtensionInit
has the URI my-awsome-extension
(which was negotiated at app level), then WebRTC will not know what extension ID it maps to.
I see two options:
The latter is somehow more appealing to me.
Right, I was thinking along the lines of Youenn's 2, that there are APIs coming in other repos which will allow custom extension negotiation. Without that you'd technically still need at least something to "reserve" an extension ID for something custom negotiated at the app level, so it doesn't get stepped on by UA (re-)negotiation, I think?
Keeping URI gives us more leeway to introduce verification/validation if we want down the line, as the UA can know when an extension should be parsable & make sense vs custom and just be opaque bytes.
I think a plain extensionId
is probably the better option.
- Add extensionId, keep uri as a convenience.
This way extensionId
and uri
could be set in a conflicting way.
- Add API to register a given URI as a RTP header extension, like we might be doing for custom codecs. In that case, UA has the info and can translate the extensionId in a uri.
The latter is somehow more appealing to me.
What are the benefits of this? My spontaneous reaction is that this just makes it slightly more convoluted.
This way
extensionId
anduri
could be set in a conflicting way.
I was thinking mostly receiver side, in case we want to expose non registered header extensions. On sender side, I am not sure we should allow sending non negotiated ids, extensionId would be ignored.
What are the benefits of this?
I see a couple of benefits:
Agree with Youenn that sending ids that are not negotiated or (for custom extensions) registered could be problematic.
I'm not sure how we can prevent it, the app can simply munge the SDP and set whichever ID it wants and then WebRTC will simply map that URI to that particular ID.
I agree that a developer can always munge SDP and then set the URI to whatever is desired to control the octet ID, so having it be URIs or IDs in the header extensions is equivalent in that sense. I guess it's just a question of what we think the "natural" way of doing this should be. I've always been a fan of the low-level octet approach, but I don't care enough about it either way.
The correct approach is to drop the restriction of URIs in https://w3c.github.io/webrtc-extensions/#dom-rtcrtptransceiver-setheaderextensionstonegotiate that the URI be known to the platform. That way, SDP will do its job of negotiating things to get numbers thettwo parties agree upon, and the platform will know how to map between URIs and numbers.
Keep it simple.
I would also prefer to simply set the ID instead of a URI. I think it's worth remembering that RTP is separate from SDP, so sticking to how payload types are represented in RTP would make more sense to me.
RtpHeaderExtensionInit
(andRtpHeaderExtension
) has aDOMString uri
member identifying the extension. This means only extensions WebRTC knows about can be used.The
uri
should probably be changed to anextensionId
instead.