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]