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

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

Network Working Group                                        P Faltstrom
Internet-Draft                                                     Tele2
Expires: March 9, 2000                                         B Larsson
                                                        Ericsson Telecom
                                                       September 9, 1999


                          E.164 number and DNS
                        draft-faltstrom-e164-03.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 March 9, 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, SIP, POTS phone call or
   SMTP.

   Discussion on this Internet-Draft is to be held on the mailing list
   ietf-e164-dns@imc.org, which is hosted by the Internet Mail
   Consortium. To subscribe, send an email to
   ietf-e164-dns-request@imc.org, with the text "subscribe" as the only
   word in the body of the mail. There is an archive of the mailing
   list at <http://www.imc.org/ietf-e164-dns/>.


Faltstrom & Larsson      Expires March 9, 2000                  [Page 1]


Internet-Draft            E.164 number and DNS            September 1999


1. Introduction

   The NAPTR[1] and SRV[2] records in DNS[3] 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, tell
   wether support for SIP exists etc. The case with H.323 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 March 9, 2000                  [Page 2]


Internet-Draft            E.164 number and DNS            September 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 can be "s" or "a" for the next step in the resolution
   process described in this document. "s" flag means that the next
   lookup should be for SRV records, and "a" that the result of the
   rewrite is a URI. Other flags are the "a" and the "p" flags.


Faltstrom & Larsson      Expires March 9, 2000                  [Page 3]


Internet-Draft            E.164 number and DNS            September 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  10 10 "s" "sip+N2R"      "" _sip._tcp.swip.net.
    IN NAPTR 100 10 "s" "h323call+N2R" "" _h323call._tcp.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 SIP protocol, secondly via the H.323 protocols with the
   registered protocol names h323call. Thirdly POTS and last SMTP (for
   VPIM voicemail over SMTP).

   In all 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 and SIP 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:

   2.8.0.4.6.2.6.5.8.6.4.e164.int.
    IN NAPTR  10 10 "a" "sip+N2R"      "" "sip:paf@swip.net".
    IN NAPTR 102 10 "s" "potscall+N2R" "" _potscall._tcp.paf.swip.net.
    IN NAPTR 102 10 "a" "smtp+N2R"     "" "mailto:paf@swip.net".

   Note that the prefered method is to use the SIP protocol, but the
   result of the rewrite of the NAPTR record is a URI (the "a" flag in
   the NAPTR record). In the case of the protocol SIP, the URI should
   be a SIP URI, which is resolved as described in RFC 2543[4].


Faltstrom & Larsson      Expires March 9, 2000                  [Page 4]


Internet-Draft            E.164 number and DNS            September 1999


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

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 March 9, 2000                  [Page 5]


Internet-Draft            E.164 number and DNS            September 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 process might also
   start with the SRV lookup, especially when using a SIP URI as the
   starting point.

   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.
   _sip._tcp.tele2.se.          IN SRV 1 1 5060 sip.tele2.se.
   _sip._udp.tele2.se.          IN SRV 1 1 5060 sip.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. The SIP server for


Faltstrom & Larsson      Expires March 9, 2000                  [Page 6]


Internet-Draft            E.164 number and DNS            September 1999


   the domain tele2.se is accessible as sip.tele2.se on port 5060. 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.

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 March 9, 2000                  [Page 7]


Internet-Draft            E.164 number and DNS            September 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 March 9, 2000                  [Page 8]


Internet-Draft            E.164 number and DNS            September 1999


References

   [1]  Mealling, M and R Daniel, "The Naming Authority Pointer (NAPTR)
        DNS Resource Record", Internet-Draft
        draft-ietf-urn-naptr-rr-03.txt, June 1998.

   [2]  Gulbrandsen, A and R Daniel, "A DNS RR for specifying the
        location of services (DNS SRV)", Internet-Draft
        draft-ietf-urn-naptr-rr-03.txt, June 1998.

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

   [4]  Handley, M, Schulzrinne, H, Schooler, E and J Rosenberg, "SIP:
        Session Initiation Protocol", RFC 2543, March 1999.

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 March 9, 2000                  [Page 9]


Internet-Draft            E.164 number and DNS            September 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 March 9, 2000                 [Page 10]


Internet-Draft            E.164 number and DNS            September 1999


   should not occur.


















































Faltstrom & Larsson      Expires March 9, 2000                 [Page 11]


Internet-Draft            E.164 number and DNS            September 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 SCP 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 March 9, 2000                 [Page 12]


Internet-Draft            E.164 number and DNS            September 1999


Appendix C. Example SIP

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

   Callee (B) is buying a service by provider X, which is telephony
   over the Internet via the use of SIP.

   Callee want to get reached on the message number +46-76-11223344,
   which is in this example supposed to be directed to the correct SIP
   URI.

   On the buissness card, the callee have printed the number
   +46-76-11223344 (and probably the SIP URI
   "sip:foobar@x.example.net".

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

   The SCP 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 "a" "sip+N2R" ""sip:foobar@x.example.net".

   This shows to the switch that the only way B can be contacted is via
   the SIP protocol, using the URI "sip:foobar@x.example.net".

   The resolution of the SIP URI, using SRV records etc, is described
   in appendix D of RFC 2543.


















Faltstrom & Larsson      Expires March 9, 2000                 [Page 13]


Internet-Draft            E.164 number and DNS            September 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 March 9, 2000                 [Page 14]


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