INTERNET DRAFT Masataka Ohta draft-ohta-notasip-04.txt Tokyo Institute of Technology Kenji Fujikawa Kyoto University 12 October 2001 Nothing Other Than A Simple Internet Phone (NOTASIP) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo describes a simple protocol for port negotiation of bi- directional UDP steam. The primary target of the application of the protocol is Internet phone without QoS guarantee and the protocol is explained with Internet phone as the application using telephone terminology. A callee's host may accept multiple streams on a well known UDP port and redirect them to other ports. 1. The Architectural Principle of the Internet Phone Fortunately enough, the Internet is the installed base of data communications. Other network technologies must find some way to interoperate with the Internet in order to survive a little longer. However, in the world of phone communication today, POTS (Plain Old OHTA & FUJIKAWA Expires on 12 April 2002 [Page 1] INTERNET DRAFT NOTASIP October 2001 Telephone Service) is the installed base. For the Internet to replace POTS within a few years, it is important that Internet telephony interoperate with POTS. So, the primary requirement for Internet telephony at this early stage is that it should be able to interoperate with a dumb analog phone, which constitutes the installed base. Historically, telephone companies in different nations have tried hard to ensure that their systems do not interoperate smoothly to protect their market. None the less, or as a result, protocols to interoperate POTS are well developed. The protocols must be constructed over voice, the only common transport over different phone systems. A notable protocol is the operator assisted call. However, as human intervention costs a lot, most POTS support tone dialing capability as a minimal digital communication capability. Note that the complex capabilities of digital phones, which are disappearing, have nothing to do with the installed base and are ignored in this memo. Possible complex capabilities of Internet phones such as multiparty teleconferencing, which are hard to operate over voice, are also ignored in this memo. It should be noted that there are multiparty teleconferencing services already available through POTS, simulation of which over Internet telephony is simple without using a complex Internet protocol. POTS is the installed base worth considering. As it is difficult for a human being to generate or recognize IP packets over POTS with voice or dial tones, protocols that need a complex exchange of IP packets should be considered seriously only after we don't have to interoperate with POTS. It is assumed that the operating system supports the notion of a connected UDP socket [UNIX]. While there are some protocol to partition a telephone device into a media gateway and a call agent (or a media controller), it is an obvious violation of the end to end architectural principle of the Internet. With NOTASIP, a telephone device or a telephone exchanger is an end system, a usual Internet host, with its own policy and control mechanism within it. 2. Caller Initiates the Call The caller's host somehow (for example, through URL in callee's Web OHTA & FUJIKAWA Expires on 12 April 2002 [Page 2] INTERNET DRAFT NOTASIP October 2001 page, as shown in Appendix A) finds the callee's IP address, UDP port number (with default port number of ) and desired encoding. The caller's host opens a UDP socket and starts sending properly encoded UDP packets of voice. 3. Callee Accepts the Call The callee's host receives a UDP packet from someone, and it opens a new connected UDP socket to the callers UDP port using a new source port number (chosen randomly) and the same IP address as the destination address of caller's packet. The callee's host, then, start ringing the phone to notify the existence of a call to the callee. The ring back tone should be sent to the caller. If the callee's host do not want to accept a simultaneous call, it may suspend the UDP port used to accept the call. Then, if the port is already connected to someone else, an ICMP port unreachable is returned, which makes the caller's host generate a busy tone to the caller. 4. Connection Established If the callee takes his phone off hook, the callee's host should send the voice of the callee to the caller's host. The caller host receives a first packet and, confirming the source IP address of the packet is callee host's, connects its UDP port to the callee's sending port and the connection is established at the caller. Then, the connection is established at the callee, if the callee receives a packet at the new socket. It should be noted that the connection is established immediately after a three way exchange of packets between the caller and the callee, even if there are some packet losses. 5. Call Termination To terminate the call, the caller's or callee's host closes the socket. The same port number should not be used again until 256 (maximum IPv4 OHTA & FUJIKAWA Expires on 12 April 2002 [Page 3] INTERNET DRAFT NOTASIP October 2001 TTL) + 30 seconds passes. 6. Interoperation with PSTN Interoperation with PSTN is performed over voice, the only common transport, with operator assistance, dial tone or anything. The exact protocol over the voice on natural language to/from telephone operators or on DTMF to/from server computers is service provider dependent and inappropriate for standardization. 7. Error Conditions If the connected UDP socket cannot be created or the socket generates an error of ICMP port or protocol unreachable, the call terminates. ICMP host or network unreachable should be ignored as a soft error. If the callee's host receives a UDP packet on a well known UDP port from someone other than the callee's host or from the callee's host with source UDP port different from the original, it should be processed as a request of new connection. If the callee's host receives a UDP packet on a new UDP port from someone other than the callee or from the callee with source UDP port different from the original, it should be ignored. If the caller's host receives a UDP packet from someone other than the callee, it should be ignored. If the caller's host receives a UDP packet from the callee's host with a source UDP port different from the original before a connection is established, it is a normal case to establish the connection. If the caller's host receives a UDP packet from the callee's host with a source UDP port different from the original after the connection is established, it should be ignored. If there is no valid packets received on a port for 30 seconds, the call terminates. 8. Portability and Mobility We discussed the way to call stationary hosts, in other words, hosts that do not support portability or mobility in the above. Now we will show how to call a particular host independent of its location OHTA & FUJIKAWA Expires on 12 April 2002 [Page 4] INTERNET DRAFT NOTASIP October 2001 and how to call the host that a called user specifies to receive a call. According to the terminology of the IP mobility WG, portability means limited mobility that allows the relocation of hosts that destroys existing connections. Among several methods described in this section, only IP mobility allows the real mobility to allow relocation of hosts with all of the connections kept alive. That is, IP mobility, though not so popular today, is the way to go. The following discussions show that there is no need to develop new protocols for portability and mobility in Internet telephony. 8.1. IP Mobility IP mobility[RFC2002], which provides mobility on the L3 level, simply implements mobility in Internet telephony. The mobility in IP mobility enables a host to use the same IP address wherever it is located. Of course, a host can also use the same IP address location- independently when the lower layer, i.e. L2, provides mobility (e.g. dial-up PPP using mobile phones). In this case, Internet telephony mobility can be easily achieved, although this may cost more. 8.2. DNS Update Generally, a caller specifies a callee not by the callee's direct IP address but by the callee's DNS name, in or not in a URL. DNS dynamic update[RFC2136, RFC2137] attains the portability, though not all name servers support it. 8.3. Web Update A user comes to know the callee's URL by looking at the callee's Web. Thus, dynamic updates of URLs in the calle's Web lead to portability in Internet telephony. CGI or Java is sufficient, so nothing is required to be standardized. 8.4. Forwarder A forwarder runs on the host on which a user usually receives calls and forwards packets to another host statically specified by the user. (placing a file like ".forward" in his/her home directory). The forwarder applications can be written in a 10-to-20 line C program. Standardization is not required here either. OHTA & FUJIKAWA Expires on 12 April 2002 [Page 5] INTERNET DRAFT NOTASIP October 2001 9. References [RFC2022] Perkins C., ``IP Mobility Support,'' RFC 2022, October 1996. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and Bound, J., ``Dynamic Updates in the Domain Name System (DNS UPDATE),'' RFC 2136, April 1997. [RFC2137] Eastlake, D., ``Secure Domain Name System Dynamic Update,'' RFC 2137, April 1997. [UNIX] See UNIX manuals. [IPHONE] FUJIKAWA K., and OHTA M., ``IPhone URL,'' Internet Draft draft-fujikawa-iphone-url-01.txt (work in progress), October 2001. [DIR] KITAGAWA T., and FUJIKAWA K., ``Simple Directory Server for IP Telephony,'' Internet Draft draft-fujikawa-iptel-direc- tory-00.txt (work in progress), October 2001. 10. Security Considerations The security of POTS accounting is often based on 4 digit password or plain credit number and is quite poor. Moreover, it is, in general, impossible to know the phone number of the caller. However these are the accepted security of the phone system. Best effort Internet phone is basically free (except for a flat rate portion) that no serious security consideration is necessary as a phone system. A possible denial of service attack can be based on forged caller source IP address, but is a lot more harmless than a similar attack through POTS with a unknown source telephone number. How a portable/mobile node informs its location of its home in a secure manner is a serious problem in portability/mobility support. Security mechanisms in IP mobility, in DNS update or in Web update help without any modifications in NOTASIP. With a forged source IP address in a request packet of a request- reply protocol, it is possible to use the server of the protcol for denial of service attack, which is unavoidable. However, with OHTA & FUJIKAWA Expires on 12 April 2002 [Page 6] INTERNET DRAFT NOTASIP October 2001 NOTASIP, if a callee's host receives a packet with forged caller's IP address, the callee's host generates a reply stream of UDP packets to the address for 30 seconds, which badly amplifies the effectiveness of denial of service attack. Thus, before the connection is estab- lished and a packet is received to the new UDP port of the callee's host, the callee's host should generate at most one packet in the reply stream for each received packet from the caller. Appendix A. How to Find Callee's Information It is often misunderstood that, after callee's IP address is somehow known, callee's port number and encoding format must be known sepa- rately. However, a mechanism to provide the IP address can often offer the port number and encoding format, too. For example, if a call is initiated from a user browsing a web page, it is convenient if URL like this: iphone://mohta.person.titech.ac.jp:10000/DVI4:8000 is embedded in a callee's home page. [IPHONE] From the URL, not only the IP address, but also the port number and encoding format can be obtained. Thus, protocols to negotiate callee's port number and encoding format with callee's host is not so useful. Such protocols may be used in exceptional situations but should not be an integral part of tele- phone protocols. Just as usual IP applications assume IP addresses or DNS names of the other side of communication are somehow provided, telephone applica- tions should just assume that all the information to initiate calls is somehow provided. Authors' Addresses Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp OHTA & FUJIKAWA Expires on 12 April 2002 [Page 7] INTERNET DRAFT NOTASIP October 2001 Kenji Fujikawa Graduate School of Informatics Kyoto University Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN Phone: +81-75-753-5387 Fax: +81-75-751-0482 EMail: magician@kuis.kyoto-u.ac.jp OHTA & FUJIKAWA Expires on 12 April 2002 [Page 8]