S. Lind Internet Draft AT&T Document: draft-ietf-enum-usage-scenarios-00.txt June 6, 2002 Category: Informational ENUM Usage Scenarios 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 [2] functionality within the larger context of 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. Some details are also provided for calls made using the ITU-defined "Global Services" [3,4,5]. The impact of number portability within the call scenarios is discussed. The objective of this document is to identify areas where gaps exist in the provision of services and suggest where protocol extensions for ENUM, SIP, TRIP, etc. are needed. The document does not propose that the examples represent the only or best approach for interworking between the PSTN and IP-based networks. 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 [6]. Lind Information - Expires December 5, 2002 1 ENUM Usage Scenarios June 6, 2002 2.1 Definitions ITSP - Internet Telephony Service Provider. An entity that provides (originates and completes) voice telephony service using IP technology. 3. Scope of Work It is envisaged that this document could be used by the ITU to cull the various service requirements out of the examples presented and to use those requirements as the main part of a new draft Recommendation (preliminarily called ôE.callflowsö). An example of such a requirement would be that the ENUM-enabled client should take the local dialing plan into account. It is also envisaged that this document could be used by various working groups within the IETF to identify areas where protocol enhancements need to be developed. Some of these areas are pointed out within this document. Other areas may become apparent after further service requirements are identified by the ITU. Some of this work may already be in progress within the IETF and close co-operation between the ITU and the IETF will speed this process of discovering existing work and initiating new work. Some areas that need exploration include the ability to obtain and transport number portability information within the call process (e.g., SIP messages), the ability for the TRIP protocol to address global service codes and network-specific numbers, and the need to interface with IN databases to ensure that interworking is fully functional. 4. Background ENUM provides the capability to translate an E.164 Telephone Number into a set of URIs using the Domain Name System (DNS). This capability has different uses depending on the applications being used and, in the case of voice services, the technology available at the source and destination of the communication. In a pure IP environment, ENUM will allow end users to be identified by a commonly used name (i.e., their telephone number) for a variety of applications. The potential for this capability simplifies the requirements spelled out in ITU-T Recommendation E.123, ôNotation for National and International Telephone Numbers, E-Mail Addresses and Web Addressesö. It also implies that end users can change IP service providers without having to change their destination identification. For example, an end user can change their underlying e-mail address from ôjohn@abc.comö to ôjohn@xyz.comö but, with ENUM set up to handle e-mail using the ôE2Uö records specified in RFC 2916, still be reached by having ENUM-enabled mail clients send mail Lind Information - Expires December 5, 2002 2 ENUM Usage Scenarios June 6, 2002 addressed to their ôtelephone numberö (e.g., mailto:+1-973-236- 6787). For voice services, ENUM will allow the easy end user identification described above as well as interworking between terminals on the PSTN and on the IP-based network. It may also allow for the implementation of more advanced services, such as ôfind-me.ö For voice communication starting on an IP-based network, ENUM can be used on each call to determine the preferred type of destination based on the priority of the network termination available. For voice communication starting on the PSTN, ENUM is more likely to be used where at least one of the destinations of the call exists on an IP-based network. +----------------+-----------------+----------------+--------------+ |\ Termination | IP-based | Both | PSTN Only | | -------------- | Network Only | | | | Origination \| | | | +----------------+-----------------+----------------+--------------+ |IP-based |ENUM used for ad-|ENUM used to de-|ENUM used to | | Network |dress translation|termine destina-|determine ad- | | |and, to some ex- |tion (based on |dress transla-| | |tent, service |service priori- |tion | | |priority |ty) and address | | | | |translation | | +----------------+-----------------+----------------+--------------+ |PSTN |ENUM used for ad-|ENUM may be used|ENUM may or | | |dress translation| |may not be | | | | |used | +----------------+-----------------+----------------+--------------+ Table 1 - Use of ENUM resources 5. Simple Voice Service Interworking 5.1 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 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. No aspects of number portability are included in the scenario. Lind Information - Expires December 5, 2002 3 ENUM Usage Scenarios June 6, 2002 +--------+ +--------+ (2) +--------+ | | | |---------->| | (3) | POTS |---------->| PSTN | | Gateway| | Phone | (1) | |<.........>| | (5) +--------+ +--------+ +--------+ ^ | ^ : | : (7) : | : : | : +--------+ +--------+ +-:-+-:--+ | | | |<............: | : | | SIP |<----------| SIP | |IP-based| | Client | (8) | 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 301-555- 1234, wants to call Jenny Jones. The number that John Smith has for Jenny, also in the US, is 301-236-6787. John dials ô236-6787ö [the hyphens are provided for readability and are not dialed]. It is worth noting that any dialed prefixes are usually dropped at the first switching point within the PSTN. As a second example, John Smith wants to call Franz Himmel in Switzerland. FranzÆs local number is 022-730-5887. John Smith would dial ô011-41-22-730-5887ö (011 being the dialing prefix for international calls placed from the United States and 41 being the country code for Switzerland). 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 Internet Telephony Service Provider (ITSP) at the point of termination. Lind Information - Expires December 5, 2002 4 ENUM Usage Scenarios June 6, 2002 Within the first example, John SmithÆs local service provider determines that the call is local, but not served by this provider. The originating provider forwards it to JennyÆs ITSP as the terminating local service provider. In the second example, the international carrier is handed the call. The call could be routed to an international switching center where the call is handed to another international carrier (where a gateway might be selected) or, if it can be determined that the destination is on an IP-based network, the gateway can be selected earlier in the call flow. Step 3 - The Gateway looks up the domain name in DNS. The Gateway at which the call enters the IP-based network must contain any ENUM functionality to transform the dialed digits to a fully qualified domain name (FQDN). The gateway must supply any missing digits in order to obtain a fully qualified E.164 number as part of the transformation. In the first example, the gateway transforms the dialed number into a FQDN of ô7.8.7.6.6.3.2.1.0.3.1.e164.arpaö. During the transformation, the country and area codes for the destination are added to the number by the gateway. In the second example, the gateway transforms the dialed number into a FQDN of ô7.8.8.5.0.3.7.2.2.1.4.e164.arpaö. In this second example, the country code is already present in the dialed digit stream. Step 4 - The DNS returns any service records associated with the URL. In the first example, the DNS returns among the records one containing the URI ôsip:jennyjones@sipservice.fooö. In the second example, the DNS returns a record containing the URI ôsip:franz.himmel@sipserver.bar.chö. Step 5 - The Gateway looks up the address (A) record for the specified host (e.g., ôsipservice.fooö) in DNS. Step 6 - DNS returns the IP address of the SIP server for the specified host. Step 7 - The call is routed through the IP-based network to the designated IP address. Step 8 - The SIP Server routes the call to the user agent client of the specified user (e.g., ôjennyjonesö). When the destination party answers, answer supervision must be returned to the originating local switch. A protocol diagram of this call flow is contained in Appendix 1. Lind Information - Expires December 5, 2002 5 ENUM Usage Scenarios June 6, 2002 5.2 Options In Identifying the Gateway The most significant problem in the above scenario is the determination of when the call must be routed to the IP-based network via the gateway. The easiest way to solve the problem would be to use different E.164 numbers for terminals on the IP-based network. However, this solution may not be feasible in certain regulatory environments where the available numbering resources are scarce. Another way to solve the problem is to route all calls to a gateway to transport the calls over an IP-based network, completing those calls to IP terminals where possible and allowing the remaining calls to egress back to the PSTN close to their destination. In the latter case, it may be useful, but not mandatory, to have ôtel:ö records to facilitate the routing to the destination gateway. There may be other solutions that lie between the previously described methods. Those possible solutions are outside the scope of this paper, but development work would be needed to implement such capabilities. 5.3 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. No aspects of number portability are included in this scenario. The various steps are denoted in parentheses within the figure and explained below. +--------+ +--------+ (5) +--------+ +--------+ | |(1,2,4) | |<........ ........>| LS | (6) | SIP |------->| SIP |--------+IP-based| : +--------+ | Client |<......>| Server |<........ Network| : +--------+ +--------+ +--------+ +--:--+--+ :....>| DNS | (3) : | +--------+ (7) : | v v +--------+ +--------+ +--------+ | | | |<......>| | | POTS |<-------| PSTN | | Gateway| (8) | 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 Lind Information - Expires December 5, 2002 6 ENUM Usage Scenarios June 6, 2002 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ö (the same number as assigned by her TSP) in the US is 301- 236-6787, wants to call John Smith. The number that Jenny has for John, also in the US is 301-555-1234. Jenny dials ô555-1234ö. Step 2 - The SIP Client looks up the name in DNS. The SIP Client must contain any ENUM functionality to transform the dialed digits to an Fully Qualified Domain Name (FQDN). The SIP Client 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 Client transforms the dialed number into a FQDN of ô4.3.2.1.5.5.5.1.0.3.1.e164.arpaö. During the transformation, the country and area codes for the destination are added to the number by the client. Step 3 - The DNS returns any NAPTR service records associated with the FQDN. In the example, the DNS returns at least one record containing the URI ôtel:+13015551234ö. If no ENUM record exists for the URL, the call should be attempted for termination on the PSTN using the dialed digits as the target for further steps in the call flow. Step 4 - The SIP Client initiates a SIP INVITE to the SIP Server using the ôtel:ö URI. Step 5 - The SIP Server may query a location server (LS) if the point of origination and the point of termination on the IP-based network are in different ITAD, using one of the Front End Protocols suggested within the TRIP framework [7] and maintained by the userÆs ITSP, for the IP address of a Gateway for this telephone number. As input to the query, the server will supply the telephone number from the ôtel:ö URI or the local routing number (LRN) if one was obtained when and if a local number portability (LNP) query was done (see section 7.2 for the discussion of LNP). Step 6 - The LS returns the IP address of the appropriate Gateway for the destination number. Step 7 - The SIP Server routes the call to the designated Gateway IP address. Step 8 - The Gateway completes the call through the PSTN to the destination phone. It must respond to any signaling (e.g., ringing, Lind Information - Expires December 5, 2002 7 ENUM Usage Scenarios June 6, 2002 busy) from the PSTN and send the appropriate information back to the call originator. A protocol diagram of this call flow is contained in Appendix 2. It should be noted that this protocol diagram also contains some of the number portability functionality not covered above. 6. Calls to E.164 Numbers using Non-Geographic Numbering Plans (Global Service Codes) In general, all Global Services, including International Freephone, International Premium Rate, and International Shared Cost, should process in a similar manner. The first step in handling a Global Service call 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 Global Service provider is an ITSP, then the originating PSTN access provider should route the call to the appropriate Gateway. The Global 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 Global Service number as a FQDN should return information that would allow the call to be routed to a proxy, redirect, or other server operated by the Global Service provider, which would then provide any call processing and termination required by the Global Service customer. Again, the service provider would be able to choose whether that processing used IN-based, IP-based or a combination of facilities. Once the necessary call processing was completed, the server could then redirect or forward the call to the appropriate point of termination. Figure 3 illustrates some of the steps necessary to provide such services originating from an IP-based terminal. This example is just one possible way of completing a global service call using ENUM. Other possibilities exist and need to be explored in conjunction with the Services Question (i.e., Q.3/2) in ITU-T Study Group 2 Step 1 - The originating customer dials an E.164 number. In the case of a global service, the end user dials the international access code for their country of origination (e.g., "011" in North America, "00" in other locations) and the destination number. As an example, Jenny Jones, who has a SIP client and whose ôphone numberö (the same number as assigned by her TSP) in the US is 301- 236-6787, wants to call the XYZ Company. The number that Jenny has Lind Information - Expires December 5, 2002 8 ENUM Usage Scenarios June 6, 2002 for the XYZ Company is +800 123 456 7890. Jenny dials ô011 800 123 456 7890ö. +--------+ +--------+ (5) +--------+ +--------+ | |(1,2,4) | |<......... .....>| DNS | (3,6) | SIP |------->| SIP |---------+IP-based| +--------+ | Client |<......>| Server |<......... Network| +--------+ +--------+ +---:--+-+ : | (7) : | v v +--------+ (8) +---------+ | SCP |<.........>| Global |---->GW, PSTN, +--------+ | Service | POTS Phone | Proxy | +---------+ ---> Voice Path ...> Signaling Path Figure 3 Global Service Call from IP-based Network to PSTN Step 2 - The SIP Client looks up the name in DNS. The SIP Client must contain any ENUM functionality to transform the dialed digits to an Fully Qualified Domain Name (FQDN). In the example, the SIP Client transforms the dialed number into a FQDN of ô0.9.8.7.6.5.4.3.2.1.0.0.8.e164.arpaö. Step 3 - The DNS returns any NAPTR service records associated with the FQDN. In the example, the DNS returns at least one record containing the URI ôsip:8001234567890@provider.host.fooö. Step 4 - The SIP Client initiates a SIP INVITE to the SIP Server using the ôsip:ö URI. Step 5 - The SIP Server looks up the address (A) record for the specified host (e.g., ôprovider.host.fooö) in DNS. Step 6 - DNS returns the IP address of a Global Service Proxy server for the specified host. Step 7 - The call is routed through the IP-based network to the designated IP address. Step 8 - The Global Service Proxy server uses the user name (i.e., "8001234567890") as well as interacting with the originating SIP client or server to collect any necessary information (e.g., time of day, place of origin) to process the call. The Global Service Proxy may have to interact with some data store of service information to Lind Information - Expires December 5, 2002 9 ENUM Usage Scenarios June 6, 2002 know how to route the call. In the illustration, the data store is a Signaling Control Point (SCP) located in the signaling path of the PSTN. The data store may return various pieces of routing information including an International Routing Address (INRA) and a Serving Service Provider Identity. This information can then be used by the Global Service Proxy to complete the call via a gateway to the appropriate destination on the PSTN. ITU-T Question 2/2 is working on the provision of routing information for calls on an IP-based network [8]. A protocol diagram of this call flow is contained in Appendix 3. 7. Issues Surrounding Calls to Ported Numbers Portability issues exist whether or not ENUM is used during the call processing. There are three types of number portability: service provider portability, geographic portability, and service portability. This document will only deal with service provider portability as it is the one type that is most likely to be implemented. For service provider portability [9], 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 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. Other examples need to be developed that represent the number portability requirements and implementations in other countries. 7.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 5.1 above. In the US, where Location Routing Numbers (LRNs) is mandated by regulation [10], 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 5.1, step 4, the DNS might contain a different record now containing the URI ôsip:jennyjones@newsipservice.fooö. The Gateway would then Lind Information - Expires December 5, 2002 10 ENUM Usage Scenarios June 6, 2002 resolve the URI in a different DNS to obtain the correct IP address for the new SIP server. 7.2 Calls originating on an IP-based network It appears that, under scenario 1, the primary impact would be that a different gateway for a given number might be used 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 SIP Server or 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 by the PSTN. It is important that the LRN be carried forward from the point at which it is obtained in order for the PSTN to know that a portability query has been done. 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 7.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.3 Further Work on Number Portability ITU-T Question 3/2 is working on a draft new Supplement to Recommendation E.370 [11]. This text should reflect information on the impacts of interworking between the PSTN and an IP-based Network when E.164 numbers are ported. The text should be shared with the IETF as it becomes more stable. 8. Conclusions and Further Work Use of ENUM functionality is fairly straightforward for simple call flows. Unfortunately, the reality of todayÆs telecommunication environment is that calling is far from simple. The issues identified within this document include: ò Identification of the need to route a call from the PSTN to a gateway at the edge of an IP-based network (this work, if necessary, would be on the PSTN), Lind Information - Expires December 5, 2002 11 ENUM Usage Scenarios June 6, 2002 ò Source of local number portability information for queries (probably as an extension to the SIP protocol) from IP-based infrastructure, and ò mechanisms for transport of LNP information to the final switching destination, (see draft-yu-tel-url-01.txt for one such example of a proposed SIP extension). 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. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Falstrom, P., "E.164 number and DNS", RFC 2916, September, 2000 3 ITU-T Recommendation E.152, International Freephone Service, February 2001 4 ITU-T Recommendation E.154, International Shared Cost Service, March 1998 5 ITU-T Recommendation E.155, International Premium Rate Service, March 1998 6 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 7 Rosenberg, J. and Schulzrinne, H., "A Framework for Telephone Routing over IP", RFC 2871, June 2000 8 ITU-T draft new Recommendation E.INRA.IP, Interworking of Routing Addresses and IP-Nmaes/Addresses 9 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) 10 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.txt ) Lind Information - Expires December 5, 2002 12 ENUM Usage Scenarios June 6, 2002 11 ITU-T COM 2-R 80, "Recommendations requiring further development, WP 1/2", March 2000 10. 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 - Expires December 5, 2002 13 ENUM Usage Scenarios June 6, 2002 Appendix 1 û Protocol Diagram of the PSTN-to-IP Call Flow Tel PSTN G/W DNS SIP SIP IP Server Client Terminal | | | | | | | | Dial | | | | | | |-------->| Setup | | | | | | |-------->| ENUM | | | | | | | Query | | | | | | |-------->| | | | | | | Return | | | | | | | URIs | | | | | | |<--------| | | | | | |DNS Query| | | | | | |-------->| | | | | | |Return IP| | | | | | | addr of | | | | | | | SIP Srvr| | | | | | |<--------| | | | | | | INVITE | | | | | | |---------+-------->| | | | | | | Trying | | | | | |<--------+---------| INVITE | | | | | | |-------->| | | | | | | Trying | | | | | | |<--------|Incoming | | | | | | |Call Ind | | | | | | Ringing |-------->| | | | | Ringing |<--------| | | | Ringing |<--------+---------| | | | Ringing |<--------| | | | | |<--------| | | | |Off Hook | | | | | | OK |<--------| | | | | OK |<--------| | | | Answer |<--------+---------| | | | |Super- | | | | | | | vision | | | | | | Answer |<--------| | | | | |<--------| | | | | | | Both Way Voice | | Both Way RTP Media| | |<--------+-------->|<--------+---------+---------+-------->| | | | | | | | Lind Information - Expires December 5, 2002 14 ENUM Usage Scenarios June 6, 2002 Appendix 2 û Protocol Diagram of the IP-to-PSTN Call Flow IP SIP SIP SIP-IN LNP DB DNS LS G/W PSTN Tel Term Client Server Proxy | | | | | | | | | | | Dial | | | | | | | | | |------>| ENUM Query | | | | | | | | |-------+-------+-------+------->| | | | | | | | | Returns URIs | | | | | | |<------+-------+-------+--------| | | | | | |INVITE | | | | | | | | | |------>| | | | | | | | | | Trying| | | | | | | | | |<------|Ported?| | | | | | | | | |------>| LNP | | | | | | | | | | Query | | | | | | | | | |------>| | | | | | | | | | LRN | | | | | | | | | LRN |<------| | | | | | | | |<------| | | | | | | | | | LS Query for Gateway | | | | | | | |-------+-------+--------+--->| | | | | | | IP Address of Gateway | | | | | | |<------+-------+--------+----| | | | | | | | INVITE | | | | | | | |-------+-------+--------+----+--->| | | | | | | | Trying | | | | | | | |<------+-------+--------+----+----|Setup| | | | | | | | | |---->| Ring | | | | | | | | |Ring-|------>| | | | | | | | | ing | | | | | | |Ringing | | |<----| | | |Ringing|<------+-------+--------+----+----| | | |Ringing|<------| | | | | | | | |<------| | | | | | | |Offhook| | | | | | | | |Ansr.|<------| | | | | | | | |Super| | | | | | | | | |visn.| | | | | | | OK | | |<----| | | | OK |<------+-------+--------+----+----| | | |Answer |<------| | | | | | | | |<------| | | | | | | | | | | | | | | | | Both Way | | | | Both Way RTP Media | | | Voice | |<------+-------+-------+-------+--------+----+--->|<----+------>| | | | | | | | | | | Lind Information - Expires December 5, 2002 15 ENUM Usage Scenarios June 6, 2002 Appendix 3 û Protocol Diagram of the IP-to-PSTN Freephone Service Call Flow IP SIP SIP FFS FFS DB DNS LS G/W PSTN Tel Term Client Server Proxy | | | | | | | | | | | Dial | | | | | | | | | |------>| ENUM Query | | | | | | | | |-------+-------+-------+------->| | | | | | | | | Returns URIs | | | | | | |<------+-------+-------+--------| | | | | | |INVITE | | | | | | | | | |------>| | | | | | | | | | Trying| | | | | | | | | |<------|INVITE | | | | | | | | | |------>| | | | | | | | FFS Processing | FFS | | | | | | |<------+-------+------>| Query | | | | | | | | | |------>| | | | | | | | | | INRA, | | | | | | | | | | SSPI | | | | | | | | | |<------| | | | | | | | | | LS Query for Gateway| | | | | | | |-------+--------+--->| | | | | | | |IP Address of Gateway| | | | | | | |<------+--------+----| | | | | | | | INVITE | | | | | | | | |-------+--------+----+--->| | | | | | | | Trying | | | | | | | | |<------+--------+----+----|Setup| | | | | | | | | |---->| Ring | | | | | | | | |Ring-|------>| | | | | | | | | ing | | | | | | |Ringing | | |<----| | | | |Ringing|<------+--------+----+----| | | | |Ringing|<------| | | | | | | | |<------| | | | | | | | |Ringing| | | | | | | | | |<------| | | | | | | |Offhook| | | | | | | | |Ansr.|<------| | | | | | | | |Super| | | | | | | | | |visn.| | | | | | | OK | | |<----| | | | | OK |<------+--------+----+----| | | | | OK |<------| | | | | | | |Answer |<------| | | | | | | | |<------| | | | | | | | | | | | | | | | | Both Way | | | | Both Way RTP Media | | | Voice | |<------+-------+-------+-------+--------+----+--->|<----+------>| | | | | | | | | | | Lind Information - Expires December 5, 2002 16 ENUM Usage Scenarios June 6, 2002 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 - Expires December 5, 2002 17
Datatracker
Report a datatracker bug
draft-ietf-enum-usage-scenarios-00
None
| Document | Document type |
Expired Internet-Draft
(enum WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Author |
Steven D. Lind
Email authors |
||
| Replaces | draft-lind-enum-callflows | ||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |