https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42770 Lari Strand <lmstrand@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lmstrand@gmail.com --- Comment #1 from Lari Strand <lmstrand@gmail.com> --- We've been using this plugin for over 5 years in our production environment in Finland with hundreds of self check machines and door systems (self service libraries): https://github.com/KohaSuomi/koha-plugin-SIPoHTTP It talks with Koha's SIP server on a per-message basis (every message will be authenticated with 93/94) and uses sockets to connect with the SIP server. Lyngsoe Systems, Bibliotheca and Mikroväylä self check system suppliers support this implementation and are all using it here. It has been proven to be very stable. We got rid of the need to have to maintain proxies/tunnels. Unstable internet connection is not a problem anymore with the devices since they don't rely on an always-on connection to Koha's SIP server anymore to be "online". It communicates with the Koha SIP server through a REST API endpoint and supports this unofficial XML schema proposed by Axiell back in the day as a protocol: https://github.com/KohaSuomi/kohasuomi.github.io/blob/master/sipschema.xsd We have already started getting the plugin ready for the integration of the SIP server being controlled from the intranet that was released in version 25.11. I would like to work on this if you think our REST-implementation is the way to go (still relying on the SIP server running in the background). We'd need to add the REST endpoint that parses/passes on messages to SIP2 server + some log4perl/Apache configuration to Koha. Obviously some changes to our plugin code needs to be made, since we have some specific code added just for our needs + we don't have the UI controlled SIP server stuff yet integrated and all SIP account data for authentication is being fetched from the sipconfig.xml file. The link you shared has the SIP messages wrapped in a JSON structure. I'm thinking of how we could support multiple variations of data being passed to the SIPOHTTPS endpoint, since we seem to have multiple data wrapping methods across the world... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42770 --- Comment #3 from Lari Strand <lmstrand@gmail.com> --- To clarify, in our implementation the self check machines use the same communication logic that the normal SIP2 protocol uses but with requests/responses wrapped in XML like this: <?xml version="1.0" encoding="UTF-8"?> <ns1:sip xmlns:ns1="http://axiell.com/Schema/sip.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://axiell.com/Schema/sip.xsd sip.xsd" login="TESTSIP2" password="xxxxxxxxxxxxxx"> <request>9900522.10AY2AZFC9F</request> </ns1:sip> They send the 93/94 authentication when the machines boot up inside an XML (or when sip server has been down). After that they send command messages that are passed in the XML like the example above. This way the logic changes required for the self check machines "core SIP logic" were kept to a minimum. So each message gets parsed, a 93/94 message is being created from the login/pw fields and hadled for each invidual message before passing on the actual command message from the XML to the SIP server. We have modified our handling of 93 messages so that the logs would not be overflooded with authSuccess entries in the action logs. We also generate responses for 99/98 messages (SC status message) in the REST API instead of passing these to the SIP server to lighten the load caused by these unnecessary "are you still online?" requests, since we're not relying on a always-on connection. Some SC manufacturers have modified their software so that they do not rely on these 99/98 messages anymore to function or they are sent less frequently (thus freeing up some of our server capacity, imagine 100's of SC machines bombarding us with these messages every minute or so). The token system seems interesting but can't they just rely on 93/94 and the checksum/sequence number field provided by the protocol itself? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.