Hi, there's an underlying assumption in Koha's Sip implementation that messages from sip units will be terminated by carriage return line feed. This works with many sip clients (including 3M). However the sip2 standard mandates that sip messages are terminated by carriage return (hex 0d). That means any client that implements the standard as specified (and I know of at least 2 such vendors) can't connect to Koha's implementation (which sits waiting for the CR). It also means that those units that send hex 0a in the body of text can cause grief. I'm wondering if anyone has any thoughts on improving the server side. Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
Colin -- Koha SIP can handle dossy ^M line endings just fine. The detection of line endings is essentially delegated to the IO::Socket::INET and Socket modules with local $/ = "\012". I don't see any reason for a client to send hex 0a or any other control character in any message field. In the spec, the transport layer is unspecified. We have telnet and RAW. The multiplicity of telnet implementations in the wild was a serious impediment to development. In fact, Koha does not even try to provide a "real" telnet server inasmuch as you cannot send telnet control sequences and expect any beneficial result. In particular, you cannot send them mid-session. The handshake is minimal. So in the end, we went with an implementation that (1) was testable with the best available SIP tools, namely the 3M emulator, and (2) supported additional telnet implementations, like putty or those on linux. Please feel free to identify the vendors with incompatible implementations. It may be possible to make the line-ending an attribute of the SIPconfig account, such that you could have a different one for a given SIP terminal. Or more likely, you can get the clients to send a different line ending. Other than that, I don't see any available perl interface that provides a better telnet layer to swap in. -- Joe Atzberger LibLime - Open Source Library Solutions On Mon, Jul 6, 2009 at 9:02 AM, Colin Campbell < colin.campbell@ptfs-europe.com> wrote:
Hi, there's an underlying assumption in Koha's Sip implementation that messages from sip units will be terminated by carriage return line feed. This works with many sip clients (including 3M). However the sip2 standard mandates that sip messages are terminated by carriage return (hex 0d). That means any client that implements the standard as specified (and I know of at least 2 such vendors) can't connect to Koha's implementation (which sits waiting for the CR). It also means that those units that send hex 0a in the body of text can cause grief. I'm wondering if anyone has any thoughts on improving the server side.
Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2
On 07/06/2009 03:00 PM, Joe Atzberger wrote:
Colin --
Koha SIP can handle dossy ^M line endings just fine. The detection of line endings is essentially delegated to the IO::Socket::INET and Socket modules with local $/ = "\012". The problem is that the protocol states that all messages end in a carrage return (hex 0d). There is no requirement to set linefeed as a terminator as it is not a message separator.
I don't see any reason for a client to send hex 0a or any other control character in any message field.
It's allowed so they will. I've seen it on a number of occasions.
I'm really talking about raw sockets implementations here. Although in my experience a "strictly conforming" implementation can handle communication over a telnet connection because basic telnet handles the extra overhead (the clients typically script the connection set up).
It may be possible to make the line-ending an attribute of the SIPconfig account, such that you could have a different one for a given SIP terminal. Or more likely, you can get the clients to send a different line ending.
This would be the way to go for flexibility. At the moment the assumption is interwoven with the protocol handling. I don't think expecting the clients to send different line endings is likely as these are usually closed (often windows) binaries. Its a lot easier to handle the vagaries of the clients in the perl code. Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
On Mon, Jul 6, 2009 at 11:01 AM, Colin Campbell < colin.campbell@ptfs-europe.com> wrote:
On 07/06/2009 03:00 PM, Joe Atzberger wrote:
Colin --
Koha SIP can handle dossy ^M line endings just fine. The detection of line endings is essentially delegated to the IO::Socket::INET and Socket modules with local $/ = "\012".
The problem is that the protocol states that all messages end in a carrage return (hex 0d). There is no requirement to set linefeed as a terminator as it is not a message separator.
The stuff I mentioned are the particulars of the implementation. You are welcome to experiment with other components, but I think you would find unilaterally setting to \010 wil break far more than it will help. I agree with you on what the spec says, but at the time of implementation, ZERO clients available to Koha developers actually behaved that way, including the reference implementation from 3M. At this time, the number of such clients available to us is still zero. We would need more information about the clients in question: - What are they? - How widespread is their use? - Are they the *current* version of their implementation or orphaned legacy code? - Does the developer still support the implementation? - Are they open source? (you've suggested they are not)
I don't see any reason for a client to send hex 0a or any other control character in any message field.
It's allowed so they will. I've seen it on a number of occasions. It would also be "allowed" to renegotiate the telnet handshake midstream. Nobody does this. I'll restate my contention. The SC has a defined number of commands and those have a defined number of required and optional fields. None of the data to be communicated in those fields should legitimately contain hex 0a or other control characters. For example, if your branchcode contains a linefeed, Koha will break in many other places, including before you are able to get a full transaction response from SIP. When do you imagine it would be appropriate for a SIP client to send, for example, a BELL character or BACKSPACE character? It may be possible to make the line-ending an
attribute of the SIPconfig account, such that you could have a different one for a given SIP terminal. Or more likely, you can get the clients to send a different line ending.
This would be the way to go for flexibility. At the moment the assumption is interwoven with the protocol handling. I don't think expecting the clients to send different line endings is likely as these are usually closed (often windows) binaries.
You could still run a middle layer on localhost. But if it can be handled cleanly via SIPconfig, I would support that.
Its a lot easier to handle the vagaries of the clients in the perl code.
Maybe. I'm sure it isn't easier to develop a whole new SIP emulator to support testing on the new config though. --Joe
I agree with you on what the spec says, but at the time of implementation, ZERO clients available to Koha developers actually behaved that way, including the reference implementation from 3M. At this time, the number of such clients available to us is still zero. We would need more information about the clients in question: I'm talking from the experience of supporting a number of clients (including 3M) on sockets connections. As to telnet, I've only used that to debug connections, in practical terms it seems approprate only for
On 07/06/2009 05:00 PM, Joe Atzberger wrote: the older clients.
When do you imagine it would be appropriate for a SIP client to send, for example, a BELL character or BACKSPACE character? I don't but the robustness principle appliers, 'be liberal in what you accept, be conservative in what you transmit'
You could still run a middle layer on localhost. But if it can be handled cleanly via SIPconfig, I would support that.
Cheers Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
participants (2)
-
Colin Campbell -
Joe Atzberger