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 STATUS OF THIS MEMO 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 ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (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 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. 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 e164.int 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 "order". * 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 tele2.se. ;; ord pr fl service re replacement IN NAPTR 100 10 "s" "h323call+N2R" "" tele2.se. IN NAPTR 102 10 "s" "potscall+N2R" "" tele2.se. IN NAPTR 104 10 "s" "smtp+N2R" "" 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. 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 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" "" tele2.se. IN NAPTR 102 10 "s" "potscall+N2R" "" tele2.se. IN NAPTR 102 10 "s" "smtp+N2R" "" tele2.se. 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 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. 4.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. 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 Tele2/Swipnet Borgarfjordsgatan 16 P.O.BOX 62 162 94 KISTA Sweden Email: paf@swip.net Bjorn Larsson Ericsson Email: etxbmhh@hf.ericsson.se 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 +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" "" 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 NS 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. 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 acme.com (which is known to A). The computer looks up the NAPTR record for acme.com, which holds the following information: acme.com. IN SOA .... IN NS .... IN NAPTR 100 10 "s" "potscall+N2R" "" acme.com. IN NAPTR 100 10 "s" "h323call+N2R" "" acme.com. What we see here is that acme.com 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 "h323.tcp.acme.com" which is as follows: h323.tcp.acme.com. IN SOA .... IN NS .... IN SRV 1 1 1720 h323.acme.com. IN SRV 2 1 1720 h323.telco.net. 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.