Network Working Group C. Yang Request for Comments: 1789 University of North Texas Category: Informational April 1995 INETPhone: Telephone Services and Servers on Internet Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note Internet Engineering Steering Group comment from the Transport Area Director: Please note well that this memo is an individual product of the author. Work on standards and technology related to this topic is additionally taking place in the IETF in the Multiparty MUltimedia SessIon Control Working Group (MMUSIC). Abstract INETPhone is a true telephone service through the Internet. It integrates the local telephone networks and the Internet using INETPhone servers. Thus a long distance call can be split into two local calls and an Internet connection, which is transparent to end users. Such a phone service through Internet will be a major step towards integrated services on Internet. In order to support the INETPhone and lay down the ground rules of the service, a scheme of "open partnership" is proposed, so that the entire Internet community can have the equal opportunity and benefits from the INETPhone service. 1. Introduction The success of traditional Internet services, such as the electronic mail, the file transfer, and the remote machine access, has inspired a row of new network applications -- the world-wide information web, voice and video conferencing, and network telemarketing are just a few to mention. With the further development in infrastructure and the architecture of integrated, multimedia information services [1,2,3], certainly the Internet will play a crucial role in shaping up the future of so-called information super-highway. Among many new applications, the voice communication through Internet bears perhaps the most potential impact, since it competes directly with the telephone communication, which has become an indispensable
part of the modern society. Recently, many software packages are available, either commercially or as public free-ware, which supports voice communication on Internet. Some of these products are targeted directly as possible substitution for long distance telephone services. However, so far, all such products only support voice communications using a computer that is on the Internet or is connected, via a SLIP link, to the Internet . This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. INETPhone integrates the local phone network with the Internet. The phone network provides local access of INETPhone service with the existing telephone facilities, whereas the Internet delivers the packets of voice communication over long distances. The service of INETPhone is illustrated by the following scenario. Assuming a user at area A wants to call another user in area B. The user first makes a local call to an INETPhone server in area A. After the connection, the user keys in the remote phone number in area B to the server. Then the server in area A makes a connection to another INETPhone server in area B, and requests the remote server to dial, as a local call, the phone number in area B. Therefore, a long distance phone connection between users in area A and B is established via two local phone connections and one Internet connection between two INETPhone servers. The INETPhone provides a general service of voice communication on Internet compatible to the existing telephone service. The motivation in developing and experimenting the INETPhone service can be two-folds: on the one hand, a general telephone service on the Internet will be a major step towards integrated services on Internet and a great challenge to the future development of Internet infrastructure and protocol architecture; on the other hand, the entire Internet community can take the advantage from the cheap and convenient voice communication of the INETPhone service. 2. Design Philosophy The design philosophy of the INETPhone differs from the most of current voice communication services on Internet in three basic aspects: integrating the existing telephone networks with the Internet; using the INETPhone servers to carry out the task of voice packet delivery on Internet; and an open-partnership of establishing the INETPhone service on Internet. The discussion of each of these aspects is given as follows. The conventional telephone service is the most popular and convenient means for voice communication across distances. Any serious effort to integrate voice communication on the Internet should take the full
advantage of this well-established service. The INETPhone bridges the existing telephone network with the Internet, so that the access of the INETPhone service will be totally based on the local phone services and facilities. This will lead to a much easier access and broader user population than the approaches of computer-based access. The INETPhone service is based on the client-server model, in which a group of INETPhone servers are responsible for accepting/initiating local calls and deliverying voice packets across the Internet. The general users (as clients) can easily access the service through a conventional phone with a local call. The creation of such INETPhone servers eases the burden from general users, and provides services of voice communication on the Internet in a more efficient and manageable manner. Hundreds even thousands of INETPhone servers will be required for the wide coverage of INETPhone services on the Internet (to cover all areas within US, at least one server needs to be installed in each area of phone area code). Instead of letting few industrials monopolize such a service on the Internet, an alternative approach based on an open-partnership scheme of INETPhone service is proposed (see Section 5), which will give equal opportunity and benefits to the entire Internet community. 3. INETPhone Servers The central components of the INETPhone service are its servers on Internet. The server acts as a gateway between the telephone network and the Internet. For this purpose, the server will have both interfaces to a computer network and the telephone network. Currently, there are many commercial telephone interface cards available on the market (such as Dialogic's Voice Boards ), which support various telephone operations of detecting/generating telephone signals (ring, DTMF, etc. ), receiving/initiating phone calls, recording (digitizing and compressing) or playing back audio signals, and monitoring the progress of a phone call. With the support of necessary hardware interfaces, the function of an INETPhone server includes: (a) Receive a local call or accept a connection from a remote server; (b) Identify the PIN of a local call and determine if to proceed the call or not; (c) Accept a phone number for remote dialing from a local call;
(d) Look up the local directory for a remote server of a requested call; (e) Make a connection to a remote server; (f) Make a local phone call upon the request of a remote server; (g) Maintain full-duplex, real-time exchanges of voice packets via Internet; (h) Maintain information exchanges with Directory Servers (see Section 4); (i) Handle exceptional conditions, such as long delay or drop of voice packets; (j) Monitor quality of service and keep accounting information. The above listed functions represent probably the minimal requirements for each INETPhone server. Some further important features, such as compression/decompression, security, multicasting, and voice mail need also to be considered when a real service of INETPhone is launched on the Internet. Since a general public of the Internet community might be involved in this proposed INETPhone service, it is probably necessary to set an open standard in the building of INETPhone servers (see Section 5). 4. Directory Servers The main philosophy behind the INETPhone service is to reduce a long distance phone call into two local calls and an Internet connection. Therefore, an INETPhone server will always be identified by its IP address with its local area code of the phone number (also possibly with its sub-regional number). In order to support a dynamic configuration of INETPhone servers on the Internet, a Directory Server(s) (DS) will be required to map between IP address and area code of INETPhone servers, which in some sense, is similar to the functions of a Name Server (such as the BIND ). After an INETPhone server is installed on the Internet, it needs to register itself with a DS. The mapping information at DS will be disseminated to INETPhone servers for the search of a remote server in response to a requested phone call. Local cache of mapping information may also be maintained at INETPhone servers to alleviate communications between INETPhone servers and Directory Server(s). Again, the function of a Directory Server for the INETPhone may require another open specification.
5. Open Partnership Voice communication and telephone service are important parts for providing integrated information services over the Internet. With the current trends of commercialized services over the Internet, sooner or later, some kind of telephone services will be launched on the Internet by some private companies. On the other hand, the operation of the INETPhone service will depend on the installment of enough INETPhone servers over the Internet, which can be achieved through a cooperative effort of the entire Internet community. This RFC proposes an open-partnership scheme for the INETPhone service, which provides equal opportunity and benefits to the entire Internet community. An outline of the proposed open-partnership scheme is listed as follows: (a) Any organization or individual person can join or withdraw from this open-partnership on a voluntary base. (b) In order to join the partnership (therefore becoming a member of the partnership), an organization or a person should at least install and maintain an INETPhone server on the Internet with the equal capacity of lines for call-in and dial-out services. (c) Each member of the partnership has the equal right to use the INETPhone service through any INETPhone servers on the Internet. All services will bear the same charges based on the number of bytes transmitted through the Internet and whatever the rate (if any) laid down by the Internet authority. (d) A not-for-profit consortium will be formed from the representatives of all members of the partnership. The main task of the consortium is to establish all regulations and specifications of the INETPhone service, and to coordinate the execution of these rules by all the members. 7. Recommendation If there is enough interests in the INETPhone service from the Internet community, the IAB may need to consider forming a special task force or working group to further look into the matter.
8. References  Adie, C., "Network Access to Multimedia Information", RFC 1614, Edinburgh University, May 1994.  Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, Xerox PARC, June 1994.  Weider, C., and P. Deutsch, "A Vision of an Integrated Internet Information Service", RFC 1727, Bunyip Information Systems, December 1994.  Walters, R., "Computer Telephone Integration", Artech House Publishers, Norwood, MA, 1994.  Dialogic Corporation, "Voice Hardware Reference", Parsippany, NJ, 1994.  Noll, M., "Introduction to Telephones and Telephone Systems", 2nd Ed., Artech House Publishers, Norwood, MA, 1991.  Albitz, P., and C. Liu, "DNS and BIND", O'Reilly & Associates, Sebastopol, Calif., 1992. 8. Security Considerations Security will be an important issue in the INETPhone service. As a general proposal, however, this RFC chooses to leave this topic for future discussions. 9. Acknowledgement This RFC is based on a currently undergoing project supported by the Department of Computer Science, University of North Texas. 10. Author's Address Cui-Qing Yang Dept. of Computer Science University of North Texas P.O. Box 13886 Denton, TX 76203 Phone: (817) 565-2822 Fax: (817) 565-2799 EMail: firstname.lastname@example.org