request for clarity on SDP munging restrictions timeline

[林飒明]

Hi all.

Recently, I found out several issues and PSAs about SDP munging restrictions. And I sincerely request for the plan and timeline about there actions.

- https://issues.webrtc.org/issues/414284082

- https://groups.google.com/g/discuss-webrtc/c/PIJZN5MTZF4

- https://groups.google.com/g/discuss-webrtc/c/XYFcJPkZUsg

As we all know, [some features were historically released through SDP munging](https://github.com/w3c/webrtc-pc/issues/2907#issuecomment-1798118415), and SDP munging is widely used today. There is even an offical [sample](https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/) demonstrating SDP munging.

As one of the many RTC service providers relying on SDP munging in browser, driving a smooth upgrade of the entire service to the standard version is particularly challenging, especially when notifiying to all customers and theire downstream users, as noted in the [previous comment](https://groups.google.com/g/discuss-webrtc/c/PIJZN5MTZF4/m/WwFr_w4xEwAJ). 

Given that the prior security threat have been resolved, I believe the following standardization actions may not require immediate urgency. Would it be possible to allow more time for a phased and well-managed migration for all service like us?

To ensure service stability and minimize disruption for our customers, we remain highly concerned in this restriction and hope the plan will be shared publicly soon.

[Tsahi Levent-Levi]

Hi,

I usually don't voice my opinion, but I will this time.

SDP munging is an anachronism. It should have been banned in WebRTC at least 5 years ago.

When it works, it is great, but when it doesn't it just doesn't. And there's no guarantee for it to work, or what even "should" work with SDP munging.

The fact that all browsers support it is only due to the fact that they all rely on a single implementation - libwebrtc.

The urgency that compelled the plan of this might have started due to a specific security threat, but the existence if this hack (I wouldn't call it a feature) is a potential for future security threats.

It is best if we as an industry resolve it sooner rather than later and give it the urgency it needs.

Yes. It is going to be a headache for implementations to make the changes needed.

But it is necessary for the health of the ecosystem of WebRTC.

Just my two cents.

Regards,

Tsahi

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/00c51153-0f3d-4259-937a-7fe739cc6886n%40googlegroups.com.

--

Regards,

Tsahi Levent-Levi

Analyst & Consultant

BlogGeek.me

Looking to improve your WebRTC app's quality and connectivity? Check out this ​3-step action plan

[林飒明]

Hi Tsahi,

I fully agree with your opinion about the historical reason for SDP munging and completely understand the urgency to fix things up. 

To clarity, I don't intend to obstruct the standardization of the ecosystem. In fact, our service was fully updated last month--after working tirelessly day and night--and we have released several fixes to eliminate all-non standard behaviour, including SDP munging, to the best of our ability. However, some features--such as Opus stereo and audio RRTR--cannot be implemented without these hacks.

Beyond the broken features mentioned above, the most challenging part is convincing our downstream customers. While we can and are willing to rapaidly modify our infrastructure and SDKs to comply with standards, our customers may not have the patience for repeated updates.

For this reason, we simply need a clear timeline for implementing these restrictions. With a structured plan, SDK providers like us can coordinate necessary changes in an orgaized manner, without the nightmare of last-minute scrambling what we experienced.

Sincerely,

Saming

[Vitaly Ivanov]

People didn't do munging for fun - there's nothing fun about it - there was no other way to make things work. I wonder if setCodecPreferences was sorted out eventually? I still use munging to force H.264 or AV1 in some demos - works like a charm everywhere. One might call it names, but if another option is to use "proper" API and get rewarded with flaky behaviors, no thank you...
https://groups.google.com/g/discuss-webrtc/c/QS7y-7zR5ok/m/2htOnnHRAQAJ

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/befd83fa-10f3-463f-90fb-f2bf5466cfcan%40googlegroups.com.

[Matt Knowles]

Completely in agreement with Vitaly. Munging is necessary, not just a hack. SDP is used for configuration. Why are we talking about limiting that configuration? There is no way to know all the use cases. Also, existing API's do not support generating the SDP's we require. If they did provide the ability to generate the SDP's we require then we are talking about adding yet another layer of abstraction to get the same result. WebRTC is complex and we as developers need to manage that complexity. It always frustrates me when the people defining API's decide to limit the control of the developers based on their own defined "best practices".  

Matt

[Sean DuBois]

Does anyone have a doc/wiki/spec of all the behavior that requires munging today?

I would love to see more ORTC-esque APIs available. I have depended on munging in the past, but for a better future maybe this is a chance to kick start the efforts to have better/more APIs :) 

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/d9b1df78-8450-4a51-8bca-397fb78a68c8n%40googlegroups.com.