SIP2 Connection error

Nidheesh,

This is sounding very close to some of the issues we were having with bibliotheca self check machines. Our issue wasn't wrong credentials though, it was temporary internet disruptions. The result was much the same: 60 second delay. Is your Evergreen server in the same building where these machines are?

Server and self check machine are in the same LAN but not in the same building.

Is there any chance to decrease the time delay from 60 seconds to 5 or 10?

Nidheesh,

The issue we had was not with the Evergreen SIP server, but with Bibliotheca's software. However, there are several settings that you can change on the Evergreen side. Which oils_sip.xml file are you using?

This is the example packed with Evergreen:

http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/examples/oils_sip.xml.example;h=57ebda4596245fc5779dcaf10ad4685d174b1b8c;hb=HEAD

And this is from the SIP Repo
http://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=SIPconfig.xml;h=2e8d240cf6ed5e8503bb8fdceacbd53a15a1b8e4;hb=HEAD

There is a timeout option there. Also, we install the perl module Socket::Linux to help address long running TCP sessions.
http://search.cpan.org/~salva/Socket-Linux-0.01/lib/Socket/Linux.pm

hi,

as checked with other bibliotheca self check machine which is integrated with koha, there is no such interruption happened while entering wrong credentials. please have a look at the video attached and let me know if anything we can work with evergreen ILS for making it works without any interruption.

Nidheesh,

Do you have any logs showing the messages between your self check machine and Evergreen?

hi,

attached more logs for your reference.

Nidheesh,

Be careful what you allow on the internet. Your logs contain some sensitive information. I am curious what your SIP config file looks like. AKA /openils/conf/oils_sip.xml for example. Right off the bat, it looks like there might be a character encoding issue. If you haven't already, I would recommend changing your config from ASCII to UTF-8. It would be on a line like this:
<encoding>ascii</encoding>

Hi, the issue between server and kiosk is having some issues. Please confirm that issue is because of character encoding.

You can see the logs at 12 pm. I'd IDA00003 tried to log in but unsuccessful. Showing error message in kiosk and few transactions are getting updated in the server.

We have changed character encoding to utf8 and did some changes to get the correct encoding.

We are not able to get a correct diagnosis on this issue

please find the configuration file and let me know if any changes needed

please have a look at the videos, SIP is disconnecting initially on every transaction. it is successful on the second attempt.

And also, observed that SIP2 is not connecting with kiosk via telnet port. it is working only with RAW port.

I don't believe the telnet port actually works. I've never tried it anyway. The raw port is the only thing I've ever used, and the only thing I've ever seen or heard anyone using.

Thank you Jason,

please let me know if there any issue for connecting two devices in the same RAW port.

Actually we have tried connecting gate and kiosk together to the server via SIP2 and got some issues. Initially gate is got connected with server but at the same moment kiosk went offline.
Tried using another telnet port to connect gate and not succeeded.

2.11.8 is the version we use. we get lot of disturbances in connecting wth RAW port. you can see the same in the videos i have attached earlier.

Nidheesh, I think you should add a max_servers attribute in the server-params element at the top of your oils_sip.xml file. I'd set it to 10 or 20 just to be safe. It sounds like you may be running out of servers.

Unfortunately, a lot of SIP clients are poorly behaved and don't cleanly close their connections, so it is easy to run out of SIP processes.

I also recommend making sure that you have installed the Socket::Linux Perl module. SIPServer will use that to close half-closed, dangling connections and shut down idle SIPServer drones.

HTH,
Jason

hi team,

we have got some improvement in the connectivity between kiosk and ILS.

but connection request from kiosk is getting rejected initially when there is an idle time between transactions.
there is no issue in the transactions when you do continuously. if there is an idle time, then the first transaction request is getting rejected. second attempt will be successful. please look in to the logs attached and let me know if it is a known issue and there is any workaround for fixing the issue.

Turn off the generation of checksums on the Kiosk.

2017-12-05 18:07:23,224 TRACE [ 3] TcpTransportProvider - TCP: 78 bytes written; 0 ms
2017-12-05 18:07:23,224 TRACE [ 3] TcpTransportProvider - TCP: read
2017-12-05 18:07:23,225 TRACE [ 3] TcpTransportProvider - TCP: 0 bytes read; 1 ms
2017-12-05 18:07:23,227 TRACE [ 3] TcpTransportProvider - TCP: read
2017-12-05 18:07:23,228 TRACE [ 3] TcpTransportProvider - TCP: 0 bytes read; 3 ms
2017-12-05 18:07:23,228 DEBUG [ 3] SipCirculationProvider - Duration of operation: 57 ms
2017-12-05 18:07:24,136 ERROR [27] TcpTransportProvider - TCP: Socket error = ConnectionAborted
2017-12-05 18:07:24,138 ERROR [27] TcpTransportProvider - TCP: Socket error = ConnectionAborted
2017-12-05 18:07:24,141 INFO [27] TcpTransportProvider - TCP: Closing connection to: 192.168.127.11:8023

Those lines suggest you have a network problem. Something closed the connection after about 4 minutes of idle time, likely a switch or a router, quite possibly one of the hosts. Your client now has to establish a new connection.

Have you install the Socket::Linux Perl module on your SIPServer host and configured keepalive in the SIPServer code?

hi Jason,

we have tried connecting both server and kiosk in the same switch and subnet but result is the same. we assume that the issue is not in network but some issues in the configuration.

SIP2 login attempt is getting failed after an idle time. can log in successfully on the second attempt and there will not be any connection issues if you do continuous transactions.

regards,
Nidheesh