idnits 2.17.1 draft-ohta-notasip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '...is service provider dependent and MUST...' RFC 2119 keyword, line 123: '...andardized. IETF MUST NOT define a sta...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 August 1998) is 9388 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'UNIX' on line 192 looks like a reference -- Missing reference section? 'RFC2327' on line 194 looks like a reference -- Missing reference section? 'SDPURL' on line 197 looks like a reference -- Missing reference section? 'RFC2002' on line 160 looks like a reference -- Missing reference section? 'RFC2136' on line 202 looks like a reference -- Missing reference section? 'RFC2137' on line 206 looks like a reference -- Missing reference section? 'RFC2022' on line 200 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT OHTA Masataka 3 draft-ohta-notasip-02.txt Tokyo Institute of Technology 4 FUJIKAWA Kenji 5 Kyoto University 6 7 August 1998 8 Nothing Other Than A Simple Internet Phone (NOTASIP) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This memo describes a simple protocol for Internet phone without QoS 31 guarantee. 33 1. The Architectural Principle of the Internet Phone 35 Fortunately enough, Internet is the install base of data 36 communication that other network technologies must find someway to 37 interoperate with the Internet to survive a little longer. 39 However, in the world of phone communication today, POTS is the 40 install base. For the Internet to replace POTS within a few years, it 41 is important that Internet phone interoperates with POTS. 43 So, the primary requirement to the Internet phone at this early stage 44 is that it should be able to interoperate with a dumb analog phone, 45 which constitutes the install base. 47 Historically, telephone companies in different nations tried hard to 48 make their system not to interoperate smoothly to protect their 49 market. None the less, or as a result, protocols to interoperate POTS 50 is well developed. The protocols must be constructed over voice, the 51 only common transport over different phone systems. A notable 52 protocol is operator assisted call. However, as human intervention 53 costs a lot, most POTS support tone dialing capability for the least 54 digital communication capability. 56 Note that complex capabilities of digital phones, which is 57 disappearing, have nothing to do with the install base and are 58 ignored in this memo. 60 Possible complex capabilities of Internet phone such as multiparty 61 teleconferencing, which is hard to operate over voice, are also 62 ignored in this memo. It should be noted that there is multiparty 63 teleconferencing service already available through POTS, simulation 64 of which over the Internet phone is not difficult without complex 65 Internet protocol. 67 POTS is the install base worth considering. As it is difficult for 68 human being to generate or recognize IP packets over POTS with voice 69 or dial tones, protocols needs complex exchange of IP packets should 70 be considered seriously only after we don't have to interoperate with 71 POTS. 73 It is assumed that the operating system support a notion of connected 74 UDP socket [UNIX]. 76 2. Caller Initiate the Call 78 The caller host somehow (through SDP URL [RFC2327, SDPURL] of 79 callee's Web page, for example) finds the callee's IP address, UDP 80 port number (with default port number of ) 81 and desired encoding. 83 The caller host opens a UDP socket and start sending properly encoded 84 UDP packets of voice. 86 3. Callee Accept the Call 88 The callee host receiving a UDP packet from someone opens a new 89 connected UDP socket to the callers UDP port using a new source port 90 number and the same IP address as the destination address of caller's 91 packet. 93 The callee host, then, start ringing the phone to notify the 94 existence of a call to the callee person. The ringing tone should 95 also be sent to the caller. 97 If the callee host do not want to accept simultaneous call, it may 98 suspend the UDP port used to accept the call. Then, if the port is 99 already connected to someone else, ICMP error packet is returned, 100 which makes the caller host generate a busy signal to the caller 101 person. 103 4. Connection Established 105 If the callee person holds up a headset, the callee host should send 106 the voice of the callee person to the caller host. The caller host 107 receives a first packet and, confirming the source IP address of the 108 packet is callee host's, connects its UDP port to the callee's 109 sending port and the call is established., 111 5. Call Termination 113 To terminate the call, the caller or callee host close the socket. 115 The same port number should not be used again until 256 (maximum IPv4 116 TTL) + 30 seconds passes. 118 6. Interoperation with PSTN 120 Interoperation with PSTN is performed over voice, the only common 121 transport, with operator assistance, dial tone or anything. The 122 exact protocol over the voice is service provider dependent and MUST 123 NOT be standardized. IETF MUST NOT define a standard on natural 124 language messages to/from telephone operators nor calling card 125 syntax. 127 7. Error Conditions 129 If the connected UDP socket can not be created or the socket 130 generates some error, the call terminates. 132 If the caller host receives a UDP packet from someone other than the 133 callee host before the call established, they should be ignored. 135 If there is no packets received to a port for 30 seconds, the call 136 terminates. 138 8. Portability and Mobility 140 We discussed the way to call stationary hosts, in other words, hosts 141 that do not support portability or mobility in the above. Now we 142 will show how to call a particular host independent of its location 143 and how to call the host that a called user specifies to receive a 144 call. 146 According to the terminology of IP mobility WG, portability means 147 limited mobility to allow relocation of hosts which destroys existing 148 connections. 150 Among several methods described in this section, only the IP mobility 151 allows the real mobility to allow relocation of hosts with all the 152 connection kept alive. That is, IP mobility, though not so popular 153 today, is the way to go. 155 The following discussions show that there is no need to develop new 156 protocols for portability and mobility in Internet phone. 158 8.1. IP Mobility 160 IP mobility[RFC2002], which provides mobility on the L3 level, simply 161 implements mobility in Internet phone. The mobility in IP mobility 162 enables a host to use the same IP address wherever it is located. 164 Of course, a host can also use the same IP address location- 165 independently when the lower layer, i.e. L2, provides mobility (e.g. 166 dial-up PPP using mobile phones). In this case, Internet phone 167 mobility can be easily achieved, although this may cost more. 169 8.2. DNS Update 171 Generally, a caller specifies a callee not by callee's direct IP 172 address but by callee's DNS name, in or not in a URL. DNS dynamic 173 update[RFC2136, RFC2137] attains the portability, though not all name 174 servers support it. 176 8.3. Web Update 178 A user comes to know callee's URL by looking at callee's Web. Thus, 179 dynamic update of URLs in Web leads to portability in Internet phone. 180 CGI or Java is sufficient, so nothing is required to be standardized. 182 8.4. Forwarder 184 A forwarder runs on the host on which a user usually receives calls 185 and forwards packets to another host statically specified by the user 186 (placing a file like ".forward" in his/her home directory). The 187 forwarder applications can be written in 10-to-20 lines' C program. 188 Standardization is requested neither. 190 9. References 192 [UNIX] See UNIX manuals. 194 [RFC2327] Handley, M. and Jacobson, V., ``SDP: Session Description Pro- 195 tocol,'' RFC 2327, Nov 1997. 197 [SDPURL] Fujikawa, K. and Kuriya S., ``SDP URL Scheme,'' Internet Draft 198 draft-fujikawa-sdp-url-01.txt (work in progress), July 1998. 200 [RFC2022] Perkins C., ``IP Mobility Support,'' RFC 2022, October 1996. 202 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and Bound, J., ``Dynamic 203 Updates in the Domain Name System (DNS UPDATE),'' RFC 2136, 204 April 1997. 206 [RFC2137] Eastlake, D., ``Secure Domain Name System Dynamic Update,'' 207 RFC 2137, April 1997. 209 10. Security Considerations 211 The security of POTS accounting is often based on 4 digit password or 212 plain credit number and is quite poor. Moreover, it is, in general, 213 impossible to know the phone number of the caller. But these are the 214 accepted security of the phone system. 216 Best effort Internet phone is basically free (except for a flat rate 217 portion) that no serious security consideration is necessary as a 218 phone system. A possible denial of service attack can be based on 219 forged caller source IP address but is a lot more harmless than the 220 similar attack with POTS. 222 How a portable/mobile node informs its location of its home in a 223 secure manner is a serious problem in portability/mobility support. 224 Security mechanisms in IP mobility, in DNS update or in Web update 225 help without any modifications in NOTASIP. 227 Appendix 229 A. SDP URL for Internet Phone 231 Callee's address is written by SDP URL in a format such as: 233 sdp://mohta.person.titech.ac.jp/#m=audio+10000+RTP-AVP+0 235 Note that a user is not forced to input such a long address every 236 time he/she calls up someone. This description is embedded as an 237 anchor in a callee's Web page and a user just clicks this anchor in 238 order to telephone. Besides, a host is able to automatically get and 239 memorize an address by receiving a call. 241 Authors' Addresses 243 OHTA Masataka 244 Computer Center 245 Tokyo Institute of Technology 246 2-12-1, O-okayama, Meguro-ku, Tokyo 152-0033, JAPAN 247 Phone: +81-3-5734-3299 248 Fax: +81-3-5734-3415 249 EMail: mohta@necom830.hpcl.titech.ac.jp 251 FUJIKAWA Kenji 252 Graduate School of Informatics 253 Kyoto University 254 Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN 255 Phone: +81-75-753-5387 256 Fax: +81-75-751-0482 257 EMail: magician@kuis.kyoto-u.ac.jp