Advance Internet Caller-ID Delivery Service [Page 1] L. Slutsman Internet Draft AT&T Laboratories Expires: September 1999 Advance Internet Caller-ID Delivery Service 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. 1. Abstract The Internet Call Waiting (ICW) has recently become a standard "check-list" service offered by many Telecommunications providers such as Nortel and Lucent. While differing in many details, all these schemes rely on the LEC provider ability to detect and signal the "busy-line" state. This signal triggers the execution of the service logic that provides the desirable effect. As a result, the Internet Call Waiting is most meaningful when offered by LEC [6] but of limited interest for long-distance providers, such as AT&T, MCI, etc. In the broader prospective, ICW may be considered a member of the class of services that manage incoming calls by making use of an Internet connection. Of special interest the Long Distance Providers is a specific subclass of services that "by-passes" LEC; the purpose of this paper is to begin the discussion of what can be implemented March 1999 Advance Internet Caller-ID Delivery Service [Page 2] when LEC services are either not available or not desirable. To this end we introduce a service--Advance Internet Caller-ID Delivery Service--that comes "close" to ICW and yet, does not rely on the terminating LEC. In addition, this service related to the PINT "click-to-dial" service and could make use of the PINT protocol. The rest of this document is as follows: Section 2 describes the service offered to the end Subscriber. Section 3 describes the architecture requirements to support the Advance Intenet Calle-ID Delivery Service. Section 4 descibes the call flows for typical scenarios. Sections 5 and 6 respectively supply referneces and provide the author address. 2. Service Description The "Advance Internet Caller-ID Delivery Service" service we describe is owned by a long-distance carrier provider (LDCP) such as AT&T, to which we refer as the service provider (SP). The subscriber to the service may have one or more Internet accounts (at home, at the office, etc.) and one or more telephone numbers to be reached. One telephone number (normally a home phone number) will be designated as the Primary Telephone Number (PTN). The PTN must be registered with the SP, and the table of alternative telephone numbers (in the order desired) will be stored in the SCP database where the PTN is the primary key. When the PTN is dialed, the list of provided telephone numbers is retrieved from the SCP, and the service performs the following steps: o Each provided telephone number, starting with the PTN is dialed. A line is considered to be unavailable if the call is not answered after a specified number of rings. o The call will be connected to the first available line. Otherwise, each IP account is analyzed to determine whether the subscriber is on the line. If he is, a pop-up window will appear on the screen with the "clickable" Caller-ID number; therefore, the subscriber may input a phone numberto receive the call and then click-to-dial the Caller-ID number. o Otherwise, if the subscriber is not on the Internet, he will be sent the email with the Caller-ID and the time of the call. 3. Architecture The service we describe requires the inter-working between Internet, PSTN, and ISP domains. We start the architecture description with the Internet domain. 3.1 Service Subscriber Internet presence. As an example, let us assume that a service subscriber has a virtual There may be two possibilities: o The subscriber has a single phone line that terminates on the "router" that distinguishes between voice and data/fax calls and connects the call to a modem or a telephone March 1999 Advance Internet Caller-ID Delivery Service [Page 3] set. o The subscriber has a second telephone line that may be used for telephone connections. The point-to-point connection to ISP1 via LEC1 is used to establish the Internet connection. LEC1 routes the customer's outgoing calls to a PSTN (any long distance provider may be used to handle outgoing calls). The LEC1 is also used to terminate incoming calls to the Service Subscriber. The ISP2 is used to connect the customer office computer to the Internet; a T1 or ISDN may be used for that purpose. |--------| |------| |------| |------| |----| |Home PC |====|Modem |====|Router|==|LEC1 |===|ISP1|==INTERNET |--------| |------| |--||--| |--||--| |----| || || |--||--| PSTN |Phone | |------| Figure 1a. Home Office |----------| |-----| |------------| |------| |Office PC |===|ISP2 |===INTERNET |Office Phone|===| LEC3 |===PSTN |----------| |-----| |------------| |------| Figure 1b. Business Office 3.2 PSTN-Internet Network Architecture The primary function of the PSTN/Internet architecture(see Figure-1c)is to support the incoming calls to the service subscriber. In short, if the voice connection is available, the PSTN will route the call to the proper Terminating LEC (LEC1 for home office); otherwise, the PSTN will hand-off the call to the Internet via the Advanced Pint Gateway (APGW ) node. Incoming calls go to LEC2 which routes them to an SP owned switch Provider Originating Switch (POS). Thus, unless special provisions on LEC2 are made, the caller is expected to be a subscriber to the LDCP that owns the service. The POS, using the LDCP Intelligent Network (IN) will recognize that the call is directed to the Service Subscriber. The service logic contained in SCP will be executed and the POS will be instructed to connect the incoming call to the service subscriber, using one of the provided telephone numbers. Should the attempt fail, the SCP will command the POS to disconnect the caller and will its Web counter-part --an appropriate APGW. To accomplish this, the SCP database should be populated with a table of the service subscribers. Each record in the table (see Table-1) must have the service subscriber PTN number as a key column, as well as a column with an IP address of a APGW. In addition, the table may be populated with a list of alternative telephone numbers in the order desired, such as an office number, to be used to reach the service subscriber. March 1999 Advance Internet Caller-ID Delivery Service [Page 4] Table-1. Service Subscriber Information Subscriber PTN: 732-922-0712 IP address of APGW: 1O35.16.20.73 Alternative#1: 732-922-0726 Alternative#2: 732-420-3752 The APGW acts as an Internet proxy server, database, service logic container and executor. In its proxy capacity, the APGW relays the messages to thei involved ISP providers. In its database capacity, the APGW contains the table (Table-2) described below. As a service logic depository, the APGW has the service subscriber's account containing the service logic programs indexed by the PTN; and finally, as a service executor, the APGW executes the subscriber-specific program, which results in sending signaling messages towards ISPs. The APGW database record uses the service subscriber PTN as a primary key and consists of columns of persistent and fluid data. The persistent data are - IPi is an IP address of ISPi, where subscript "i" identifies an ISP. - IPIDi is either an IP address of the subscriber (if the subscriber has one) or a pair of (logini, passwordi) registered with ISPi otherwise. - Emaili is an email address on the ISPI. The persistent data are be provisioned by the LDCP. The fluid data Si is the status of the subscriber on the ISPi (connected or disconnected). The APGW has to fetch Si from ISPs. Table-2.APGW Record (Data shown for ISP1 only) Subscriber PTN: 732-922-0712 ISP1 IP: 251.244.120.1 IPID1: lslusman,sigh*such Email1: lslutsman@monmuth.com S1: On |------| |---| |---| |----|===ISP1 | LEC2 |===|POS|===|SCP|===|APGW| |--||--| |---| |---| |----|===ISP2 || Incoming Call |--||--| |Phone | |------| Figure-1c. Incoming Call Architecture 4. Call Flow As a representative scenario, let us consider the case where the service subscriber specifies two telephone numbers to be reached: the PTN that is his home office address, and his business telephone number. Upon receiving the incoming call, POS starts the call set up process by sending IAM towards LEC1 (Figure-2a). At the same March 1999 Advance Internet Caller-ID Delivery Service [Page 5] time, the POS intercepts the IAM message, gets the Called-Party-Number (CdPN) and uses it for a lookup in its ANI table. If the CdPN is one of the service subscribers, the POS sends a query message M1 containing CdPN to the SCP. In addition, the POS will wait for a certain number of rings to figure out the availability of the home office line. Should the ACM from the LEC1 arrive at the POS during the waiting time, the call will be connected. The SCP response M2, containing the service subscriber data (Table-1), may arrive priori to or after the expiration of the waiting period. If the call is connected, the M2 is ignored, otherwise the POS will check for alternative numbers to dial. The POS sends the IAM message to the LEC3 that terminates calls to the business telephone number and starts to count the rings. Upon receiving the ACM from LEC3 the POS connects the call to the business office. Should this line be unavailable, the caller is disconnected and the POS sends message M3 to the SCP with the request to initiate the Internet Caller-ID Delivery (Figure-2b). The SCP makes the database query, gets the APGW IP address, and sends message M4 to the APGW. In addition, the message M4 contains the click-to-dial-back number (the caller number). For each ISP the APGW checks if the subscriber is on the line by sending query message M5 to the ISP. The ISP responds with the user's disposition in the message M6 (any change in the user's disposition after this message and during the critical time is signaled by ISP message M8). If the service subscriber is on the line, the APGW sends message M7 to the ISP containing CdPN, and click-to-dial-back number. Otherwise the APGW sends the email, containing CdPN, click-to-dial number, and the call-time to the service subscriber. As was mentioned above, the same procedure is repeated for each ISP. POS LEC1 SCP LEC3 |==(IAM)==> | | | |==========(1)=======>| | |<=========(2)========| | |========(IAM)========|=======>| |<===========(ACM)==============| Figure-2a. Call Flow POS SCP APGW ISP |====(3)======>| | | | |===(4)=====>| | | | |====(5)=>| | | |<===(6)==| | | |<===(8)==| | | |====(7)=>| Figure-2b. Call Flow (Cont) 5. References draft-slutsman-aicd-00.txt> Expires: September 1999 Advance Internet Caller-ID Delivery Service [Page 6] [1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 [2] ITU-T Q.12xx Recommendation Series, Geneva, 1995. [3] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The Intelligent Network Standards, their Application to Services". McGraw-Hill, 1996. [4] M. Krishnaswamy, "PSTN-Internet Internetworking - An Architecture Overview", Internet Draft [5] H. Schulzrinne, "SIP for Click-To-Dial-Back and Third-Party Control", Internet Draft [6] A. Brusilovsky, "A Proposal for Internet Call Waiting Service using SIP", Internet Draft [7] S. Petrack, "IP Access to PSTN Services: Basic Service Requirements, Definitions, and Architecture", Internet Draft [8] Handley, Schulzrinne, Schooler, Rosenberg, "SIP: Session Initiation Protocol", Internet Draft 6. Authors' Address Lev Slutssman E-mail: lslutsman@att.com Telephone: +1-732-420-3752 Fax: +1-732-368-1919 AT&T Laboratories 200 Laurel Avenue Middletown, NJ 07748 USA draft-slutsman-aicd-00.txt> Expires: September 1999