SSIP Communicator

Author: KANADA, Yasusi

The SSIP Communicator is a GUI-based chat program that is short, written in Java, and intended to be used for learning internet-based protocols and communication programs. Let's try using the program! If you are interested, look at the source program. In this document, I explain the protocol called the SSIP, and usage and the structure of the SSIP Communicator. I also mention to problems of the SSIP and suggest possible solutions.

Introduction

Socket-based simple communication programs are often used for programming seminars for beginners. However, such programs are not suited for playing and so they are not very much interesting. In addition, there is a large gap between such toy programs and communication programs for real use. However, it is not practical to use real-world communication programs in a seminar class. The SSIP Communicator is intended to fill the gap. The SSIP Communicator uses an original protocol called the SSIP (Simple Session Initiation Protocol). The SSIP is similar to but much simpler than the SIP (Session Initiation Protocol), which is a standard protocol, and the SSIP Communicator enables simple experiments of text chatting (conversations by characters) using simple GUI (Graphical User Interface).

Internet Protocols

The SSIP was built on internet protocols, the IP (Internet Protocol), and the UDP (User Datagram Protocol) or TCP (Transmission Control Protocol). So it is required to have at least minimum knowledge on the IP and UDP to understand the SSIP.

The IP is the base protocol for communications on the Internet or other IP networks (i.e., networks that use the IP), and it was standardized by an organization called the IETF (Internet Engineering Task Force). The IP is used in packet-switching networks, so a form of packet called the "IP packet" is used. An IP packet consists of a header and a payload (data part) similar to other types of packets. In IP networks, each computer has an address called an IP address, which is 32 bit long (in IPv4) or 128 bit long (in IPv6). An IP packet header contains the sender's and receiver's IP addresses.

The UDP is an upper-layer protocol of the IP; i.e., it utilizes the functions of the IP and adds several higher-level functions. The UDP was also standardized by the IETF. A UDP packet is usually contained in an IP packet. To distinguish communications between a computer and multiple other computers, a positive 16 bit number called a "port" is used in the UDP. Ports are specified for both sender and receiver.

A feature of IP networks is that, if a packet is lost in the communication path, it is not necessary to recover the packet. The UDP does not have a function to recover lost packets, so it is necessary to add a function to detect and to re-transmit the lost packet if the communication that uses the UDP is to be reliable. However, because it is wasteful for each application to implement such a recovery function, a protocol called the TCP (Transmission Control Protocol) that enables reliable communications by packet re-transmission and other functions was standardized in the IETF. The TCP is also an upper-layer protocol of the IP. You must first connect to the remote site when starting a communication using the TCP, and you must disconnect when terminating the communication. This method is similar to a communication by using telephone. Packets are guaranteed to reach the remote site while connected. However, the transmission delay is not bounded in stead, so it does not suited for real-time communications. Source and destination ports are specified in the TCP similar to the UDP.

The SIP (Session Initiation Protocol) was designed mainly for bidirectional communications such as IP telephone or conference systems, and was standardized by the IETF. The design of the SIP is similar to that of the HTTP (Hyper-Text Transfer Protocol), which is used for Web. Text chat can be sent by using the SIP, but communication contents are usually sent by using another protocol. Information usually sent by the SIP is declaration of communication beginning or ending, or the protocol and the media type (e.g., CODEC) for the content communication. The TCP or UDP is used for the lower-layer protocol of the SIP.

SSIP -- A Toy Protocol for Dialogs

The SIP was designed to satisfy various requirements for communication controls. So the specification of the SIP is quite large and complicated. The SIP specification document, RFC 3261, has 269 pages, and there are many other related documents. A beginner do not have to read all of them. However, it is not easy to write application programs that communicate by using the SIP nor to understand them.

Therefore, I developed an original protocol called the SSIP (Simple Session Initiation Protocol) that is similar to the SIP but much simpler. The SIP has request message types (i.e., methods) called INVITE, BYE and MESSAGE, and a response message type called OK (200 OK). The SSIP has only four types of messages: INVITE, BYE, MESSAGE, and OK. There is no distinction between request and response messages in the SSIP in contrast to the SIP or HTTP.

The basic communication sequence in the SSIP is shown in the right figure; i.e., when A wants to talk to B, A first sends INVITE message to B. After B sends back OK message to A, a dialogue establishes (i.e., A and B are "connected" similar to a telephone dialogue). While connected, both A and B can freely send text messages each other. (A MESSAGE message cannot be sent to the other site without a connection unlike a SIP MESSAGE message.) To finish the dialogue, either A or B can send a BYE message to the other site. This cuts the connection between A and B.

The state transition diagram of SSIP communications is shown in the right figure. The four basic states are the Disconnected, Calling, Ringing, and Connected states. The initial state is the Disconnected state. When the Call button is pushed, it generates an INVITE message and makes transition to the Calling state. If it receives an OK message in this state, it makes transition to the Connected state. Or, an INVITE message is received in the Disconnected state, it makes transition to the Ringing state. If the Answer button is pushed in this state, it generates an OK message and makes transition to the Connected state. If a MESSAGE message is received in the Connected state, the state is not changed. If the Send button is pushed in that state, a MESSAGE message is outputted but the state is not changed. If a BYE messge is received in the Connected, Calling, or Ringing state, it makes transition to the Disconnected state. If the Hung button is pushed in that state, it sends out a BYE message and makes transition to the Disconnected state.

Usage of SSIP Communicator

The program of the SSIP Communicator is in http://www.kanadas.com/ssip/ssip.zip. You can freely download this program. It is in a ZIP format. To use this program, J2SE (Java 2 Standard Edition) (version 1.3 or later (?)) is required. If you have not yet installed it, (if today is at the beginning of year 2004) download and install J2SE 1.4.2 before you use it. If you install the SSIP Communicator to two or more computers that are connected by IP networks such as LAN or the Internet, you can communicate between them. (However, a firewall or NAT (Network Address Translator) between the computers would disable the communication between them.)

To invoke the SSIP Communicator on Microsoft Windows, you can double-click a batch file called ssip.bat, which is included in the above archive, or you can move to the directory that contains the bacth file and type "ssip" and return. (Note that the execution path must contain the directory of java.exe.) You can also understand the invocation method on other platforms such as Linux or Solaris, by looking at this batch file.

A communication example using the SSIP Communicator is shown in the right figure. When the SSIP Communicator is invoked, a window in the figure is displayed. Here, A and B are assumed to invoke the SSIP Communicator on their own PCs. The IP addresses of A's PC and B's PC are assumed to be 133.144.4.246 and 133.144.4.99. In this example, A first specifies the IP address of B's PC, and pushes the Call button. If B's PC has a host name, A can specify the host name instead of the IP address. (As opposed to SIP that the users specify the user IDs, the remote terminal (i.e., computer) must be specified in SSIP.) Then an INVITE message is sent to B's PC, and the window shows a message "Ringing: ... (the remote site address)". If B pushes the Answer button, an OK message is sent to A's PC, and a message "Connected to ... (the remote site address)" is shown on both A's and B's PCs. Both A and B can, then, send texts freely by pushing the Send button using MESSAGE messages; here, A sends "Hello!" to B. Both A and B can disconnect by pushing the Hung button using a BYE message; here A disconnects.

Structure of SSIP Communicator

The SSIP Communicator was written in Java, and the program size is about 600 lines. To enable looking at whole program, I tried to minimize the program size. Protocols are usually structured as layers such as IP-UDP-SIP, so the programs that implement the protocols also have layered structures. This means the programs are "stacked". In the communication world, a collection of protocol program is, thus, called a "protocol stack". The structure of the SSIP protocol stack is shown in the right figure; i.e., there is the TCP or UDP layer over the IP layer, and they are built-in to Java. There is a thin layer (a program that has small add-on function) between the TCP / UDP and the SSIP layer. This protocol does not have a name, but it is represented by a Java interface (an abstraction of classes) called SocketIOStream. The SSIP protocol is implemented by the SsipProvider class. A class that uses SSipProvider must implement an interface called SsipListener (i.e., the class must have the four methods that are declared in SsipListener). In the SSIP Communicator, the Main class defines the GUI, and it implements the communication specified in the class by using SsipProvider.

Parameters, such as the local and the remote ports, the sizes of the window and dialog items, can be specified in the Main class. If you use different values for LocalPort and RemotePort, you can run two instances of the SSIP Communicator on one computer and communicate each other. (However, to do this, you have to create two copies of the SSIP Communicator which have different values of LocalPort and RemotePort.)

In detail, the SSIP Communicator consists of the following classes.

• The SsipProvider class: the SSIP stack
  • The methods of SsipProvider, i.e., invite(), ok(), message(), and bye(), process SSIP message sending.
  • The methods of SsipProvider, i.e., processInvite(), processOk(), processMessage(), and processBye(), process SSIP message receiving.
• The Main class: a window-based test program
  • The methods of Main, i.e., invite(), ok(), message(), and bye(), process SSIP message sending. These methods are invoked by the user.
  • The methods of Main, i.e., processInvite(), processOk(), processMessage(), and processBye(), process SSIP message receiving. These methods are called back from SsipProvider.
  • The Main class is a subclass of JApplet. It works on a Web browser.
• The SocketIOStream interface
  • The SocketIOStream interface defines the methods that the lower layer of SSIP must implement. The major methods of SocketIOStream are read() and write().
  • The UDPSocketIOStream class is an implementation of SocketIOStream which uses UDP.
  • The TCPSocketIOStream class is an implementation of SocketIOStream which uses TCP.
  • Either UDPSocketIOStream or TCPSocketIOStream is used. Which to use is specified in Main. The both has the same basic functions.
• The SsipListener interface
  • It defines the methods to be implemented in a class that uses SsipProvider (Main in this example). It defines the four methods: processInvite(), processOk(), processMessage(), and processBye().

Problems and Possible Solutions

The SSIP is a very simple protocol and thus it is not very suited for use in the real world. So the SSIP Communicator has many problems and inconvenience for real-time communications. I think it is a good exercise for an introduction to communication programs to find them and solve part of them by modifying the SSIP Communicator. (However, it is not recommended to solve all the problems and inconvenience because it is a very hard exercise.) Several hints for the problems are listed.

• A failure response is returned when an INVITE request failes in the SIP, but no such response is returned in the SSIP (because no failure response is defined).
• No sender nor receiver addresses (user IDs) are included in SSIP messages as opposed to SIP messages.
• A message must fit in a packet in the SSIP.

It is a good exercise to think of what problems occur from the above facts, and what other problems occur, and how these problems can be solved.

Warnings