idnits 2.17.1 draft-campbell-sip-e164-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 74: '...ble numbers. A user agent MUST NOT use...' RFC 2119 keyword, line 76: '... agent MAY use other domains for the...' RFC 2119 keyword, line 87: '...E.164 number, it SHOULD make a DNS que...' RFC 2119 keyword, line 88: '...of a tel URL. It SHOULD NOT use a DNS ...' RFC 2119 keyword, line 91: '... a local outbound proxy SHOULD not use...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A UAC that is configured to use a local outbound proxy SHOULD not use enum. It should instead delegate that responsibility to the proxy. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2806 (ref. '4') (Obsoleted by RFC 3966) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft Ben Campbell 4 draft-campbell-sip-e164-00.txt dynamicsoft 5 November 13, 2000 Expires: May 2001 7 E.164 Resolution in SIP 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes how SIP may use the DNS to resolve services 33 associated with E.164 numbers, as specified in [1] 35 Introduction 37 There are several situations where a SIP User Agent [2] must resolve 38 a destination for a telephone number. For example, a user might 39 specify a tel URL [4]. Commonly a UA would resolve such a number by 40 sending an INVITE to another pre-provisioned network element, which 41 presumably knows what to do with it. 43 [1] describes a method of using DNS NAPTR[3] records to resolve 44 resources that are associated with an E.164 number. There are several 45 situations where this approach can be advantageous for a SIP UA. 47 Terminology 49 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 50 in this document are to be interpreted as described in RFC2119. 52 Scope of Document 54 This document describes when a SIP user agent should use the method 55 described in [1] to resolve E.164 telephone numbers. It does not 56 describe the actual details of telephone number resolution, since 57 they are well defined in [1]. Neither does it describe the 58 provisioning of the telephone numbers in DNS in the first place. 60 E.164 Telephone Number usage in SIP 62 Telephone numbers are commonly specified in SIP either through the 63 use of a tel URL, or through the use of a SIP URL with a user 64 parameter that has a value of "phone." For example: 66 tel:+1234567890 67 sip:+1234567890@example.com;user=phone 69 Both examples describe a globally-scoped telephone number (i.e. E.164 70 number). 72 An important aspect of an E.164 number is that it is globally 73 addressable. [1] specifies the use of the DNS domain of "e164.arpa" 74 for globally addressable numbers. A user agent MUST NOT use 75 "e164.arpa" to resolve a locally scoped telephone number. The user 76 agent MAY use other domains for the resolution of numbers in a local 77 or private dial plan. [1] states that a prefix of "+" before the 78 digit string designates the number as globally addressable. 80 User Agent Client 82 A UAC may need to send a request to a resource associated with a 83 telephone number. It may need to start a new call to the resource, or 84 it may have received the number as a contact in an existing call leg. 86 When a UAC needs to send a request to a resource associated with an 87 E.164 number, it SHOULD make a DNS query to resolve the number if it 88 was presented in the form of a tel URL. It SHOULD NOT use a DNS query 89 to resolve a number that was presented as part of a SIP URL. 91 A UAC that is configured to use a local outbound proxy SHOULD not use 92 enum. It should instead delegate that responsibility to the proxy. 94 It is tempting to say that the tel URL and SIP URL in the examples 95 refer to the same phone number, therefore should both be resolved 96 using DNS. However, the SIP URL also contains a host part. In this 97 case, the request destination should be the host pointed to by the 98 host part of the URI. The decision of how to handle the telephone 99 number should be delegated to the destination device. 101 Proxy 103 When a proxy receives a request with an E.164 number in the 104 requestURI, it MAY use DNS to resolve the number, depending on local 105 policy. In this case, a proxy MAY use DNS to resolve an E.164 number 106 contained in a SIP URL, if the domain part of the URL is owned by the 107 proxy. 109 For example, a proxy or redirect server might choose to use DNS to 110 find associated resources for all requests with an e.164 number in 111 the requestURI, or it might choose to check with a location 112 services first, and use DNS only when the location service had no 113 contacts associated with the requestURI. 115 PSTN Gateway 117 A PSTN to SIP gateway MAY use DNS to find resources associated to 118 which an incoming PSTN call should be routed, only if it can 119 construct an e.164 number from dialed digits. Alternately, the 120 gateway might refer the call to a proxy or redirect server by sending 121 an INVITE request with the e.164 number in the requestURI. A gateway 122 MUST NOT use the "e164.arpa" domain to resolve a non e.164 number. It 123 MAY use other domains to resolve non-e.164 numbers. 125 A gateway might be able to construct the e.164 number from the 126 dialed number in the case of a DID call, or from a post-dial digit 127 string, or through some other method. However, it is not 128 appropriate to use the "e164.arpa" domain to resolve resources for 129 a locally scoped number, or number from a private dial plan. A 130 gateway may use internal domains for that purpose. 132 DNS Query results 134 [1] specifies that the NAPTR RR service field specifies the 135 resolution protocol and resolution service. For sip and tel URIs, the 136 service field SHOULD be "sip+E2U" and "tel+E2U" respectively 138 The resulting URI SHOULD be resolved according to the normal SIP 139 address resolution rules. A SIP application SHOULD ignore a resulting 140 URI if the service field does not contain a service it understands. 141 Since the only schema that are universally understood by SIP user 142 agents are "sip" and "tel", only URIs with service fields of 143 "sip+E2U" and "tel+E2U" should be present in DNS for the purpose of 144 being used by a SIP UA. 146 The application SHOULD handle the NAPTR order and preference fields 147 as specified in [1]. 149 The final result of the ENUM resolution SHOULD be treated the same as 150 the results from any other location service, that is, it should 151 appear in the requestURI of the resulting SIP request. If the result 152 is an E.164 number, the application SHOULD attempt to resolve the new 153 number using DNS. If the result included no records that the 154 application can use, the application MAY attempt to resolve the 155 number using local methods. 157 Application Examples 159 The following are some examples of applications that could be 160 facilitated using DNS resolution of resources associated with e.164 161 telephone numbers. 163 E.164 Number as a Universal Identifier 165 Using DNS to resolve resources associated with telephone numbers 166 would allow the same number to be used whether reaching a user via 167 the PSTN or over the Internet. For example, a users telephone number 168 could be used as a key to determine a SIP URL, Mailto URL, or other 169 identifiers. The user's business card would only need the one number 170 instead of the common series of URLs and addresses common today. 172 The author does not propose that a telephone number is a good 173 choice for a universal identifier. In fact, a number is fairly 174 non-mnemonic as identifiers go. This example is intended as an 175 example only, and is in no way prescriptive. 177 Egress Gateway Location 179 Associating resources with a number in DNS allows SIP to PSTN gateway 180 selection to be determined by the owner of the number, instead of the 181 originator of a call. This could be accomplished by associating the 182 e.164 number with a SIP URL that pointed to the gateway or gateways 183 of choice. 185 Ingress Gateway Call Routing 187 A PSTN to SIP gateway (or an associated proxy) could determine the 188 ultimate destination for an inbound call by querying DNS and 189 presenting an e.164 number constructed from the called number or a 190 post-dial string. This approach does not require the gateway to have 191 any prior knowledge of the number in order to route the call. 193 Open Issues 194 Should this draft go into more detail on how an application should 195 interpret the resulting NAPTR RRs, specifically concerning the order 196 and preference fields? This is specified in [1], but it might improve 197 clarity to restate it here. 199 Security Considerations 201 This document suggests using the Domain Name Service to resolve 202 telephone numbers, and is therefore subject to the same security 203 issues as DNS. 205 Acknowledgements 207 The author would like to thank the following for their discussion or 208 other contribution to this draft: 209 Robert Sparks 210 Steve Donovan 211 Jonathan Rosenburg 212 Dean Willis 214 References 216 [1] P. Faltstrom, "E.164 number and DNS", Internet Draft, Internet Engineering Task Force, 218 August 2, 2000. Work in progress. 220 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 221 Session Initiation Protocol," Request for Comments (Proposed 222 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 224 [3] Mealling, M and R Daniel, "The Naming Authority Pointer (NAPTR) 225 DNS Resource Record", (work in 226 progress), June 1998. 228 [4] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 229 2000. 231 Author's Address 233 Ben Campbell 234 dynamicsoft 235 5100 Tennyson Parkway 236 Suite 1200 237 Plano, Texas 75024 238 USA 239 email: bcampbell@dynamicsoft.com