SDP "Bumper lanes"

[aboba]

What if a developer only wants to customize audio but not video? We have discussed allowing applications to access RTCRtpReceiver.rtpTransport and RTCRtpSender.rtpTransport.

The question is what restrictions are placed on these send/receiver-specific RtpTransports by SDP:

Unnegotiated PT? Easy to check
Invalid Payload? Not easy to check
Unnegotiated Header Extension ID? Easy
Invalid Header Extension Value? Not Easy
Unnegotiated SSRC? MIDs allow any
Unnegotiated MID/RID? Not too hard
Unnegotiated RTCP type? What if it's custom?
All the m-lines are recvonly/inactive? Easy

So the restrictions imposed by "bumper lanes" could be unnegotiated PTs, Header Extension IDs, MIDs, RIDs, directions, and maybe RTCP types.

But if the applications wants to turn off the "bumper lanes" it can munge the SDP to make them "negotiated".

So why not make it easy?

rtpTransport.bumperLanesEnabled = false

[aboba]

Comment from Harald at Nov. 21 virtual interim: removing the restrictions could create conflict in the situation where RtpTransport traffic is being multiplexed with unmodified PeerConnection traffic. As an example, RtpTransport could use Payload Type 7, but then a renegotiation happens and the PeerConnection allocates Payload Type 7.

[alvestrand]

The same thing applies for all "unnegotiated" features.
I suspect that "bumperLanesEnabled = false" would have to be "SdpReNegotiationEnabled = false" - you're on your own, you can't use SDP O/A to make modifications. (No problem with using it for initial setup, though).

[dontcallmedom-bot]

This issue was discussed in WebRTC December 5 2023 meeting – 05 December 2023 (Issue #10: SDP Bumper lanes)