One document matched: draft-ohta-notasip-02.txt

Differences from draft-ohta-notasip-01.txt

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]