[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                           HF Zhu
INTERNET-DRAFT                                                UTAustin
Expire in six months                                      October, 1997

               DNS and URL Level Addressing for
           Public Circuit-Switching Network Devices

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.  Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time.  It is
not appropriate to use Internet Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet


Recently there are a number of efforts [sw1, sw2, in,tpc, etc.] of trying to
connect the packet-switching network with circuit-switching network, especially
connecting the Internet with public telephone networks.  The first problem
of such interconnection is naming and addressing, later will come with
directory services and routing problems.  This draft concentrates on
naming for DNS and URL.  Other problems are discussed in other documents
[utrpt, framework].

1. Requirements

   Requirements are as specified in [RFC2119].

2. DNS and URL Naming

2.1 Introduction

   New Internet top domains for naming devices of public circuit switching
networks are proposed here.  For example: for a telephone number 471-1234
in Austin (area code 512) in US (country code +1), we use
4711234.512.1.tel as its name, or even more advanced like this:
4711234.austin.us.tel, which is not always one-to-one mapping.  To reach
an extension, one or many "p" as defined in [urltel1] which stands for
pausing one or more second after dialing the number can be used.  For instance,
234pp4711234.512.1.tel stands for dialing +1-512-4711234 and wait for two
seconds (two "p") and connect to extension 234.  A dot can also be added
between the phone number and the extension number such as

   For fax, the top domain of .fax is proposed to use.  The name for a fax
number of 471-5555 in Austin of US can be 4715555.512.1.fax, or
4715555.austin.us.fax, which is actually the same port for

   Since the mapping of DNS to IP is many-to-many, this scheme is valid
with current DNS conventions.  Similar rules can be applied to other
devices, such as xxx.isdn, etc..

HF Zhu                                                       [Page 1]

Internet-Draft       DNS and URL Addressing for PTSN        Oct, 1997

   URL can be achieved via the above DNS naming.  For example:
SIP://4711234.512.1.tel .

   This naming can also facilitate the voice mail or fax_via_email, for
example: someone@4711234.512.1.tel .

2.2 Formal Syntax

   Name := [ extension 1* extsymbol ] local_number "." area "." country
           "." device_domain

   device_domain := "tel" | "fax" | .... etc.

   country := country_code | country_domainname

   area    := area_code | area_name

   local_number := 1*phonedigit

   extension    := 1*phonedigit

   phonedigit   := dtmf_digit | digit

   digit        := "0" | "1" | "2" | "3" | "4" | "5" |
                   "6" | "7" | "8" | "9"

   dtmf-digit   := "*" | "#" | "A" | "B" | "C" | "D"

   extsymbol    := "p" | others .. ?

    Note: can be further refined or enhanced with some other functions.

3. Address Lookup

   The SRV DNS [rfc2052] can be used to support looking for a server on
which a new protocol is running to provide information on interconnection
services or even general integration services.  We call these servers
 "Interconnection Information Server", or "Integration Information
Server" (or Info. Server, in short).  The information include
the "connection points" (can be a Web server or gateway/router) between
Internet and Public Telephone Switching Network, together with the
information about services on those points (e.g. service types, price,
local QoS, etc.).  Actually the SRV DNS is just one of the five methods
used in SIP (Session Initiation Protocol) [sip] to look up a server.
All these five methods can be used to look up Info Servers.  It is easy
to deploy these DNS services as the domains we use here are new domains.

   A list of Info servers for the same domain are available for
fault-tolerance (such as primary, secondary, etc.).  They provide a list
of connection points to the PTSN (or even general public circuit switching
networks offerred by some connection providers  for a specific tel/fax
number or a group of tel/fax numbers. The list should also contain
some neccessary information such as the price and services, etc..
These connection points can be many forms, such as Web servers, or
high-performance gateways/routers to facilitate large traffic.

   The query between a host and a Info Server can be done by a simple
protocol, or appropriate existing directory service protocols.  The NIC of
each level under .tel and .fax domain must be responsible for the
correctness of the information stored in these Info Servers.

HF Zhu                                                      [Page 2]

Internet-Draft   DNS and URL Addressing for PTSN             Oct,1997

  The protocol should be as simple as possible to improve performance
(when using dynamic connection points decision and routing, refer to [2]).
It can be designed based on TCP and UDP, like SIP.  The protocol should also
provide a mechanism to exchange information among them and keep them

  Therefore, an extension of SIP may be used for the above purpose.
This should be discussed in the MMUSIC Working Group of IETF to see if it
is needed to design a new protocol.

  Other directory services on the Internet such as LDAP [ldap], or those
directory services discussed in the IDS (Integrated Directory Service) WG
of IETF.  However, basically, over-complicated directory services are not
necessary and may add burden to the client and reduce the performance.

4. Security Consideration

  Security is important to ensure the Info Server store the correct
information for each connection providers.

5. Author's Address

   Haifeng Zhu
   Electrical & Computer Engineering Department
   The University of Texas at Austin
   Austin, TX 78712-1084

   Email: zhf@ece.utexas.edu
   Tel: +1-512-475-6875
   Fax: +1-512-232-1739

6. References

Some of the authors names will be added as soon as I find them. Sorry.

[utrpt] Haifeng Zhu, "Interconnecting Internet and Public Circuit-Switching
Networks: Architecture and Technology", Research Report CS97395T, The
University of Texas at Austin, 1997

[framework] Haifeng Zhu, "Framework for Interconnecting Internet and Public
Circuit-Switching Network", Internet-Draft, "Work in progress", 1997

[urltel1] A. Vaha-Sipila, URLs for Telephony,
draft-antti-telephony-url-01.txt, Sep. 19, 1997

[sip] MMUSIC WG of IETF, Handley, Schulzrinne, Schooler, SIP: Session
Initiation Protocol, draft-ietf-mmusic-sdp-04.ps, 2nd Sept, 1997

[sw1] I. Faynberg, M. Krishnaswamy, H. Lu, A Proposal for Internet and
Public Switched Telephone Networks Internetworking, draft-faynberg-
telephone-sw-net-00.txt, March, 1997

[sw2] M. Krishnaswamy, H. Lu, Information Exchange to Be Supported by
the Service Suppport Transfer Protocol (SSTP), draft-krishna-telephone-sw-

[in] L. Conroy, M. Lautenbacher, R. Scholl, Analysis of Services and Interfaces
used when Interworking Between the Internet and the Intelligent Network (I.N.),

[h323] International Telecommunication Union, Packet Based Multimedia Communi-
cations Systems, ITU-T H.323

[rfc2119] S. Bradner, Key words for use in RFCs to Indicate Requirement
Levels, RFC 2119, March, 1997

HF Zhu                                                     [Page 3]

Internet-Draft   DNS and URL Addressing for PTSN           Oct, 1997

[tpc] RFC 1530-1569, RFC 1703, TPC.INT experiments

[qosroute] Eric Crawley, Raj Nair, Bala Rajagopalan, Hal Sandick, "A Framework
for QoS-based Routing in the Internet", draft-ietf-qosr-framework-01.txt

[ldap] RFC 1777, RFC 1778, and a draft version 3 proposal.

HF Zhu                                                     [Page 4]