jigasi exception on placing incoming call for a conference room

[ashailly]

Hi,
I have enabled the sip gateway - jigasi container for jitsi meet. I’m using Asterisk as a sip server and Jitsi Desktop as a sip client
Outgoing calls to a registered sip client from jitsi meet is working over jigasi gateway . The sip client is able to join the video conference room for audio.

Issue - incoming call is not able to join the video conference room.

Jigasi logs shows NullPointerException on "jigasi.JvbConference.getResourceIdentifier". Is there any missing configuration that could be causing this exception for incoming calls ?
Please help.

Asterisk Dial plan configured with room name “siptest” –
exten => 103,1,SIPAddHeader(X-Room-Name: siptest)
exten => 103,2,Dial(SIP/jigasi)
exten => 103,3,Hangup()

Jigasi log -
Jigasi 2018-11-28 09:15:59.405 INFO: [3478] org.jitsi.jigasi.SipGateway.incomingCallReceived().188 Incoming call received…
Jigasi 2018-11-28 09:16:00.407 INFO: [3479] org.jitsi.jigasi.SipGatewaySession.run().894 Wait thread cancelled
Jigasi 2018-11-28 09:16:00.407 SEVERE: [3478] impl.protocol.sip.SipStackSharing.logApplicationException().1145 An error occurred while processing event of type: javax.sip.DialogTerminatedEvent
java.lang.NullPointerException
at org.jitsi.jigasi.JvbConference.getResourceIdentifier(JvbConference.java:354)
at org.jitsi.jigasi.JvbConference.start(JvbConference.java:404)
at org.jitsi.jigasi.SipGatewaySession.joinJvbConference(SipGatewaySession.java:315)
at org.jitsi.jigasi.SipGatewaySession.onJoinJitsiMeetRequest(SipGatewaySession.java:538)
at net.java.sip.communicator.impl.protocol.sip.OperationSetJitsiMeetToolsSipImpl.notifyJoinJitsiMeetRoom(OperationSetJitsiMeetToolsSipImpl.java:112)
at net.java.sip.communicator.impl.protocol.sip.CallSipImpl.processInvite(CallSipImpl.java:569)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processInvite(OperationSetBasicTelephonySipImpl.java:1103)
at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processRequest(OperationSetBasicTelephonySipImpl.java:337)
at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.processRequest(ProtocolProviderServiceSipImpl.java:1114)
at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.processRequest(SipStackSharing.java:732)
at gov.nist.javax.sip.EventScanner.deliverRequestEvent(EventScanner.java:250)
at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:146)
at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:185)
at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:1324)
at gov.nist.javax.sip.stack.SIPServerTransactionImpl.processRequest(SIPServerTransactionImpl.java:811)
at gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:568)
at gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:514)
at gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:319)
at java.lang.Thread.run(Thread.java:748)

[saghul]

Ping @damencho

[korob93]

Any news?

[ashailly]

No, I never heard back from anyone :(. Tried to reach out to Damian and Saul as well, but no response. If you ever find a solution to this issue please do let me know. Thanks for checking,Regards,Shailly. On ‎Wednesday‎, ‎December‎ ‎26‎, ‎2018‎ ‎04‎:‎48‎:‎56‎ ‎PM‎ ‎EST, Dmitry <notifications@github.com> wrote: Any news? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[saghul]

The holiday season is a tricky one, I'll try to look into this soon.

[korob93]

Hello @ashailly @saghul. I went to my ${CONFIG}/jigasi/sip-communicator.properties (which is ~/.jitsi-meet-cfg/jigasi/sip-communicator.properties) and set net.java.sip.communicator.impl.protocol.sip.acc1.DOMAIN_BASE value equal to XMPP_DOMAIN in my .env file. NullPointerException has gone. Btw, is this XMPP_DOMAIN supposed to be changed to a real domain my server is assigned to? Because I changed it to jitsi.<my subdomain>.<my domain>

[saghul]

set net.java.sip.communicator.impl.protocol.sip.acc1.DOMAIN_BASE value equal to XMPP_DOMAIN in my .env file.

I'm not sure you need that. How about setting it to the domain in the SIP address?

Btw, is this XMPP_DOMAIN supposed to be changed to a real domain my server is assigned to? Because I changed it to jitsi.<my subdomain>.<my domain>

No, you shouldn't change that. All XMPP traffic is internal and doesn't leave the Docker network. As such, changing it is pointless, because as long as Docker knows how to route the traffic you are good to go.

[korob93]

@saghul do you mean net.java.sip.communicator.impl.protocol.sip.acc1.SERVER_ADDRESS? I set it's value to sip gateway LAN ip address

[ashailly]

NullPointerException has gone

Hi @korob93 - Is your incoming call able to join the video conference room after the fix ?
I checked my sip-communicator.properties file, and it's default set to the XMPP_DOMAIN value, so that's shouldn't be an issue on my end I guess...

[saghul]

do you mean net.java.sip.communicator.impl.protocol.sip.acc1.SERVER_ADDRESS? I set it's value to sip gateway LAN ip address

@korob93 That should be set to your SIP server's address or domain.

[korob93]

@ashailly yes, but there were some other problems to solve after the NullPointer. I've noticed that prosody certs generation failes while starting up docker (I'm not sure if this is reproducable in this repo, my teammates made a fork), so had to fix this issue. Then I've enabled internal storage for prosody's muc and internal muc. Finally, I went to jvb's sip-communicator.properties and changed AUTHORIZED_SOURCE_REGEXP, 'cause incomig calls were rejected due to calls are only allowed from the focus user. I'm not quite sure if I've configured everethyng as it should be since I'm not familiar with conferencing, but at least I made it possible to call the conference =)

Speaking of NullPointer, as you can see from here, it can be either when callContext or callContext.getCallResource() is null, 'cause stacktrace begins with that line. CallResource should be set in updateCallResource private method. The only public methods, calling updateCallResource are setDomain and setSubDomain. If we look for setDomain calls we will see, that it's called from here and it's value is taken from sip-communicator.properties file from DOMAIN_BASE prop. Basically, that made me think I should specify it in my config file

[damencho]

@saghul DOMAIN_BASE should be specified. Is this what you were asking for?

The 'calls are only allowed from the focus user' is cause we are dropping the p2p calls as they are not supported and we establish only calls initiated from jicofo.