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