INTERNET DRAFT OHTA Masataka draft-ohta-notasip-02.txt Tokyo Institute of Technology FUJIKAWA Kenji Kyoto University 7 August 1998 Nothing Other Than A Simple Internet Phone (NOTASIP) Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes a simple protocol for Internet phone without QoS guarantee. 1. The Architectural Principle of the Internet Phone Fortunately enough, Internet is the install base of data communication that other network technologies must find someway to interoperate with the Internet to survive a little longer. However, in the world of phone communication today, POTS is the install base. For the Internet to replace POTS within a few years, it is important that Internet phone interoperates with POTS. So, the primary requirement to the Internet phone at this early stage is that it should be able to interoperate with a dumb analog phone, which constitutes the install base. OHTA & FUJIKAWA Expires on 6 February 1999 [Page 1]
INTERNET DRAFT NOTASIP August 1998 Historically, telephone companies in different nations tried hard to make their system not to interoperate smoothly to protect their market. None the less, or as a result, protocols to interoperate POTS is well developed. The protocols must be constructed over voice, the only common transport over different phone systems. A notable protocol is operator assisted call. However, as human intervention costs a lot, most POTS support tone dialing capability for the least digital communication capability. Note that complex capabilities of digital phones, which is disappearing, have nothing to do with the install base and are ignored in this memo. Possible complex capabilities of Internet phone such as multiparty teleconferencing, which is hard to operate over voice, are also ignored in this memo. It should be noted that there is multiparty teleconferencing service already available through POTS, simulation of which over the Internet phone is not difficult without complex Internet protocol. POTS is the install base worth considering. As it is difficult for human being to generate or recognize IP packets over POTS with voice or dial tones, protocols needs 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 support a notion of connected UDP socket [UNIX]. 2. Caller Initiate the Call The caller host somehow (through SDP URL [RFC2327, SDPURL] of callee's Web page, for example) finds the callee's IP address, UDP port number (with default port number of <to be assigned by IANA>) and desired encoding. The caller host opens a UDP socket and start sending properly encoded UDP packets of voice. 3. Callee Accept the Call The callee host receiving a UDP packet from someone opens a new connected UDP socket to the callers UDP port using a new source port number and the same IP address as the destination address of caller's packet. OHTA & FUJIKAWA Expires on 6 February 1999 [Page 2]
INTERNET DRAFT NOTASIP August 1998 The callee host, then, start ringing the phone to notify the existence of a call to the callee person. The ringing tone should also be sent to the caller. If the callee host do not want to accept simultaneous call, it may suspend the UDP port used to accept the call. Then, if the port is already connected to someone else, ICMP error packet is returned, which makes the caller host generate a busy signal to the caller person. 4. Connection Established If the callee person holds up a headset, the callee host should send the voice of the callee person to the caller 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 call is established., 5. Call Termination To terminate the call, the caller or callee host close the socket. The same port number should not be used again until 256 (maximum IPv4 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 is service provider dependent and MUST NOT be standardized. IETF MUST NOT define a standard on natural language messages to/from telephone operators nor calling card syntax. 7. Error Conditions If the connected UDP socket can not be created or the socket generates some error, the call terminates. If the caller host receives a UDP packet from someone other than the callee host before the call established, they should be ignored. If there is no packets received to a port for 30 seconds, the call terminates. OHTA & FUJIKAWA Expires on 6 February 1999 [Page 3]
INTERNET DRAFT NOTASIP August 1998 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 and how to call the host that a called user specifies to receive a call. According to the terminology of IP mobility WG, portability means limited mobility to allow relocation of hosts which destroys existing connections. Among several methods described in this section, only the IP mobility allows the real mobility to allow relocation of hosts with all the connection 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 phone. 8.1. IP Mobility IP mobility[RFC2002], which provides mobility on the L3 level, simply implements mobility in Internet phone. 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 phone mobility can be easily achieved, although this may cost more. 8.2. DNS Update Generally, a caller specifies a callee not by callee's direct IP address but by 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 callee's URL by looking at callee's Web. Thus, dynamic update of URLs in Web leads to portability in Internet phone. 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 OHTA & FUJIKAWA Expires on 6 February 1999 [Page 4]
INTERNET DRAFT NOTASIP August 1998 (placing a file like ".forward" in his/her home directory). The forwarder applications can be written in 10-to-20 lines' C program. Standardization is requested neither. 9. References [UNIX] See UNIX manuals. [RFC2327] Handley, M. and Jacobson, V., ``SDP: Session Description Pro- tocol,'' RFC 2327, Nov 1997. [SDPURL] Fujikawa, K. and Kuriya S., ``SDP URL Scheme,'' Internet Draft draft-fujikawa-sdp-url-01.txt (work in progress), July 1998. [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. 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. But 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 the similar attack with POTS. 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. OHTA & FUJIKAWA Expires on 6 February 1999 [Page 5]
INTERNET DRAFT NOTASIP August 1998 Appendix A. SDP URL for Internet Phone Callee's address is written by SDP URL in a format such as: sdp://mohta.person.titech.ac.jp/#m=audio+10000+RTP-AVP+0 Note that a user is not forced to input such a long address every time he/she calls up someone. This description is embedded as an anchor in a callee's Web page and a user just clicks this anchor in order to telephone. Besides, a host is able to automatically get and memorize an address by receiving a call. Authors' Addresses OHTA Masataka Computer Center Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-0033, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.hpcl.titech.ac.jp FUJIKAWA Kenji 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 6 February 1999 [Page 6]