Internet telephony signaling

Telematics and Informatics 18 (2001) 159±194

www.elsevier.com/locate/tele

Internet telephony signaling Ibrahim Mortada, Wilfried Probst * Universite du Quebec a Montreal, P.O. Box 8888, Station Centre-Ville, Montreal, QC, Canada H3C 3P8

Abstract The term ``multimedia session'' refers to the integration of data coming from various sources, such as sound, video and text, within a computer application. Telephony over the Internet is among the more exciting current developments. The signaling of a telephone call consists of the set of messages and procedures used to establish a connection, to request changes in communication bandwidth, to obtain the message status for the end points participating in the conversation, and to close the link. At present there exist two competing signaling protocols for Internet telephony, viz., the H.323 protocol sponsored by the ITU and the Session Invitation Protocol (SIP) sponsored by the IETF. Each of them supplies its own signaling mechanisms. In this paper, these two protocols in terms of their main functionalities are compared. Based on the results of this comparison, a Client/Server architecture for the development of an application that supports a basic SIP implementation, as well as the formulation of requests allowing the establishment and the disconnection of communications between a number of users in a multimedia session are then de®ned. Ó 2001 Elsevier Science Ltd. All rights reserved. Keywords: Multimedia session; Internet telephony; Telephone signaling protocol; Session initiation protocol; Object-oriented development

1. Introduction Over the last years, the Internet has evolved from a research network towards a globally available network for information retrieval and transmission of data. Every user who has access to a computer equipped with a sound card, microphone, and media software has the capability of connecting to this network. At the same time,

*

Corresponding author. Tel.: +1-514-987-3000; fax: +1-514-987-8477.

0736-5853/01/$ - see front matter Ó 2001 Elsevier Science Ltd. All rights reserved. PII: S 0 7 3 6 - 5 8 5 3 ( 0 0 ) 0 0 0 2 7 - 7

160

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

many di€erent Internet services have been developed, such as voice and video transmission, which have become increasingly popular. The characteristic of combining the multimedia capacity of a workstation and its Internet connectivity is called multimedia conferencing. In such a conference, the multimedia data are transmitted in several ¯ows of media, called sessions, between participating users. These sessions may be either telephone conversations or one of several other types of media. The transmission of multimedia information over the Internet requires special protocols, such as the Real Time Transport Protocol (RTP) (Schulzrinne et al., 1996), which is used to facilitate the synchronization and recuperation of variations of delay and loss of packets, and so allows systems of di€erent manufacture to function together. This protocol works in conjunction with the Real Time Control Protocol (RTCP) for the analysis and management of real ¯ow time. The Reservation of Resources Protocol (RSVP) (Braden et al., 1997) permits the de®nition of bandwidth characteristics and delays which must be negotiated when establishing a multimedia session to guarantee the quality of services. Furthermore, other protocols are necessary to establish and to end a session, to locate users on the Internet, to negotiate capacities, and to invoke services such as the transfer and setup for Internet telephony. Two protocols currently exist for control and signaling on the Internet: H.323 (ITU-T Recommendation H.323, 1998), which is a recommendation developed by the International Telecommunications Union (ITU), 1 and Session Initiation Protocol (SIP) (Handley et al., 1999; Schulzrinne and Rosenberg, 1999), which is being developed by the Internet Engineering Task Force (IETF). 2 1.1. Statement of the problem One of the problems in joining multimedia sessions is how potential members of a session can obtain information on the parameters of the session, such as the multicast address of the group, the Time To Live (TTL), the address of the destination host, port, codes, etc. Two basic approaches are currently being used. · The session and its parameters are announced, and users who see the announcement, can join in the session. · The users are explicitly invited to join in multimedia sessions by other users. The ®rst approach does not guarantee access to the announcement by a user who would like to participate in a session. The invitation to users to join a session can be extended by means of a telephone call or an e-mail message. Indeed, both types of invitation have their drawbacks:

1 2

International Telecommunications Union, ITU, http//:www.itu.int. International Engineering Task Force, IETF, http//:www.ietf.org

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

161

receipt of the invitation within a short delay is not guaranteed when sent by e-mail. On the other hand, the use of classic telephony by several participants could prove expensive and complex. 1.2. Objectives and organization of this paper Signaling on the Internet and the invitation of parties to a multimedia session have attracted the attention of several companies involved in developing multimedia applications. As a result, ecient and easy to use methods and tools are absolutely essential for the development of such systems. The principal objective of this paper is to de®ne and implement an application which serves to de®ne, formalize and manipulate the basic requests of SIP, e.g., INVITE, REGISTER, BYE and ACK, based on the last published draft of this protocol. This seemed to us more simple to implement when compared to other existing applications based on the H.323 protocol, such as netmeeting and net2phone which also permit the invitation of several users to an Internet session. The objective of our implementation is to address the following requirements. · The speci®cations of the parameters of the session in the application must be simple enough to allow non-expert users to use the application in the multimedia sessions. Furthermore, an expert user should also be able to indicate the session parameters in a ¯exible manner. · The user should be able to invite other users to new sessions. · The host user should be capable of indicating the invitation address in a very simple manner. · After successfully sending an invitation, the multimedia sessions should be created automatically. · The guest user should be able to manipulate the invitations automatically. · The users within a session can communicate together in ``chat'' mode. · The user should be able to end the invitation (chat session). To accomplish these requirements, we have used as a basis the SIP, which we consider to be the best choice. Seeing that we are in the developmental stage, a supplementary task of our work is to ®nd the problems according to the draft during implementation. Regarding the organization of this paper, the next section gives a brief introduction to telephony on the Internet and its social impacts. Section 3 then compares several aspects of the SIP and H.323 protocols. It aims to justify our choice of an SIP-based implementation and includes as well a discussion in¯uenced by the literature. A basic knowledge of these protocols is assumed. In Sections 4 and 5, the practical and operational part of our work is presented. We will de®ne an architecture permitting the research of a user on the Internet with respect to communication with other users. Our system supports the formulation of the requests, which enable the signaling of calls between users.

162

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

2. Internet telephony The expression ``Internet Telephony'' is currently used to designate practically any application employing the IP protocol and techniques for transmitting voice over infrastructures of diverse status and technologies: private networks, IP backbone networks, etc. (Schulzrinne and Rosenberg, 1998b). This concept allows conventional telephony to be substituted by the use of a computer and the Internet. The computer multimedia replaces the telephone, and the Internet is the link between the users. The telephony Internet uses data compression between two users. By utilizing codecs, algorithms are used to assemble/compress the data into packets which are then transmitted in a continuous ¯ow. Upon receipt of the packets, the codecs immediately begin to read the data without waiting to receive the whole index (quasi real time). The architecture and setting-up techniques provide diverse services for solving various problems extending to most of the topical questions in the domain of networks and telecommunications services. Furthermore, with the constantly increasing speed of microprocessors, and the development of signal processing techniques, it has now become realistic to transmit voice just as other data are transmitted on the Internet network. We will present the signaling and types of Internet telephony, its quality of services and its challenges, for the purpose of clarifying a somewhat unclear situation, as well as for outlining some social perspectives and implications of the subject. 2.1. Telecommunications and the Internet Telecommunications and the Internet are two logics which have two di€erent ways of functioning. For the analysis of telephone network, the philosophy on which telephone communication is based must be considered. This network is conceived in such a way as to assume a quality of service standard, i.e., the reliability of the communication is of primary concern. The premise on which communications on Internet are built is not the same as that of the telephone. In contrast with the telephone where the quality of service and the reliability of the exchanges are primary, the Internet favors access to the network, this access not being subject to the exclusive use of lines. Since the whole world is involved, the available resources must be shared, and consequently the network becomes slower and less reliable with an increased load. These di€erent concepts of communication are the result of structures and of divergent technical procedures. 2.2. Types of Internet telephony To begin, we can distinguish three types of Internet telephony according to the terminal used by each of the two correspondents.

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

163

Fig. 1. Internet telephony (using PCs).

Fig. 2. Internet telephony (using a telephone).

· The telephone communication between two computers connected on the Internet, as shown in Fig. 1. · The telephone communication between a computer and a telephone or between two computers by means of gateways which act as interface between the telephone network and the Internet. · The telephone communication between two telephones with the aid of gateways across the Internet and one using control servers, as indicated in Fig. 2. 2.3. Internet signaling Within the framework of voice transport, signaling plays a very important role. Indeed, it is at this phase that the one will negotiate the di€erent parameters of quality of service and other parameters of signaling. For example, one indicates the minimum ¯ow to be assured, the delay in handling, the location of the users, etc. 2.3.1. Signaling functionality The signaling of the Internet telephony consists of a certain number of functions. Translation of user name and location. Performs the mapping between the names of di€erent levels of abstraction e.g., a name common to the domain and a user name at a particular Internet host. These translations require simple consultations of tables at the server level or the location of the entity sought. Negotiation of capacities. Allows a group of end systems to convene on the exchange of media and their respective parameters, e.g., the encodings, bandwidth, etc. The combination and type of media in a call do not need to be uniform. This is the case where the di€erent sessions point by point involve di€erent media and their

164

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

parameters. Much coding software is capable of receiving di€erent forms of encoding in a simple conference simultaneously, e.g., during the restriction of the sending of one media type for each ¯ow. Any participant of the call may invite others into the current call and end associations with anyone among them. Change of the capacities. Permits adjustment of the composition of media sessions during a call. This may be either because the participants require supplementary or reduced functionality, or due to constraints imposed or withdrawn by the addition or suppression of participants in the call. The set of these functions does not have to be addressed by a single protocol; for e.g., H.323 may be used for establishment of the sessions between end systems and gateways, while SIP may be responsible for gateway-to-gateway signaling. 2.4. The architecture of Internet telephony Contrary to the circuit switching telephony, the telephone services of the Internet are built on a hierarchy of packet switching protocols, as illustrated in Fig. 3. The functions of the signaling protocol of traditional SS7 telephony (Russel, 1995) include routing, reservation of resources, call acceptance, address translation, establishment of the call, as well as its management and billing. In an Internet environment, the routing is controlled by protocols such as BGP (Rekhter and Li, 1995), the reservation of resources by RSVP or other such protocols. At the same time signaling protocols such as SIP and H.323 have been developed for the

Fig. 3. Protocol architecture of Internet telephony.

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

165

translation of addresses of the application layer, and for establishing and controlling the calls. On the other hand, at present no billing protocol exists for Internet telephony, although RADIUS (Rigney, 1997), in combination with the authentication service of SIP, could handle this objective. 2.5. Quality of service The circuit switching telephone network has been conceived to guarantee a high quality of service. On the other hand, up to now the Internet telephony does not provide for the o€ering of a constant quality of service, nor does it prioritize certain types of trac. For this reason, network architecture designers, manufacturers and service providers are currently concentrating their e€orts on the de®nition and implementation of these concepts. In this paper, the expression Quality of Service (QoS) signi®es the set of quantitative and qualitative parameters, which describe the service characteristics desired by the applications, and the characteristics of the services provided instantaneously by the distributed system (Vogel et al., 1995; Kerherve, 1994). The notion of QoS as applied to communications provides for the establishment of two lists submitted to the network during a request for connection. The ®rst contains the desired quality parameters to be reached and maintained. The second speci®es the minimal acceptable values for this quality of service. None of the criteria generally de®ned for a telephone conversation on the Internet can screen the quality of service. · The delay of transport is precarious by nature; · the volume is not guaranteed; · the delivery of the packets is not guaranteed. However, the loss of voice packets in data networks is preferable to their re-transmission. Indeed, even if some packets are lost in transit, the loss will be imperceptible to the human ear, thus, preserving an an acceptable listening quality. 2.6. Challenges of Internet telephony The Internet is not currently adapted to a reliable transport of voice data. This is due to the way the network operates, the slowness of message transmission (and eventual re-transmission), and of the sending and receiving of packets. The network is sometimes too slow in routing the packets and respects neither the order nor the time interval between them. Normally, within the network, packets are treated equally, i.e., they take their place in the queues of the routers, without regard to the information they carry or which services they provide. It is known that the routers are sometimes slow to deliver the accumulated messages. It then follows that telephony, which requires very short routing delays, is not well suited to this method of operation and that the routers are not adapted to the constraints of real time transmission. This network

166

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

problem may be resolved by a mechanism of reservation of resources. Instead of handling the packets received sequentially, the switches could give priority to some of them. This approach, contrary to the usual FIFO principle, is supported by RSVP. This protocol permits a transfer of packets that is not handled in the normal way by the routers whenever a service (telephony, for example) needs it. When an RSVP reservation and a level of quality are requested, the necessary resources are reserved for priority processing of messages. This privileged use of resources will likely result in billing. Next, the transport protocols used are not well suited either. TCP (Stevens and Wright, 1995) hinders the speed and the ¯uidity of the reading of the packets on reception, due to its control mechanisms. It slows down the reading of a message in order to receive the complete set of all its packets. If one of them gets lost, the source will be asked to re-transmit it. Considerable delays arise before the control packets arrive at the sender and before the missing packets are re-transmitted and received at the destination. While favoring the reliability of a transmission, this represents a major inconvenience for telephony. It has been observed that with a loss of over 5% of the packets, the TCP procedures of re-emission slow the message trac so much that conversation in real time is seriously a€ected. The alternative is UDP, which sends packets one by one without ¯ow control. This protocol does neither provide for detection of packet losses nor does it guarantee their arrival in the proper sequence; it is however faster than TCP. These inconveniences can be palliated by the adoption of RTP (with UDP), which favors transmission in real time. This protocol permits time stamping of the packets: indicating their hour of creation, and facilitating their synchronization by the receiver. The new version of the network protocol IP (IPv6) possesses ®elds of supplementary data, an identi®er of ¯ow for detecting and assuring the continuity of an even ¯ow of real time data and an index of priority indicating the degree of urgency in processing. The IPv6 envelope of the packets allows for real time privileges by designating a priority ®eld, which will result in fast preferential processing. 2.7. Social impact Social change always follows technological change, indeed each new invention brings about advances in our lifestyle. Not long ago letter writing was the only means of keeping in touch with relatives and friends who did not live nearby. With Alexander Graham Bell's invention of the telephone, conversations could be held at a distance, without the requirement of displacing oneself. Marconi's wireless brought the news of the world into the living rooms of the nations. The circle of communications kept expanding throughout the 20th century: radio, television, satellites and other developments followed. The telephone companies used to have a monopoly on voice communications. All that has rapidly changed. Media and communications are expanding in directions never dreamed of scant years ago. Co-axial cables are competing with telephone

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

167

wires. Satellites have made cellular phones a world-wide extension of our physical bodies and they proliferate everywhere. Desktop and portable computers, equipped with the required interfaces and connected to the Internet, are becoming almost as ubiquitous. Miniaturization and portability of electronic devices, as well as e€ective means of communicating are omnipresent in the digitalized world around us. New Web-based communications giants such as AOL and MCI have emerged. The traditional providers of services, i.e., the telephone companies, will have to adapt to these changes by either entering the new markets themselves, or by o€ering new services at competing costs. Our social customs are being in¯uenced drastically by these technological developments. Newspapers, television and ®lms can now be viewed on the Internet. It has already a€ected our shopping habits, with E-commerce paralleling regular commerce, E-banking doing the same to traditional banking, the introduction of Etickets, to name just a few. With government spending on digitalization and widespread Internet extension to the developing countries, these trends will only accelerate. Since it is a low cost means of communication for the end user, its popularity will certainly increase in the future. In Canada, for example, talking on the telephone is a national pastime. More time is spent per capita in telephone conversations than in any other industrialized country, as there is no surcharge for local calls. With the information revolution and the Internet in particular, we have reverted in part to communicating by mail, using, however, a new electronic form of postal service, the e-mail. With the advent of chat lines, we have yet another way to communicate globally via the Internet. Interactive on-line textual communications are now being enhanced by voice and image transmission. It is evident that Internet telephony is a harbinger of future communications, promising increasing sophistication and portability. Nevertheless, some unanswered questions remain: will Internet telephony continue to be as free as it is now? Will the Internet infrastructure be able to handle the trac caused by vastly increased multimedia transfers? Only the future can answer them. 3. SIP versus H.323 The Internet telephony requires a set of control protocols for the establishment of connections, exchange of capacities and conference control. Presently, ITU's H.323 and IETF's SIP are the two protocols which have been designed to meet these needs. The IETF standard is interoperable with the ITU standard at the level of voice transmission, since the latter incorporates the RTP protocol of IETF in its H.323 standard (Schulzrinne and Rosenberg, 1998a). The ITU supporters have the objective of gaining the support of several manufacturers, while those of SIP doubt the interoperability of the H.323 products and demonstrate the technical advantages of telephony with SIP. The link between the SIP and the H.323 was a point of discussion during the development of SIP. There is

168

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

a certain overlap, but the two protocols derive from di€erent problem domains, and do not tackle exactly the same set of problems. It may be said that many manufacturers are starting to integrate the SIP protocol into their products. In this section, we will compare the two protocols according to the following criteria (see Schulzrinne and Rosenberg (1998c) for further details): simplicity, functionality, scalability, services, connection states, security and server states. 3.1. Simplicity SIP is a very simple protocol, for several reasons, compared to the H.323 protocol. · The total sum of basic speci®cations of H.323 (without ASN.1 and PER) is 736 pages, while that of SIP (with its extensions of call control and protocols of session descriptions) contains only 153 pages. · H.323 de®nes hundreds of elements while that of SIP has only 37 di€erent headers, each with a limited number of values and parameters. · H.323 uses a binary representation for its messages, based on ASN.1 and Packed Encoding Rules (PER) which complicates the development and improvement of the analysis of messages. H.323 incorporates the H.225, RTP and RTCP protocols, each of which must be coded in a coherent manner. H.225 is also based on ASN.1 for carrying out the coding and the decoding. For their part, RTP and RTCP are based on Type Length Value (TLV). There may be problems of interoperability directly related to the use of these last forms of coding and of decoding, e.g., the version of the ASN.1 compiler used. In return, SIP codes its messages in textual format (like HTTP). This format tends to facilitate the development and analysis emerging from high-level programming languages such as TCL, Perl, Java. The overhead of these types of protocols is important, but their usage of small messages for control does not pose this problem. Furthermore, SIP reuses the existing syntaxes and analyses of HTTP which can be rapidly modi®ed for the use of SIP. 3.2. Functionality In addition to the basic service of calls in traditional telephony, SIP and H.323 both support certain services of call control, advanced devices and capacity exchange. 3.2.1. Call establishment and disconnection Call establishment in version 2 of H.323 is based on a reliable transport protocol. As such, it requires a bi-phased connection: TCP connection and call connection. The next version of H.323 (version 3) supports TCP as well as UDP, which simpli®es the procedure of call establishment. In SIP this process is similar to that of version 3

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

169

of H.323. The calling or the called user can end a call with the message RELEASE COMPLETE (in H.323) or with the message BYE (in SIP). 3.2.2. Exchange of capacity The procedures of capacity exchange are intended to assure that the multimedia signals which are transmitted can be received and processed correctly by the receiving terminal. H.323 uses the H.245 protocol for the exchanges of capacities. The information allowing a terminal to receive and decode the data is known at the other terminal by the transmission of its capacity. All terminal capacities are described by a set of structures, the CapabilityDescriptor, each of which is a simple structure formed of SimultaneousCapabilities and a CapabilityDescriptorNumber. With this, very detailed information on the capacities of each terminal can be expressed by a relatively compact structure. SIP uses SDP for capacity exchanges. The calling correspondent may use an OPTION request to discover the capacity of the called party. At present, SIP does not possess all the negotiation ¯exibility of H.245 (ITU-T Recommendation H.245, 1998), due to the limited expression facilities of SDP (Jacobson and Handley, 1998). For e.g., SIP does not support asymmetrical capacities (for receiving or transmitting only) and the simultaneous capacities of audio and video encoding. 3.2.3. Interoperability A protocol of signaling of Internet telephony must be capable of cooperating with di€erent versions, and other signaling protocols on global networks. 3.2.3.1. Interoperability between versions. This is an important characteristic, which permits interactions between newer and older versions of a protocol. In fact, H.323 is totally backward compatible. This interoperability is indispensable for clients; if they possess a product based on H.323 version 2 they are not forced to upgrade when the server is changed to a newer, improved version of the protocol. The new server must then support all the functions of the former version. On the other hand, if a characteristic in SIP is not essential, it is removed in the next protocol version. This approach eliminates a large number of instructions and reduces the complexity of protocol, but it destroys the compatibility between di€erent versions. 3.2.3.2. Interoperability with other signaling protocols. To interface with the traditional telephony services, the signaling protocols of Internet telephony need to support the SS7 signaling system. Signaling messages like Q.931 are used in the procedures of H.323, which facilitate the interoperability with ISDN/Q.931. However, the messages of call establishment in H.323 are only a subset of those in SS7/ISUP. Since there is no established norm for the transmission of messages of such type on an H.323 network, this latter can only translate a portion of SS7 messages in the conversion. In SIP, no translation function for SS7 signaling

170

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

messages is supplied. Although there is an Internet draft on this subject (Donovan and Cannon, 1998), the transport of signaling information has not yet been established. 3.2.4. Services H.323 and SIP o€er approximately equivalent services. A comparison in this domain is dicult, as new services are constantly added to SIP and H.323. We think that the comparison (Table 1) will rapidly change due to the current evolution of this domain. Personal mobility is a very important reason for IP telephony service usage. In SIP, a caller may utilize an URL to locate and reorient the called party at di€erent sites, following the movements of the person. SIP also supports the search of users on several machines. This means that servers can obtain the search information from several supplementary servers. A SIP server may also procure the request at several machines in parallel (forking proxy), so as to accelerate the search. This service is supported by H.323, but with many limitations. One can redirect a caller to try several addresses. However, it cannot be used to allow the caller to express preferences during the initial call invitation. Furthermore, H.323 has not been conceived for operating in wide area networks. It supports the expediting of call requests between servers, but does not allow a gatekeeper to procure a request from several servers. 3.2.5. Control H.323 assures the control of the bandwidth employed in a conference by the use of gatekeepers. SIP does not handle this control problem at present, but there is a lot of research in this domain, aiming at the adoption of the RSVP protocol for this purpose. In a multi-conference with many users, all the trac must pass through a central point in H.323 (see Section 3.4). This generates a bandwidth surcharge, thus producing a performance problem. Table 1 Comparison between the characteristics of call controls in SIP and H.323 Characteristic

SIP

H.323

BLIND TRANSFER Operator-Assisted Transfer Hold Multicast Conferences MULTI-UNICAST CONFERENCES Bridged Conferences Forward Call Park Directed call Pickup

Yes Yes Through SDP Yes Yes Yes Yes Yes Yes

Yes No Not available Yes Yes Yes Yes Yes Yes

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

171

3.2.6. Servers states In an H.323 system, the telephony gateways have to manipulate the calls of a multitude of users. Likewise, the SIP servers and their gateways have to handle many calls. In fact, the suppliers of telephony on the IP network and the number of calls processed by a large server can be signi®cant. Therefore, the simpler the signaling, the greater the speed of processing. In SIP, a transaction involving several servers and gateways can be stateful or stateless. In the stateless model, a server receives a call request, executes a certain operation, expedites the request and then forgets it. SIP messages contain sucient information to allow the reponse to be expedited correctly. Furthermore, SIP can be transmitted on TCP or UDP. In the case of UDP, no connection state is needed. This signi®es that the servers can be based on UDP and function in a stateless manner, reducing the memory requirements and improving the scalability. H.323, on the other hand, requires the gatekeepers to be stateful. They must maintain the state of the call. Furthermore, the connections are TCP based, which means that a gatekeeper must keep its TCP connection open for the entire duration of a call. This may pose serious problems of scalability for large gatekeepers (see Section 3.5). Furthermore, a gateway or a gatekeeper must handle the signaling messages for each call. 3.3. Flexibility A well-de®ned protocol should have the capacity to extend the current functionality for future development. It should allow the designers of the applications to personalize sub-components according to individual interest. 3.3.1. Extensibility Extensibility is a metric for measuring a protocol of telephony signaling on IP. Like in any extensively used service, its attributes evolve as new applications are developed, and problems of incompatibility between versions result. The set of functions of extensibility and compatibility of HTTP and SMTP (developed over time) are integrated in SIP. By utilizing the heading Require, the client can indicate the set of characteristics known by the server. If the server does not recognize a feature, it sends back an error code enumerating the characteristics not understood. To improve the value of the extensibility, numeric error codes are organized hierarchically (as in HTTP) allowing for the addition of supplementary attributes, and de®ning their semantics in a class with respect to their compatibility. The textual coding signi®es the self-description of header ®elds (the signi®cance of ®elds To, From, and Subject is simple to understand). Adding new header ®elds in di€erent implementations will be recognized by their names. Since SIP is similar to HTTP, the mechanisms developed for the extensibility of HTTP can be reused in SIP.

172

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

For its part, H.323 also supplies mechanisms of extensibility, which are generally NonstandardParam ®eldplaced in various locations of ASN.1. These parameters contain a manufacturer's code, followed by a signi®cant non-transparent value, which permits other makers to develop their own extensions. As the values of these non-standard parameters are not self-describing, the interoperability between the terminals of di€erent construction is limited. 3.3.2. Duplication One of the drawbacks of H.323 is the duplication of the real functionality of other parts of protocol, particularly in the case of RTCP, which was conceived for supplying a number of feedback and conference control functions. Starting with two conference partners, up to a thousand broadcast sessions can be reached. H.245 also supplies its own feedback mechanisms and simple conference controls (such as obtaining the list of conference participants). We view some of these H.245 mechanisms as redundant and conceived speci®cally for small- and medium-sized conferences. 3.3.3. Integration An important characteristic of SIP is its integration with the Web and other network services. It is important to realize that the power of the Internet is its support for a vast choice of applications. An Internet telephony protocol should endeavor to integrate well with these, particularly the Web. 3.3.4. Codec support Another critical perspective concerns audio and video codecs. SIP uses the SDP protocol to transport the codec data supported by a session end point. These codecs are identi®ed by character-string names, which can be recorded by any person or group with IANA 3. This means that SIP can function with any codec, and that other applications can ascertain the IANA codec name. On the other hand, H.323 is restricted to the use of codecs developed by the ITU, limiting the compatibility between users. Furthermore, in H.323, each codec must be recorded centrally and standardized. 3.3.5. Modularity H.323 is less modular than SIP. It de®nes a sequence of vertically integrated protocols even for a simple application. They are interrelated with the sub-protocols of H.323: · establishment and closure of a call, · exchange of media capacity, · control of conference, · control of admission and bandwidth, 3

Internet Assigned Numbers Authority (IANA), http://www.iana.org

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

173

· supplementary services, · location of the users. The problem is that each one of these modules is di€erent and dynamic (specially developed for the quality of service). Also, as they are all integrated into a single protocol, the elimination of any of these modules and the use of a new and separate protocol are dicult to achieve. The modularity of SIP allows it to be used in parallel with H.323. It is possible to use the descriptive elements of H.245 capacities in SIP without making changes to the latter. A user can use SIP to locate another user through the multi-hop search facilities of SIP. Once the user is located, a reorientation response may be utilized by an H.323 URL, indicating that the actual communication must take place with H.323. 3.4. Third party call control SIP permits the de®nition of new services by means of its powerful mechanisms for the control of third party calls. These mechanisms allow a third party to inform other entities of the creation and termination of calls. As shown in Table 1, these mechanisms can be used to de®ne a variety of services, including immediate transfers, calls over bridges, transitions from multi-unicast to multicast and diverse other variations of communication. As an example of these service extension and creation mechanisms, the Public Telephone Network (PSTN) and an IETF Working Group have de®ned a simple extension of SIP called the ``click-to-call'' service. In this scenario, a user clicks a button on a Web page and a PSTN entity links the user's telephone to a representative of its customer service. This requires a control protocol (in this case SIP) between the Web server and a mechanism approved by the PSTN. H.323 also supplies a number of basic features along this line. The Facility message allows a called entity to orient the caller to contact a di€erent party (fundamentally, an immediate transfer). The H.245 message CommunicationModeCommand allows its central point of control (MC) to change the media encoding for a conference linking various participants. The ®rst command is of rather limited scope, while the second is only executed by the MC for the call. Neither one nor the other supplies the generic mechanisms needed for the control of a third party and to de®ne new services. 3.5. Scalability We also note that H.323 and SIP di€er in terms of scalability. This property can be observed at di€erent levels. A large number of domains. H.323 was initially conceived for use on a local area network. The newer version de®nes the concept of zone, and procedures for locating users through zones and for de®ning e-mail names. However, for a large number of

174

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

domains and complex locating operations, H.323 su€ers from problems of scalability. It does not supply any simple means for loop detection in complex multidomain searches. SIP, however, uses an algorithm similar to that used in BGP (Rekhter and Li, 1995) for this purpose, which can be carried out in a stateless manner as seen in Section 3.2. Conference sizes. H.323 supports multiple-party conferences with multicast distribution of data, but it requires a central MC for the processing of all signaling, even for small conferences. This presents several diculties. First, the user must supply the functionality of the MC for leaving a conference, resulting in the termination of the whole conference. In addition, since the functionality of MC and gatekeeper are optional, H.323 cannot support three-party conferences in certain cases. We note ®nally that the MC constitutes a bottleneck for large conferences. SIP on the other hand handles all sizes of conferences. There is no requirement for a central MC as the coordination of the conferences is entirely distributed, which improves scalability and reduces complexity. Feedback. H.245 de®nes the procedures which enable receivers to control the encoding of media, the rate of transmission, and the error recovery. This type of feedback makes sense in point-to-point scenarios, but is non-functional in multipoint conferences. SIP, by contrast, relies on RTCP to provide feedback on the quality of reception (and also for obtaining the lists of group participants). RTCP, like SIP, operates in an entirely distributed way. 3.6. Security The SIP entities (source and destination) rely on HTTP and proxy-Authentication mechanisms of authentication. The security validation is of a cryptographic nature; the encryption is supported from one hop to another via SSL/TSL (Secure Socket Layer), but SIP may use the protection mechanisms of any transport or HTTP layer (e.g., SSH or S-HTTP). SSL supports symmetrical and asymmetrical authentication, i.e., the server may do the veri®cation process itself, or the client and the server can do a mutual authentication. SIP also de®nes end-to-end authentication and encrypting by using Pretty Good Privacy (PGP) or S/MIME. H.323, on the other hand, de®nes the security mechanisms and the means of negotiation through the H.235 protocol. 3.7. Conclusion In terms of functionality and services supported, version 2 of H.323 and SIP are very similar. The advantages of SIP include ¯exibility in adding new parameters, its ease of implementation and of debugging, and its use in supporting a textual description session. On the other hand, H.323 has certain advantages over SIP, which consists of its strong interoperability with traditional telephony, its backward compatibility, and its power to change capacities between entities on a H.323 net-

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

175

work. We note ®nally that the competition between these two protocols serves to diminish their di€erences in each successive version, as their designers closely scrutinize each other's work. 4. Architecture of our application This section presents our implementation with the SIP protocol. As stated before, we judged it to be easier to implement than an H.323 version, as well as more ecient in its performance. We will ®rst describe the proposed model, its components and the principal classes used in our application. We will then illustrate it by means of examples explaining the execution stages of the application. 4.1. Implementation environment Our application was developed using the object-oriented language Java for its simplicity compared to other languages such as C++. Our main objective was to develop our system in a robust, secure, portable, distributed and dynamic environment, with multithreading support and easy to use for building Internet applications. We used version 1.1.7 of the Java Development Kit for this purpose. The operating system installed on our machines is the French version of Windows 98 (hence some of the headings). In addition, we used the graphic tool Symantec Visual Cafe version 3 for developing our graphical interface. We have developed about twenty classes supporting the graphical interface and the application, with about ten thousand lines of Java code. This application was coded and tested on a set of 333 MHz Pentium PCs with 128 Megabytes of RAM connected to a LAN as well as to the Internet. 4.2. General architecture Invitation of users to a session, based on the Session Invitation Protocol, requires several stages of implementation of a SIP Client/Server as described in the RFC (4326). On the client side, a user agent is needed to enable the sending user to enter the parameters of the requests and the headers of the session, and to execute these requests relating to the corresponding tasks. All clients must be able to: · generate requests: INVITE, BYE, REGISTER and ACK; · analyze the headers: Call-ID, Content-Length, Cseq, From, etc.; · understand the body of SDP; · identify the state code classes 1±6 and act accordingly; · manipulate the incoming responses. After a reply to the invitation is received, the calling user should be noti®ed of its success (200 OK) or failure; · understand the essential parameters of the SIP-URL part of the header ``Contact''.

176

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

The user interface is required to inform the called party and to allow him to accept or reject the invitation. Based on the user's choice, a response must be created and transmitted to the sending client. Receiving requests requires a complex and robust invitation server that runs continuously. After receiving the incoming call, it must locate the called user and redirect the request to the exact site of the latter. It then waits for TCP connection requests, which it then handles accordingly. The search of a user location, essential to establish an invitation session, may be achieved in several ways that are not outlined in the SIP speci®cations. Consequently, we have created our own database. Fig. 4 illustrates the architecture of

Fig. 4. Proposed architecture.

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

177

implemented software, and the interactions between the various components during the processing of the SIP request. In summary, the four principal components of the architecture are: · The workstations for executing session invitations are based on SIP. They are used to enter the parameters of the invitation to the session and for transferring the request created to an appropriate SIP server. When a request is received, it is veri®ed that the media requested are supported, the called user is advised, and an appropriate SIP response is sent to the selected callee. · SIP is a signaling server used for location searches of users and the incoming requests are redirected. It must function on each host server able to receive and process the SIP requests. · The location service is a database, which contains SIP URLs of the current location of users and their time of expiration. · The client database is used to record information on the frequent users of communications. · The media server operates solely to control the participants in a session (list of participants, exit the session). In general, a SIP request is created by a user who sends it to the SIP server, according to the address indicated in INVITE. The server consults the location service to ®nd the invited user and transfers the response to the sending client. An INVITE request will be automatically generated and sent to the invited user together with the subject and media of the call, who in turn replies by accepting or refusing the invitation. In the case of acceptance, a conversation will take place; at any time, if one of the participants wants to quit, he sends a BYE request, indicating his desire to terminate the session.

4.3. Components of the architecture The methodology for implementing our application consisted of developing the following components. 4.3.1. Client database The invitation of users to a multimedia session requires knowledge of the SIP addresses. To achieve this, the ®rst step we took was to create an MS-Access database, as illustrated in Fig. 4. This permits the recording of addresses and other information pertinent to the user description (last name, ®rst name, street address, e-mail, SIP address, telephone number, country and URL) to facilitate the invitation. The direct manual modi®cation of this database did not seem to be appropriate, so the client was provided with an interface permitting the user to add, delete, and modify records. The practical use of this database is presented in Section 5.3.

178

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

4.3.2. Location service Another component of the architecture is the location service. This component registers the URLs pointing to the current addresses of the users to be invited and the expiration time of this record. The main operations performed on this database are: · register a record, · cancel a record, · search for a record in the database, · refresh the the database every 2 min. In order to output the information in the database we have implemented a class concerned with the printing of its contents. 4.3.3. SIP client The SIP client, designed for multimedia conferences on the Internet, is used to manipulate a simple conference by creating, terminating, and con®guring their session parameters. First, the pertinent SIP client must o€er a graphical interface to the users allowing them to state their invitation parameters such as the SIP address, the DNS and the description of the session. Then, the client must create and formalize the SIP requests and determine the appropriate SIP server to be contacted. After sending the invitation, the client must await the responses that arrive, and handle the returned response code. The success or failure of the invitation is announced to the calling user. To render the session invitation with the client more ergonomic, sessions are created automatically after receiving a successful response. 4.3.4. SIP server This server is designed to handle SIP-based session invitations. It must carry out the following tasks. Recording users. At each receipt of a registration request ``Register'', the server must verify if the ®eld ``Expire'' is zero or not. When non-zero, the registration request is sent to the location service, indicating the expiration time and the user address. Next, a search is launched, and a 200 OK response will be generated by the server and sent to the user asking for the registration. Example. REGISTER 132.208.136.32 SIP/2.0 Via: SIP/2.0/UDP 132.208.136.32 Call-Id: [email protected] From: sip:[email protected] To: 132.208.132.189 CSeq: 1 REGISTER Expires: 2700

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

179

When the ®eld ``Expire'' is equal to 0, a similar request for cancelling the record is sent to the location service, also generating a 200 OK response to the user requesting the registration. Redirection of a call. A supplementary task of the SIP server is to receive and manipulate the INVITE request. It must search the locations of the user appearing in the Request-URL ®eld. So, depending on the number of locations found, the server handles the request as follows: if the called party is connected to a single terminal, a 302 Moved Temporarily response is generated. Example. SIP/2.0 302 MovedTemporarily Via: SIP/2.0/UDP 132.208.136.32 Call-Id: [email protected] From: sip:[email protected] To: sip:[email protected] Contact: sip:[email protected] If the invited party is connected to several terminals, a 300 MultipleChoices response is generated; its format is similar to that of the 302 MovedTemporarily response, except that it will contain more than one contact. On the other hand, if the invited party being searched is not registered by the location service, a 404 NotFound reply transmitted to the sender of the invitation. Example. SIP/2.0 404 Not Found Via: SIP/2.0/UDP 132.208.136.32 Call-Id: [email protected] From: sip:[email protected] To: sip:msheik@132. 208.132.189 Processing incorrect requests. Another task of the SIP server is to generate a 606 NotAcceptable reply to incomplete or incorrect requests; it is similar to the 404 NotFound message above. 4.4. Limitations We have implemented our application so that it supports the following tools: Chat, Audio, and Video. However, constrained by the equipment currently available in our laboratory, our practical tests have been limited to the Chat tool at present. The principal tasks achieved in our application are thus: · the registration of the SIP server in a database; · the choice of users for entering into communication; · the response to an invitation (accept or reject); · the creation of an index for managing the invitation of the parties; · the tracing of the results on the states of invited users; · the conversation between parties in a session;

180

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

· the sending of mail to a user, when unable to make contact by other means. Among the characteristics not yet dealt with at present are: · no support of UDP in SIP, · no handling of a stopped server, · no support of passwords by the server, · only a part of all the SIP packets have been implemented, · the graphical interface of the server is not implemented, · the broker server is not implemented. Some characteristics have been omitted because the SIP draft used was not perfectly clear on their implementation. The draft suggested that we use LDAP as the server database, but we have decided to create our own (using MS-Access). Also, contrary to SIP standard speci®cations, we did not use the DNS records of SRV for locating the SIP servers, as SRV is only experimental and not in extensive use at present. Finally, we have been unable to discover the format and exact procedure for executing such consultations. 5. Implementation aspects In this section, we will describe the functions associated with each of these tasks and provide examples explaining the events caused by their execution. 5.1. Functional description 5.1.1. Registration at the location service Each time the user is available for communication, it is necessary to send a REGISTER message to the SIP server, containing at least a Contact address. This request must contain at least the following ®elds. REGISTER 132.208.136.32 SIP/2.0 Via: SIP/2.0/UDP 132.208.136.32 Call-Id: [email protected] From: sip:[email protected] To: 132.208.132.189 CSeq: 1 REGISTER Expires: 7200 Contact: sip:[email protected] Content-type: application/sdp Content-length: 117 The 200 OK response returns the ®elds: To, From, Call-Id and Cseq of the request, with the possible addition of a label in the To ®elds. Example. SIP/2.0 200 OK Via: SIP/2.0/UDP 132.208.136.32

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

181

From: sip:[email protected] To: 132.208.132.189 5.1.2. Initialization of SIP requests The establishment of a call by a user triggers an INVITE request to invite other users to a multimedia session. Fig. 5 shows the steps to be executed to carry out an invitation to a session. First, the user must enter the required parameters. The procedure Invite( ) then generates the invitation and sends the request to the SIP server. A SIP request must also be created for each invitation with a unique Call-Id. All requests are registered in the INVITE vector for later reuse of their ®elds (e.g., to end a call or cancel the registration of a participant). Its format is similar to that of the register request. Before expediting the request to a server, the client must specify the latter by examining the host part of the called party's address. The client then, attempts to make its own connection to a prede®ned TCP port on the server and sends the request. In case a connection is established, an event will be triggered if the socket

Fig. 5. Initialization of requests.

182

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

at the server becomes readable. Finally, to avoid an in®nite response time, a timeout is activated. When it expires (over 30 s), the socket will be closed. 5.1.3. Reception of SIP replies As we the have previously mentioned, the issuing of SIP requests is only one task of a SIP client. Another responsibility is the handling of SIP responses, consequent to the invitations. The process that handles incoming SIP responses is called under certain circumstances, e.g., if the TCP socket to which the SIP request has been sent becomes readable, thus, indicating that a response is coming from the contacted entity. Fig. 6 shows the set of functions launched in the response. After analyzing the response (procedure Parse( )), a response procedure calls the function for reading the con®gurations indicated in the response and records them in the ``Reply'' vector. If the response received is a ®nal reply, the time-out counter will be stopped and the TCP socket with the server closed, since the invitation process is terminated and no further reply is expected from this Call-Id. Since the caller must be informed about the reply received, a window will be created, informing the callee of the subject contained in the response. Actions are executed according to the code of the response. If the invitation is successful (200 OK), the session will be automatically created. 5.1.4. Call rejection The rejection of a call generates a response of class 600 (e.g., BusyEveryWhere) or 400 (e.g NotFound) to be sent back to the requester. The caller should be noti®ed of the rejection, and no media should be exchanged. If the user agent called permits multiple types of rejection (600 BusyEveryWhere), each of these should be tested in turn to verify that it is understood by the client. In each case the client should at least send an ACK, indicating to the caller that the call has been rejected. However, the following ®elds must be controlled. Example. SIP/2.0 404 NotFound (or 600 BusyEveryWhere) Via: SIP/2.0/TCP 132.208.136.32 Call-Id: [email protected] From: sip:[email protected] To: sip:[email protected] 5.1.5. Processing incoming calls In this section, we describe how the connection is established between the correspondents, how the socket becomes readable, and how the incoming SIP requests are consequently carried out. Fig. 7 shows the principal stages of these operations.

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

183

Fig. 6. Response processing.

First, a procedure must read the SIP message received, verifying the parameters of the request. Afterwards the client generates a response 101 Trying to the user indicating that the invitation has been received. Example. SIP/2.0 101 Trying (and 180 Ringing)

184

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

Fig. 7. Processing of arriving calls.

Via: SIP/2.0/UDP 132.208.136.32 Call-Id: [email protected] From: sip:[email protected] To: sip:[email protected] CSeq: 2 INVITE After reading the call parameters, the client veri®es that the types of media and their coding are supported. If they are not, a 115 UnsupportedMediaType response is generated. Otherwise, the called party is noti®ed of an arriving request and a 180 Ringing response is sent to the caller, advising him of the current state of the invitation. In addition, to prevent an endless displaying of the window, a time-out is issued to close the window if the called party fails to respond within a reasonable

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

185

delay. The window displaying the request and the type of media requested allow the user to accept or reject the call. If the call is accepted, a conversation session will be opened and a ``Chatting'' window automatically appears. 5.1.6. Termination of a call If a participant wants to end an established call, a BYE request is sent to all users in the ``Invite'' vector, conveying his intent to quit the session. A 200 OK response will be automatically generated and sent to the requester. Henceforth, no media will be exchanged with this correspondent. Furthermore, the following ®elds in the request need to be controlled. Example. BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 132.208.136.32 Call-Id: [email protected] From: sip:[email protected] To: sip:[email protected] CSeq: 1 BYE 5.2. Main classes In this section we describe the following principal classes, as outlined in Fig. 8. 5.2.1. User interface classes The user interfaces consist of several classes employed for communication with the user in a graphical manner. 5.2.2. Client class The Client class is used to execute SIP classes. It generates the following events for communicating with the user (creator of the request): Client ! graphical interface · IncomingCallEvent: generated when someone calls. · OutgoingCallEvent: generated when someone has responded. · NewCallIdEvent: generated when a new Call-Id has been created. · IncomingTimedOutEvent: generated when an incoming call has expired (timed out). The principal methods are: · GetMedia: Veri®es what types of media are known by the program. · GotEvent: Listens to the events of Call, Receiver and TimeOut classes. · Locate: Locates a user by means of the Server class. · LocInv : Locates and invites a user · Register: Registers the user with the location service through the server. · Reply: Responds to a call. · Unregister: Cancels the server user.

186

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

Fig. 8. Classes of the application.

5.2.3. Receiver/Incoming classes The Receiver class listens to incoming invitations on a speci®c port. When a new invitation is received, an Incoming class is created for it, which will be responsible solely for this invitation. The Receiver class can then continue to listen to other invitations. This is achieved by giving each incoming object its own thread. Incoming then informs the Client class that a new invitation has been received. The Client then processes the invitation to which there are three possible responses: accept, reject, or time-out. After the Incoming class has received a reply, it closes the connection as no other transmission with the client is forthcoming. The principal methods used in these classes are: · Kill: close the connection and cease listening to communications. Consequently, this renders it impossible to send other messages on this connection. · Run: execute the thread used for listening to communications on this connection. · Send: used by the client for sending a response to the calling party. · Send-packet: sends a SIP packet on the current connection.

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

187

5.2.4. Class call The Call class is an instance of the Client class, used as an object for each invitation and/or location. This class generates events of the types ExceptionEvent and ResponseEvent. ResponseEvents are generated when a ResponsePacket has been received. Call is implemented with a thread that begins executing with the methods invite( ) or locate( ), and can be stopped by using kill( ). Call ! Client · ExceptionEvent: sent when there is a dysfunction. · ReplyEvent: sent when someone has answered. The principal methods used in this class are: · GetPacket: returns the packet. · GotEvent: listens to the TimeOutEvents of the TimeOut class. · Invite: sends an invitation to the called party, or a REGISTER/UNREGISTER packet to the SIP server. · Kill: stops the Call thread. · Locate: contacts the SIP server speci®ed in the SIP packet and requests the location of the called user. · Run: executes the thread. 5.2.5. DNSLookup class This class determines the number of IP addresses available on the Internet. It can also determine all the MX records. · Query: interrogate a DNS server on the IP number of an address. 5.2.6. Packet class This class contains the SIP packet standards and the methods for their creation and analysis. The Incoming, Client andServer classes employ them. There is a class for each of the di€erent types of packets, and an abstract class ``Packet'' for the analysis of packets. 5.2.7. Server class The Server class uses the Receiver class for listening to arriving requests, which it veri®es in its database; it then sends a Packet-type response. 5.2.8. DataBase server class DataBaseServer is a database class containing information regarding the location of users and which the Server must know.The principal methods are: · Find : searches for a user in the database. · PrintDb: displays the database on the screen. · Refresh: refreshes the database every 2 min. · Register: registers a user in the database. · Unregister: cancels the registration of a user in the database.

188

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

5.2.9. DataBase_Client class This database performs the registration of SIP addresses of frequent users. The main methods used are: · Insert: Registers a record in the database. · Update: Modi®es a record. · Delete: Deletes a registration. · Select: Selects a registration. 5.2.10. SDPPacket class This class is used for the description of the session. Its methods are: · AddMedia: Adds the media required for an invitation used by the SDP packet · GetSDPPacket: Recovers an SDP packet. 5.3. Application example When a client application is launched, a dialog box appears (Fig. 9). This window allows the user to enter his SIP address (to be identi®ed in a session, generally a combination of user and SIP server names), the DNS server and the expiration time in ms (time during which the user is registered in the database of the SIP server). Once the user has entered all the parameters, he must choose one of the following options.

Fig. 9. Main menu.

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

189

5.3.1. Register button By clicking on this button, the user's present location will be registered in the SIP server database, then a message ``You are now registered'' will be displayed. Otherwise, the message ``You are not registered'' will be displayed. 5.3.2. Exit button If the user clicks on this button, the registration will be canceled automatically in the database of the SIP server and the application will be terminated. 5.3.3. Repertory button Clicking on this button will result in another window appearing (Fig. 10). There the user can modify, add and delete registrations. This interface consists of a list of persons who are already entered into the database. When a user selects a person from the list, all relevant information will be displayed in ®elds situated in the center of the window. These ®elds can be altered by pressing the following buttons: ``Modify'' permits the modi®cation of a record; ``Add'' enables the addition of records; Delete removes the person selected; ``Erase'' deletes all the ®elds; OK con®rms the changes; ``Close'' closes the window; and ``Play Audio'' and ``Stop Audio'' start and stop the audio playing. 5.3.4. Invite button This button allows the user to select persons to invite. Any person chosen can be added to the session by pressing ``Add to a session''. A person can also be selected for

Fig. 10. Information on participants.

190

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

removal from the invitation list by pressing ``Delete from the Session''. Names, SIP addresses, phone numbers, etc., are shown in the Participant Selection window (not shown), in order to assist the user in making these choices. To activate the invitation, the user presses ``Invite'', otherwise, ``Cancel''. The window will disappear in either case. 5.3.5. Results After an invitation has been made, a new window appears (see Fig. 11) where the results can be viewed. If the user receives at least one acceptance, he presses the ``Tool'' (``Outil'') button to join the participants in the session The Results window remains open until the user clicks on ``Close''. The ®rst ®eld of the table in the window below shows the SIP addresses of the called parties and the other ®elds the status of the invitations, (e.g., Trying to ®nd location, Location not found, Media Not Supported, Ringing, Accepted Invitation, Rejected Invitation, etc). 5.3.6. Incoming call When a user invites another, a window comes up (see Fig. 12) at the callee's location (if found). This window contains the caller's name and SIP address, the subject of the session and the media used. The called party can now accept or decline the invitation by clicking ``YES'' or ``NO''. 5.3.7. Chatting If the invitation has been accepted, a Chatting dialog box appears (see Fig. 13). The parties who have accepted the invitation of the caller will be displayed in the ``List of clients''. Each user in the session may change his name by typing a new name

Fig. 11. Invitation results.

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

191

Fig. 12. Incoming call.

and pressing ``Change name''. The modi®ed name will be automatically changed at all the other parties, and a message indicating the change will be displayed in the Chatting window. Every time the user wishes to have a conversation with the others, he must type the message in the ``Message'' ®eld and then press ``Send''. In order to quit the session, ``Disconnect'' must be pressed, and a message will be displayed so that all participants will see that one of the group has left. ``Erase'' removes the Chatting box while Close closes the window. 5.3.8. E-mail When it is impossible to contact the called party because of a rejection of an invitation or for other reasons, the caller can click on the SIP address of the person called (shown in the ``Results'' window). A dialog box will appear with the name and electronic address of the party called, as well as the electronic address of the caller. Once the user writes a text and clicks on the Send button, a message will come up con®rming that the text has been sent.

6. Conclusion The future of Internet telephony is very promising, but extremely dicult to predict, as the principal decision-makers are the companies who are working to

192

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

Fig. 13. Chat window.

extend this technology. The possibility of voice and data transmission on the same network is the principal reason for its development. Furthermore, the techniques ``Voice Over IP'' (VOIP) are still new and their evolution has advanced very rapidly in a short period of time. Yet, through all this, one perceives that the applications of these technologies are only at their very beginning and that the full social impact has yet to be realized. At present, it is certain that the only constraint on the great strides being made in Internet telephony concern quality. However, this limitation will be reduced by enhancing the Internet bandwidth, and increasing the speed of switching and of compression algorithms. Internet telephony can only be expanded. In this paper, we brie¯y introduced the concepts of Internet telephony, as compared to traditional telephony, and de®ned the concept of signaling. We then presented a short comparison between the SIP and H.323 protocols, based on their main characteristics. The relative level of complexity of these two protocols has already attracted the interest of large companies such as MCI, one of the largest supporters

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

193

of SIP. Several other companies have also begun to replace their products by others adapted to this protocol instead of H.323. We are of the opinion that SIP is superior for operating on the Internet. However, for connections to the PSTN, H.323 appears to be more solid at the present time. Our main contribution has been to develop an application based on the Client/ Server architecture of the SIP protocol, to implement the majority of signaling messages between several PCs, and to establish communications between them. Moreover, the processing and the formulation of requests have been the focus of particular attention. We have tackled the access to an MS-Access database at the client level from a Java environment, and to another database at the server level. In this context, we have completed the formulation of the main SIP requests while respecting the speci®cations of this protocol as outlined in its draft. This application requires software that is easy to understand and use. It must allow the signaling between persons connected and registered in a database, enabling them to enter into communication among themselves. Several examples of requests used during the execution of the program have been presented as illustration. The model presented was conceived for a text environment as well as for voice and video. However, the lack of available workstations equipped with multimedia hardware limited the implementation of our application and forced us to focus on text conversation, i.e., Chatting. Other limitations in our work, as listed in Section 4.4, were partly due to the current state of the SIP Draft. Current work is directed toward reducing these shortcomings, in order to transform it into a production software. · To render our application more functional and dynamic, so that it can support other types of messages and networks, and to improve the implementation of the SIP base. · To integrate with other types of servers (e.g., using RTSP servers for voice mail boxes). · To establish a voice session between two telephones, involving the usage and implementation of a gateway able to communicate with the PSTN by means of the JTAPI package (Java Telephony API) developed by Sun. · To develop an interface between the two protocols SIP and H.323 so as to make interoperability between them possible. References Braden, B., Zhang, L., Berson, S., Herzog, S., Jamin, S., 1997. Resource reSerVation Protocol (RSVP) version 1: Functional Speci®cation, RFC 2205, Internet Engineering Task Force, October. Donovan, S., Cannon, M., 1998. A Functional Description of SIP-PSTN Gateway, Internet Draft, IETF, November. Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., 1999. SIP: Session Initiation Protocol, Internet Draft, Internet Engineering Task Force, January (work in progress). ITU-T Recommendation H.323, 1998. Systems for multimedia communication in packet mode.

194

I. Mortada, W. Probst / Telematics and Informatics 18 (2001) 159±194

ITU-T Recommendation H.245, 1998. Control Protocol for multimedia communication, February. Jacobson, V., Handley, M., 1998. SDP: Session Description Protocol, RFC 2327, Internet Engineering Task Force, April 1998 (work in progress). Kerherv'e, B., 1994. On distributed multimedia information presentational application: functional and computational architecture and QOS negotiation. In: Proceedings of the International Workshop on Protocols for High-Speed Networks. Chapman & Hall, London, pp. 732±739. Rekhter, Y., Li, T., 1995. A border gateway protocol 4 (BGP), RFC 1771, Internet Engineering Task Force. Rigney, C., 1997. RADIUS Accounting, RFC 2139, Internet Engineering Task Force, April. Russell, T., 1995. Signaling System #7. McGraw-Hill, New York. Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1996. RTP: a transport protocol for real-time applications, RFC 1889, Internet Engineering Task Force. Schulzrinne, H., Rosenberg, J., 1998. Signaling for Internet Telephony, Technical Report CUCS-005-98, Columbia University, New York. Schulzrinne, H., Rosenberg, J., 1998. Internet Telephony: Architecture and Protocols ± an IETF Perspective, July 2. Schulzrinne, H., Rosenberg, J., 1998. A comparison of SIP and H.323 for Internet telephony. Network and Operating System Support for Digital Audio and Video (NOSSDAV), Cambridge, England. Schulzrinne, H., Rosenberg, J., 1999. The session initiation protocol: providing advanced telephony services across the Internet. Bell Labs Technical Journal. Stevens, R.W., Wright, G.R., 1995. TCP/IP Illustrated, vol. 2, Addision-Wesley, Reading, MA. Vogel, A., Kerherve, B., Bochmann, G.v., Gecsei, J., 1995. Distributed multimedia and QoS: a survey, IEEE Multimedia, pp. 10±19.