Internet Engineering Task Force J.Bjorkner, S.Nyckelgard Internet Draft Hotsip, Telia Document: draft-bjorkner-spirits-vsua-00.txt July 2000 A SPIRITS solution based on virtual SIP user agents 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 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. Abstract This document discusses events occurring in a telephony network that could be useful for call related services created in an Internet environment. It also shows one possible implementation of a SPIRITS protocol based on Session Initiation Protocol (SIP) [2]. The SPIRITS working group has not yet done any protocol decisions, so this draft is written for informative purpose showing that the introduction of virtual SIP user agents (SIP UAs) in a SPIRITS client makes it possible to realize the services described in the pre-spirits implementations document [3]. The advantage of introducing SIP UAs in the SPIRITS client is that a SPIRITS proxy and a SPIRITS server then also could be used by any other voice network that natively speaks SIP, for example wireless 3G networks and voice over IP networks. This would also allow the PSTN network to utilize the services created for those networks. The document is not focused on how these services are subscribed for within the telephony network, since there is several appropriate methods to do this from an end users perspective, from calling the customer service to submit a web form. The action taken after this subscription is dependent of the voice network attached to the J.Bjorkner,S.Nyckelgard [1] Internet Draft vsua July 2000 SPIRITS client. This document has the focus on the Internet specific parts of the protocol, which should be voice network independent. 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2. Introduction This document describes a solution to the problem where an event in a telephony network needs to trigger a service that will operate on a particular data within the telephony network associated with the event. The solution described makes it possible to distribute this service logic out from the telephony network to a host on an IP network, or in fact also to a host on the Internet. The solution is coherent with the architecture developed within the SPIRITS working group and proposes a solution based on SIP (Session Initiation Protocol) [2]. There are two reasons to use SIP as a foundation for the SPIRITS protocol: By using SIP will it be possible for SIP speaking voice networks to utilize the SPIRITS services; SIP is designed for Internet use with respect to scaling and security and contains necessary placeholders for information related to voice calls. The solution described fits in to the SPIRITS architecture defined by the SPIRITS working group shown in Figure 1. The interfaces defined with this solution are B and C. The interface D is not described in this document, since it is dependent on the signaling protocols used in the underlying network. The D interface only affects the SPIRITS client implementation according to this proposal and leaves the interfaces B and C unaffected. If one would like to use the already existing service protocols defined for PSTN to talk to IP based hosts, then these protocols can be tunneled as they are by using the protocols defined in the IETF SIGTRAN working group. Those protocols are however not designed for an Internet environment with respect to trust relations and transport conditions, so therefore could it be useful to map functionality from these protocols to something more Internet friendly. Another disadvantage with this method is that these protocols exist in different national flavors in different countries and even in some cases differs among the networks owned by a single operator. On the Internet exists no flavors of a standard, and it is important that a SPIRITS server could work together with several operators in different countries, without having to install special software to make it work. These problems are solved by a protocol mapping as described in this document. J.Bjorkner,S.Nyckelgard [2] Internet Draft vsua July 2000 +-----------+ | SPIRITS | | Server | +-----+-----+ | B +-----------+ | SPIRITS | | Proxy | +-----+-----+ | C +-----------+ | SPIRITS | | Client | +-----+-----+ | D +-----------+ | Voice net | | service | | function | +-----------+ Figure 1. The basic idea with this proposal is to show that it is possible to create a solution which make the PSTN phones to appear as if they were SIP phones to the SPIRITS server. The motivation for this is that there will soon be a large number of innovative services that will be deployed for SIP networks. If a PSTN could behave as a SIP networks from a signaling point of view, it could easily make use of these services. Another rationale to use telephony services implemented in SIP is that SIP will be the signaling protocol used for the all IP 3G wireless networks. The functions provided by service protocols used in an IN environment in today's PSTN networks differs depending on which version and flavor of the IN protocol that is used. Instead of focusing on the particular functions and the naming of the functions within the different IN protocols, a set of general functions of interest for a SPIRITS service are defined and explained in the next section. The set of general functions is a subset of capabilities of the current IN protocols. They provide a balanced tradeoff between complexity and functionality. Having this signaling protocol agnostic view ensures that no PSTN specific behavior is built into the SPIRITS protocol, which is essential in order to make SPIRITS useful also for other voice networks than PSTN. 3. Telephony events that could trigger a SPIRITS server J.Bjorkner,S.Nyckelgard [3] Internet Draft vsua July 2000 This section lists events occurring in a voice network that could trigger a request from the voice network to a SPIRITS server. It also outlines the information that is passed between the SPIRITS client and the SPIRITS server. Parameters and formats are subjects for a follow-up draft. The events are divided into three different categories: call origination, call termination and non-call related. C->S: denotes information passed from the SPIRITS Client to the SPIRITS server. S->C: denotes information passed in the opposite direction. 3.1 Call origination events 3.1.1 Event O1 (Call initiation) C->S: call identifier, calling party address, called party address, dialed address, S->C: response code, call identifier, [calling party address, called party address, dialed address] This event is triggered when a user has filled out a complete address (i.e. dialed a number) but before a route has been selected for the call. A normal response from the SPIRITS server carries the same parameter fields as the query but the SPIRITS server may have changed any data field(s) except 'call identifier'. The returned data is used for routing the call in the voice network. An alternative response may indicate to the SPIRITS client to complete the call as dialed or to reject the call. Services possible to create with this event are e.g. Call Barring, Speed Dialing, VPN services, Number Portability etc. This event maps to a SIP Invite request. 3.2 Call termination events 3.2.1 Event T1 (Call received) C->S: call identifier, calling party address, called party address, dialed address, S->C: response code, call identifier, [calling party address, called party address, dialed address] This event is triggered when a call is received at the switch servicing the callee, before the phone starts ringing. J.Bjorkner,S.Nyckelgard [4] Internet Draft vsua July 2000 The response from the SPIRITS server may indicate to the SPIRITS client to make the callee's phone ring, to redirect the call to another destination or to reject the call. Services possible to create with this event are: Conditional Redirection, Call Filtering, Internet Call Waiting, Internet Caller Identification, etc. This event maps to a SIP invite request. 3.3 Call progress informative events 3.3.1 Event I1 (Call failed) C->S: call identifier, calling party address, called party address, dialed address, reason of failure S->C: This event is sent if a call for some reason failed to be set up. This event maps to a SIP 503 Service Unavailable response. 3.3.2 Event I2 (Callee busy) C->S: call identifier, calling party address, called party address, dialed address S->C:-- This event is sent if the called party is busy due to an ongoing phone call. This event maps to a SIP 486 Busy Here response. 3.3.3 Event I3 (Call rejected) C->S: call identifier, calling party address, called party address, dialed address, reason of rejection S->C:-- This event is sent if the called party rejects an incoming call for some reason. This event maps to a SIP 603 Decline response. 3.3.4 Event I4 (Call terminated) J.Bjorkner,S.Nyckelgard [5] Internet Draft vsua July 2000 C->S: call identifier, calling party address, called party address, dialed address S->C:-- This event is sent if any of the calling parties terminates the call by hanging up. This event maps to a SIP Bye request. 3.4 Non call related events 3.4.1 Event N1 (User logged on) C->S: user id S->C: -- This event is sent when a user logs on to his phone, i.e. turns on his cell phone. This information is useful for intelligent routing services. This event maps to a SIP Register request. 3.4.1 Event N2 (User logged off) C->S: user id S->C: -- This event is sent when a user logs off from his phone, i.e. turns off his cell phone. This information is useful for intelligent routing services. This event maps to a SIP Register request. 3.4.1 Event N3 (Position changed) C->S: user id, spatial location S->C: -- This event is sent when a user updates his position in the network. His geographical coordinates for his current position are sent within the event. This information is useful for intelligent call routing services. Note. It is probably good to have the option to send this event slightly before an event that might have use of the information, J.Bjorkner,S.Nyckelgard [6] Internet Draft vsua July 2000 instead of constantly sending these messages when an user is moving around. This event maps to a SIP Register request. 4. Architecture Since telephony calls usually involves two ore more parties is it proposed that the SPIRITS client actually consists of two logical entities representing the calling and called party. These entities could be viewed as virtual phones, or virtual users. Those entities are called user agents (UA) throughout this document. The user agent representing the calling party is named user agent A (UAA), and the UA representing the called party is named user agent B (UAB). Depending on if the SPIRITS client is residing in the originating end of the network or terminating end of the network are these named originating or terminating user agents (OUA, TUA). The idea is that when a call is to be set up from a user subscribing to a SPIRITS service is a UAA corresponding to the calling party created within the SPIRITS client. At the same time is a UAB set up to represent the called party. An event is sent from the UAA to the SPIRITS proxy, which could modify the call setup information before it is sent to the UAB. The SPIRITS proxy will then remain within the signaling path between the UAA and the UAB throughout the call to receive call related events. The advantage with this setup is that the UAA and UAB don't have to reside within the same SPIRITS client for the services residing in the SPIRITS proxy to work. The same SPIRITS proxy could then serve voice networks of a more distributed nature. Some services, for example Internet Call Waiting, requires some end user interaction. In this case will the SPIRITS proxy forward the incoming event to the SPIRITS server for user notification. If a response is not received from this server within a certain amount of time could the proxy process the message according to some pre- defined logic. The most complex scenario is when a user who has an originating SPIRITS service is calling a user who has a terminating SPIRITS service. In this case will the call informative events pass flow through two SPIRITS servers as shown in Figure 2. J.Bjorkner,S.Nyckelgard [7] Internet Draft vsua July 2000 +----------------+ +----------------+ | SPIRITS proxy | | SPIRITS proxy | +----------------+ +----------------+ | | | | /|\ | /|\ | | \|/ | \|/ | | | | +-+----+--+----+-- +-+----+--+----+-+ | |OUAA| |OUAB| | | |TUAA| |TUAB| | | +----+ +----+ | | +----+ +----+ | | SPIRITS Client | | SPIRITS client | +----------------+ +----------------+ | | 0---0 +-----------+ +-----------+ 0---0 /_\-->-| Exec. Syst|------------->-------|Exec. Syst.|-->-/_\ +-----------+ +-----------+ Orig. Side Term. Side Figure 2. 5. Transport protocol This document proposes to use SIP as a transport protocol for the SPIRITS messages. One reason for this is that it designed to work in an environment consisting of the entities described in the SPIRTIS architecture. As the next section will show could SIP be used as it is without any new extensions to be able to create the services described in the pre-SPIRITS implementations document [3]. Instead needs the behavior it the entities be specified, and the encoding of the necessary information to be transported from the SPIRITS client to the SPIRITS proxy and servers. 6. System components This section gives a description of the components necessary to create a SPIRITS service and their behavior. 6.1 Executive system This is the logic in the voice network responsible for setting up a call, in a PSTN network is this corresponding to a switch. The executive system is required to report all events occurring in the J.Bjorkner,S.Nyckelgard [8] Internet Draft vsua July 2000 telephony network necessary to create SPIRITS services to the SPIRITS client. The executive system has the knowledge that a user is subscribing to a SPIRITS service and is invoking a SPIRITS client for all inbound and outbound calls for this user. 6.2 SPIRITS Client The SPIRITS client is the bridge between the voice network's service function and the SPIRITS services created in an IP environment. The SPIRITS client have a default behavior on inbound calls that triggers it to send out requests to a SPIRITS proxy on the IP network. Its handling of the call is determined from the responses of these requests. Therefore is there no need for the SPIRITS client to have any knowledge of the service executed in the IP network. The SPIRITS client could be viewed of having two sides, one inbound side and one outbound. An inbound call to a user having a SPIRITS service is associated with the inbound side of the client and that UA, the UAA. Depending of the type of service could the SPIRITS client stay involved in the signaling path for the rest of the call. In this case is an outbound UA, UAB, associated with the connected address. In the case of a service that wants to stay within the signaling path is the invite message forwarded to the UAB, with a request URI containing the number to connect the inbound call leg with. The address of UAB is carried in the route: header of the initial Invite request. 6.2.1 SPIRITS Client UA Outbound Requests The UAA sends a SIP Invite to the SPIRITS proxy. The request URI contains the dialed inbound number, the from: field the calling party's number and the to: field the originally dialed number. The to: field could differ from the request URI if any redirection had occurred in the voice network. The UAA also inserts a route: header indicating the address of the UAB associated with this call. The UAA or UAB sends a BYE request when an active call associated to the client is terminated to the proxy. 6.2.2 SPIRITS Client UA Inbound Requests When a SIP Invite is received by the UAB makes the SPIRITS client the executive system to create an outbound call leg to the telephone number in the request URI. The progress of setting up this call leg is reported back to the SPIRITS proxy with appropriate provisional responses. When the called party on this leg answers the phone is a 200 OK sent back through the proxy to the UAA. If the Invite contained a record-route header would all further requests be sent according to these routes. By this could a SPIRITS proxy ask to receive the BYE message sent when the call is terminated. J.Bjorkner,S.Nyckelgard [9] Internet Draft vsua July 2000 If the Invite message contains a replaces: header would the SPIRITS client tear down any ongoing call leg towards the telephone number and call ID indicated in this header. The replaces header is introduced in the SIP Call Control Services draft [4]. When a Bye request is received by any UA is the call leg associated with this UA terminated by a signal from the SPIRITS client to the executive system. 6.2.3 SPIRITS Client responses A number of different SIP responses could be received to the invite sent by the UAA. The action to these responses is described below. 200 OK, indicates that the SPIRITS client should signal down to the executive system to connect inbound call leg with the call leg corresponding to the UAS. The SPIRITS client will stay associated with the call until it ends. 302 Moved Temporarily, the SPIRITS client tells the executive system to redirect the incoming call to the telephone number in the contact: field of the response. The SPIRITS client is released from the call. 404 Not found, indicates that the SPIRITS client should signal down to the executive system to connect the call to the telephone number of the inbound call. The SPIRITS client is released from the call. 603 Decline, tell the executive system to reject the inbound call. The SPIRITS client is released from the call. 6.3 SPIRITS proxy The SPIRITS proxy is the entity that implements the SPIRITS services. The behavior is similar to a SIP redirect/proxy server since it performs some action based on the request URI of an incoming request and either responds back or forwards the invite to the next hop server. In the case of a SPIRITS proxy would the next hop server always be the UAB since the UAA always inserts a route header containing its address. If there is need for user interaction would the proxy know if a user is online by the register messages sent from the user to the proxy. In this case could a request be sent to the user before the incoming request is forwarded or responded to. 7. Call flows This section shows how the services described in the pre spirits implementations document could be realized according to the proposed solution. The target services according to the SPIRITS charter are: Internet Call Waiting, Internet Caller Identification and Internet Call Forwarding. The SPIRITS protocol should not be hard wired to J.Bjorkner,S.Nyckelgard [10] Internet Draft vsua July 2000 just fit these services, the protocol is a useful tool for people implementing services in a SPIRITS proxy or SPIRITS server. These examples show the involved message transactions. It needs to be defined how to encode the information to be transported within the messages. 7.1 Internet Call Waiting Internet Call Waiting (ICW) is an example of a terminating service which is executed when the call signaling is reaching the executive telephone system responsible for the called party. Since ICW is just involved during the call setup phase is there no need for the SPIRITS server to be involved in the signaling path after the call has been established. The following steps are invoked in the service execution. 1. The inbound call setup signaling is received at the receiving executive system. This system associates the called number with a SPIRITS customer and invokes a SPIRITS client. This invocation is out of scope for this working group, and is dependent on the signaling mechanisms used in the voice network. 2. The SPIRITS client creates an UAA and UAB which will be used to control the call setup in the voice network. 3. The UAC send a SIP Invite message to the SPIRITS Proxy. If a user is online would he have sent a SIP Register to the SPIRITS proxy that contained the IP host he is running his ICW software on. In this case would the proxy forward the Invite message to the ICW client (SPIRITS server). If he were not registered with the SPIRITS proxy would the proxy respond with a 404 Not Found message to the UAA. This would cause the SPIRITS client to signal back to the executive system to continue the call setup with the dialed number. 4. If the user were online would he receive an Invite message. This invite message contains the calling party's number in the from: field that could be used for caller identification. The ICW software (SPIRITS server) would show a window telling the user that there is an incoming call. He could then have the option to reject, accept or redirect the call to another number. In the case of rejection would the SPIRITS server return a 603 Decline response to the proxy. This would cause the proxy to respond with the same message to the UAA. If the call is accepted is the Invite forwarded to the UAA contained in the route: header. This invite will contain a replaces: header to indicate that the ongoing call should be terminated. The call ID for this ongoing were fetched by the SPIRITS proxy during the call setup of this ongoing call. In this case would the UAB cause the executive system to disconnect any connected voice calls for this user and after that connect the inbound call that was accepted. If the user whishes to redirect the call to any other answering place, for example a soft phone on his PC or a cell phone would a 302 Moved Temporarily be returned with the phone number to redirect to in the J.Bjorkner,S.Nyckelgard [11] Internet Draft vsua July 2000 contact: field of the answer. This would cause the executive system to set up the inbound call to this telephone number. 5. When a response is received at the UAA is action taken according to above. This would cause the call to be connected and make a phone to start ringing. 7.2 Internet Caller Identification The Internet Caller Identification (ICI) service is a somewhat simplified version of Internet Call Waiting. The message flow is the same as for that service, except that the UAC immediately connects the call. The Invite message sent out from the UAA would be received by the ICI software that a user have registered with the SPIRITS proxy. This message would cause a window to pop up which displays the name and number of the calling party. This information is fetched from the from: field of the Invite message. 7.3 Internet Call Authorization This is an example of a more advanced call barring service which is an originating service. The idea is that a user can set up rules which regulates which number that can be dialed or not. This set of rules is stored in the SPIRITS server. If a number is dialed that is blocked by the rule set could the SPIRITS server alert the user that this is the case, and ask for an authorization code. This would cause a software to pop up a window asking for the code. If the right code were entered would the call setup continue. The message flow for this service is as follows: 1. All outbound calls for a user be detected by the executive system. The dialed number would be sent to the SPIRITS client that creates an UAA for this call. 2. An Invite message is sent to the SPIRITS proxy. This proxy contains an access control list of the numbers that this user is allowed to call. If there is a granted number is a 200 OK sent back to the UAA. If it is a number that is not permitted to call is the action dependent of if the user is running his ICA application or not. If the user were not logged on would the proxy return a 603 Decline to the UAA. 3. If the user is logged on, i.e. have registered with the proxy is the Invite forwarded to the application. In normal SIP scenarios is the client authenticating himself for the server, i.e. authentication is necessary to send a request. In this scenario is the opposite necessary, authentication is necessary to send a response. This could be done by inserting an WWW-authenticate header containing a challenge in the Invite message sent from the proxy. This would cause a window to pop up asking for an authorization code and also displaying the dialed from and to numbers. From this code is a response calculated and returned in a authentication header in a 200 OK response back to the proxy. The J.Bjorkner,S.Nyckelgard [12] Internet Draft vsua July 2000 proxy checks whether this was a valid authentication, and if it was the case forwards the Invite to the UAB to set up the call. Otherwise is a 603 Decline returned to the UAA. 7.4 Internet Call Distribution This is an example of how an automatic call distribution service could be built on top of the tools described in this document. A call distribution service is a service that selects a termination number depending on some built in logic, independent of the dialed number. The service is a terminating service. This service is also involved during the whole call setup and the call itself since it needs to know if a call was successfully set up and when a call ends. The steps involved during a call invoking such a service is described below. 1. An inbound call is received by the executive system in the voice network. The executive system has the knowledge that this dialed number has an associated SPIRITS service. 2. The executive system invokes the SPIRITS client and provides it with the called and calling party number. 3. The SPIRITS client creates a UAA and UAB. The UAA is associated with in inbound call leg to the executive system. The UAB will be the entity responsible to create an outbound call leg from the executive system towards a recipient of the call. The recipient is of the call determined by the SPIRITS proxy according to some built in logic. These two user agents could be viewed as mirrors of the phones involved during the call. 4. The UAA sends an Invite message to the SPIRITS proxy. The dialed number is inserted in a tel: URL in the request URI of the message. The proxy looks performs its logic based on the values of for example the request URI and the from: field. Based on this information is a new termination number determined which is inserted in the request URI of the invite message before it is forwarded. Since the SPIRITS client needs to get this information to the UAB, is a route header containing the address of the UAB inserted in the Invite message sent to the SPIRITS proxy. This will force the proxy to forward the Invite to the UAB. The proxy also inserts a record- route header in the Invite message before it is forwarded, to ensure that all further requests is sent through the proxy. 5. The UAB receives the Invite message. The request URI contains the number to be called. The UAB uses this number and makes the executive system to contact this number. The executive system sends back status information to the SPIRITS client regarding the call setup progress. These messages are mapped to appropriate SIP provisional responses and are sent back from the UAB via the proxy to the UAA. If the call setup fails or takes too long time could the proxy send a Cancel to the UAB to terminate the call setup attempt, and send a new Invite to the UAB with a new number to try. By this could call forward on no answer be created. J.Bjorkner,S.Nyckelgard [13] Internet Draft vsua July 2000 6. When the executive system reports back to the SPIRITS client that the intended destination has been reached is a 200 OK sent back from the UAB through the proxy to the UAA. When this is received by the UAA will the SPIRITS client report down to the executive system that the call should be connected 7. When the calling party hangs up will a BYE message be sent from either the UAs, through the proxy, to the other UA. This is useful if the service in the proxy needs this to free up some resources or create some statistics. From the view of the proxy is this call setup looking like any call setup between two SIP endpoints. This has the advantage that the same service proxy could be used for both a SIP network and a SPIRITS enabled telephony network. The SPIRITS client is performing basically the same task as a PINT server is doing. The PINT server is creating two call legs in the PSTN and ties them together. In this case we already have one of the legs, and creates another which then is tied together with the first one. 8. Security Considerations Since the transactions occurring between the SPIRITS client and SPIRITS proxy contain sensitive data is it recommended that hop-to- hop encryption or a secure transport layer be used for this communication. These mechanisms are described in section 13 of [2]. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, M., et al., "SIP: Session Initiation Protocol", RFC 2543, March 1999 3 Lu, H., et al., "Pre-Spirits Implementations of PSTN-initiated Services", IETF Internet Draft draft-ietf-spirits- implementations-00.txt, May 2000 4 Schulzrinne,H., Rosenberg,J., "SIP Call Control Services (draft 1)",IETF Internet Draft draft-ietf-mmusic-sip-cc-01.txt, June 1999, www.cs.columbia.edu/~jdrosen 10. Acknowledgments 11. Author's Addresses J.Bjorkner,S.Nyckelgard [14] Internet Draft vsua July 2000 Jorgen Bjorkner Hotsip AB Barnhusgatan 16 SE-111 23 Stockholm Sweden Phone: +46 70 666 23 26 Email: Jorgen.Bjorkner@Hotsip.com Soren Nyckelgard Telia Research AB SE-123 86 Farsta Sweden Phone: +46 31 89 77 71 Email: Soren.M.Nyckelgard@telia.se J.Bjorkner,S.Nyckelgard [15] Internet Draft vsua July 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into J.Bjorkner,S.Nyckelgard [16]