[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 draft-ietf-enum-e164-dns

     Regards, Patrik

Network Working Group                                        P Faltstrom
Internet-Draft                                                     Tele2
Expires: February 23, 2000                                     B Larsson
                                                        Ericsson Telecom
                                                         August 25, 1999

                           E.164 number and DNS
                        draft-faltstrom-e164-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 23, 2000.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

   This document discusses the use of DNS for identifying available
   services that can be used to contact a phone number. It also, for
   some of these services, discusses how to route the messages to a
   specific destination using the same techniques. Specifically it
   presents a way of implementing portable phone numbers, where the
   services used can be the H.323 protocol, POTS phone call or SMTP.

Faltstrom & Larsson    Expires February 23, 2000                [Page 1]


Internet-Draft            E.164 number and DNS               August 1999

1. Introduction

   The NAPTR and SRV records in DNS can be used for looking up what
   services are available for a specific domainname, and for each one
   of these combinations of destinations and protocols, an ordered list
   of destinations to use. This technology can be used for redirecting
   a phonecall from one phone number to a second one, map a POTS phone
   number to an endnode to use for H.323 services etc. The latter can
   be used when gatewaying a POTS phonecall from the POTS systems to a
   service using the H.323 protocol on top of the IP protocol stack.

   These records in DNS can be looked up by an SCP when it receives a
   SS7 query from the SSP, just like the SCP today can use any
   traditional database service when acting as an IN node in the
   telephony network.

     +---+    +---+    +---+    +-----------+
     |SSP+----+STP+----+SCP+----+IN-Database|
     +---+    +---+    +---+    +-----------+

       SSP - Service Switching Point
       STP - Signal Transfer Point
       SCP - Service Control Point

    Figure 1: SS7 network with traditional IN-Database

   When these records are stored in DNS, the IN service automatically
   gains all the functionality which DNS has, i.e. being a distributed,
   global lookup service.

     +---+    +---+    +---+    +-----------+
     |SSP+----+STP+----+SCP+----+    DNS    |
     +---+    +---+    +---+    +-----------+

    Figure 2: SS7 network with DNS

1.1 Terminology

   "Must" or "Shall" - Software that does not behave in the manner that
      this document says it must is not conformant to this document.

   "Should" - Software that does not follow the behavior that this
      document says it should may still be conformant, but is probably
      broken in some fundamental way.

   "May" - Implementations may or may not provide the described
      behavior, while still remaining conformant to this document.

Faltstrom & Larsson    Expires February 23, 2000                [Page 2]


Internet-Draft            E.164 number and DNS               August 1999

2. Identifying available services

   For a record in DNS, the NAPTR record is used for identifying
   available ways of contacting a specific endnode. Specifically it can
   be used for knowing what services exists for contacting a specific
   domainname, including phone numbers by the use of the e164.int
   domain.

   The identification is using the NAPTR recorce record defined for use
   in the URN resolution process, but it can be generalized in a way
   that suits the needs specified in this document.

2.1 The NAPTR record

   The key fields in the NAPTR RR are order, preference, service,
   flags, regexp, and replacement. For a detailed description, see:

   o  The order field specifies the order in which records MUST be
      processed when multiple NAPTR records are returned in response to
      a single query.

   o  The preference field specifies the order in which records SHOULD
      be processed when multiple NAPTR records have the same value of
      "order".

   o  The service field specifies the resolution protocol and
      resolution service(s) that will be available if the rewrite
      specified by the regexp or replacement fields is applied.

   o  The flags field contains modifiers that affect what happens in
      the next DNS lookup, typically for optimizing the process.

   o  The regexp field is one of two fields used for the rewrite rules,
      and is the core concept of the NAPTR record.

   o  The replacement field is the other field that may be used for the
      rewrite rule.

   Note that the client applies all the substitutions and performs all
   lookups, they are not performed in the DNS servers. Note also that
   it is the belief that regexps should rarely be used. The replacement
   field seems adequate for the vast majority of situations.

2.1.1 Specific use of some fields in the NAPTR record

   The flags must be "s" for the next step in the resolution process
   described in this document. "s" flag means that the next lookup
   should be for SRV records. Other flags are the "a" and the "p"
   flags.

Faltstrom & Larsson    Expires February 23, 2000                [Page 3]


Internet-Draft            E.164 number and DNS               August 1999

   The service supported for a call must be N2R, i.e. the POTS
   terminal, computer terminating the H.323 call etc is to be seen as
   the resource in an NAPTR view.

2.1.2 Example of use

   tele2.se.
   ;;        ord pr fl  service            re replacement
    IN NAPTR 100 10 "s" "h323call+N2R" "" h323call.tcp.tele2.se.
    IN NAPTR 100 10 "s" "h323call+N2R" "" h323call.udp.tele2.se.
    IN NAPTR 102 10 "s" "potscall+N2R" "" potscall.tcp.tele2.se.
    IN NAPTR 104 10 "s" "smtp+N2R"     "" smtp.tcp.tele2.se.

   This describes that the domain tele2.se is preferrable contacted via
   the H.323 protocol with the registered protocol name h323call.
   Secondly POTS, and thirdly SMTP (for voicemail over SMTP).

   In all three cases above, the next step in the resolution process is
   to look up an SRV record to know what node to contact for each
   protocol.

   Note that the terminating address for POTS is the same domainname as
   the H.323 protocol even though the hostname can not be used as an
   endnode address in those protocols. The mapping back to a phone
   number is done in the SRV record later.

   Also note that it is possible to use this method for describing
   other access methods aswell, i.e. the preferred method for
   contacting a domain might be via Email, secondly via POTS.

2.1.3 When the virtual address is a phone number

   When the target address is a phone number, it is first translated
   into a RR name in the e164.int domain. It is done by reversing the
   order of the digits in the phone number and placing dots inbetween,
   to make delegation of series of numbers possible in the DNS.

   Example:

   0.0.0.4.6.2.6.5.8.6.4.e164.int.
    IN NAPTR 100 10 "s" "h323call+N2R" "" h323call.tcp.tele2.se.
    IN NAPTR 100 10 "s" "h323call+N2R" "" h323call.udp.tele2.se.
    IN NAPTR 102 10 "s" "potscall+N2R" "" potscall.tcp.tele2.se.
    IN NAPTR 102 10 "s" "smtp+N2R"     "" smtp.tcp.tele2.se.

   The rest of the resolution of the routing is done as described
   above.

Faltstrom & Larsson    Expires February 23, 2000                [Page 4]


Internet-Draft            E.164 number and DNS               August 1999

2.1.4 The potscall protocol name

   The potscall protocol name is just a placeholder so one knows that
   the protocol to use is POTS. Because the protocol is not run on top
   of IP, the address to use when addressing the endnode has to be a
   phone number. See x.x how that is done in detail.

Faltstrom & Larsson    Expires February 23, 2000                [Page 5]


Internet-Draft            E.164 number and DNS               August 1999

3. What node to contact

   The SRV record is used for identifying what host to contact for a
   given service. Clients ask for a specific service/protocol for a
   specific domain (the word domain is used here in the strict RFC 1034
   sense), and get back the names of any available servers.

   This is applied for each record one is interested in among the ones
   returned when looking up the NAPTR record.

   The format of the SRV record is described in detail in [6], but
   briefly the format is as follows:

     Service.Proto.Name TTL Class SRV Priority Weight Port Target

   Service - The symbolic name of the desired service, as defined in
      Assigned Numbers or locally.

   Proto - TCP and UDP are at present the most useful values for this
      field, though any name defined by Assigned Numbers or locally may
      be used (as for Service).

   Name - The domain this RR refers to.

   TTL - Standard DNS meaning.

   Class - Standard DNS meaning.

   Priority - As for MX, the priority of this target host.

   Weight - Load balancing mechanism.

   Port - The port on this target host of this service.

   Target - As for MX, the domain name of the target host.

3.1 Example

   h323call.tcp.tele2.se.     IN SRV 1 1 1720 h323gw.tele2.se.
   h323call.udp.tele2.se.     IN SRV 1 1 1720 h323gw.tele2.se.
   potscall.tcp.tele2.se.     IN SRV 1 1 0
0.0.0.4.6.2.6.5.8.6.4.e164.int.
   smtp.tcp.tele2.se.         IN SRV 1 1 25   mailgw1.swip.net.

   This shows that if the H.323 protocol is used, the host with name
   h323gw.tele2.se should be contacted on port 1720. If POTS is to be
   used, the host 0.0.0.4.6.2.6.5.8.6.4.e164.int. is to be contacted.
   This in turn means that the address to use as a B-address is
   +46-8-56264000. For SMTP, the host mailgw1.swip.net is to be
   contacted.

Faltstrom & Larsson    Expires February 23, 2000                [Page 6]


Internet-Draft            E.164 number and DNS               August 1999

3.2 Specific rules for POTS and SRV records

   The portnumber have no meaning, and neither has the protocol name.
   The protocol name must be TCP, and the port number must be 0.

   The value of the port number must be ignored by the client.

Faltstrom & Larsson    Expires February 23, 2000                [Page 7]


Internet-Draft            E.164 number and DNS               August 1999

4. Security Considerations

   As this system is built on top of DNS, one can not be sure that the
   information one get back from DNS is more secure than any DNS query.
   To solve that, the use of DNSSEC for securing and verifying zones is
   to be recommended.

   The caching in DNS can also make the propagation time for a change
   take the same amount of time as the time to live for the NAPTR and
   SRV records in the zone that is changed. The TTL should because of
   that be kept to a minimum. The use of this in an environment where
   IP-addresses are for hire (i.e. DHCP) must therefore be done only
   very carefully.

Faltstrom & Larsson    Expires February 23, 2000                [Page 8]


Internet-Draft            E.164 number and DNS               August 1999

References

   [1]  Mockapetris, P, "Domain names - Implementation and
        Specification", RFC 1035, November 1987.

Authors' Addresses

   Patrik Faltstrom
   Tele2
   Borgarfjordsgatan 16
   127 61 Kista
   Sweden

   EMail: paf@swip.net
   URI:   http://www.tele2.se

   Bjorn Larsson
   Ericsson Telecom
   126 25 Stockholm
   Sweden

   EMail: etxbmhh@hf.ericsson.se
   URI:   http://www.ericsson.se

Faltstrom & Larsson    Expires February 23, 2000                [Page 9]


Internet-Draft            E.164 number and DNS               August 1999

Appendix A. Example, E.164 Number Portability

   1.  Caller (A) uses a phone, connected to the PSTN network, on
       number +46-8-7525252. The number is allocated for (A) by Telco
       (Z) which have got the number from the local E.164 coordinator
       (regulator in the country where (Z) is active).

   2.  Callee (B) have a phone, connected to the PSTN network, on
       number +46-346-23232. This number is allocated for (B) by Telco
       (X).

   3.  Caller (B) has though moved his phone from Telco (X) to Telco
       (Y), but wanted to still use the number he got from Telco (X).
       Telco (X) puts in his DNS an NS record as follows:

   2.3.2.3.2.6.4.3.6.4.e164.int. IN NS ns.telcoy.net.

        In this scenario, ns.telcoy.net is the name of the dns server
       which Telco (Y) uses for his IN system. Telco (Y) allocates an
       E.164 number for Caller (B), and this number is +46-8-919191.
       Telco (Y) puts in his DNS the following:

   $ORIGIN 6.4.e164.int.
   potscall.tcp.2.3.2.3.2.6.4.3 IN SRV 10 10 1.9.1.9.1.9.8

   4.  Caller (A) dials the number of caller (B), and the SSP at Telco
       (Z) is sending a query for Global Title Translation to the
       closest SCP using using the TCAP protocol, which is part of SS7
       the signalling protocol.

   5.  The SCP look up the destination number (called-id) in DNS, the
       SRV record, for routing information to a destination. The query
       is for potscall.tcp.2.3.2.3.2.6.4.3.6.4.e164.int. According to
       the DNS delegation / recursion rules, the query will end up at
       the nameserver for Telco (Z), which will return the NS record,
       which refers to the nameserver for Telco (Y).

   6.  The nameserver for Telco (Y) responds with the SRV record above,
       which the SCP interprets as information that a Global Title
       Translation should occur from +46-346-23232 to +46-8-919191.
       That respons is sent back to the SSP.

   7.  The SSP uses "normal" methods with SS7 when allocating trunk
       circuits for the actual phone call to +46-8-919191.

   Note that this algorithm also works even though the DNS doesn't
   include any records at all regarding the phone number queried for.
   The SCP is in this case getting a negative response from DNS, and is
   then translating this into the fact that a Global Title Translation

Faltstrom & Larsson    Expires February 23, 2000               [Page 10]


Internet-Draft            E.164 number and DNS               August 1999

   should not occur.

Faltstrom & Larsson    Expires February 23, 2000               [Page 11]


Internet-Draft            E.164 number and DNS               August 1999

Appendix B. Example Unified Messaging

   Caller (A) uses a phone, connected to the PSTN network, on number
   +46-8-7525252.

   Callee (B) have a two phones, one cellular phone on number
   +46-70-411111, and one ordinary phone connected to the PSTN network
   on number +46-8-7111111.

   Callee want to get reached on the unified message number
   +46-76-11223344.

   On the buissness card, the callee have printed the number
   +46-76-11223344. He buys a telephone number routing service from the
   company Number Inc.

   Caller reads the buissness card, lifts the handle, and punches the
   number +46-76-11223344.

   The phone switch looks up the NAPTR record in DNS for
   4.4.3.3.2.2.1.1.6.7.6.4.e164.int. The DNS server for Number Inc. has
   the following information in its DNS:

   4.4.3.3.2.2.1.1.6.7.6.4.e164.int. IN SOA ....
    IN NS ....
    IN NAPTR 100 10 "s" "potscall+N2R" "" potscall.tcp.a.number.com.

   This shows to the switch that the only way B can be contacted is via
   the PSTN network. As A is also connected to the PSTN network, no
   gateway have to be used.

   In the next step, the switch is figuring out what number on the PSTN
   network to use. This information is fetched by looking up the SRV
   record for the record potscall.tcp.a.number.com. This information is
   held in the DNS which Number Inc. runs as follows:

   potscall.tcp.a.number.com. IN SOA ....
    IN NS ...
    IN SRV 2 1 0    1.1.1.1.1.4.0.7.6.4.e164.int.
    IN SRV 1 1 0    1.1.1.1.1.1.7.8.6.4.e164.int.

   We here see that the B want to be reached if possible on the number
   +46-70-411111, and secondly on the number +46-8-7111111. The switch
   is routing the phonecall to the desired number over the PSTN
   network.

Faltstrom & Larsson    Expires February 23, 2000               [Page 12]


Internet-Draft            E.164 number and DNS               August 1999

Full Copyright Statement

   Copyright (C) The Internet Society (1999). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.

Faltstrom & Larsson    Expires February 23, 2000               [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/