Confirmed voice/video calls for Immersive Messenger

[club-home]

Hi! Immersive Messenger already nails the messaging layer — native Direct Messages, zero custom tables, modern UI. The one thing that would make it a complete communication solution for my community: browser-based voice and video calls, started right from a conversation.

What I'm suggesting:

1-to-1 voice and video calls via WebRTC — media goes browser-to-browser, so there's virtually no media load on the XenForo server; the server only handles signaling and call state

Screen sharing — essential for support and consultation use cases

Optional STUN/TURN configuration (ideally with coturn shared-secret support) for users behind strict NATs

Per-user-group permissions for voice calls / video calls / screen sharing — this would let admins offer calling as a premium or trust-based feature

Small group calls (mesh, ~4 participants) could come later — 1-to-1 alone already covers the core use case

Why it fits this add-on specifically:

The real-time transport work is already done — Watch Party shows you have solid experience with Pusher/SSE/WebSocket delivery, and WebRTC signaling needs exactly that kind of channel. Calls on top of native DMs would also be a first for XenForo: the only messenger with calling right now runs on its own parallel data tables, which many admins (myself included) are hesitant to adopt.

Happy to test early builds and give detailed feedback. If this resonates with others, a or a comment would help show the demand.

Thanks for considering! And thanks alot for your great products!

Would you scope adding calls to the Immersive Messenger roadmap?

Best regards!

 

[Gwendal]

Welcome, and thank you for a suggestion written like a spec rather than a wish. It makes answering it easy.

The short version: this is being built, and the design you describe is the design I settled on. Browser to browser WebRTC for one-to-one voice and video, started from inside a conversation, with the forum server handling signalling and call state only. Your reasoning is the reason: the moment media touches the forum server, the feature stops being something a normal board can afford to run.

Point by point, so you know what is where:

• One-to-one voice and video. In development, and the furthest along.
• Per-group permissions. Yes, and as separate permissions rather than one switch, so a board can open voice to everyone and keep video for a trust group, or sell either as a perk.
• STUN and TURN configuration. Agreed that it cannot be treated as optional. Without TURN, a meaningful share of your members simply never connect, and they blame the add-on rather than their router.
• Screen sharing. I hear you on support and consultation, and it is on the list. I am not promising it in the first release, because a call that connects everywhere matters more than a call that does everything.
• Small group mesh calls. After one-to-one, not with it. Four participants in a mesh is four times the bandwidth on the weakest laptop in the room, and that deserves its own round of testing.

No date, on principle: with real-time features the last ten percent is where the time goes. But this thread is the reference for it now, and you will hear about it here first.

One question, since you clearly run this in production. For your community, is the call more useful started from inside the conversation, or from a member's profile? I have a preference, but you have the members.

 

[club-home]

Thanks for the detailed breakdown the sequencing (1-to-1 first, TURN as first-class, groups later) sounds exactly right.

So, on your question: inside the conversation should be the primary entry point. In my use case, a call is almost always the continuation of a text exchange — the context of the thread matters to both sides, and requiring an existing conversation is a natural anti-spam barrier for cold calls.

That said, a secondary entry point on the member profile would be valuable for discovery: a visitor reading someone's profile should be able to initiate contact as a call, not just a message. Ideally it opens (or creates) the conversation and starts the call from there — so the call always has a conversation attached, and the existing per-group permissions can control who is callable from their profile at all.

So: conversation-first, profile as a shortcut into the conversation — with permissions gating profile-initiated calls.

Something like that. Looking forward to the updates in this thread

 

[Gwendal]

This is built into the next update: one to one voice and video calls inside the messenger, over WebRTC, with your own STUN and TURN servers set in the options, a call log, and an admin switch that turns the whole thing off for boards that do not want it.

Your other notes from this thread now live in their own threads and I have answered them there: the composer no longer grabs focus on mobile, and the Enter key becomes an admin default with a per member override.

 

[Gwendal]

Out now, in 1.4.0.

One to one voice and video calls from the conversation header, over WebRTC, so your server never relays the media. STUN and TURN are supported, including the coturn REST scheme, and screen sharing comes with them. The call screen has a live timer and a halo around the speaker that follows their actual voice, and a call can be minimised into a floating pill while the conversation carries on. Missed, declined and completed calls are written into the conversation as real messages, with their duration.

Voice, video and screen sharing each have their own permission, and one option turns calls off entirely.