A few month ago, as we were looking for a topic for our thesis, we start thinking about Internet telephony. The question was to which extent it will be possible to make an ordinary telephone call via an ISDN using a connected computer.
We disassembled two test programs that were applied (for sending and receiving of an audio file) in order to find a way to work with the ISDN card. So we found out that the programs communicate with the software by use of a 'named pipe', and we were able to initialize a call. Nevertheless, there was no information how signalling is done.
Of course, we raised a question to SUN. The answer was, the software has been explicitly developed for PPP. The test programs were applied for historical reasons only. We were advised not to use the 'named pipe', since the interface may change from one version to next.
The SUN people referred to another product, namely the SunXTL 1.2, which should enable the use of the ISDN card for our purposes. The product was acquired and installed.
The architecture offers a distributed telephony environment. But when we were looking for a MPI[ The MPI connects one type of a physical device (like an ISDN card) with the XTL teleservices. It transforms the internal functions of the XTL in actions running on the device (e.g. initiating a call) and, vice versa, incoming events (e.g. incoming call) to internal messages, Without the MPI it is not possible to use the underlying hardware.] for the ISDN card, it turns out that no one exists. Asking the SUN people again, they told use to get such MPI from another manufacturer. The software offered no way to use the ISDN card.
After this discouraging experience we asked at GMD for an usable implementation. There, the response regarding the XTL architecture was somewhat restrained and we were recommended to wait for another while. At that time an ISDN card was under development at GMD. Better reliability and support was promised.
We were still not satisfied with the results, since
Furthermore, the semester vacation just started in Helsinki and further development could be expected only in a few month.
But the SunShine project was the only reference we could find for the support of programming the ISDN card. Thus, we decided to collaborate. One part of the development was still done by Bengt Olof Shalin, the other one by us.
ISDN was standardized by the International Telecommunication Union (ITU). Recommendation I.120 [itu9303:I.120] gives an overview about the framework of ISDN recommendations (ref. picture 7.2).
For further understanding particular ISDN layers will be roughly presented in the following.
The physical layer (Physical Layer) in ISDN is specified by the ITU rec. I.430 [itu9303:I.430] for the basic access [ There are three kinds of access: the basic access, the *primary multiplex access*, and Broadband-ISDN. Basically they differ in the exchange rate and in physical properties. In the following, we will consider the basic access only.] The ISDN card provides an interface to this physical layer. Since this already works well, we will not tackle it any more in the following.] The second layer (Link Layer) provides data exchange based on the physical layer. The addressing of sender and receiver is located here as well as reliable date exchange by error recognition and recovery. Multiplexing of several access points is done as well. The layer is specified by Q.920 [itu9303:Q.920] (same as I.440 [itu9303:I.440]) and Q.921 [itu9303:Q.921] (corresponds to I.441 [itu9303:I.441]).
The third layer (Network Layer) provides communication among two or more parties. In the context of ISDN this may be, for example, a telephone call between two parties using ISDN. The layer is specified by Q.930 [itu9303:Q.930] (I.450 [itu9303:I.450]) and Q.931 [itu9303:Q.931] (I.451 [itu9303:I.451]).
The other layers are not relevant for our work and will not be considered in the folllowing.
In the SunShine project the layer 2 and 3 has been implemented. Thus, we were able to access the "ordinary" ISDN. As already mentioned, there were a lot of errors in the implementation. Furthermore, it was not designed for use in a real environment, but for test purposes. No programming interface was provided.
The project came up with the decision to develop one part completely from the scratch. Fortunately, the implementations of the two layers were completely separated. Layer 2, exactly Q.921 LAP-D protocol, was implemented as an autonomous streams extension for the SUN kernel. The Q.931 protocol implementation was linked to the application.
We decided to implement the Q.931 modul. Additionally, a programming interface should be provided. Beng Olof Shalins decision was to revise the Q.921 modul.
All incoming messages according to Q.931 have the same structure (see picture 7.4.2). After the message is identified according to the Protocol Discriminator field as a Q.931 message, the Call Reference Value (CRF) part of the message is decoded as well as the Message Type (MT). As the next part, a list with Information Elements (IE) may follow. If existent, the elements will decoded one after the other and stored in an internal data structure. As described in Q.931 unknown IEs are ignored without producing an error.
All the functions required for the handling of a particular message type are collected in one source file. At the time being, the following Q.931 Message Types are evaluated (compare Q.931 [itu9303:Q.931], paragraph 3.1):
The following types are missing with respect to Q.931:
Until now, this has been enough for the usage of the implementation. Message of the missing types were never received. Nevertheless, for a Q.931 conformance they should be handled.
For each message sent and received the Q.931 Finite State Machine of the related context is executed. Additionally, all the timers defined in Q.931 are handled according to the SDL [Int93b] diagrams. The timers are realized by the Schedule modul.
Some outgoing messages, and some incoming as well, require an indication made to the application. In these cases an IsdnLib Indication is generated in the particular functions, and the Callback Function of the application that was registered before is called.
Therefore, and for better overview these encoding and decoding functions are located in an own modul. For each IE two functions exist implemented as one particular source file. One function realizes the encoding, the other one decoding. For test purposes most IEs have a further function for formatted output of the content.
In the actual implementation the following IEs are supported (alphabetical order):
The IEs marked are not completely implemented yet.
The Scheduler is used, for example, by the Q.931 Finite State Machine module for the realization of the timers.
The ISDNLib bases mainly on the modules described before such as the Scheduler modul. When the IsdnLib was developed one consideration was to bind it into tcl/tk[ tcl/tk ist eine Scriptsprache, die von John K. Ousterhout entwickelt wurde.] later. Therefore, it must be possible to use the tcl scheduling functions. For this purpose the implementation expects some "shell" functions with the name of schedule modul functions and calling the tcl implementation functions. This is not yet tested!
At the beginning of the project, we were thinking about the most simple interface to support ISDN. The following varieties were considered:
The realization of asynchronous signalling appears to be quite difficult. In ISDN at every time messages may come in for connections already established or to be established. to relate the messages to the particular connections, we needed something like the Call Reference Value of the Q.931 messages. A new protocol would be required defining different message structures by its own.
The new protocol would become as complex as the Q.931 protocol itself. So, there was no advantage doing things this way.
There was one small disadvantage with this choice. Since the library is a part of the process a blocking of the program would affect the ISDN interface. Incoming Q:931 messages could not be handled Q.931 conform any more.
Nevertheless, we preferred this last variant. We called the new library IsdnLib.
The particular functions of the ISdnLib are explained in the addendum D in form of manual pages. The implementation of the IsdnLib is part of addendum E.