EURESCOM P909 contribution to PINT and SPIRITS [Page 1] PINT Working Group Valerie Blavette SPIRITS Working Droup Gianni Canal Internet Draft Uwe Herzog Carlo Alberto Licciardi Stephane Tuffin Expires: September 2000 EURESCOM P909 contribution to PINT and SPIRITS Interaction between Internet and PSTN to request services from one domain to the other 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 This document is intended to provide input to the IETF SPIRITS Working Group(SPIRITS WG) and to the IETF PINT Working Group (PINT WG) from the viewpoint of European network operators that are involved in EURESCOM P909 Project "Enabling Technologies for IN Evolution and IN-Internet Integration". The input is based on current results that were achieved in the project. As the project title says P909 project deals with IN-Internet integration issues. The project has defined an architecture for IN-Internet inte gration and it has selected and described some IN-Internet services which can be interesting from the business perspective and challenging from the technical perspective. Some of these services are "officially" chartered in IETF: ICW in SPIRITS, Click-to-Dial (Request to Call) as well as proposed March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 2] Conference Service in PINT. However, there are additional IN-Internet convergence services that P909 studies and that are included in this document only as examples. Selected services can help in defining requirements both in the context of how services supported by IP network entities can be started from IN (Intelligent Network) requests and how Internet applications can request and enrich PSTN (Public Switched Telephone Network) telephony services. In section 2 and 3 of this Internet Draft you find some general information on EURESCOM and P909 project. Section 4 briefly introduces some of the services P909 has selected, section 5 describes for some services why there is a need to notify entities in the Internet from PSTN/Intelligent Networks domain in order to provide the requested service features. Section 6 describes the service requirements for scenarios where the PSTN telephony service is requested from Internet. Sections 7, 8 and 9 respectively address security considerations, supply references, and provide the authors addresses, as required by [1]. Section 10 acknowledges individuals providing assistance in the creation of this document, and, finally, Section 11 provides Glossary of terms. TABLE OF CONTENTS 1. Abstract 2. EURESCOM 3. EURESCOM P909 Project 4. Overall Service Description 4.1 Internet Call Waiting 4.2 Virtual Second Line 4.3 Click-to-Dial 4.4 Distributed and Enhanced Call Center 4.5 Meeting Scheduler 4.6 Unified Communication 4.7 Virtual Presence 4.8 Virtual Private Network 5. IN service triggering internet services 5.1 Virtual Presence Service 5.2 Internet Call Waiting 5.3 Meeting Scheduler 5.4 Unified Communication 5.5 Distributed and Enhanced Call Center 6. IN service request from the Internet 6.1 Click-to-Dial 6.2 Meeting Scheduler 7. Security considerations 8. References 9. Authors addresses 10. Acknowledgements 11. Glossary March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 3] 2. EURESCOM EURESCOM(European Institute for Research and Strategic Studies in Telecommunications) is an Institute for performing collaborative Projects on research and strategic studies in all areas of telecommunications. It was founded in 1991 and is located in Heidelberg, Germany. Currently, there are 24 Shareholders from 23 European countries involved in EURESCOM and it is open to any network operator or service provider who wishes to join. EURESCOM's overall mission is to carry out pre-competitive R&D Projects. The aim is to support the R&D Project Shareholders to establish future-oriented telecommunication networks and services. In addition, EURESCOM has to carry out studies in order to be able to recommend longer term strategic options concerning R&D in services, networks and supporting technologies. More precisely, EURESCOM's objectives are to: - stimulate and co-ordinate pre-competitive and pre-normative collaborative R&D Projects including field trials and pilot projects - enable the development of harmonised strategies by its Shareholders for the planning, operation and provision of future European public telecommunications networks and services - contribute to Europe-wide service deployment and service usage - contribute to European and world-wide standardisation - contribute to the work of international bodies and relevant European R&D programmes 3. EURESCOM P909 Project Enabling technologies for IN evolution and IN-Internet integration is the focus of P909. The IN-Internet convergence can be expressed in terms of delivery of specifications, and identification/evaluation and integration of off-the-shelf products supported by some prototypes development. In particular the project addresses: - Identification of IN-Internet services in a competitive context (click-2-dial, unified messaging, ...) - Definition (or adaptation) of a service architecture that facilitates the synergy between IN and Internet services; - Evolution of the Network Intelligence to support new IN services and integrated IN-Internet services in terms of: - evolution of IN architecture (Reference and Business Models) and elements (SCP, SMS, IN-IP, ...); - integration of IN and Internet services (i.e. to integrate IN and Internet in a simple call completion service with a transparent access, independent of caller and called terminal); - Definition of an unified Call Control for IN-Internet services based on ongoing initiatives (e.g Parlay) March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 4] - Definition of guidelines to PNOs for step-wise introduction of middleware solutions. - Investigation of protocols (e.g. IETF PINT, IETF SPIRITS, IETF SIP) for Web and IN services convergence (IN Services; customisation through the Web, interfacing IN with 3rd party systems, definition of open interfaces between SCP and Web server); - Selecting and testing products maturity from IN and Internet side w.r.t. the defined architecture; - Integration and assembling of existing products (or prototypes) in order to prototype middleware platforms for IN and Internet services; this could lead to use gateway to access new SCPs (i.e. a CORBA SCP), to integrate and control technologies and products such as Voice-IP gateways, PINT/SPIRITS gateways, gatekeepers and MCUs (Multimedia Conference Units) ITU H323 compliant. - Implementating services on top of IN-Internet middleware platforms (the definition of such platforms leads also to the definition of components that enable/facilitate the access to other stakeholders and the related co-operation /federation). Companies that are involved in P909 project are: Telefonica I+D, KPN Research, T-Nova DeutscheTelekom Innovationsgesellschaft mbH, France Telecom, CSELT/Telecom Italia, Telenor AS, Broadcom Eireann Research and Portugal Telecom. 4. Overall Service Description P909 has selected a line of services to study. These services are interesting from the business and technical perspective in the context of IN-Internet convergence. Some of these IN-Internet services are "officially" chartered or proposed in IETF: Click-to-Dial (Request to Call), Conference Service in PINT and ICW in SPIRITS. However, there is a number of additional IP-PSTN convergence services that P909 studies and that are included in this document for example only purpose. This section briefly describes the selected services. 4.1 Internet Call Waiting Internet call waiting service enables a user engaged in a dial up Internet session to be alerted when an incoming call has arrived. After the Internet user has been alerted, he is given several options for handling the call e.g., forwarding it, sending a waiting announce/tone, accepting the call over PSTN suspending the Internet session, or accepting the call over IP keeping alive the Internet session. March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 5] 4.2 Virtual Second Line This service allows the subscriber to answer incoming phone calls while his/her single telephone line is busy due to an ongoing Internet session. A vocal gateway can be used to transform the incoming PSTN call into a Voice over IP flow directed to the terminal interconnected to the Internet. In this way, the terminal could manage the IP flow carrying the voice along with the other IP flows originated by the Web surfing. 4.3 Click-to-Dial (Request-to-Call) A user is able to initiate a telephone call by clicking a button during a web session. The called address (as well as the caller address) is either an IP address or a phone line number. The charging party could be either the initiator or one of the called parties. 4.4 Distributed and Enhanced Call Center The integration of IN and Internet would allow to decrease the costs of the call centres. A first opportunity is the implementation of network-based call centre solutions in order to achieve distributed/virtual call centres. With this approach, the actual necessary infrastructure in each call centre could disappear, and some new paradigms like teleworking could be used. 4.5 Meeting Scheduler Meeting Scheduler is a service that enables an user to have a web based user interface to schedule a meeting. He decides the time and the attendants. The timing information is used by an external application that launches the service via the access function. Every meeting attendant is confirmed, either with an e-mail notification and a following confirmation process via a web page or with a phone call. 4.6 Unified Communication The Unified Communication Service allows users to send, retrieve and receive messages disregarding the format and the terminal where the user is connected. The user should be able to create and respond to multimedia messages from any terminal and create and send any type of message without regard to the recipient's mailbox requirements. The user should also be able to reply to messages and forward messages with calls, and reply and forward calls with messages. 4.7 Virtual Presence "Virtual Presence" service allows its subscribers to be reached March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 6] anywhere, anyway (by using both asynchronous messages and real time communication) and from any terminal independently of the type of terminal he is logged to. "Virtual Presence" extends the characteristics of a Personal Number service to the context of Internet/Telecom convergence. The aim of the service is to provide an integrated set of features that enable for example a subscriber to control the incoming calls according to a set of personal screening/ routing rules (a sort of "net-secretary") and terminal registrations, that he/she could dynamically modify. 4.8 Virtual Private Network The Enhanced VPN Service would allow to use most of cases of the VoIP paradigm. The main characteristics of this service could be: - Integration of several terminals into the VPN: fixed and mobile phones, PC, ... - Several communication modes (Phone to phone, Phone to PC, PC to phone, PC to PC) - Use of traditional features in VPN service: Unified billing, Abbreviated dialling, Call restrictions (extra/intra VPN calls), etc. The service logic could manage information about the connections between the VPN positions, in order to select the cheapest way to reach the destination of a call, either in an intra VPN call or in an extra VPN call. 5. IN service triggering to the internet Some IN Services could be extended to notify events or send information to the Internet domain. It should enable services like Internet Call Waiting, Virtual Presence, etc. It must be possible to have access to the Internet domain from IN for the purpose of - Invoking Internet services, e.g. forwarding of fax/SMS as email - Notify call information - Controlling VoIP resources - Access to customer and service information stored on Internet Databases/Web Server, e.g. downloading share information from a Web server for transfer to a GSM phone using SMS. The following services can well help in defining requirements in the context of how services supported by IP network entities can be started from IN (Intelligent Network) requests. 5.1 Virtual Presence Service The VP service may work with a heterogeneous set of terminals: e.g., fixed and mobile phones, fax and PC, and new generation terminals (PDA, WebPhones, WAP-based mobile phones). The association subscriber-terminal can be dynamically changed (personal mobility). In addition a subscriber can be registered on multiple terminals of the same type. A service subscriber has a single virtual identity in March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 7] the system, referenced by a logical name, Personal Alias, (used from the Internet context) and a Personal Number (used both from IN context and Internet one). More precisely the user can: 1. Register/De-register: (s)he can choose the terminals where (s)he decided to be contacted. 2. Configure: (s)he can define the group of terminals of common use. 3. Set personalization rules: using a graphical application, (s)he can introduce and manage filtering rules to be applied to incoming asynchronous or synchronous communication requests. Rules are modeled according to the ECA paradigm, i.e. Event-Conditions-Actions: 1. An event is an external stimulus addressed to the subscriber. Conditions represent constraints on rules scope. 2. Actions are operations performed if and only if all conditions of the rule are satisfied when the event occurs. Rules are activated by a single event; they are evaluated against a set of conditions, and trigger a sequence of actions. Service features that have an impact on the PSTN-to-IP context are: - Notifying the subscriber about incoming synchronous communication request on his/her PC. As an example considering Gianni who had previously set some customised rules for handling incoming communication requests from other users. A user tries to contact Gianni from a phone by using his personal number (1364555). The incoming call request is processed by the service. The service analyses the rules and one of them fires (event and condition matches). For example the action associated to the rule is to route the call to the Gianni's office PC. Then the service forwards the call to the PC of the subscriber who is requested to accept the call through some standard API or network protocols (e.g. IETF SIP). After she/he clicks on the appr opriate button the call is completed and the two users are put through. - Notifying the subscriber about incoming asynchronous communication request (e.g. vocal message) on his/her PC. A user tries to contact Gianni from a phone by using his personal number (1364555). The incoming call request is processed by the service. The service analyses the rules and one of them fires (event and condition matches). For example the action associated to the rule is to route the call to the Gianni's home phone but this is busy. The service then evaluates the rule associated to the busy condition and for example it forwards the call to voice-mailbox of the subscriber. (S)He is then notified about this voice message. 5.2 Internet Call Waiting Internet call waiting (ICW) is a service that enables a user engaged March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 8] in a dial up Internet session to be alerted when an incoming call has arrived. After the Internet user has been alerted, he is given several options for handling the call (e.g., forwarding it, sending a waiting announce/tone, accepting the call over PSTN suspending the Internet session, or accepting the call over IP keeping alive the Internet session). In parallel the caller is announced that the callee is busy and (s)he is asked to hold the line. In order to enable the service the subscriber has to use a client software that performs the registration phase by storing the association between the PSTN line number (i.e. CLI) and the IP address of his/her Internet session. Service features that have an impact on the PSTN-to-IP context are: - Handling an incoming call The subscriber receives a PSTN call directed to his/her phone, which is busy, since it is engaged in a dial-up Internet session. The IN Service Switching Point (SSP) triggers the service logic to handle this call event. The caller is connected to a Intelligent Peripheral in order to send a message to inform him/her to wait (call queueing). The service retrieves the IP address of the callee and then, depending on the user profile, notifies the incoming call to the Internet user with caller number or name or other call relater information. The Internet user may choose different options: 1. Accept call on PC using voice over IP 2. Accept call on phone 3. Suspend IP session and answer the call on the phone 4. Reply the caller with a pre-registered message 5. Reject the call In the following sections ICW service scenarios are described in more details. 5.2.1 Connection To Internet This scenario describes what happens when an ICW subscriber (e.g. Bob) connects to Internet by means of a dial-up connection. Preconditions: Bob has subscribed to ICW service Post Conditions: Trigger Detection Point (DP) 13 (in ETSI Core INAP terminology DP13 corresponds to TCalledPartyBusy event) is armed so that when there is an incoming call for Bob and his line is busy the ICW is notified. The dial-up connection is established. First Bob launches the Internet connection software, which dials the ISP phone number, that is an number which represents an IN service. As a result of the pre-arranged agreement between the Internet service provider and the network provider the DP3 (AnalyzedInformation) was set. March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 9] The SSP triggers the service logic by sending an InitialDP message to the IN Service Control Point (SCP). Then the SSP, through a gateway, notifies the ICW Service Logic about a network event related to an incoming call for the ISP phone number. The service logic is executed within a kind of SLEE (Service Logic Execution Environment) that provide API to interact with network functionality. The ICW service logic consequently sets TDP13 using some management interface on the SSP. The ICW service logic then subscribes to call event related to Bob's call leg disconnection since it needs to disarm the TDP13, when the Internet connection is disconnected. The ICW Service Logic gives instruction to the network to route the call to the address of the Network Access Server (NAS) to be connected. Furthermore it arms DP7 (OAnswer) in order to be notified about the result of the call routing. The connection is set up between the SSP and the NAS and consequently the network acknowledges the establishment of the connection. Since the ICW Service Logic needs to monitor NAS disconnection as well as Bob's disconnection, it subscribed to call event (DP9 ODisconnect) related to NAS disconnection (this subscription could not be requested before the successful notification of the call routing to the NAS). When the network acknowledges the successful establishment of the call leg towards the NAS, the call processing is stopped at the DP7 (OAnswer) since it has been set as an EDP-R. The ICW service logic instructs the SCP to continue the call processing (this is mapped onto the INAP operation Continue). The subscriber is now requested to authenticate through a login and password. This subscriber data are sent to a Radius server to authenticate him and to retrieve from a directory server Bob's user profile based on its home phone number. The association between the IP address of Bob and Bob's home phone number is stored in his user profile. The software in charge of handling invitations is launched automatically after the connection to Internet is established e.g. IETF SIP UAC. 5.2.2 Incoming Call Notification This scenario describes what happens when a user tries to call Bob at March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 10] his home phone number. Preconditions: Bob is connected to Internet. Post Conditions: Bob is notified of an incoming call and have to chose either to reject the call, to answer the call over a PSTN line or to answer the call over IP. An unnamed user dial Bob's phone number. Bob's SSP detects that Bob's phone line is busy and according to the previous arming of TDP13, an InitialDP message is sent to the SCP in order to notify that a call has been triggered. The call is routed to an Interactive Voice Response (IVR), which implements IN-Special Resource Functions. The ICW Service Logic instructs to send a ConnectToResource message to the SSP. The SSP then establish the connection to the IVR. The service logic sends the PlayAnnouncement operation to the IVR thus an announcement is played to the user. In the meantime (while the announcement is played or even while the connection to the IVR is established), the ICW Service Logic retrieves Bob's user profile from the directory server in order to get Bob's PC IP address. The ICW service logic sends an invitation (e.g. SIP INVITE message) to Bob with information about the caller (e.g. Calling Line Identity) asking him either to: - Accept call on PC - Accept call on phone - Suspend IP session and answer the call on the phone - Reply the caller with a pre-registered message - Reject the call Bob's choice is sent back to the ICW Service Logic via a SIP response message. The IVR reports the end of the Announcement to the SSP. 5.2.3 Rejecting The Call This scenario describes what happens when Bob is invited to a call by an unnamed user and chooses to reject it. Preconditions: Bob is connected to Internet via a dial-up connection, an incoming call has arrived for Bob, Bob chooses to reject the call. Post Conditions: The incoming call is terminated. The dial-up connection is still active. When the Internet user rejects the incoming call the ICW service logic requests to play an announcement to the unnamed user saying that the callee has rejected the call. The service logic asks to play an announcement. When the announcement is finished the SSP notify the ICW Service Logic about the end of it. The ICW Service Logic then releases the call initiated by the unnamed user. March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 11] 5.2.4 Accepting The Call On The Phone This scenario describes what happens when Bob is invited to a call by an unnamed user and chooses to answer on his PSTN line. Preconditions: Bob is connected to Internet by means of a dial-up connection, an incoming call has arrived for Bob, Bob chose to answer the call on his PSTN line. Post Conditions: The dial-up connection is terminated and the call is established between Bob and the unnamed user using PSTN to PSTN connection. The ICW client software disconnects the dial-up connection. Therefore a disconnect signal is sent to the SSP. This is triggered by the SSP since an EDP9 (ODisconnect) related to the call between Bob and the NAS was previously armed. Consequently the SSP sends an EventReportBCSM operation to the ICW Service Logic. The ICW Service Logic disarms TDP13 on Bob's phone line by means of some management interface. Since a connection to an IVR was still established, the ICW Service Logic releases this connection. The SSP disconnect the connection to the IVR and sends to the NAS a message to disconnect it. As the result of the previous arming of an EDP9 (ODisconnect) related to the disconnection of the NAS the SSP sends an EventReportBCSM operation to the ICW Service Logic. The NAS detects the end of the dial-up connection and instructs the Radius gateway to stop the accounting. The Radius gateway asks the accounting server to stop the accounting for Bob's account. Bob's user profile is updated by deleting the IP address from the scope of the previous dial-up connection. The ICW Service Logic has just released the call to the NAS, therefore it tries to route the call to Bob's phone line. The call finally is routed to Bob's phone line. 5.2.5 Accepting The Call On IP This scenario shows what happens when Bob during his Internet session chooses to answer an incoming call using VoIP. Preconditions: Bob is connected to Internet, an incoming call has arrived for Bob, Bob chooses to answer the call over IP. Post Conditions: The call is established between Bob and the unnamed user using a VoIP gateway. Since a connection to an IVR was still established, the ICW Service Logic release this connection. The SSP disconnect the connection to the IVR. The ICW Service Logic retrieves Bob's IP address and instructs the network to route the call to the appropriate VoIP gateway and requests to be notified of the outcome of the call routing. The SSP establish the PSTN connection to the VoIP gateway. The ICW Service Logic controls the VoIP gateway to terminate the call to Bob's IP address. Depending on the VoIP gateway used, different March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 12] control interfaces are possible e.g. H323, MeGaCo, ... The VoIP gateway terminates the call to Bob's IP address. 5.3 Meeting Scheduler The service is a meeting scheduler and initiator. A user has a web based user interface to schedule a meeting. He decides the time and the attendants. This information is recorded in the service profile, once it is decided it is authorised. The timing information also is used by an external application that launches the service. The service retrieves the attendant's list from the service profile and uses the user profile to locate the users. Two kinds of communications are considered: VoIP and POTS meaning that users can be located both on a telephone and a PC. The service establishes as many calls as needed and puts all of them in the same communication. Some of the information can reside within the user's domain (e.g. attendant list), being accessed from the service upon execution time. Service features that have an impact on the PSTN-to-IP context are: - Notification of phone attendance confirmation on meeting manager's PC During the meeting confirmation phase the service logic checks for every meeting participant the availability of an E-mail address in his/her user profile. If the participant has no e-mail address, the service logic chooses a telephone number and a time at which the meeting participant might be available by elaborating the User Profile data and uses this information to schedule, via an external application, an attendance confirmation via phone. The phone attendance confirmation process is activated by the an external scheduler. Using the information related to a particular meeting attendant, a new call is created. The service logic instructs the Call Control component to interact with the Service Node to create a new Call leg and to route it to the meeting participant's phone number. When (s)he answers, (s)he is requested to dial his/her PIN to authenticate him/her. After the successful authentication data check against his/her User Profile information, a message is played informing him/her of the scheduled meeting and asking her/him to confirm his/her attendance. Meeting participant's answer (dialled digit) is then collected and depending on it, her/his attendance is confirmed in the meeting profile manager. The meeting manager is informed about this acceptance by means of a pop up window or by updating a graphical application. - Notification of meeting start on PC for VoIP users. After the meeting is scheduled the service informs the attendants about it for example by Email. Each potential attendant is requested to confirm his/her participation. The service can have 2 different choice: 1. It could check the User profile to get the location of the user at the time the meeting is scheduled. 2. It could ask the attendant to provide this information directly. March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 13] In the first case an external scheduler to start a new conference triggers the meeting activation process. It has previously obtained a list of attendants from the service profile containing the identification of those users who have confirmed their attendance at the meeting. From the User Profile, it has obtained a list of possible locations for each user, ordered by user preferences at the time when the conference is going to take place. Once it has obtained all the needed information related to the attendants, it starts the conference and notifies VoIP attendants of the meeting start by popping up a window on their PC. They can at this point accept or deny to join the conference. - Notification to the chair's PC of participants who left or joint the conference. During the execution of the service the conference status, in term of participants and time they have been logging in, is monitored. The chair (who scheduled the meeting) may be not logged in the conference. (S)He is informed in any case about any change of the conference status. For example if a participant leaves or joint the conference the chair is notified about this on his/her PC and this information are stored in a file and used for billing off-line procedures. - On-line notification which participant(s) is currently talking. The service could have the feature to update a graphical user interface, which maintains an image of the current conference status. So that participants who are also connected to Internet could receive graphical information about who is talking. This service feature depends on the capability of the resource, which provides the multiparty audio bridging feature to the service, to capture and use information about traffic flows for each leg. 5.4 Unified Communication The Unified Communication Service allows users to send, retrieve and receive messages disregarding the format and the terminal where the user is connected. The user should be able to create and respond to multimedia messages from any terminal and create and send any type of message without regard to the recipient's mailbox requirements. The user should also be able to reply to messages and forward messages with calls, and reply and forward calls with messages. Service features that have an impact on the PSTN-to-IP context are: - Interworking between different session e.g. telephone call and chat session. The following scenario is very interesting from the technical perspective since messages are exchanged when different sessions (i.e. telephone call and chat session) are occurring. In this scenario two users (John and Mary) are involved in telephone call and two other users (Anna and Mike) are involved in Chat session. Suddenly, Mike knows that John's mother is at the hospital. So, he sends a message (i.e. e-mail message) to John March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 14] marked as a High Priority message. The provider notifies John about the message. John holds the phone call, calls the messaging service and receives the message (in a voice format, text-to-speech conversion is required). Sends a reply to John in a voice form at, the provider converts it in a text format and sends an E-mail to Mike. Meanwhile John unholds the call to inform Mary he has to hang-up. 5.5 Distributed and Enhanced Call Center The Distributed and Enhanced Call Center scenario shows several sides of IN-Internet integration. It features the speech connection of a PSTN terminal to a VoIP terminal, where the service logic controlling the call resides in a 3rd party domain. It also shows how a call between a VoIP terminal and a PSTN terminal could be set up initiated from the Internet, through a 3rd party service. The call center agents are provided with a PC with a Web interface. The PC is connected to Internet, and it uses this con nection to register/deregister availability of handling incoming calls (data communication), and to establish the communication with the client using VoIP (voice communication). This solution has the advantage that the call center can have the agent positions totally distributed and the agent could even be located in his/her own home. The agent is also able to place outgoing calls by the use of a click-to-dial like service to initiate a call (PC to phone). The logic and data for selecting the "best" availa ble agent is allocated in an external domain seen from the IN point of view. It could reside in the company administration domain or this service could be outsourced to another company. The logic and data for agent selection could also be allocated in the IN domain, but this case is not examined further here. Service features that have an impact on the PSTN-to-IP context are: - Incoming call notification and advanced reply. The best available agent is notified on his/her PC about incoming calls directed to him/her. He is presented with a menu window, which allows him to choose between the following choice: 1. Accept the call 2. Reject the call 3. Forward the call to another agent 4. Reply by typing a message that is translated into speech 5. Reply by sending back a dynamic Web page built by composing information 6. IN service request from the Internet. It should be possible to open the access to IN functions during an internet session. It should enable: March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 15] - PINT-like services: Click (Request) to Dial , Click (Request) to Fax and Voice access to web content. - Access to customer and service information. - Access to IN routing services, IP telephony GW using IN-based address resolution. Services may required specific Intelligent Peripheral resources with media transformation like text-to-fax and text-to-speech. The following services can well help in defining requirements in the context of how services supported by IN entities can be started from Internet requests. 6.1 Click-to-Dial (C2D) A user is able to initiate a telephone call by clicking a button during a web session. The called address (as well as the caller address) is either an IP address or a phone line number. The charging party could be either the initiator or one of the called parties. Service features that have an impact on the IP-to-PSTN context are: - Starting a call by selecting an user(s) on a Web page 6.1.1 Click2Dial invocation The user invokes the Click2Dial service. The service logic contacts Call Control to setup a call to setup a call between the caller and the called user. It should be possible for a user to initiate a call between two parties, neither of which is the user. If the user invoking the call is to be billed, this means that the C2D service has to known the initiator of the call so that the information may be passed to billing system. In the C2D service, especially if the call is placed (and paid for!) by a third party, it is difficult to determine who is the originating party and who is the destination party. This has an impact on the use of the Parlay interface insofar as some order must be placed on the parties so that there is an origination and a destination to the call. This document assumes that the originating address is taken as the first address entered (User A) and the destination address is the second address entered (User B ) Preconditions The user is logged on to the system and has selected the click-2-dial service for invocation Post Conditions A call has been established between the origination and the destination. The user (this is the user to be billed for the service) requests March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 16] that a call be placed between two users: User A and User B. The C2D service is requested to initiate a call between the indicated parties. The C2D first initiates the routing of the call towards the first party in the call (User A). The C2D service is notified that the routing of the call towards the first party has been successful. Then it initiates the routing of the call towards the second party in the call (User B) and it is notified that the routing of the call towards the called party has been successful. The call should now be active. 6.1.2 Call Setup The following sections describe the call setup from the viewpoint of the Call control. Four scenarios have been identified: PSTN-PSTN, PSTN-PC, PC-PSTN, PC-PC. 6.1.2.1 PSTN as originating party terminal The address of the origination is resolved from the User Profile. If the originating user is registered on a PSTN phone then the originating call leg is routed towards the PSTN. Preconditions The calling user is logged on to the system and has selected/invoked the click-to-dial service. Post Conditions The call has been set up towards the origination address. A call leg has been established towards the origination address. First the user A's UserProfile is contacted to return the correct terminal to which the call should be delivered: in this case a PSTN address. An invocation to create a new Call is sent to the call control manager which returs the call session Id. The call manager creates a new call. At this point the service logic initiates the routing of the call towards the first party in the call (User A) and waits the result of this operation. The result is sent to the C2D service logic. 6.1.2.2 PSTN as destination party terminal (PSTN-PSTN) The address of the destination is resolved from the User Profile. The user is registered on a PSTN. The call is routed towards the destination. Preconditions The call has been routed to the origination. Post Conditions The call has been set up towards the destination. A call leg has March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 17] been established towards the destination. The call setup is complete. The C2D service logic requests to user B's UserProfile to return the correct terminal to which the call should be delivered. The Address of the terminal to which the call should be delivered -in this case a PSTN address - is returned. The C2D service logic initiates the routing of the call towards the second party in the call (User B). The result of this operation is sent to the C2D service logic. 6.1.2.3 PC as destination party terminal (PSTN-PC) The address of the destination is resolved from the User Profile. The user is registered on a PC. The call is routed towards the destination. Preconditions A call leg has been established to the origination. Post Conditions The call has been set up towards the destination. A call leg has been established towards the destination. The call setup is complete. The C2D service logic requests to user B's User Profile to return the correct terminal to which the call should be delivered. The Address of the terminal to which the call should be delivered -in this case an IP address- is returned. The service logic then invites User B to the current session by using the User ID of the user and the address of the terminal at which the user is to be invited. SIP may be used as the invitation mechanism. User responses to the invitation. The response to the invitation is sent to the service logic. In case the user accepted, the C2D service logic initiates the routing of the call towards the second party in the call (User B). The result of this operation is sent to the C2D service logic. 6.1.2.4 PC as originating party terminal The address of the origination is resolved from the User Profile. If the originating user is registered on a PC then a call leg is routed towards the Internet. In reality the call is not routed yet. But from the point of view of the service logic, the Call Control behaves as if the call has been routed correctly. Preconditions The calling user is logged on to the system and has selected/invoked the click-to-dial service. Post Conditions The call has been set up towards the origination The C2D service logic requests to user A's UserProfile to return the March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 18] correct terminal to which the call should be delivered. The Address of the terminal to which the call should be delivered - in this case an IP address - is returned. The service logic then invites User A to establish a new session. SIP may be used as the invitation mechanism. User responses to the invitation. The response to the invitation is sent to the service logic. In case user A accepts the service logic instructs the call manager to create a new call. The call manager creates a new call. The C2D service logic initiates the routing of the call towards the first party in the call (User A). The result of this operation is sent to the C2D service logic. 6.1.2.5 PSTN as destination party terminal (PC-PSTN) The address of the destination is resolved from the User Profile. The user is registered on a PSTN. The call is routed towards the destination. Preconditions The call has been routed to the origination. Post Conditions The call has been set up towards the destination. A call leg has been established towards the destination. The call setup is complete. The C2D service logic requests to user B's UserProfile to return the correct terminal to which the call should be delivered. The Address of the terminal to which the call should be delivered -in this case a PSTN address-is returned. The C2D service logic initiates the routing of the call towards the second party in the call (User B). The result of this operation is sent to the C2D service logic. The call setup is complete. 6.1.2.6 PC as destination party terminal (PC-PC) The address of the destination is resolved from the User Profile. The user is registered on a PC. The call is routed towards the destination. Preconditions A call leg has been established to the origination. Post Conditions The call has been set up towards the destination. A call leg has been established towards the destination. The call setup is complete. The C2D service logic requests to user B's User Profile to return the correct terminal to which the call should be delivered. The Address of the terminal to which the call should be delivered -in this case an IP address - is returned. March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 19] The service logic then invites User B to the current session by using the User ID of the user and the address of the terminal at which the user is to be invited. SIP may be used as the invitation mechanism. User responses to the invitation. The response to the invitation is sent to the service logic. In case the user accepted, the C2D service logic initiates the routing of the call towards the second party in the call (User B). The result of this operation is sent to the C2D service logic. The call setup is complete. 6.2 Meeting Scheduler (MS) This section provides a description for a meeting scheduler and initiator service. In it, an user has a web based user interface to schedule a meeting. He will decide the time and the attendants. This information is recorded for the service profile, once it is decided it is authorised. The timing information is also used by an external application that launches the service via the access function. Every meeting attendant is confirmed, either with an e-mail notification and a following confirmation process via a web page or with a phone call. Once the service is launched, it uses the attendants list and the service profile to locate the users. Two kind of communications are considered: VoIP and POTS. The service sets up the communication to the end users using a service node. The service node has a direct connection to the PSTN and uses the call control component, controlling the vocal gateway to establish the connection to the VoIP terminals. The service establishes as many calls as needed and puts all of them in the same co mmunication. Service features that have an impact on the IP-to-PSTN context are: - Starting a meeting by selecting a user(s) and timing on a Web page. 6.2.1 Meeting creation The Meeting manager accesses via a Web Browser the provider Web page containing the MS applet. (S)He sets relevant information for the meeting to take place, e.g. meeting attendants and date/time of the meeting - along with some authentication information to confirm meeting managerĘs identity. Preconditions The Meeting manager must have a Web access to log in the system and to set the MS service. Post Conditions Meeting confirmation process is started. The Web Server launches the Meeting Scheduler Servlet, which interacts with the Service Logic. The MS Servlet checks in order to confirm the meeting manager authentication data. Furthermore it checks if the meeting participants identifier do really exist and whether the terminals specified in the User Profile configurations March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 20] meet the service requirements. The MS Servlet then, accesses the Meeting Profile Manager to include the new meeting information. Meeting Profile Manager returns a meeting identifier whi ch have be used by the meeting participants to confirm their attendance to the meeting. This identifier is also shown to the meeting manager in a HTML page confirming the success of the operation. 6.2.2 Meeting confirmation Preconditions A meeting must have been created following the meeting start process. Post Conditions Participants are informed about the meeting by Email or by phone. During the meeting confirmation phase the service logic checks for every meeting participant the availability of an E-mail address in his/her user profile. If an E-mail address exists, the MS service logic sends an E-mail to the meeting participants informing her/him of the meeting. If the meeting participant has no e-mail address, the service logic chooses a telephone number and a time at which the meeting participant might be available by elaborating the User Profile data and uses this information to sch edule, via an external application, an attendance confirmation via phone. The sequence is repeated for every meeting participant in the participant list of the meeting. 6.2.3 Web attendance confirmation Preconditions The participant received an e-mail including the meeting attendance confirmation URL, meeting identifier and related meeting information like the participant list. Post Conditions The participant confirms his attendance. The participant accesses via a Web browser the Web page containing the meeting attendance confirmation form. The participant is authenticated by means of user name and password which are checked against personal data in his/her User Profile. Then (s)he selects the confirmation choice and finally (s)he is shown with a HTML page to notify the success of the operation. 6.2.4 Conference activation Preconditions The meeting activation process has obtained the list of possible points of presence for of the participants. Post Conditions The conference is activated. March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 21] The meeting activation process is activated by a time-dependent scheduler to start a new conference. It has previously obtained a list of attendants from the meeting profile manager containing the information related to those users who confirmed their attendance. From the User Profile, it gets a list of possible locations for each user, ordered by user preferences at the time when the conference is going to take place. Once it has obtained all the needed information related to the attendants, the service logic creates a new call instance in the Service Node through interacting with the Call Control. 6.2.5 Call legs set up Preconditions A new call has been created but no call leg is attached yet. Post Conditions The participants' call legs are created Once the conference has been started and a call has been created, the meeting activation process needs to create a call leg for each of the attendants. The first point of presence of the first attendant is selected and the Call Control is asked to route the call leg to that address. If the address is a telephone number, the Call Control just instructs the Service Node to route the call leg to it. If the address is an IP address, the call leg has to be routed through a vocal gateway. Consequently the Call Control instructs the Service Node to route the call leg to one of the phone numbers assigned to the vocal gateway and instructs the gatekeeper to translate that number to the desired IP address. When the call reaches the vocal gateway it requires from the gatekeeper, using RAS proto col, the target IP address. If the end user doesnĘt answer the call, the next point of presence is selected and the call leg is routed to this new address. This procedure is repeated until the end user answers or all possible addresses are tried. When an user answers, music or some announcement is played to him/her until the process to call all the attendants is finished. At that point the conference is ready to be set up. 6.2.6 Conference start Preconditions A call has been created and all the related call legs have also been created, but they are not attached yet. Post Conditions The conference has been completely set up and the attendants can talk to each other. When all attendants have been contacted and they have answered (or at March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 22] least all their different possible addresses have been tried) the conference can be started. As a first step the music/announcement is stopped. Then the Service Node is instructed to create a conference and to attach the call legs to it. 7. Security considerations P909 recognises that security considerations are quite essential for successful deployment of the described services. P909 addresses security considerations for the example services by focusing on the following items: o Peer entity authentication is required to allow an end-user to prove its identity to the provider domain in the network. This can be accomplished via a Web-based access by means of the user name and password or personal number and PIN. o In addition, a secure communications could be used in case personal data are transmitted for authentication and user prefererences elaboration purposes e.g. by means of the SSL technology. o End-user profile verification to validate the authorisation of the end user to use a service. o Prevention of uncontrolled disclosure of information without the permission of its owner. Since the security issues are still work in progress in P909,the material of this section is of preliminary nature and must be revisited in a forthcoming paper. 8. References [1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 [2] S.Bradner, "The Internet Standards Process", RFC2026 [3] M. Barry et al., "What an IN system should be", Deliverable 1 Eurescom P909, October 1999 [4] V. Blavette et al., "Architecture and Scenario for Internet-IN Convergence", Deliverable 2 EURESCOM P909, February 2000 [5] I.Faynberg et al., "On a pre-SPIRITS Implementation in the Lucent Technologies Online Communications Center", draft-ietf-spirits-lucentocc-00.txt, February 2000 [6] I.Faynberg et al., "Toward Definition of the Protocol for PSTN-initiated Services Supported by PSTN/Internet Interworking", draft-ietf-spirits-protocol-00.txt, March 2000 [7] L. Slutsman, "A proposal for new PINT building blocks with March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 23] applications to Conference Calling", draft-ietf-pint-conf-01.txt, Expires: July 2000 9. Authors' Addresses Valerie Blavette E-mail: valerie.blavette@cnet.francetelecom.fr Telephone: +33 2 96053221 Fax: +33 2 96053784 CNET/France Telecom Technopole Anticipa 2 avenue Pierre Marzin 22307 Lannion Cedex (France) Gianni Canal E-mail: canal@cselt.it Telephone: +39 011 2285630 Fax: +39 011 2285069 CSELT/Telecom Italia, via Reiss Romoli, 274, I-10148 Torino (Italy) Uwe Herzog E-mail: Uwe.Herzog@telekom.de Telephone: +49 6151 837880 Fax: +49 6151 834590 T-Nova Deutsche Telekom Innovationsgesellschaft mbH Technologiezentrum Darmstadt D-64307 Darmstadt (Germany) Carlo Alberto Licciardi E-mail: carlo.licciardi@cselt.it Telephone: +39 011 2285705 Fax: +39 011 2285069 CSELT/Telecom Italia, via Reiss Romoli, 274, I-10148 Torino (Italy) Stephane Tuffin E-mail: stephane.tuffin@cnet.francetelecom.fr Telephone: +33 2 96053217 Fax: +33 2 96053784 CNET/France Telecom Technopole Anticipa 2 avenue Pierre Marzin 22307 Lannion Cedex (France) 10. Acknowledgments The authors would like to acknowledge Roberto Minerva and Alec Brusilovsky for their contributions to the creation of this March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 24] document. 11. Glossary API Application Programming Interface C2D Click-To-Dial (Request to Call) CALL CLI Calling Line Identity CORBA Common Object Request Broker Architecture CTI Computer Telephony Interface DP Detection Point ECA Event Condition Action EDP-R Event Detection Point-Request ETSI European Telecomminications Standards Institute EURESCOM European Institute for Research and Strategic Studies in Telecommunications GSM Global System for Mobile communication GW GateWay HTML HyperText Markup Language ICW Internet Call Waiting IETF Internet Engineering Task Force IN Intelligent Network INAP Intelligent Network Application Protocol IP Internet Protocol IN-IP IN-Intelligent Peripheral ISP Internet Service Provider ITU International Telecommunication Union IVR Interactive Voice Response MGCP Media Gateway Control Protocol MS Meeting Scheduler MCU Multipoint Conference Unit NAS Network Access Server PC Personal Computer PDA Personal Digital Assistant PIC Point-In-Call PIN Personal Identification Number POTS Plain Old Telephone Service PSTN Public Switched Telephone Network RFC Request For Comments SCP Service Control Point SIP Session Initiation Protocol SLEE Service Logic Execution Environment SMS Service Management System SN Service Node SSL Secure Socket Layer SSP Service Switching Point TDP Trigger Detection point TINA Telecommunication Information Network Architecture TLC Telecommunication URL Uniform Resource Locator March 2000 EURESCOM P909 contribution to PINT and SPIRITS [Page 25] VP Virtual Presence VoIP Voice over IP (Internet Protocol) VPN Virtual Private Network WG Working Group March 2000