obs-webrtc: Add static stun server

[nab-os]

Description

I added a way to configure a STUN Server to the WHIP configuration in a static way from the settings.

I added a text field and a checkbox in the stream settings page accessible only when selecting the WHIP output:

Motivation and Context

This change enables SDP negotiation to have every ice candidates before sending the offer.
This allows using servers that don't support Trickle ICE (I don't think it's implemented yet in the plugin anyway)
Currently ice servers are setup temporarily from Link headers from the SDP Answer.

How Has This Been Tested?

Tested behind a NAT on a distant whip server with nab-os/Omniroom

Types of changes

New feature: static STUN server configuration

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate. (Don't hesitate to tell me if it's ok or not)
• I have included updates to all appropriate documentation. (Not sure if there is appropriate documentation)

[nab-os]

It's still missing translation for the setting field label.
As it's my first contribution to this project I'm trying things around so I'll push this afterwards.

[nab-os]

After some thinking I'm gonna add a checkbox to enable/disable waiting on candidates

[nab-os]

Only missing the clang-format check at this point

[nab-os]

I can't get the clang format check to pass, I must be missing something,
Do I just need to run clang-format -i <path> on each file I edited ?

[Sean-Der]

Thank you so much for doing this @nab-os. It’s such a honor to see people use this :)

Would setting STUN Servers via Link Header fit you use case?

[nab-os]

Hi @Sean-Der !
I've been using obs-webrtc and broadcast-box for something like a year and a half.
So thank you a lot ! It's my honor to help you with this.

About the Link headers:
As mentioned in the RFC, it depends on the server implementation.
As the SDP offer is already sent when the headers are parsed in the http answer, the server doesn't have the correct candidates first hand in case of a NAT.
The OPTIONS request before the POST is NOT RECOMMENDED, and also may not be implemented.
It means doing an ICE Restart with the ICE Servers extracted from the first SDP Answer or doing Trickle ICE.
But for a server not implementing both these features and for performance/latency I think we should support static STUN/TURN servers.

I don't have a way to try that TURN is working properly tho.
But from libdatachanel's implementation, it should work in theory.

That would be nice if someone could try TURN servers.

[nab-os]

Is it normal that running ./build-aux/run-clang-format/ edits some files but none are the ones I edited ?
Like it means there is formating issues in the repo but also the formating check workflow is saying the files I edited have issues but I can't find where.

EDIT: It was the clang-format version

[nab-os]

Ready for review

[Sean-Der]

@nab-os What do you think of adding Trickle ICE support to Broadcast Box + OBS? We return the STUN server in the Link header, and then OBS posts the gathered candidate.

It would be nice if a user could switch between OBS/FFmpeg/GStreamer etc... and get connectivity without having to configure their own STUN servers.

[nab-os]

@Sean-Der Ok I understand what you mean, clients should rely on the server to learn about the STUN/TURN server(s)
I just implemented Trickle ICE on nab-os/Omniroom and it works with meetecho/simple-whip-server.
I'm gonna try to do that in broadcast-box and obs too

[nab-os]

Should we still try to merge this feature in case Trickle ICE is not implemented on the user's server ?

[nab-os]

@Sean-Der
Every WHIP client I've found includes this feature:

• gstreamer whipsink
• meetecho/simple-whip-client

[Sean-Der]

I HATE pushing back, I am a 'default yes' person. In the best interest of OBS/how the project operates I don't think this should be merged.

Your 'Trickle ICE' PR is the better version of this. One of the goals for OBS is to make it is approachable as possible for users. Adding this to the UI hits a few points

• It is a niche topic. Non-technical users will see it and be concerned/not understand it.
• The amount of people who use it will be very small
• The desired outcome can be established via Trickle ICE.

---

If you disagree/OBS developers disagree I am totally fine with this getting merged though! I am just anticipating/trying to capture the spirit of previous discussions about OBS + UI.

[nab-os]

I kind of disagree because it would be in the "advanced" UI group and still solve a use case where Trickle ICE is not implemented server-side.
I understand what you mean tho, and I'm not super attached to getting static STUN merged if we get Trickle ICE merged.
I just want to be able to use OBS for WHIP one way or the other in the end so I won't die on this hill 😆 But maybe it's a bit selfish to think like this 😅