S. Lind Internet Draft AT&T Document: draft-lind-enum-callflows-00.txt July 2000 Category: Informational ENUM Call Flows for VoIP Interworking Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 made obsolete 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. 1. Abstract This document provides illustrations of the use of ENUM functionality and identifies issues associated with such use. To accomplish this objective, the document presents service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a "direct dial" basis. For more complicated calls, requiring number portability or freephone call processing, the issues are described with the intent of working through those issues in subsequent drafts. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Call from the PSTN to a Terminal on an IP-based Network This scenario is illustrated in figure 1. A customer on the PSTN wishes to reach another customer whose terminal ("phone") is connected to an IP-based network. In the illustration, the Lind Information - January 2001 1 ENUM Call Flows for VoIP Interworking July 2000 destination terminal is a SIP client, but other client protocols may be equally applicable. The various steps are denoted in parentheses within the figure and explained below. +--------+ +--------+ (2) +--------+ | | | |---------->| | (3) | POTS |---------->| PSTN | | Gateway| | Phone | (1) | |<.........>| | (5) +--------+ +--------+ +--------+ ^ | ^ : | : (7) : | : : | : +--------+ +--------+ +-:-+-:--+ | | | |<............: | : | | SIP |<----------| SIP | |IP-based| | Client | | Server |<----------+ Network| +--------+ +--------+ +-----:--+ : v +--------+ ---> Voice Path | | (4) ...> Signaling Path | DNS | | | (6) +--------+ Figure 1 Call From PSTN to IP-based Network Step 1 - The originating customer dials an E.164 number. The actual digits dialed depend on the dialing plan in effect at the point of origination. The customer may dial a local number (or intra-NPA within the US), an intercity number (or inter-NPA within the US), or international number. Any dialing prefixes required by the dialing plan must be entered. As an example, John Smith, whose phone number in the US is 908-555- 1234, wants to call Jenny Jones. The number that John Smith has for Jenny, also in the US, is 973-236-6787. John dials "19732366787" (the first digit "1" is a prefix required by the dialing plan and not the country code for the United States). It is worth noting that dialed prefixes are usually dropped at the first switching point within the PSTN. Step 2 - The PSTN Service Provider forwards the call to the appropriate Gateway. Selection of the appropriate Gateway may depend on a number of different factors, including regulatory factors in effect at the point of call origination. The physical location of the Gateway in relation to the point of origination may also depend on several factors including the relationships between the PSTN Service Provider and the ITSP at the point of termination. Lind Information - January 2001 2 ENUM Call Flows for VoIP Interworking July 2000 Within the example, John Smith's local service provider determines that the call is interLATA and forwards it to John's presubscribed interexchange carrier. The IXC may determine that the destination is on an IP-based network and if it has its own gateways, may forward the call to a gateway closest to the call's point of origination. If the IXC does not have its own gateways or cannot determine the type of termination network, it may transport the call to a point closest to the call's point of termination before handing the call to the ITSP as a terminating local service provider. Step 3 - The Gateway looks up the name in DNS. The Gateway at which the call enters the IP-based network must contain any ENUM [3] functionality to transform the dialed digits to an URL. The gateway must supply any missing digits in order to obtain a fully qualified E.164 number as part of the transformation. In the example, the gateway transforms the dialed number into a URL of "7.8.7.6.6.3.2.3.7.9.1.e164.arpa". During the transformation, the country code for the destination is added to the number by the gateway. Step 4 - The DNS returns any service records associated with the URL. In the example, the DNS returns among the records one containing the URI "sip:jennyjones@ip.att.net". Step 5 - The Gateway looks up the URI in DNS. Step 6 - DNS returns the IP address and port of the SIP server for the desired end user. Step 7 - The call is routed through the IP-based network to the designated IP address and port. When the destination party answers, answer supervision must be returned to the originating local switch. 4. Call from a Terminal on an IP-based Network to a phone on the PSTN This scenario is illustrated in figure 2. A customer on an IP-based network wishes to reach another customer whose phone is connected to the PSTN. In the illustration, the originating terminal is a SIP client, but other client protocols may be equally applicable. The various steps are denoted in parentheses within the figure and explained below. Lind Information - January 2001 3 ENUM Call Flows for VoIP Interworking July 2000 +--------+ +--------+ (2,4) +--------+ +--------+ | | (1) | |<........ ........>| LS | (5) | SIP |------->| SIP |--------+IP-based| : +--------+ | Client | | Server |<........ Network| : +--------+ +--------+ +--------+ +--:--+--+ :....>| DNS | (3) : | +--------+ (6) : | v v +--------+ +--------+ +--------+ | | | |<......>| | | POTS |<-------| PSTN | | Gateway| (7) | Phone | | |<-------| | +--------+ +--------+ +--------+ ---> Voice Path ...> Signaling Path Figure 2 Call from IP-based Network to PSTN Step 1 - The originating customer dials an E.164 number. The actual digits dialed depend on the dialing plan in effect at the point of origination. The customer may dial a local number (or intra-NPA within the US), an intercity number (or inter-NPA within the US), or international number. Any dialing prefixes required by the dialing plan must be entered. As an example, Jenny Jones, who has a SIP client and whose "phone number" (as assigned by her ITSP) in the US is 973-236-6787, wants to call John Smith. The number that Jenny has for John, also in the US is 908-555-1234. Jenny dials "19085551234" (the first digit "1" is a prefix required by the dialing plan and not the country code for the United States). Step 2 - The SIP Server looks up the name in DNS. The SIP Server must contain any ENUM functionality to transform the dialed digits to an URL. The SIP Server must supply any missing digits in order to obtain a fully qualified E.164 number as part of the transformation. In the example, the SIP Server transforms the dialed number into a URL of "4.3.2.1.5.5.5.8.0.9.1.e164.arpa". During the transformation, the country code for the destination is added to the number by the gateway. Step 3 - The DNS returns any service records associated with the URL. In the example, the DNS returns, most likely, only one record containing the URI "tel:+19085551234". Step 4 - The SIP Server queries a location server (LS), using one of the Front End Protocols suggested within the TRIP framework [4] and maintained by the user's ITSP, for the IP address of a Gateway for this telephone number. Lind Information - January 2001 4 ENUM Call Flows for VoIP Interworking July 2000 Step 5 - The LS returns the IP address of the appropriate Gateway for the destination number. Step 6 - The SIP Server routes the call to the designated Gateway IP address. Step 7 - The Gateway completes the call through the PSTN to the destination phone. It must respond to any signaling (e.g., ringing, busy) from the PSTN and send the appropriate information back to the call originator. 5. Issues Surrounding the Handling of Freephone Calls In general, the first step in handling a freephone number is to determine, based on the number dialed, who the appropriate service provider is that can process and complete the call. In the case of PSTN-originated calls, that process is in place today and should not be impacted by interworking with IP-based networks. If the designated freephone service provider is an ITSP, then the originating PSTN access provider should route the call to the appropriate Gateway. The freephone service provider would then be responsible for any necessary call processing and final number translation using IN-based (i.e., SS7 signaling to an SCP), IP-based (e.g., ENUM and/or other infrastructure used by the ITSP), or a combination of facilities, as the service provider sees fit. For IP-originated calls, the same general principle holds true. Using the DNS, a query for the freephone number as a URL should return information that identifies the service provider. The call can then be routed to the gateway of that service provider for call processing and termination. Again, the service provider would be able to choose whether that processing used IN-based, IP-based or a combination of facilities. Even if a freephone call originates and terminates on an IP-based network, the ITSP at the point of origination needs only identify the freephone service provider and route the call to the gateway of the provider for whatever processing is deemed necessary. Further work is necessary to define the information that DNS would contain to identify the service provider and how that information might be provisioned and maintained. 6. Issues Surrounding Calls to Ported Numbers For service provider portability [5], three scenarios need to be examined that may impact processing of calls that go between the PSTN and an IP-based network. The first is that a customer may switch between two different PSTN service providers. As an example in the US, a customer might switch between an "incumbent local service provider" and a "competitive local service provider" or vice Lind Information - January 2001 5 ENUM Call Flows for VoIP Interworking July 2000 versa. The second scenario is that a customer may switch between a service provider on the PSTN to an ITSP (or vice versa). The third scenario is that a customer may switch between two different ITSPs. 6.1 Calls originating on the PSTN Calls under the first scenario should be handled already in today's PSTN environment. For the second scenario, there are issues about what gets populated in the LNP database on the PSTN side of the interface to route the call to a Gateway as described in section 3 above. In the US, where Location Routing Numbers (LRNs) is mandated by regulation [6], it might be necessary for Gateways of the ITSP at the destination end to be identified by a LRN. For scenario 3, assuming the call reaches a Gateway, the change should be reflected in a different URI for the destination subscriber in the first DNS lookup. In our example in section 3, step 4, the DNS might contain a different record now containing the URI "sip:jennyjones@sipservice.net". The Gateway would then resolve the URI in a different DNS to obtain the correct IP address and port for the new SIP server. 6.2 Calls originating on an IP-based network It appears that, under scenario 1, the primary impact would be that the gateway for a given number might change or the gateway would need to determine that the terminating PSTN service provider has changed. The DNS might need to contain the LRN for the new termination point. The LS would have to be responsive to point to the new Gateway, if appropriate, for that destination number. The Gateway, if the LRN was not available from the DNS, may have to perform additional LNP queries on an IN-basis. If such queries are not performed at or somewhere upstream from the Gateway, the call may be routed to the wrong service provider or the ITSP may be charged for the necessary LNP queries performed on its behalf. Under scenario 2, it would appear that the change would occur within the DNS in that instead of returning a "tel:"-based URI, the DNS might now return a URI pointing to a SIP or H.323 terminal. Under scenario 3, the call would not terminate on the PSTN and the DNS would simply point to a different URI similar to the change described in section 6.1 for scenario 3. Lastly, for whatever solutions may be chosen and developed, the solutions must meet any operational and performance requirements mandated by regulation. 7. Conclusions and Further Work Use of ENUM functionality is fairly straightforward for simple call flows. Unfortunately, the reality of today's telecommunication Lind Information - January 2001 6 ENUM Call Flows for VoIP Interworking July 2000 environment is that calling is far from simple. The issues identified within this document include: - identification of freephone service providers within DNS, - identification of Gateways using location routing numbers (or potentially by other means), - source of local number portability information for queries from IP-based infrastructure, - mechanisms for transport of LNP information to the final switching destination, - provision and maintenance of information in DNS. While some of these issues may be outside the scope of ENUM, they nevertheless have to be addressed if IP-based communication will be viable. Between the IETF and the ITU, core competencies exist to address these issues; continued cooperation will be beneficial. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Falstrom, P., "E.164 number and DNS", draft-ietf-enum-e164-dns- 00.txt, April 25, 2000 4 Rosenberg, J. and Schulzrinne, H., "A Framework for Telephone Routing over IP", RFS 2871, June 2000 5 ITU-T Recommendation E.164, The international public telecommunication numbering plan - Supplement 2: Number Portability, November 1998 (see also draft-ietf-enum-e164s2-np- 00.txt) 6 Second Report and Order In the Matter of Telephone Number Portability (FCC Docket No. 95-116), FCC 97-289, Adopted August 14, 1997 (see http://www.fcc.gov/Bureaus/Common_Carrier/Orders/1997/fcc97289.tx t) Lind Information - January 2001 7 ENUM Call Flows for VoIP Interworking July 2000 9. Author's Addresses Steven D. Lind AT&T Bldg. 2, Room 2G25 180 Park Avenue Florham Park, NJ 07932 U.S.A. Phone: +1 973 236 6787 Email: sdlind@att.com Lind Information - January 2001 8 ENUM Call Flows for VoIP Interworking July 2000 Full Copyright Statement 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. 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. Lind Information - January 2001 9