External Service Discovery

[madmath03]

Is your feature request related to a problem? Please describe. Several (if not all) WebRTC clients, like NextCloud Talk or JavaScript XMPP Chat, ask for a TURN secret to authenticate but Ejabberd does not seem to setup one (correct me if I'm wrong).

Describe the solution you'd like I would like a parameter for listening module ejabberd_stun to set a TURN REST API secret. I'm guessing auth_type should also be updated to allow a secret type. Configuration could look like that:

  -
    port: 3478
    ip: "0.0.0.0"
    transport: udp
    module: ejabberd_stun
    use_turn: true
    turn_ip: "10.20.30.40"
    auth_type: secret
    auth_secret: "mysupersecretsharedwithstunturnclient"
    auth_realm: "example.com"

As reference, same function but from the coturn doc:

--use-auth-secret TURN REST API flag. Flag that sets a special WebRTC authorization option that is based upon authentication secret. This feature purpose is to support "TURN Server REST API" as described in TURNServerRESTAPI.pdf in the docs. This option is used with long-term credentials mechanism. --static-auth-secret Static authentication secret value (a string), for TURN REST API. If not set, then the turn server will try to use the 'dynamic' value in turn_secret table in user database (if present). The database-stored value can be changed on-the-fly by a separate program, so this is why that other mode is 'dynamic'. Multiple shared secrets can be used (both in the database and in the "static" fashion). https://github.com/coturn/coturn/wiki/turnserver#webrtc-usage

Describe alternatives you've considered Not using ejabberd for STUN/TURN ? 😅

Additional context NA

[weiss]

Ejabberd does not seem to setup one (correct me if I'm wrong).

Yes, ejabberd uses the configured (XMPP) authentication backend for STUN/TURN.

I would like a parameter for listening module ejabberd_stun to set a TURN REST API secret.

If STUN/TURN is to be used in the context of XMPP, it seems more obvious to add support for XEP-0215.

[madmath03]

Forgive if I'm going to say something stupid, kind of new to the XMPP environment, but I do not see how external service discovery would solve the use case I mentioned. By that I mean that the XMPP client needs to implement XEP-0215, ie send a request for credentials. So clients, like JSXC, would also need an evolution to support this, am I right ?

Otherwise, I do agree that the XEP-0215 spec is directly related to TURN REST API suggested so that seems like a good thing to implement :+1:

[weiss]

So clients, like JSXC, would also need an evolution to support this, am I right ?

Yes. Just like support for querying some REST API would have to be added; unless they (or the libraries they're using) already do that (dunno). The Jingle clients I'm aware of just specify the user's XMPP credentials for STUN/TURN, as currently expected by ejabberd.

[badlop]

No news in this ticket for two months, I guess it's either solved or isn't relevant anymore.

[madmath03]

@badlop wait, what ? As discussed with @weiss, this ticket pretty much ended up as a feature request to support XEP-0215. As far as I know, the XEP-0215 support has not been added to Ejabberd, so why close it if "no news" since the news would be on processone side ??

[zinid]

@madmath03 please stop behaving like you own ProcessOne. The ticket was not assigned to anyone, which means nobody in ProcessOne is interested in the feature. I personally don't like the mentioned XEP because there is a standardized mechanism to discover STUN/TURN servers (RFC5389, Section 9). And in regards to authentication: ejabberd supports Long-Term Credential Mechanism to authenticate against existing accounts. If you need more features you're better off to use standalone feature rich STUN/TURN server.

[madmath03]

@zinid I absolutely did not think that I own ProcessOne 😅 Simply the message from @badlop made me think that they were expecting news from me to advance further on the subject, not that the feature will be dropped because no one consider it worthwhile. Your answer in that regard gives a better explanation on the reason to close this, so thanks for that.