Ko Uchiyama
Herbert Ignacio
Abstract
The Internet Telephony Gateway System interfaces an internet bound client with a POTS telephone line by means of the Teltone T-311 Telephone Access Unit, allowing internet-to-phone and phone-to-internet communications. The system employs a directory server which can be located anywhere on the internet. The gateway hardware is located in at a remote location, interfacing the PSTN to a computer connected to the internet via ethernet. The internet bound client can be anywhere on the internet provided they are on a Java VM capable workstation with Java Media Framework installed. Although the computer to which the gateway is attached acts as a host to the PSTN, it too will act as a client to the SIP driven directory server. The computer to which the gateway is attached must register itself with the directory server, as must the client wishing to accept phone calls. When a request to make a call is placed on the directory server, the internet address of the requested computer is returned to the requester. It is then up to the requester's client software to make a connection to the requested computer. A caller from the PSTN is capable of placing a call on the internet via the gateway knowing either the IP of the client they wish to call, or the email address of the user they wish to call.
Architecture
The directory server is driven by SIP and holds the database of all the people that have ever logged into the directory server.
The directory server can be anywhere on the internet; however, the directory server must have a well defined IP address in order that client programs know where to locate the server. This is because we have no intentions of registering an SIP resource record with any already established DNS services, nor do we have intentions to run our own.
The database entries consist of each user's universal ID (i.e. their email address), their location, including their hostname and port number, protocol, and an indication of whether that user is currently registered with the directory server as being "logged in" to a remote computer somewhere on the internet. Each database entry is saved on the server in a special directory, one user per file. The file contains the URL that was submitted by the user during registration.
The main responsibility of the directory server is to maintain this database, to register and de-register clients, and to initiate a session between two clients which request to communicate with each other.
When a user wishes to receive calls from a phone attached to the PSTN, that user must register his/her location with the directory server. S/he does this by placing a request on the directory server which includes the address of the computer s/he is logged in to. Similarly, in order to make calls to a PSTN telephone, the user must first register their location with the directory server in the identical manner. These functions are carried out by the SIP REGISTER method. The gateway must also register its location on the SIP directory server, so that every client wishing to make calls over the PSTN need not know the location of every gateway.
When the user wishes to make a call to a PSTN telephone, the client makes a request to the directory server using the SIP INVITE method for the location of an available POTS gateway. Once the client receives that information, the client proceeds to make a RTP connection with the POTS gateway, using the Location information it received from the directory server. Once a connection has been established between the client and the POTS gateway, the client can now request to make an outgoing telephone call over PSTN. The client provides the gateway with the telephone number to dial. Note: The directory server does not provide this information. The user must know the phone number s/he wishes to call. The gateway proceeds to make that telephone call and then establishes a connection between POTS and the internet, enabling internet to phone communication.
When a user wishes to make a call from a PSTN telephone to someone on the internet, s/he must place a call to a POTS gateway. The phone number of the POTS gateway must be known; the directory server will not hold information on the POTS gateway's phone number, and in the event that the caller does not have access to a computer, the directory server will not be accessible anyway. When the POTS gateway receives an incoming call, it answers the call after a specified number of rings. Once the call has been established, the interface between POTS and the attached computer is instantiated. The caller now has the ability to enter information via the numeric keypad. The Teltone T-311 has the ability to convert these DTMF signals to ASCII for processing by the computer. The user follows the prompts to make an internet phone call and ultimately must enter the Universal Identification Code or IP address of the party they wish to call. Once this information is obtained, the client attached to the gateway makes the sequence of requests, with the directory server, necessary to locate that user on the internet. Once the callee's location is determined, the client proceeds to establish a RTP connection with the callee. The caller and callee now have a direct phone-to-internet connection established.
Once the connection is established between the client and gateway computers, audio is transmitted between the two clients over RTP by encapsulating RTP packets into UDP packets and transmitting them to a JMF host on either end which processes the packet based on the RTP packet's header information. JMF's RTP Session handlers take care of RTP packet ordering based on RTP packet numbers and timestamps. The RTP header information is not generated by JMF; this information must be calculated and encapsulated by the programmer. We took care of this encapsulation of the audio data into RTP, and in turn into UDP, and transmitted the packet as UDP. The calculations for the timestamp are based on the fact that 8000 samples of 8-bit monoaural data is generated by the SoundBlaster Pro UNIX audio driver per second. Because packets are 48 samples in size, each packet's timestamp is incremented by 6 milliseconds each. RTP packet retransmission is not handled simply because retransmission of real-time data is not necessary; these packets will be ignored by the RTP Session handler anyhow.
The interface between the POTS gateway and the host Solaris workstation was written in C to ensure that communication with the hardware was handled correctly. All other components were however developed in Java, so the product will be platform independant. All components requiring reception of audio data over RTP require the Java Media Framework, in order to make playback of audio data transparent and platform independant. Our work focusses on the encapsulation of that audio datum into RTP, not on actually playing the audio back.
The interface between all separate components (gateway interface, client user interface, RTP transmitter, RTP receiver, SIP transmitter, SIP reciever, SIP directory server) uses RTP/UDP/TCP sockets for inter-component communications. All SIP driven communication happens over TCP connections.
Wish List
Enable PSTN only users the ability to check email and read web pages using a text to speech utility.
Enable voice mail.
Enable voice to text for sending textual e-mail.
Enable users without access to computers, the ability to register their phone number on the directory server, enabling phone number lookup directly on the directory server. Each entry must still have some sort of Universal Identification Code associated with it.
When there are multiple computers acting as gateways to POTS, the directory server must dynamically choose which gateway's address to send to the requester.
Enable phone to phone communications by allowing one gateway client to request communication with another gateway client through the directory server. This is a trivial addition.
This page was last updated on 05/12/98.