INTERNET DRAFT Shan Lu draft-lu-telurl-wildcard-00.txt sentitO Networks November 28, 2001 Expires: May 28, 2002 Extensions to Tel URLs to Support PSTN Gateway Registration Using SIP 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document proposes two extensions to the telephone URL scheme. With these extensions, phone numbers starting with a given prefix or spanning a given range can be represented. Their applications in SIP- PSTN gateway and large SIP endpoint registrations are also discussed. Shan Lu [Page 1] Internet Draft Tel URL Wildcard November 28 2001 1. Introduction RFC2806 [1] defines URLs for telephone, fax, or modem calls. The location of a terminal with a specific phone number can be represented by a "tel", "fax", or "modem" URL scheme. In practice, however, there also exists a need to represent an endpoint that possesses or services a cluster of phone numbers. An example is a PSTN gateway that can terminate phone numbers starting with a certain pattern (e.g., NPA- NXX). Another example is an access device on which a range of consecutive phone numbers has been configured. In both cases, it will be useful to be able to identify such endpoints without references to a particular phone number. In this document, we propose two new extensions to the "tel" and "fax" URL schemes to support the capability to specify a group of phone numbers. Sections 2 and 3 define the extensions. Sections 4 and 5 provide some examples and their applications for SIP registration. Discussions and relationship to other solutions are given in Section 6. 2. Extensions to "tel" URL Scheme Two new fields are proposed for "future-extension" in [1]: global-phone-number = "+" base-phone-number [isdn-subaddress] [post-dial] * (area-specifier | service-provider | phone-number-attribute | ; new extension phone-number-range | ; new extension future-extension) local-phone-number = 1*(phonedigit | dtmf-digit | pause-character) [isdn-subaddress] [post-dial] area-specifier * (area-specifier | service-provider | phone-number-attribute | ; new extension phone-number-range | ; new extension future-extension) phone-number-attribute = ";" number-attribute-tag "=" number-attribute-ident number-attribute-tag = "number-attribute" number-attribute-ident = ("prefix" | "range" | other-number-attribute) phone-number-range = ";" number-range-tag "=" number-range-value number-range-tag = "number-range" number-range-value = 1*DIGIT phone-number-attribute can appear at most once. "prefix" indicates that the URL represents all phone numbers that may be formed by appending one or more digits to the number specified immediately after "tel:". "range" indicates that the URL represents a group of consecutive phone Shan Lu [Page 2] Internet Draft Tel URL Wildcard November 28 2001 numbers whose numerical values are at least that of the number specified immediately after "tel:" and that the size of the group is specified by number-range-value in phone-number-range. This implies that phone-number-range can also appear at most once and can only appear when phone-number-attribute appears and indicates "range". Although it is not prohibited, the use of phone-number-attribute and phone-number-range in the presence of isdn-subaddress, post-dial, or dtmf-digit is ambiguous and therefore is discouraged. 3. Extensions to "fax" URL Scheme Two new fields are proposed for "future-extension" in [1]: fax-global-phone = "+" base-phone-number [isdn-subaddress] [t33-subaddress] [post-dial] * (area-specifier | service-provider | phone-number-attribute | ; new extension phone-number-range | ; new extension future-extension) fax-local-phone = 1*(phonedigit | dtmf-digit | pause-character) [isdn-subaddress] [t33-subaddress] [post-dial] area-specifier * (area-specifier | service-provider | phone-number-attribute | ; new extension phone-number-range | ; new extension future-extension) phone-number-attribute = ";" number-attribute-tag "=" number-attribute-ident number-attribute-tag = "number-attribute" number-attribute-ident = ("prefix" | "range" | other-number-attribute) phone-number-range = ";" number-range-tag "=" number-range-value number-range-tag = "number-range" number-range-value = 1*DIGIT The meaning of the proposed components is the same as discussed in Section 2. 4. Examples tel: +1-301-947; number-attribute=prefix represents all phone numbers whose digit string starts with "+1-301- 947", for example, +1-301-947-1234. Note that the maximum length of the phone number is not specified by this URL, but rather is imposed by local policy. Shan Lu [Page 3] Internet Draft Tel URL Wildcard November 28 2001 fax: +1-301-947-1001;number-attribute=range;number-range=24 represents the following fax numbers +1-301-947-1001, +1-301-947-1002, +1-301-947-1003, ..., +1-301-947-1024. tel: 301-947;phone-context=+1;number-attribute=prefix can be used to represent all phone numbers in the form of 301-947-xxxx and that the numbers are only usable when dialed in the U.S. Note that while phone-context may be used to indicate an environment where all phone numbers start with a given digit string, however, it by itself can not be used to represent multiple phone numbers. Compare the above example with tel: 301-947-1234;phone-context=+1 which points to a specific number (301-947-1234) when dialed within the U.S. 5. Applications One application of the proposed extensions is for a SIP-PSTN gateway to indicate the PSTN numbers it can terminate when it registers with a SIP registrar. REGISTER sip:registrar.company.com SIP/2.0 To: tel: 301-947;phone-context=+1;number-attribute=prefix Contact: sip: gateway.company.com can be used to register a PSTN gateway which can dial any PSTN number in the form of 301-947-xxxx when used in the U.S. Then, a SIP proxy that is aware of this registration may route a call for 301-947-5678 to this gateway using the following Request URI: sip: 301-947-5678;phone-context=+1@gateway.company.com;user=phone. Note that without the proposed extensions, it is impossible in SIP to register a PSTN gateway in this fashion. Another example is to register multiple SIP UAs in a single SIP REGISTER message. REGISTER sip:registrar.company.com SIP/2.0 To: tel: 222-1001;phone-context=222;number-attribute=range;number- range=48 Contact: sip: device.company.com can be used to register an access device with two T1 capability (48 Shan Lu [Page 4] Internet Draft Tel URL Wildcard November 28 2001 ports) and the ports are configured with numbers from 222-1001, 222- 1002, ..., to 222-1048. After the registration, a SIP proxy may route a call for 222-1040 to this access device using the following Request URI: sip: 222-1040;phone-context=222@device.company.com;user=phone. Note that only one SIP REGISTER message is needed when the proposed extensions are used as opposed to 48 without them. 6. Discussion We proposed two new extensions to the telephone URL scheme in this document. With these extensions, a SIP-PSTN gateway may register itself through the SIP REGISTER method and identify the set of PSTN phone numbers that it can terminate. Based on this information, calls to PSTN can be properly routed. A SIP endpoint that serves a large number of telephone users may also utilize these extensions to reduce the number of registration messages. Section 5 implies that when a SIP proxy performs a location service for an incoming request, the proxy would match the request URI with the "address of record" URI in its location database using the "longest match" rule. This is a departure from the "exact match" rule that is commonly used today. However, it is more an implementation issue than a protocol one. [1] and its updates do not mandate how location service is implemented. While these extensions allow a SIP-PSTN gateway to register with any phone number prefix or range, we envision that they are most useful when the prefix is the NPA-NXX of a PSTN end switch that the gateway connects to. In this application, the gateway has media and signalling paths to one or more PSTN end exchanges. In the PSTN, each of these exchanges is identified by one or more NPA-NXX. When the gateway registers with these NPA-NXX's, calls to these PSTN switches will be routed to them through the gateway. Note that when a gateway registers with NPA-NXX, it is not necessarily true that the numbers the gateway dials out to the PSTN (in the form of an ISUP IAM) will be a 10-digit PSTN number. The number of digits dialed is a policy issue local to the gateway. One benefit of registering with NPA-NXX is the ability to support Local Number Portability (LNP) in the IP domain. Note that in the LNP context, each PSTN end switch is represented by a Location Routing Number (LRN), which is usually a 10-digit number formed by appending zeros to the switch's NPA-NXX. When a gateway registers with NPA-NXX, it becomes clear what PSTN switches it can terminate to. Hence when a call to a ported number needs to be routed based on LRN, the appropriate PSTN gateway (and PSTN end switch) can be selected. Shan Lu [Page 5] Internet Draft Tel URL Wildcard November 28 2001 If a registrar does not understand these new extensions when a gateway attempts to register, two things may happen. The registration request may be rejected with 400 Bad Request because the SIP CONTACT header has an empty user name (see Open Issue section below). The gateway would then stop registration with this registrar. This is essentially a harmless situation to the registrar. If, however, the registration is accepted, the registrar would treat the entire REGISTER TO header as a user name and most likely will result in a non-match for any incoming requests. This is also a harmless situation for the registrar. The only possibility for problem is when a SIP user has the same phone number as the prefix contained in the registration request. We would argue that this will be rare in reality and is probably a bad practice to start with. Other proposals [3,4] have been made to address the PSTN gateway registration issue. They take either the IP telephony routing approach or use the service selection mechanism. They cover areas of load balancing, failure detection, and discovery in addition to gateway registration. As a result, the solutions are based on non-SIP protocols. As a comparison, the proposed solution in this document only addresses PSTN gateway registration and specifically a gateway's capability to terminate a set of phone numbers. The biggest advantage is simplicity: only minor extensions within the SIP registration context are needed. For more complicated applications such as load balancing and high reliability, other approaches may still be used. It is our belief that while sophisticated routing-based solutions are warranted in some environment, a simple gateway registration solution exclusively based on SIP may be highly desirable for other applications. For example, the gateway itself may have built-in solutions for reliability and load sharing across different interfaces. Such a gateway should not be penalized with the burden of non-SIP protocols for the simple task of registering itself with a SIP registrar. 7. Open Issue When the proposed extensions are used for SIP registration, the CONTACT header in the SIP REGISTER message does not have a user name. While this is permitted in the SIP grammar of the CONTACT header, it is nonetheless invalid when used as a SIP request-uri in a SIP INVITE. A SIP rule is needed to allow this type of SIP CONTACT header and to specify that the user portion will be added based on the incoming SIP request for which a user location service is being performed. The intention is that a separate document will be needed to address impacts of the proposed extensions on SIP registration. It will cover the CONTACT header format, the request URI match rule, and any other issues that might be identified. Shan Lu [Page 6] Internet Draft Tel URL Wildcard November 28 2001 8. Security Considerations It is strongly recommended that registrations based on these extensions be authenticated by the registrar. The gateways should also authenticate any requests for services to the PSTN side. 9. Author's Address Shan Lu sentitO Networks 2096 Gaither Road, Suite 100 Rockville, MD 20850 USA Phone: +1-301-947-1900 Email: shanlu@sentito.com 10. References [1] A. Vaha-Sipila, "URLs for telephone calls", RFC2806, April, 2000. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol", RFC2543, March, 1999. [3] W. Zhao and H. Schulzrinne, "Locating internet telephony gateways via SLP", Internet-Draft, September, 2001. [4] J. Rosenberg and H. Salama, "Usage of TRIP in gateways for exporting phone routes", Internet-Draft, July, 2001. 11. Full Copyright Statement Copyright (c) The Internet Society (2001). 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 implementation 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. Shan Lu [Page 7] Internet Draft Tel URL Wildcard November 28 2001 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. Shan Lu [Page 8]