us-west gets picked up only if I stop us-east (or its the only jvb left?), makes no sense.
Is the configOverwrite listed as an options here IFrame API | Jitsi Meet working? Do I need to pass extra parameters?
If the above configs are correct (syntax wise too), where can I start debugging, what logs?
jitsi-meet 2.0.7210-1
jicofo 1.0-874-1
You cannot overwrite config.deploymentInfo using the iframe API.
That option is coming from the backend.
Ok, is there any other way using iframe API that I can send client location info to backend? url params? How does backend keep up to date where each client is to assign correct region jvb?
Or on the nginx server we use some sort of geo location package to grab info from the headers, but after that how does one set userRegion: “us-east” in the backend?
There are several posts in the forum explaining it. What we use is route53 that gives you the closest server. So there are haproxies in every region that is supported and they add an HTTP header before forwarding the request to the nginx, where nginx fills in the userRegion based on that header while config.js is server-side included.
So when one opens a conference in us-east, and the shard that is used is us-east and a second participant joins from us-west that participant will hit the haproxies in us-west that will add the header before forwarding the request to us-east shard where the user’s config.js will have us-west as userRegion.
Ok so I got nginx to fill the userRegion like this :
geoip_country /usr/share/GeoIP/GeoIP.dat;
geoip_proxy_recursive on;
geoip_proxy 0.0.0.0/0;
proxy_set_header GEOIP_COUNTRY_CODE $geoip_country_code;
map $geoip_country_code $user_aws_region {
default us-east-2c;
SG us-west-1b;
KR us-west-1b;
EU us-east-2c;
AF us-east-2a;
NA us-east-2a;
SA us-east-2c;
AN us-east-2c;
AS us-west-1b;
OC us-west-1b;
VI us-east-2c;
US us-east-2c;
}
Then in server config.js is served:
deploymentInfo: {
shard: "shard1",
region: '<!--# echo var = "user_aws_region" default=""-->',
userRegion: '<!--# echo var = "user_aws_region" default=""-->'
},
us-east-2c : JMS plus one JVB
videobridge {
http-servers {
public {
port = 9090
}
}
websockets {
server-id = "3.129.56.175"
enabled = true
domain = "meetbit.live:443"
tls = true
}
octo {
enabled=true
region="us-east-2c"
relay-id="3991d955-5c42-474d-8ca0-1119f81c2e09"
bind-address=0.0.0.0
public-address=3.129.56.175
}
}
us-west-1b: JVB
videobridge {
http-servers {
public {
port = 9090
}
}
websockets {
server-id = "54.193.8.166"
enabled = true
domain = "meetbit.live:443"
tls = true
}
octo {
enabled=true
region="us-west-1b"
relay-id="0a8e79dd-3e4d-40ae-a0a4-bd1ec5e82313"
bind-address=0.0.0.0
public-address=54.193.8.166
}
}
us-east-2a: JVB
videobridge {
http-servers {
public {
port = 9090
}
}
websockets {
server-id = "3.17.157.237"
enabled = true
domain = "meetbit.live:443"
tls = true
}
octo {
enabled=true
region="us-east-2a"
relay-id="50d1a6d6-5273-4845-b17d-117c3be6fc34"
bind-address=0.0.0.0
public-address=3.17.157.237
}
}
Jicofo
jicofo {
xmpp: {
client: {
client-proxy: focus.meetbit.live
}
trusted-domains: [ "recorder.meetbit.live" ]
}
bridge: {
brewery-jid: "JvbBrewery@internal.auth.meetbit.live"
selection-strategy: SplitBridgeSelectionStrategy
}
authentication: {
enabled: true
type: XMPP
login-url: meetbit.live
enable-auto-login: false
}
}
Now sometimes when a new JVB is created or added (like auto scale) I auto populate its jvb.conf and get a log like this:
Jicofo 2022-04-20 12:52:41.831 INFO: [35] JvbDoctor.bridgeAdded#129: Scheduled health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/c78d51d5-d57f-4deb-b483-8093984d9476, version=2.1.634-gff8609ad, relayId=54.193.8.165:4096, region=us-west-1b, stress=0.00]
while other times the keys are missing values:
Jicofo 2022-04-20 12:54:19.424 INFO: [35] JvbDoctor.bridgeAdded#129: Scheduled health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/19e0d6ad-f760-4574-a85a-cd666c50d49d, version=2.1.665-g3a90ccdc, relayId=null, region=null, stress=0.00]
how can I fix this?
Second question, I have SplitBridgeSelectionStrategy used for testing, now I open a conference and all 4 participants show Connected to: us-east-2a from us-east-2c, but the docs say that strategy It tries to select a new bridge for each client, regardless of the regions. That means the conference was opened in us-east-2a and all other participants were assigned JVB us-east-2c correct? Why were there no other bridges assigned? Is it related to the above question?
This is wrong, this is the region of the shard and needs to match where the config.js is.
When you host a meeting in us-west: region is us-west, but clients can be coming from different regions - userRegion will be different.
Ok I see, so for my case I just got one shard (JMS) and that will have a static Region like ‘US’ for example, then I need to edit that JMS nginx (or the config.js directly) to always set Region = ‘US’ and just edit userRegion?
deploymentInfo: {
shard: "shard1",
region: "US",
userRegion: '<!--# echo var = "user_aws_region" default=""-->'
},
Made that change and restarted:
systemctl restart nginx
systemctl restart prosody
systemctl restart jicofo
systemctl restart jitsi-videobridge2 (all)
Jicofo 2022-04-20 14:41:10.677 INFO: [35] JvbDoctor.bridgeAdded#129: Scheduled health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/c78d51d5-d57f-4deb-b483-8093984d9476, version=2.1.634-gff8609ad, relayId=54.193.8.165:4096, region=us-west-1b, stress=0.00]
Jicofo 2022-04-20 14:41:15.414 INFO: [35] JvbDoctor.bridgeAdded#129: Scheduled health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/b18e62e6-8d58-467d-bda9-860450e5ad00, version=2.1.634-gff8609ad, relayId=3.17.157.236:4096, region=us-east-2a, stress=0.00]
Null again
Jicofo 2022-04-20 14:41:20.901 INFO: [35] JvbDoctor.bridgeAdded#129: Scheduled health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/19e0d6ad-f760-4574-a85a-cd666c50d49d, version=2.1.665-g3a90ccdc, relayId=null, region=null, stress=0.00]
Started a new conference, everyone is Connected to us-west-1b from us-east-2c on SplitBridgeSelectionStrategy, why was us-east-2c the only bridge picked?
You don’t have a bridge from us-east-2c you have one from us-east-2a, those are different regions.
us-east-2c is where the JMS (Jicofo, nginx, prosody) is along with one JVB:
videobridge {
http-servers {
public {
port = 9090
}
}
websockets {
server-id = "3.129.56.174"
enabled = true
domain = "meetbit.live:443"
tls = true
}
octo {
enabled=true
region="us-east-2c"
relay-id="3991d944-5c42-474d-8ca0-1119f81c2e09"
bind-address=0.0.0.0
public-address=3.129.56.174
}
}
I just restarted it:
Jicofo 2022-04-20 15:23:02.004 INFO: [35] JvbDoctor.bridgeRemoved#102: Stopping health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/19e0d6ad-f760-4574-a85a-cd666c50d49d, version=2.1.665-g3a90ccdc, relayId=3991d944-5c42-474d-8ca0-1119f81c2e09, region=us-east-2c, stress=0.00]
Jicofo 2022-04-20 15:22:40.230 INFO: [35] JvbDoctor.bridgeAdded#129: Scheduled health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/19e0d6ad-f760-4574-a85a-cd666c50d49d, version=2.1.665-g3a90ccdc, relayId=null, region=null, stress=0.00]
If I stop it and start a new conference with just us-east-2a and us-west-1b, everyone in the room is connected to us-east-2a from us-east-2c
I’m confused, for me this should be connected to US from us-east-2c.
Don’t expect there to see the bridge, this is just the region and userRegion. For the bridge you will see in the stats server count:
Actually, ignore my last message, that is not correct …
And now your bridge does not report a region 
You think that us-east-2c jvb is causing issues with region? But it is stopped, still all 4 people in the conference have connected to us-east-2a from us-east-2c, it’s like us-west-1b is not being picked up, but it is sending good health checks.
That became really messy.
For regions use just us-east and us-west or stick to just one representation of that.
I think your problem is that you don’t have a correct value in region in deployment info.
So the first participant joining sends and IQ to jicofo saying the region of this shard is us-west (the region it uses is deploymentInfo.region) and reports and its userRegion.
The second participant joins from us-east. Jicofo needs to pick jvb, using region based strategy it sees participant 1 one userRegion is us-west and selects a bridge from that region. It matches the strings so us-east-2a is a different region compared to us-east-2c. For the second participant it sees its userRegion is us-east chooses jvb from that region if available if not it defaults to the region where the conference is - us-west and if that is not found any bridge.
(I’m not 100% sure about the details and corner cases of the selection mechanism but that should be easy to check in the code)
Let me see if I understand this correctly, there’s only one /etc/jitsi/meet/my.domain-config.js file per shard (JMS/Conference), the first participant to join gets to set its deploymentInfo.region, then the second participant joins with a given userRegion and now Jicofo has two people and it need to find a jvb for them, it goes to the first participant’s userRegion and looks at a mapping like userRegion → [ jvb1, jvb2, …] and picks one of them, same for second partcipant , if not found then region → [ jvb1, jvb2, …], if that’s not found then any bridge.
My only question is what file do we put that mapping region → [ jvb1.region, jvb2.region, …]?
In my case:
us-east → [ us-east-2a, us-east-2c]
us-west → [ us-west-1b]
Make sure you configure your jvbs as us-east in jvb.conf, and make sure that is the region string that is written in userRegion and region in config.js. So everywhere you have us-east. Same and for us-west, use only us-west.
Ok did that and restarted everything.
us-east-2c just won’t die, I changed its jvb.conf, its STOPPED, lol.
videobridge {
http-servers {
public {
port = 9090
}
}
websockets {
server-id = "3.129.56.174"
enabled = true
domain = "meetbit.live:443"
tls = true
}
octo {
enabled=true
region="us-east"
relay-id="3991d944-5c42-474d-8ca0-1119f81c2e09"
bind-address=0.0.0.0
public-address=3.129.56.174
}
}
It’s the one on the JMS:
Jicofo 2022-04-20 19:22:44.728 INFO: [36] JvbDoctor.bridgeRemoved#102: Stopping health-check task for: Bridge[jid=jvbbrewery@internal.auth.meetbit.live/19e0d6ad-f760-4574-a85a-cd666c50d49d, version=2.1.665-g3a90ccdc, relayId=3991d944-5c42-474d-8ca0-1119f81c2e09, region=us-east, stress=0.00]