Internet Engineering Task Force                      Patrik Faltstrom
Internet Draft                                       Tele2/Swipnet
draft-faltstrom-e164-00.txt                          Bjorn Larsson
June 1998                                            Ericsson
Expires: December 1998

                Where to terminate a phone call


This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute work-
ing 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 mate-
rial 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 (Africa),
(Northern Europe), (Southern Europe),
(Pacific Rim), (US East Coast), or
(US West Coast).

Distribution of this document is unlimited.

1. Abstract

This document discusses the use of DNS [1] 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 message(s) 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 [2], POTS [4] phone call or something else like SMTP.

2. Introduction

The NAPTR [5] and SRV [6] 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.

2.1 Terminology

"Must" or "Shall" - Software that does not behave in the manner that
           this document says it must is not conformant to this
"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

3. 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 domain.

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

3.1 The NAPTR record

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

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

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

 * 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.

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

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

 * 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.

3.1.2 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.

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.

3.1.3 Example of use
;;        ord pr fl  service            re replacement
 IN NAPTR 100 10 "s" "h323call+N2R" ""
 IN NAPTR 102 10 "s" "potscall+N2R" ""
 IN NAPTR 104 10 "s" "smtp+N2R"     ""

This describes that the domain 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.

3.1.4 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 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.

 IN NAPTR 100 10 "s" "h323call+N2R" ""
 IN NAPTR 102 10 "s" "potscall+N2R" ""
 IN NAPTR 102 10 "s" "smtp+N2R"     ""

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

3.2 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 4.x how that is done in detail.

4 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

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

     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).

     The domain this RR refers to.

     Standard DNS meaning.

     Standard DNS meaning.

     As for MX, the priority of this target host.

     Load balancing mechanism.

     The port on this target host of this service.

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

4.1 Example     IN SRV 1 1 1720     IN SRV 1 1 1720     IN SRV 1 1 0         IN SRV 1 1 25

This shows that if the H.323 protocol is used, the host with name should be contacted on port 1720. If POTS is to be used,
the host 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 is to be contacted.

4.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.

5. 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 [7] 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.

6. Authors information

  Patrik Faltstrom
  Borgarfjordsgatan 16
  P.O.BOX 62
  162 94 KISTA


  Bjorn Larsson


7. References

[1]    RFC 1035: Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

       RFC 1034: Mockapetris, P., "Domain names - concepts and
        facilities", STD 13, RFC 1034, November 1987.

[2]    ITU-T Recommendation H.323 (1996), "Visual Telephone Systems and
        Equipment for Local Area Networks which provide a Non-Guaranteed
        Quality of Service".

[3]    ISDN, ITU-T recommendation I.241.1

[4]    POTS, ITU-T recommendation E.105

[5]    RFC 2168: Daniel, R., Mealling, M., "Resolution of Uniform
        Resource Identifiers using the Domain Name System", June 1997.

[6]    RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying
        the location of services (DNS SRV)", October 1996.

[7]    RFC 2065: Eastlake, D., Kaufman, C., "Domain Name System
        Security Extensions", January 1997

Appendix A -- Examples

A.1 Example number 1

Caller (A) uses a phone, connected to the PSTN network, on number

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

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

The phone switch looks up the NAPTR record in DNS for The DNS server for Number Inc. has the
following information in its DNS: IN SOA ....
 IN NS ....
 IN NAPTR 100 10 "s" "potscall+N2R" ""

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 This information is held in
the DNS which Number Inc. runs as follows: IN NS SOA ....
 IN NS ...
 IN SRV 2 1 0
 IN SRV 1 1 0

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.

A.2 Example number 2

Caller (A) uses a computer, connected to the Internet. The computer do
have support for the H.323 protocol.

He want to contact the company ACME Inc, which have the domainname
(which is known to A).

The computer looks up the NAPTR record for, which holds the
following information: IN SOA ....
 IN NS ....
 IN NAPTR 100 10 "s" "potscall+N2R" ""
 IN NAPTR 100 10 "s" "h323call+N2R" ""

What we see here is that can be contacted both via PSTN and via
H.323. A can make the choice of either using some gateway to PSTN that he
has access to, or to run the call using H.323 all the way to the access
point that Acme Inc assigns.

In this example, the user tries to use the H.323 protocol, which means
that A selects to use the NAPTR record "h323call+N2R".

In the next step, the SRV record "" which is as follows: IN SOA ....
 IN NS ....
 IN SRV 1 1 1720
 IN SRV 2 1 1720

As we can see, you should first try to use the H.323 access point at
Acme, and secondly at the H.323 access point at the Telco which Acme seem
to have a contract with.