Hi.
I just installed jitsi on debian Buster. I got web based conferencing working and also configured jigasi to connect to my Voip provider.
But the dial in option is still not shown when joining a room.
Any idea what to do?
Kind regards,
Andreas
1 Like
you have to install and configure jigasi but it’s not intuitive or well documented
And you managed to dial out to your VoIP provider. Lucky you.
I’ve been struggling with my jigasi installation for a long time now, and still nothing.
Do you mind sharing your config details?
To my understanding (I struggle with jigasi currently as well) dial in directly from a SIP Provider will probably not work, as jigasi expects a custom SIP header in the INVITE Message of an incoming call, telling it which room to join.
So, you are probably better of if you connect an asterisk or freeswitch etc. in the middle, so you have a way of manipulating the headers (after asking the user for a conference number, for example).
An example setup very similar to what I am trying is here: https://community.jitsi.org/t/jitsi-dev-ivr-dial-in-setup/13598/5
Showing the dialin Numbers and the Conference number took a while for me to find out as well…
The way it worked for me is buried in here:
https://evilcreamsicle.com/index.php/2018/03/28/jitsi-meet-w-call-in-and-active-directory/
It seems to need https for the json with the numbers.
And you need to specify both the API URL and the numbers url in your config.js, e.g. (from above example):
// Call In Numbers and Codes
dialInNumbersUrl: 'https://assetbin.domain.com/jitsiNumberList.php',
dialInConfCodeUrl: 'https://jitsi-api.jitsi.net/conferenceMapper',
Regards
Thomas
3 Likes
Thanks for sharing that info!
What about dialing out?
I mean, I’ve managed to register jigasi on my Asterisk server, so I should be able to dial out, but I can’t. Asterisk receives an empty string and tries to match the “s” priority/extension in the incoming SIP context.
In fact, the jitsi-meet web UI shows me a notification such as " has been invited.", ie., “empty string” has been invited… So I’m guessing that the web application is not sending the number I’m typing over to jigasi.
EDIT: I added a screenshot here: Jitsi-meet and jigasi SIP to Asterisk server
One step at a time. Dialout can probably best debugged on the asterisk side (and I would guess the problem is on that side too)
Using the asterisk cli, you can enable sip debugging for the extension that jigasi is registered on.
Then do something like “core set verbose 5” and "sip set debug peer ".
After that, let jigasi dial out, and watch the asterisk console; take your time and work through it, with these debug infos, you should be able to find the problem.
Regards
Thomas
The log’s below.
The IP addr. of my jitsi-meet server is 10.215.144.139-
4901 is the SIP extension number.
inf-voip is the Asterisk server’s hostname.
The problem I see is that Asterisk tries to look up s in the dialplan’s from-sip-external context.
The “s” priority or extension does not exist in that context.
What I’m wondering is why is it trying to look up “s” instead of the number I typed when I was inviting someone from the web application (the plus sign).
[Apr 1 14:46:21] VERBOSE[1415] logger.c:
<--- SIP read from 10.215.144.139:5060 --->
OPTIONS sip:inf-voip SIP/2.0
Call-ID: 827b26370b99df108d3d33c2a5e83910@0:0:0:0:0:0:0:0
CSeq: 3323 OPTIONS
From: "4901" <sip:4901@inf-voip>;tag=c8423913
To: "4901" <sip:4901@inf-voip>
Via: SIP/2.0/UDP 10.215.144.139:5060;branch=z9hG4bK-353036-3e5f48a96f05fc52ea925fd77b8897e6
Max-Forwards: 70
Contact: "4901" <sip:4901@10.215.144.139:5060;transport=udp;registering_acc=inf-voip>
User-Agent: Jigasi1.1.38-g8f3c241Linux
Allow: INFO,UPDATE,OPTIONS,MESSAGE,BYE,REFER,SUBSCRIBE,ACK,CANCEL,PUBLISH,NOTIFY,INVITE
Allow-Events: refer,conference,remote-control,presence,presence.winfo
Content-Length: 0
<------------->
[Apr 1 14:46:21] VERBOSE[1415] logger.c: --- (12 headers 0 lines) ---
[Apr 1 14:46:21] VERBOSE[1415] logger.c: Looking for s in from-sip-external (domain inf-voip)
[Apr 1 14:46:21] VERBOSE[1415] logger.c:
<--- Transmitting (no NAT) to 10.215.144.139:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.215.144.139:5060;branch=z9hG4bK-353036-3e5f48a96f05fc52ea925fd77b8897e6;received=10.215.144.139
From: "4901" <sip:4901@inf-voip>;tag=c8423913
To: "4901" <sip:4901@inf-voip>;tag=as6719373d
Call-ID: 827b26370b99df108d3d33c2a5e83910@0:0:0:0:0:0:0:0
CSeq: 3323 OPTIONS
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:10.215.147.115>
Accept: application/sdp
Content-Length: 0This is only a quick-and-dirty solution for dialing out, but thanks to @damencho this works on my site (no Asterisk):
On the Jitsi-Server, file
/etc/jitsi/jigasi/sip-communicator.properties
amended 2 lines:
org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=<MyNewStandardRoom>
net.java.sip.communicator.service.gui.ALWAYS_TRUST_MODE_ENABLED=true
(though I put in a Let’s Encrypt certificate…)
But inviting works now (of course only in <MyNewStandardRoom>).
So, just to make sure my production Asterisk server (1.4) isn’t the culprit, I decided to install the latest stable Asterisk version available on Debian 9 where I also have Jitsi-Meet & Jigasi.
That would be Asterisk 13 where I configured it as “basic” as possible, listening on port 5061 as port 5060 is already taken by Jitsi. I created two SIP extensions: 4901 (used by jigasi) and 4053 (a softphone I’d like to invite into a jitsi-meet conference room).
Here’s my super simple Asterisk configuration:
# cat /etc/asterisk/extensions.conf
[from-internal]
exten = 4053,1,Dial(SIP/4053,300,tTWg)
same = n,Hangup()
# cat /etc/asterisk/sip.conf
[general]
bindaddr=0.0.0.0:5061
context=default
[4053]
deny=0.0.0.0/0.0.0.0
disallow=all
type=friend
secret=somesecret
qualify=yes
port=5060
permit=0.0.0.0/0.0.0.0
nat=yes
host=dynamic
dtmfmode=info
dial=SIP/4053
context=from-internal
canreinvite=no
allow=gsm,alaw,ulaw,h264
[4901]
deny=0.0.0.0/0.0.0.0
type=friend
secret=jigasisecret
qualify=yes
port=5060
permit=0.0.0.0/0.0.0.0
nat=yes
host=dynamic
dtmfmode=rfc2833
dial=SIP/4901
context=from-internal
canreinvite=yes
Both SIP extensions seem to be OK:
# asterisk -rx "sip show peers"
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
4053/4053 10.215.144.48 D Yes Yes A 5060 OK (3 ms)
4901/4901 10.215.144.139 D Yes Yes A 5060 OK (5 ms)
Unfortunately, I was unable to see the above SIP extension 4901 with “status OK” with the default jigasi properties. I had to add PREFERRED_TRANSPORT=udp. Here’s the full config:
# grep -v ^# /etc/jitsi/jigasi/sip-communicator.properties | grep -v ^$
org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=testhman
net.java.sip.communicator.impl.protocol.SingleCallInProgressPolicy.enabled=false
net.java.sip.communicator.impl.neomedia.codec.audio.opus.encoder.COMPLEXITY=10
net.java.sip.communicator.packetlogging.PACKET_LOGGING_ENABLED=true
net.java.sip.communicator.impl.protocol.sip.acc1403273890647=acc1403273890647
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.ACCOUNT_UID=SIP\:4901@10.215.144.139
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.PASSWORD=jigasisecretencoded
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.PROTOCOL_NAME=SIP
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.SERVER_ADDRESS=10.215.144.139
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.SERVER_ADDRESS_VALIDATED=true
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.SERVER_PORT=5061
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.PROXY_ADDRESS=10.215.144.139
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.PROXY_PORT=5061
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.PROXY_ADDRESS_VALIDATED=true
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.PROXY_AUTO_CONFIG=false
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.USER_ID=4901@10.215.144.139
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.KEEP_ALIVE_INTERVAL=25
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.KEEP_ALIVE_METHOD=OPTIONS
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.PREFERRED_TRANSPORT=udp
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.VOICEMAIL_ENABLED=false
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.AMR-WB/16000=750
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.G722/8000=700
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.GSM/8000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.H263-1998/90000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.H264/90000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.PCMA/8000=600
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.PCMU/8000=650
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.SILK/12000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.SILK/16000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.SILK/24000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.SILK/8000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.VP8/90000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.iLBC/8000=10
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.opus/48000=1000
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.red/90000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.speex/16000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.speex/32000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.speex/8000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.telephone-event/8000=1
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.Encodings.ulpfec/90000=0
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.OVERRIDE_ENCODINGS=true
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.DEFAULT_ENCRYPTION=false
net.java.sip.communicator.impl.protocol.sip.acc1403273890647.DOMAIN_BASE=meet.mydomain.org
org.jitsi.jigasi.xmpp.acc.IS_SERVER_OVERRIDDEN=true
org.jitsi.jigasi.xmpp.acc.SERVER_ADDRESS=127.0.0.1
org.jitsi.jigasi.xmpp.acc.VIDEO_CALLING_DISABLED=true
org.jitsi.jigasi.xmpp.acc.JINGLE_NODES_ENABLED=false
org.jitsi.jigasi.xmpp.acc.IM_DISABLED=true
org.jitsi.jigasi.xmpp.acc.SERVER_STORED_INFO_DISABLED=true
org.jitsi.jigasi.xmpp.acc.IS_FILE_TRANSFER_DISABLED=true
net.java.sip.communicator.service.gui.ALWAYS_TRUST_MODE_ENABLED=true
org.jitsi.jigasi.ENABLE_SIP=true
I then connected to https://meet.mydomain.org/testhman, clicked on the + sign, typed in “4053”, and noticed that the jitsi-meet web UI keeps notifying me that " has been invited" (ie. blank string instead of “4053”). Anyway, I guess that’s a minor bug if and only if the number I dialed is honored.
Now I’m finally getting an error in /var/log/jitsi/jigasi.log that I wasn’t seeing before when connecting to Asterisk 1.4:
2020-04-04 01:22:16.994 WARNING: [82] org.jitsi.jigasi.xmpp.CallControl.checkAuthorized().287 Requests are not secured by JID filter!
2020-04-04 01:22:16.994 INFO: [82] org.jitsi.jigasi.xmpp.CallControl.handleDialIq().211 [ctx=158595613699230988622] Got dial request fromnumber -> 4053 room: testhman@conference.meet.mydomain.org
2020-04-04 01:22:17.001 INFO: [82] org.jitsi.jigasi.JvbConference.setXmppProvider().539 [ctx=158595613699230988622] Using ProtocolProviderServiceJabberImpl(Jabber:5646fa2f@meet.mydomain.org/5646fa2f)
2020-04-04 01:22:17.009 WARNING: [82] org.jitsi.xmpp.component.ComponentBase.log() PROCESSING TIME LIMIT EXCEEDED - it took 17ms to process: <iq type="set" to="callcontrol.meet.mydomain.org" from="focus@auth.meet.mydomain.org/focus368795356414708" id="lKMaD-260886"><dial xmlns="urn:xmpp:rayo:1" to="4053" from="fromnumber"><header value="testhman@conference.meet.mydomain.org" name="JvbRoomName"/></dial></iq>
2020-04-04 01:22:17.235 INFO: [83] impl.protocol.jabber.OperationSetBasicTelephonyJabberImpl.registrationStateChanged().125 Jingle : ON
2020-04-04 01:22:17.236 INFO: [83] org.jitsi.jigasi.JvbConference.registrationStateChanged().577 [ctx=158595613699230988622] Registering XMPP.
2020-04-04 01:22:17.237 SEVERE: [83] impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin().1003 Failed to connect to XMPP service
org.jivesoftware.smack.SmackException: No supported and enabled SASL Mechanism provided by server. Server announced mechanisms: [PLAIN]. Registered SASL mechanisms with Smack: [SASL Mech: GSSAPI, Prio: 100, SASL Mech: SCRAM-SHA-1-PLUS, Prio: 100, SASL Mech: SCRAM-SHA-1, Prio: 110, SASL Mech: DIGEST-MD5, Prio: 200, SASL Mech: CRAM-MD5, Prio: 300, SASL Mech: PLAIN, Prio: 400, SASL Mech: X-OAUTH2, Prio: 410, SASL Mech: EXTERNAL, Prio: 500, SASL Mech: ANONYMOUS, Prio: 500]. Enabled SASL mechanisms for this connection: [ANONYMOUS]. Blacklisted SASL mechanisms: [SCRAM-SHA-1-PLUS].
at org.jivesoftware.smack.SASLAuthentication.selectMechanism(SASLAuthentication.java:361)
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:192)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.loginInternal(XMPPTCPConnection.java:387)
at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:491)
at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:448)
at net.java.sip.communicator.impl.protocol.jabber.AnonymousLoginStrategy.login(AnonymousLoginStrategy.java:84)
at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin(ProtocolProviderServiceJabberImpl.java:1371)
at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin(ProtocolProviderServiceJabberImpl.java:970)
at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.initializeConnectAndLogin(ProtocolProviderServiceJabberImpl.java:795)
at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.register(ProtocolProviderServiceJabberImpl.java:500)
at org.jitsi.jigasi.util.RegisterThread.run(RegisterThread.java:59)
2020-04-04 01:22:17.268 WARNING: [87] org.jivesoftware.smack.roster.Roster.processStanza() Roster not loaded while processing Presence Stanza [id=9aD0m-38,type=error,]
2020-04-04 01:22:17.270 SEVERE: [83] org.jitsi.jigasi.JvbConference.registrationStateChanged().581 [ctx=158595613699230988622] XMPP Connection failed.
# cat /etc/prosody/conf.d/meet.mydomain.org.cfg.lua
VirtualHost "meet.mydomain.org"
authentication = "ldap2"
- ssl = {
key = "/etc/prosody/certs/meet.mydomain.org.key";
certificate = "/etc/prosody/certs/meet.mydomain.org.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
Component "conference.meet.mydomain.org" "muc"
storage = "null"
--modules_enabled = { "token_verification" }
admins = { "focus@auth.meet.mydomain.org" }
Component "jitsi-videobridge.meet.mydomain.org"
component_secret = "czzEeVRH"
VirtualHost "auth.meet.mydomain.org"
ssl = {
key = "/etc/prosody/certs/auth.meet.mydomain.org.key";
certificate = "/etc/prosody/certs/auth.meet.mydomain.org.crt";
}
authentication = "internal_plain"
Component "focus.meet.mydomain.org"
component_secret = "lqrfPXSD"
VirtualHost "guest.meet.mydomain.org"
authentication = "anonymous"
Component "callcontrol.meet.mydomain.org"
component_secret = "ivqzsJSh"
Any ideas?
I finally got it working somehow.
I used this for jigasi:
org.jitsi.jigasi.xmpp.acc.USER_ID=myldapuser@meet.mydomain.org
org.jitsi.jigasi.xmpp.acc.PASS=myldappassword
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
org.jitsi.jigasi.USE_SIP_USER_AS_XMPP_RESOURCE=true
I don’t quite understand what USE_SIP_USER_AS_XMPP_RESOURCE means.
In any case, isn’t there a way to allow jigasi to connect to xmpp without authentication while enabling authentication for the main virtualhost? I’m using LDAP for authentication, and these users must periodically renew their credentials. I don’t want to use an LDAP user for jigasi… I have zero experience with Prosody. I’ve tried adding anonymous to the callcontrol component like so:
Component "callcontrol.meet.mydomain.org"
component_secret = "jigasisecret"
authentication = "anonymous"
but it doesn’t seem to work.
Any suggestions?
EDIT: Never mind. I used a special LDAP/AD user for jigasi. I guess I’ll keep it that way.
What would really be useful to everyone is a publicly writable wiki periodically reviewed/edited by the Jitsi devs so that user contributions can be stored in just one place and easily searched for. The forum has interesting findings, but they are dispersed. The official documentation is fine but lacks quite a few things. The user-contributed docs would really help people out.
1 Like
I have a very similar problem, when I run the secure domain jigasi does not connect to XMPP
org.jitsi.jigasi.JvbConference.registrationStateChanged().581 [ctx=15862572610601744470295] XMPP Connection failed.
Hi @Vieri_Di_Paola, @DanielAudio
Don’t know if this helps in your specific situation, but we spent days trying to figure out why jigasi couldn’t authenticate to the XMPP prosody server. In our case, this was also preventing us from being able to call outbound.
Here’s the fix we used to resolve the issue:
In /etc/jitsi/jigasi/sip-communicator.properties, uncomment or add the following lines.
# If you want jigasi to perform authenticated login instead of anonymous login
# to the XMPP server, you can set the following properties.
# org.jitsi.jigasi.xmpp.acc.USER_ID=SOME_USER@SOME_DOMAIN
# org.jitsi.jigasi.xmpp.acc.PASS=SOME_PASS
# org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
org.jitsi.jigasi.xmpp.acc.USER_ID=JIGASI@YourFQDN
org.jitsi.jigasi.xmpp.acc.PASS=PlaintextPassword
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
where the above USER_ID and PASS are also the same used to create the JIGASI user in prosody by using the command:
sudo prosodyctl register JIGASI YourFQDN PlaintextPassword
After doing the above and for the config changes to take effect restart, prosody, jocofo, jigasi and jitsi-videobridge2 with the following commands:
sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jigasi
sudo systemctl restart jitsi-videobridge2
Hopefully this helps!
1 Like
We are still however unable to get inbound calling to work with our SIP provider. It appears that the issue is caused by “No JVB room name provided in INVITE header”.
Here’s what we see in the jigasi log:
jigasi_1 | Jigasi 2020-04-18 21:41:15.549 INFO: [264] org.jitsi.jigasi.SipGateway.incomingCallReceived().196 [ctx=15872604755491484561672] Incoming call received…
jigasi_1 | Jigasi 2020-04-18 21:41:16.551 INFO: [265] org.jitsi.jigasi.SipGatewaySession.run().1475 [ctx=15872604755491484561672] No JVB room name provided in INVITE header
Unfortunately, we do not have the ability to configure the INVITE header at our SIP provider.
When we try to set a default JVB room name ( ‘org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME’ config property) as per the documentation, this however makes no difference. Jigasi just immediately hangs up. So setting the default JVB room name appears to be broken in the current implementation of jigasi.
Is anyone else able to get inbound calling to work correctly by setting the default room name property, in lieu of having to set the room name in the INVITE header?
Thanks much!
(As per documentation at https://github.com/jitsi/jigasi:)
Jigasi will register on your SIP server with some identity and it will accept calls. When Jigasi is called, it expects to find a ‘Jitsi-Conference-Room’ header in the invite with the name of the Jitsi Meet conference the call is to be patched through to. If no header is present it will join the room specified under ‘org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME’ config property. In order to change it, edit ‘jigasi-home/sipcommunciator.properties’ file.
UPDATE:
We finally managed to get inbound calling working by only setting the org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME property, w/o setting the INVITE header. The default room name property appears to be case-sensitive. The default room name must precisely match (upper and lower case) the room name that was used to create the meeting by the moderator.
However, now we have another issue. If the room moderator sets a password on the default room, an inbound caller can’t join the room, since there is no way for the inbound caller to enter a password.
Checking the jigasi log, we now see:
**
2020-04-19 17:31:52.350 SEVERE: [1254] org.jitsi.jigasi.JvbConference.joinConferenceRoom().701 net.java.sip.communicator.service.protocol.OperationFailedException: Failed to join chat room […] with nickname: 171945ace5d. The chat room requests a password.
**
This isn’t the behavior we want. Is there a way to configure Jigasi to allow inbound callers to join the room even if the moderator has set a password on the room?
I suppose, the standard procedure could be to first allow all callers that will be joining the meeting to first call in and connect, and then the moderator can set the room password. Doing this then locks the room and prevents anyone else from being able to join the conference once the room password has been set. A moderator could then remove the room password to admit other callers to join the room, but this would be real pain, especially if callers get disconnected and need to call back in during a meeting in progress. If the room password is set, then they aren’t and won’t able to call back in.
So again, is there any way to configure Jigasi to allow inbound callers to join the room even if the moderator has set a password on the room?
1 Like
You need to send the password via SIP header.
This can be achieved by creating an IVR to collect the password from the caller (if one exists) then , add the password SIP header and pass the call to Jigasi.
1 Like
That’s not possible without custom programming by our SIP provider, nor would we want to hard-code the password for security reasons.
So again, I presume there isn’t any way to configure Jigasi to allow inbound callers to join the room when the moderator has set a password on the room?
No, you need to implement an IVR to ask user for password and send it as a header, otherwise this breaks the security and there is no point of having a password.
If you cannot do it on your sip provider, then you will need asterisk or freeswitch to implement your IVR asking for room Id and password and set the sip headers.
1 Like
You wouldn’t hard code the password. The IVR would ask the caller for the password. Then the user enters a password, the IVR adds the entered password as a SIP header and passes the call onto Jigasi. If the caller entered an incorrect password into the IVR , then they’re denied and the call is dropped.
This assumes you have access to the PBX, otherwise your options are limited in general with SIP integration.
Well that makes perfect sense. Thanks for the technical clarification @Craig_Eustice and @damencho. It’s very helpful.
We have at the moment two separate private Jitsi-Meet instances with Jigasi/Jibri setup for testing and running on two different VMs, One is running the the non-Docker quick install, and the other is running the Docker quick-install. Unfortunately, I don’t have much experience with SIP or XMPP messaging but this is changing rapidly as we’ve been asked to help medical first-responders setup secure remote video conferencing systems here in NYC. Jitsi is truly an extraordinary platform, especially in light of some of the security/privacy issues that have surfaced with other platforms, and we are very grateful for the existence of Jitsi.org.
Regarding the Jitsi instance running on Docker, how does one set the default JVB room name to enable inbound calling without having to set the INVITE header or hack the docker-composed, auto-generated config files? There doesn’t appear to be a .env variable defined that enables one to set this default JVB room property.
Also, would be deeply appreciative of any guidance on how to setup either a freeswitch or asterisk-based SIP client front end for our various Jitsi/Jigasi installs to configure some kind of auto-attendant/room routing capability. To be clear, we generally do not have access to our SIP provider’s server-side settings, so hence we need another way to control the INVITE headers.
Any advice or technical guidance on this is very deeply appreciated.
I don’t use the Docker version, but are you saying neither version connects or just the Docker version?
For me , I simply changed the default siptest line in file: /etc/jitsi/jigasi/sip-communicator.properties
to read: org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=videoconference1
I also had random XMPP issues until adding: net.java.sip.communicator.service.gui.ALWAYS_TRUST_MODE_ENABLED=true