[jitsi-users] Jigasi not answering an incoming SIP call


#1

I'd welcome any tips on troubleshooting a Jigasi server not auto-answering calls coming in across SIP.

The server is Debian 9, and I installed the Jitsi stack using https://jitsi.org/downloads/ubuntu-debian-installations-instructions/

I have configured authentication (following the “secure domain” example at https://github.com/jitsi/jicofo).

I installed jigasi using apt-get.

I have configured it with credentials for my SIP server, and I can see on the SIP server that it is registering as a client successfully.

As I cannot send custom SIP headers are the moment, I am reliant on the value in org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME

This is currently set to org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest (the default)

However, when I go to https://subdomain.domain.tld/siptest, and authenticate and create the room, and then call the extension of the SIP client, the call rings, but Jigasi does not answer.

What is the best way of debugging this, please?

Neil


#2

Hi,

Can you try setting
org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest@conference.yourdomain.com
And try whether it makes any difference.

Regards
damencho

···

On Wed, Aug 23, 2017 at 9:51 AM, <jitsi@neilzone.co.uk> wrote:

I'd welcome any tips on troubleshooting a Jigasi server not auto-answering
calls coming in across SIP.

The server is Debian 9, and I installed the Jitsi stack using
https://jitsi.org/downloads/ubuntu-debian-installations-instructions/

I have configured authentication (following the “secure domain” example at
https://github.com/jitsi/jicofo).

I installed jigasi using apt-get.

I have configured it with credentials for my SIP server, and I can see on
the SIP server that it is registering as a client successfully.

As I cannot send custom SIP headers are the moment, I am reliant on the
value in org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME

This is currently set to org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest (the
default)

However, when I go to https://subdomain.domain.tld/siptest, and authenticate
and create the room, and then call the extension of the SIP client, the call
rings, but Jigasi does not answer.

What is the best way of debugging this, please?

Neil

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Thanks damencho

Can you try setting
org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest@conference.yourdomain.com <mailto:org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest@conference.yourdomain.com>

I’ve changed to this format, then restart the server, but no change: the call to the extension carries on ringing.

Neil

···

On 23 Aug 2017, at 15:56, Damian Minkov <damencho@jitsi.org> wrote:


#4

On digging into the jigasi.log file, I see this, but I’m not sure what to do with the information:

2017-08-23 18:28:05.361 INFO: [559] org.jitsi.jigasi.JvbConference.registrationStateChanged().540 XMPP (15e102305cb@subdomain.domain.tld): RegistrationStateChangeEvent[ oldState=Unregistered; newState=RegistrationState=Registering; reasonCode=-1; reason=null]
2017-08-23 18:28:05.372 SEVERE: [564] org.jivesoftware.smack.Connection.notifyListener() null
java.lang.NullPointerException
  at java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
  at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
  at net.java.sip.communicator.impl.protocol.jabber.extensions.caps.EntityCapsManager.removeUserCapsNode(EntityCapsManager.java:359)
  at net.java.sip.communicator.impl.protocol.jabber.extensions.caps.EntityCapsManager$CapsPacketListener.processPacket(EntityCapsManager.java:980)
  at org.jivesoftware.smack.Connection$ListenerWrapper.notifyListener(Connection.java:877)
  at org.jivesoftware.smack.PacketReader$ListenerNotification.run(PacketReader.java:403)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

When I hang up, I see the call terminate:

2017-08-23 18:28:17.285 INFO: [573] org.jitsi.jigasi.GatewaySession.handleCallState().774 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=Peer Name <extension@domain.tld>;status=Disconnected

(No, it is not actually “subdomain.domain.tld” :))

Neil

···

On 23 Aug 2017, at 16:32, jitsi@neilzone.co.uk wrote:

Can you try setting
org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest@conference.yourdomain.com <mailto:org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest@conference.yourdomain.com>

I’ve changed to this format, then restart the server, but no change: the call to the extension carries on ringing.


#5

Did you configure credentials for the jigasi user (you need to create
a jigasi user inside prosody and configure those inside jigasi
config):
https://github.com/jitsi/jigasi/blob/master/jigasi-home/sip-communicator.properties#L77

···

On Wed, Aug 23, 2017 at 12:32 PM, <jitsi@neilzone.co.uk> wrote:

On 23 Aug 2017, at 16:32, jitsi@neilzone.co.uk wrote:

Can you try setting
org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=siptest@conference.yourdomain.com

I’ve changed to this format, then restart the server, but no change: the
call to the extension carries on ringing.

On digging into the jigasi.log file, I see this, but I’m not sure what to do
with the information:

2017-08-23 18:28:05.361 INFO: [559]
org.jitsi.jigasi.JvbConference.registrationStateChanged().540 XMPP
(15e102305cb@subdomain.domain.tld): RegistrationStateChangeEvent[
oldState=Unregistered; newState=RegistrationState=Registering;
reasonCode=-1; reason=null]
2017-08-23 18:28:05.372 SEVERE: [564]
org.jivesoftware.smack.Connection.notifyListener() null
java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
at
java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
at
net.java.sip.communicator.impl.protocol.jabber.extensions.caps.EntityCapsManager.removeUserCapsNode(EntityCapsManager.java:359)
at
net.java.sip.communicator.impl.protocol.jabber.extensions.caps.EntityCapsManager$CapsPacketListener.processPacket(EntityCapsManager.java:980)
at
org.jivesoftware.smack.Connection$ListenerWrapper.notifyListener(Connection.java:877)
at
org.jivesoftware.smack.PacketReader$ListenerNotification.run(PacketReader.java:403)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

When I hang up, I see the call terminate:

2017-08-23 18:28:17.285 INFO: [573]
org.jitsi.jigasi.GatewaySession.handleCallState().774 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=Peer Name <extension@domain.tld>;status=Disconnected

(No, it is not actually “subdomain.domain.tld” :))

Neil

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#6

Hello damencho

Thanks for your ongoing support.

Did you configure credentials for the jigasi user (you need to create
a jigasi user inside prosody and configure those inside jigasi
config):
https://github.com/jitsi/jigasi/blob/master/jigasi-home/sip-communicator.properties#L77

I had not done this, no.

I have created a jigasi user in prosody with:

prosodyctl adduser jigasi@subdomain.domain.tld <mailto:jigasi@subdomain.domain.tld>

I verified that the user/password can authenticate to create a conference room, via the web interface.

I mapped that user into sip-commmunicator.properties:

# 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=jigasi@subdomain.domain <mailto:org.jitsi.jigasi.xmpp.acc.USER_ID=jigasi@subdomain.domain>.tld
org.jitsi.jigasi.xmpp.acc.PASS=password-goes-here
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
org.jitsi.jigasi.xmpp.acc.BOSH_URL_PATTERN=https://subdomain.domain.com/http-bind?room={roomName} <https://subdomain.domain.com/http-bind?room={roomName}>

I visited https://subdomain.domain.com/http-bind?room=siptest in my browser, and that shows the BOSH answering page.

However, calls are still not answered.

I have pasted the full log here: https://pastebin.com/Lz4tLUSu

I think the key parts are:

2017-08-24 07:27:22.245 SEVERE: [2710] util.UtilActivator.uncaughtException().119 An uncaught exception occurred in thread=Thread[RequestProcessor[660341971]: Receive thread 0,10,main] and message was: Connection is not open

···

On 23 Aug 2017, at 19:09, Damian Minkov <damencho@jitsi.org> wrote:

2017-08-24 07:27:32.264 SEVERE: [2719] org.jitsi.jigasi.SipGateway.notifyCallEnded().190 Call resource not exists for session 15e12ec7763@subdomain.domain.tld <mailto:15e12ec7763@subdomain.domain.tld>

Many thanks for any further thoughts you might have,

Neil


#7

Sorry for replying to myself.

# 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=jigasi@subdomain.domain <mailto:org.jitsi.jigasi.xmpp.acc.USER_ID=jigasi@subdomain.domain>.tld
org.jitsi.jigasi.xmpp.acc.PASS=password-goes-here
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
org.jitsi.jigasi.xmpp.acc.BOSH_URL_PATTERN=https://subdomain.domain.com/http-bind?room={roomName} <https://subdomain.domain.com/http-bind?room={roomName}>

I visited https://subdomain.domain.com/http-bind?room=siptest <https://subdomain.domain.com/http-bind?room=siptest> in my browser, and that shows the BOSH answering page.

I have disabled the BOSH functionality. I had thought it was required, to enable an XMPP user, but https://github.com/jitsi/jigasi/issues/52 suggests I was wrong.

I am now using:

# 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=jigasi@subdomain.domain <mailto:org.jitsi.jigasi.xmpp.acc.USER_ID=jigasi@subdomain.domain>.tld
org.jitsi.jigasi.xmpp.acc.PASS=password-goes-here
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
# org.jitsi.jigasi.xmpp.acc.BOSH_URL_PATTERN=https://subdomain.domain.com/http-bind?room={roomName} <https://subdomain.domain.com/http-bind?room={roomName}>
  
At this point, I goe a different error:

2017-08-24 07:44:01.718 SEVERE: [64] org.jivesoftware.smack.PacketReader.notifyConnectionError() Closes the connection temporary
Server does not support security (TLS), but security required by connection configuration.: forbidden(403)

My server is using a LetsEncrypt certificate, and I am not sure how to configure it *not* to use SSL.

I tried setting:

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

But this did not make a difference (presumably because it is not a problem with the certificate's trust, but because it is trying to use SSL), and I got the same error message:

2017-08-24 07:51:36.131 SEVERE: [79] org.jivesoftware.smack.PacketReader.notifyConnectionError() Closes the connection temporary
Server does not support security (TLS), but security required by connection configuration.: forbidden(403)

I have tried ROOM_NAME as both siptest and siptest@subdomain.domain.com <mailto:siptest@subdomain.domain.com>

Neil

···

On 24 Aug 2017, at 07:38, jitsi@neilzone.co.uk wrote:


#8

You need to check why the server doesn't support TLS. Is this prosody?

···

On Thu, Aug 24, 2017 at 1:57 AM, <jitsi@neilzone.co.uk> wrote:

On 24 Aug 2017, at 07:38, jitsi@neilzone.co.uk wrote:

Sorry for replying to myself.

# 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=jigasi@subdomain.domain.tld
org.jitsi.jigasi.xmpp.acc.PASS=password-goes-here
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false

org.jitsi.jigasi.xmpp.acc.BOSH_URL_PATTERN=https://subdomain.domain.com/http-bind?room={roomName}

I visited https://subdomain.domain.com/http-bind?room=siptest in my browser,
and that shows the BOSH answering page.

I have disabled the BOSH functionality. I had thought it was required, to
enable an XMPP user, but https://github.com/jitsi/jigasi/issues/52 suggests
I was wrong.

I am now using:

# 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=jigasi@subdomain.domain.tld
org.jitsi.jigasi.xmpp.acc.PASS=password-goes-here
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
#
org.jitsi.jigasi.xmpp.acc.BOSH_URL_PATTERN=https://subdomain.domain.com/http-bind?room={roomName}
At this point, I goe a different error:

2017-08-24 07:44:01.718 SEVERE: [64]
org.jivesoftware.smack.PacketReader.notifyConnectionError() Closes the
connection temporary
Server does not support security (TLS), but security required by connection
configuration.: forbidden(403)

My server is using a LetsEncrypt certificate, and I am not sure how to
configure it *not* to use SSL.

I tried setting:

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

But this did not make a difference (presumably because it is not a problem
with the certificate's trust, but because it is trying to use SSL), and I
got the same error message:

2017-08-24 07:51:36.131 SEVERE: [79]
org.jivesoftware.smack.PacketReader.notifyConnectionError() Closes the
connection temporary
Server does not support security (TLS), but security required by connection
configuration.: forbidden(403)

I have tried ROOM_NAME as both siptest and siptest@subdomain.domain.com

Neil

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#9

Yes, it is prosody.

In terms of external access, to jitsi-meet, the user visits https://subdomain.domain.tld/roomname, so I have https support at least in some place on that server, but perhaps that is not relevant?

Best wishes

Neil

···

On 24 Aug 2017, at 13:00, Damian Minkov <damencho@jitsi.org> wrote:

You need to check why the server doesn't support TLS. Is this prosody?


#10

You need to check why the server doesn't support TLS. Is this prosody?

Yes, it is prosody.

In terms of external access, to jitsi-meet, the user visits
https://subdomain.domain.tld/roomname, so I have https support at least in
some place on that server, but perhaps that is not relevant?

https is terminated by a webserver (nginx, apache or jetty). The xmpp
account of jigasi as you have configured it is connecting to prosody
port 5222 which doesn't offer a TLS for some reason ...
At the moment not sure what can be wrong ...

···

On Thu, Aug 24, 2017 at 7:11 AM, <jitsi@neilzone.co.uk> wrote:

On 24 Aug 2017, at 13:00, Damian Minkov <damencho@jitsi.org> wrote:

Best wishes

Neil

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#11

Strange… Thanks for the pointers; I will take a look and see if I can find something in prosody config.

If it helps, I used the Debian packages for all the jitsi components.

Best wishes

Neil

···

On 24 Aug 2017, at 13:41, Damian Minkov <damencho@jitsi.org> wrote:

In terms of external access, to jitsi-meet, the user visits
https://subdomain.domain.tld/roomname, so I have https support at least in
some place on that server, but perhaps that is not relevant?

https is terminated by a webserver (nginx, apache or jetty). The xmpp
account of jigasi as you have configured it is connecting to prosody
port 5222 which doesn't offer a TLS for some reason ...
At the moment not sure what can be wrong ...


#12

The answer appears to be that:
  a.) the relevant certificates were owned by root:root, and not prosody. This seems fine for the web server (jetty), but meant prosody could not access them. chown to prosody:prosody seems to have done the trick. (I suspect I’ll need a script to fix this automatically on renewal with LetsEncrypt.)
  b.) having changed the ownership, the prosody error log said there was a problem with the certificate’s trust. I uncommented net.java.sip.communicator.service.gui.ALWAYS_TRUST_MODE_ENABLED=true

I also experimented with changing

  org.jitsi.jigasi.xmpp.acc.SERVER_ADDRESS=127.0.0.1

to

  org.jitsi.jigasi.xmpp.acc.SERVER_ADDRESS=::1

It appears to work with either set.

Initially, it seemed to attempt to connect one call multiple times but, after another restart, it seems to be accepting just one call.

Thank you for all your help.

Neil

···

On 24 Aug 2017, at 15:33, jitsi@neilzone.co.uk wrote:

https is terminated by a webserver (nginx, apache or jetty). The xmpp
account of jigasi as you have configured it is connecting to prosody
port 5222 which doesn't offer a TLS for some reason ...
At the moment not sure what can be wrong ...

Strange… Thanks for the pointers; I will take a look and see if I can find something in prosody config.


#13

Neil

On point A (presuming your using Debian) install the package 'ssl-cert' and then add user prosody to group ssl-cert and chown your private key to root:ssl-cert with 640 permissions

A bit neater and may survive (haven't tried) your Lets Encrypt renewals

Tom

···

On 24 Aug 2017, at 20:22, jitsi@neilzone.co.uk wrote:

On 24 Aug 2017, at 15:33, jitsi@neilzone.co.uk wrote:

https is terminated by a webserver (nginx, apache or jetty). The xmpp
account of jigasi as you have configured it is connecting to prosody
port 5222 which doesn't offer a TLS for some reason ...
At the moment not sure what can be wrong ...

Strange… Thanks for the pointers; I will take a look and see if I can find something in prosody config.

The answer appears to be that:
  a.) the relevant certificates were owned by root:root, and not prosody. This seems fine for the web server (jetty), but meant prosody could not access them. chown to prosody:prosody seems to have done the trick. (I suspect I’ll need a script to fix this automatically on renewal with LetsEncrypt.)
  b.) having changed the ownership, the prosody error log said there was a problem with the certificate’s trust. I uncommented net.java.sip.communicator.service.gui.ALWAYS_TRUST_MODE_ENABLED=true

I also experimented with changing

  org.jitsi.jigasi.xmpp.acc.SERVER_ADDRESS=127.0.0.1

to

  org.jitsi.jigasi.xmpp.acc.SERVER_ADDRESS=::1

It appears to work with either set.

Initially, it seemed to attempt to connect one call multiple times but, after another restart, it seems to be accepting just one call.

Thank you for all your help.

Neil

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#14

Thanks, Tom — that would certainly be neater than my post-renewal bash script.

Neil

···

On 24 Aug 2017, at 19:27, Tom Richardson <tom.richardson@mailbox.org> wrote:

On point A (presuming your using Debian) install the package 'ssl-cert' and then add user prosody to group ssl-cert and chown your private key to root:ssl-cert with 640 permissions

A bit neater and may survive (haven't tried) your Lets Encrypt renewals