Jigasi not answering incoming call from Twilio

I have a script (webhook) in Twilio which answers incoming call, plays a greeting, collects digits then dials out to Jigasi to connect the call into a conference (room number is known). The call into Jigasi just rings a few times and hangs up. The script works for calling out to a softphone but not Jigasi (it is registered in the SIP domain).

Any suggestions ?

Thx.

Is there anybody in the room? The default is Jigasi to wait for 30 seconds to receive an invite from jvb, and that will not happen if there is nobody in the room.
You can control this with jigasi config: org.jitsi.jigasi.JVB_INVITE_TIMEOUT, default value is 30000.

Thx for the reply. I setup a meeting first with a person in it then call the script. Here are the last 20 lines of Jigasi log -

root@ec2-54-234-174-22:/var/log/jitsi# tail -20 jigasi.log

at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)

at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)

at java.base/sun.security.validator.Validator.validate(Validator.java:264)

at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)

at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222)

at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)

at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)

… 17 more

Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)

at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)

at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)

… 23 more

2022-08-16 21:02:15.702 INFO: [842] SipGatewaySession$SipCallStateListener.handleCallState#1440: [ctx=16606837007385368109] SIP call ended: CallPeerChangeEvent: type=CallPeerStatusChange oldV=net.java.sip.communicator.service.protocol.CallPeerState:Incoming Call newV=net.java.sip.communicator.service.protocol.CallPeerState:Disconnected for peer=+17328413612 +17328413612@rahuligan.sip.us1.twilio.com;status=Disconnected

2022-08-16 21:02:15.709 INFO: [842] SipGatewaySession.sipCallEnded#694: [ctx=16606837007385368109] Sip call ended: Call: id=1660683700734178881117 peers=0

2022-08-16 21:02:15.711 INFO: [842] JvbConference.stop#575: [ctx=16606837007385368109] Removing account Jabber:12607c6d@ec2-54-234-174-22.compute-1.amazonaws.com/12607c6d

2022-08-16 21:02:15.711 INFO: [842] net.java.sip.communicator.impl.protocol.jabber.OperationSetBasicTelephonyJabberImpl.registrationStateChanged: Jingle : OFF

2022-08-16 21:02:15.712 SEVERE: [842] AbstractGateway.notifyCallEnded#121: [ctx=16606837007385368109] Call resource not exists for session.

2022-08-16 21:02:15.712 INFO: [842] SipGatewaySession$CallPeerListener.peerStateChanged#1501: null SIP peer state: Disconnected

Also added this to prosody.config.lua -

Component “internal.auth.ec2-54-234-174-22.compute-1.amazonaws.com” “muc”

storage = “memory”

modules_enabled = {

“ping”;

}

admins = {focus@auth.ec2-54-234-174-22.compute-1.amazonaws.com”, “jigasi@auth.ec2-54-234-174-22.compute-1.amazonaws.com}

muc_room_locking = false

muc_room_default_public_jids = true

Is jigasi using bosh or does it connect to port 5222?

If it is the second one you can enable this: jigasi/sip-communicator.properties at dc53aced12d92fcc14f7aeee47e345cfb9ec9039 · jitsi/jigasi · GitHub

If it is bosh, you need a valid certificate in order to use jigasi, use Let’s Encrypt.

Worked … uncommented

net.java.sip.communicator.service.gui.ALWAYS_TRUST_MODE_ENABLED=true

You sir are a genius!