Jibri fails when XMPP Domain != Web domain

To date, I’ve been setting up Jitsi components with a generic XMPP domain (e.g. jitsi.xmppdomain) that is different from the domain name it is hosted on (e.g. meet.mydomain.com). This allowed me to create server images that are preinstalled and preconfigured, and deployable under different hostnames.

This scheme appears to work fine, until I started dabbling with Jibri.

I tried working around the issue by passing my actual domain name to xmpp.environments.xmpp-domain in jibri.conf, but this failed because Jibri also uses the xmppDomain for pattern matching when extracting the tenant name from the Room JID

Is there any way around this? Or have my shot myself in the foot my assuming XMPP domain could be decoupled from web domain?

Currently the only workaround for this would be to use Jibri’s HTTP API, which allows passing a meeting url in directly. This isn’t ideal, though, for a few reasons:

  1. The HTTP API is only somewhat officially supported
  2. Jicofo does not support using the HTTP API, so you’d need to do all that signaling manually
  3. The HTTP API doesn’t support updates after a session has started

So overall it’s not a great situation for a production solution. This issue has come up a few times, but hasn’t been a priority, historically, as it’s now how we set up our environments. I don’t think there’d be opposition to someone contributing changes to fix it, though.

Thanks for the clarification.

I’ve never use Kotlin so not sure if I’d be able to come up with a decent solution, but happy to give it a shot.

Assuming I did, would you accept a PR to add an optional config option for web-domain (perhaps defaulting to xmpp-domain if unset)? This would then be used to generate call URL instead of xmpp-domain. Of course, I’m unfamiliar with Jibri codebase so would very much appreciated better suggestions :slight_smile:

Currently we extract the call url from the JID here with the use of this helper.

Implementing this will take changes in quite a few places. You’ll need to pass something in the JibriIq, which is defined in this repo, but I’m not sure the best way to handle things like tenant (i.e. should the field in JibriIq be the entire url, or just a base url and we still use the JID for the tenant? Or should Jicofo do that? @damencho probably has some ideas there). You’d then also need to implement some logic in Jicofo to fill out this information in the JibriIq.

:smiley: And there I was being my simple-mindedness self thinking it would be a simple fix.

I assumed we could leave everything as it is so tenant and callname could still be extracted in same way (using Room JID and xmpp-domain), and then just use web-domain at the very end when composing the actual call url here:

I’m obviously missing whole a lot of the big picture from my mental model.

So this is kinda what I had in mind:

I’m well aware this is a noobish inelegant solution, but I had time to kill and decided to try it out anyway :slight_smile: This compiles (to my surprise) and appear to do the right thing on my deployment.

Is this a workable option?

I’ve been considering your solution, and have come to realise that other than the edge components (ELB/haproxy) no other components within my jitsi stack has configs that are aware of the web domain used, only XMPP domain.

Which means a lot will need to change for host headers to be extracted from requests and eventually passed to Jibri via JibriIQ. Doing this has a nice benefit of Jibri not needing configs that are coupled to web domain (and can support multiple web domains per deployment) but frankly, it is beyond the scope of my timebox or understanding of Jitsi implementation at the moment. :frowning:

Which leaves me with my naive workaround of passing alternative web domain directly to jibri config.

Should I go with my workaround linked in post above (assuming it doesn’t break something else) or should I explore alternatives?

Appreciate your thoughts, @bbaldino @damencho .

@damencho @bbaldino Apologies in advance for being a nuisance, but I’ll still wondering (hoping) if you’d accept a PR along the lines of the changes above?

For now, that’s the only solution within my reach, and I’m trying to avoid having to maintain a Jibri fork.


This had been merged on Friday Add the option to configure the base-url of the call used by Jibri to… by oanaianc · Pull Request #406 · jitsi/jibri · GitHub and pushed to stable so we can release new stable releases for docker with updated chrome version …

Excellent! Thank you.

(also, nice to know I was not completely off base with may attempt. PRs look similar :slight_smile: )