Skip to content

webrtcbin: can't add STUN/TURN servers after streams are added

Hi,

I recently wrote a WHIP client based in GStreamer's webrtcbin, which works great. There is one new feature of the protocol that won't work in the current version of the webrtcbin stack, though. I've explained the issue in more detail in an issue on my project, but I'll copy the relevant details here.

Specifically, the new version of the WHIP draft adds support for an automatic configuration of STUN/TURN servers to use in WHIP clients:

https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html#name-stun-turn-server-configurat

The way it works is that WHIP servers can return a series of STUN/TURN servers (and credentials, if needed) in Link headers in the 201 in response to the HTTP POST (or optionally in response to the OPTIONS too), e.g.:

Link: stun:stun.example.net; rel="ice-server";
Link: turn:turn.example.net?transport=udp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password";
Link: turn:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password";
Link: turns:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password";

The WHIP client can then parse those Link values and add the STUN/TURN servers to its own stack for gathering.

Unfortunately, this seems not to work as expected with webrtcbin. While there is, for instance, an add-turn-server signal that can be used to add a TURN server dynamically, that doesn't seem to have any effect after the pipeline has been started. In my initial tests, in fact, I tried delaying the set-local-description call to after we set the servers, just to see if that may be the cause, and that didn't help.

Checking the code:

  • add-turn-server calls gst_webrtc_bin_add_turn_server, which in turn calls gst_webrtc_ice_add_turn_server;
  • gst_webrtc_ice_add_turn_server just adds the new server to a hashtable, ice->turn_servers.

The internal method that actually adds the TURN server to the libnice stack via nice_agent_set_relay_info, though, is _add_turn_server, which is only called by gst_webrtc_ice_add_stream. Since in the WHIP client we add streams only when we first create our pipeline, and so always before we prepare an offer we can send to the WHIP server, trying to add a STUN/TURN server after that will not work, which is a problem as those Link headers arrive in response to our offer in the first place.

The WHIP draft does have some text on this:

There are some webrtc implementations that do not support updating the ICE server configuration after the local offer has been created. In order to support these clients, the WHIP endpoint MAY also include the ICE server configuration on the responses to an authenticated OPTIONS request sent to the WHIP endpoint URL sent before the POST requests.

I will indeed add support for this OPTIONS workaround in my WHIP server, but the problem is that there's no guarantee all WHIP servers will implement this too (it's a MAY). As such, I thought I'd open an issue anyway in case you weren't already aware of it. Not sure what the right way to handle this might be: maybe a new signal to start using new servers? I also see that most of the signals try to refer to the official WebRTC API, and so this might be seen as a deviation from that.

Thanks!