There are four protocols covered by the ISCL standards. These are:
The Line Connection Protocol is used to establish the maximum packet size for transferring information between a client and a server, and for determining the version of the ISCL standard to use. Generally, a client will request a connection with a server. The server can then accept or reject the connection request. The server will also then request a line connection check to determine whether the client and the server can communicate. Along with this request, the server sends information on the maximum packet size it can handle and the version of the standard it uses.
The client receives this information and generates a line connection response. Please note that the maximum packet size will be the smaller value of the client's maximum packet size and the server's maximum packet size. The client then sends a line connection response back to the server.
Once the line connection has been successfully established, the server is then ready to request mutual authentication.
The mutual authentication protocol lets both the client and the server verify that the computer to which each is connected is cleared to receive information. The server begins by issuing a GETCHALLENGE command. This generates a random number, which in turn is used to create a challenge code.
The challenge code is then sent to the client. The client issues an INTERNAL AUTHENTICATE command, which takes the challenge code and generates a response code. This response code is then returned to the server. The client has also generated its own GETCHALLENGE command and has generated a challenge code. This is sent to the server with the response code. This allows the client to verify that it should be communicating with the server.
The server receives the response code from the client and generates an EXTERNAL AUTHENTICATE command. The original challenge code and the response code returned from the client are compared. If the response code is found to be a legitimate response code for the challenge code, the server has authenticated the client. The server also takes the challenge code received from the client and generates an INTERNAL AUTHENTICATE command. This also generates a response code from the received challenge code. This response code is then sent back to the client.
The client receives the response code from the server and generates an EXTERNAL AUTHENTICATE command. The original challenge code is compared to this response code. If the response code is found to be a legitimate response code for the challenge code, the client has authenticated the server.
At this point, the client sends the server a message that the mutual authentication has been completed.
Messages may be sent secured or unsecured. Regardless of the encryption mode or the message authentication mode, messages can still be sent unsecured.
Sending and receiving a secured message is achieved by encrypting the data and adding a message authentication code, also encrypted, to the message. Upon receipt, the message is decrypted and the authentication code verified.
When the connection is no longer needed, one computer/entity of a connection sends a line disconnection request to the other (peer) computer. The computer receiving the request then sends a line disconnection response.
For more information about these protocols, refer to the "MEDIS-DC STANDARDS for Integrated Secure Communication Layer Protocols, V 1.00."
Help Collections
Raster .NET | C API | C++ Class Library | HTML5 JavaScript
Document .NET | C API | C++ Class Library | HTML5 JavaScript
Medical .NET | C API | C++ Class Library | HTML5 JavaScript
Medical Web Viewer .NET
Multimedia
Direct Show .NET | C API | Filters
Media Foundation .NET | C API | Transforms
Supported Platforms
.NET, Java, Android, and iOS/macOS Assemblies
Imaging, Medical, and Document
C API/C++ Class Libraries
Imaging, Medical, and Document
HTML5 JavaScript Libraries
Imaging, Medical, and Document