Custom extensions not supported

[Philipel-WebRTC]

RtpHeaderExtensionInit (and RtpHeaderExtension) has a DOMString uri member identifying the extension. This means only extensions WebRTC knows about can be used.

The uri should probably be changed to an extensionId instead.

[tonyherre]

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).

[Philipel-WebRTC]

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.

[youennf]

I see two options:

1. Add extensionId, keep uri as a convenience.
2. 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.

[tonyherre]

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.

[Philipel-WebRTC]

I think a plain extensionId is probably the better option.

1. Add extensionId, keep uri as a convenience.

This way extensionId and uri could be set in a conflicting way.

2. 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.

[youennf]

This way extensionId and uri 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:

• adding an API allows to no longer differentiate UA known header extensions from custom header extensions. We can still expose non negotiated header extensions if we think that is useful (I guess ignore is probably the default option).
• It would remove the need for web applications to do SDP munging.
• In general, it seems less error prone, debugging might be easier, it keeps sender and receiver in sync via SDP...
• web developers seem to prefer strings (like mime types) instead of ids (like payload types).
• on sender side, it seems better conceptually to only be able to send header extensions that have been negotiated.

[aboba]

Agree with Youenn that sending ids that are not negotiated or (for custom extensions) registered could be problematic.

[Philipel-WebRTC]

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.

[pthatcher]

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.

[alvestrand]

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.

[Philipel-WebRTC]

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.