Network Working Group H. Lu, Editor Request for Comments: 2995 I. Faynberg Category: Informational J. Voelker M. Weissman W. Zhang Lucent Technologies S. Rhim J. Hwang Korea Telecom S. Ago S. Moeenuddin S. Hadvani NEC S. Nyckelgard Telia J. Yoakum L. Robart Nortel Networks November 2000 Pre-SPIRITS Implementations of PSTN-initiated Services Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
Surveying the implementations, we can make the following observations: o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it. o Session Initiation Protocol (SIP) is used in most of the implementations as the base communications protocol between the PSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.) o All implementations use IN-based solutions for the PSTN part. It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS Working Group to define the inter-networking interfaces that will support interoperation of the future implementations of SPIRITS services. 1. Introduction ................................................ 3 2. Service Description of Internet Call Waiting ................ 4 3. Korea Telecom's ICW Implementation .......................... 5 3.1. Overview .................................................. 5 3.2. Network Architecture ...................................... 6 3.3. Network Entities .......................................... 7 3.3.1. SSP ..................................................... 7 3.3.2. SCP ..................................................... 7 3.3.3. IP ...................................................... 7 3.3.4. ICW Server System ....................................... 7 3.3.5. ICW Client System ....................................... 8 3.3.6. Firewall ................................................ 9 3.4. Network Interfaces ........................................ 9 3.5. Protocols ................................................. 9 3.5.1. Intelligent Network Application Part Protocol (INAP) .... 9 3.5.2. PINT Protocol ........................................... 9 3.6. Example Scenarios ........................................ 11 3.6.1. ICW Service Subscription ................................ 11 3.6.2. ICW Client Installation ................................. 11 3.6.3. ICW Service Activation .................................. 12 3.6.4. Incoming Call Notification .............................. 14 3.6.5. Incoming Call Processing ................................ 15 188.8.131.52. Accept the Call ....................................... 16
184.108.40.206. Forward the Call to Another Number .................... 18 3.6.6. ICW service De-activation ............................... 20 4. The Lucent Technologies Online Communications Center ........ 21 4.1 Overview ................................................... 21 4.2. Architecture .............................................. 22 4.3. Protocol and Operations Considerations .................... 25 5. NEC's Implementation ........................................ 28 5.1. Overview .................................................. 28 5.2. Architecture and Overall Call Flow ........................ 29 5.3. Interfaces and Protocols .................................. 31 5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface ........... 31 220.127.116.11. Connecting to SPIRITS Services ........................ 31 18.104.22.168. Message Types ......................................... 31 22.214.171.124.1 Connection Management Message Type ................... 31 126.96.36.199.2. Data Message Type ................................... 33 5.3.2. SPIRITS Server-ICW Client Application Interface ......... 34 5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use .............................................. 35 188.8.131.52. Overview .............................................. 35 184.108.40.206. Session Initiation .................................... 35 220.127.116.11. Secure Reliable Datagram Transport .................... 36 18.104.22.168. Session closure ....................................... 36 6. Telia/Nortel's Implementation ............................... 36 6.1. Overview .................................................. 36 6.2. Architecture and Protocols ................................ 37 6.3. Security .................................................. 39 7. Security Considerations ..................................... 40 8. Conclusion .................................................. 40 9. References .................................................. 41 10. Authors' Addresses ......................................... 41 11. Full Copyright Statement ................................... 44
The document first gives a detailed description of the ICW service. Then it proceeds to discuss each of the four implementations. The final sections of the document contains security considerations, the conclusion and references. It is important to note that even though the term "SPIRITS server" is used throughout the document, it has no universal meaning. Its connotation depends on the context and varies from implementation to implementation.
+ Playing a pre-recorded message to the calling party and disconnecting the call + Forwarding the call to voice mail + Forwarding the call to another number + Rejecting (or Forwarding) on no Response - If the subscriber fails to respond within a certain period time after the dialog box has been displayed, the incoming call can be either rejected or handled based on the treatment pre-defined by the subscriber. o Automatic Incoming Call Disposition - Incoming calls are automatically handled based on dispositions pre-defined by the subscriber without his or her real-time intervention. The subscriber can pre-define the default disposition (e.g., re- directed to voice mail) for general calls as well as customized dispositions for calls from specific numbers. In the latter case, the subscriber selects a particular disposition for each originating number and stores this information in a profile. When a call comes in, the subscriber won't be presented the call but can examine the treatment and outcome of the call from the caller log (as described in the call logging bullet). Naturally, this feature also allows the subscriber to specify the desired treatment for calls originating from private or unpublished numbers. o Multiple Call Handling - Multiple calls can arrive during call disposition processing. With multiple call handling, the subscriber is notified of the multiple calls one by one. o Call Logging - A detailed log of the incoming calls processed during the ICW service is kept. Typical information recorded in the log include the incoming call date and time, calling party number, calling party name, and call disposition. Section 2. (The major exception is the feature of receiving the incoming call over the Internet using voice over IP.) In addition, the Korea Telecom implementation supports flexible activation and de-activation of the ICW service:
o Automatic Activation/De-activation - When Internet dial-up connection is set up, the ICW service is activated or de-activated automatically. o Manual Activation/De-activation - The subscriber can de-activate the ICW service manually when call notification is not desired during the Internet dial-up session and activate it when needed.
call record in the call log contains the following information: - Calling Time - Calling Party Number - Calling Party Name (optional) - Call Processing Method (Accept/Reject/Forward/Forward to VMS) - Result (Success/Fail) 1] for communications between the SCP and the ICW Server System, and between the ICW Server System and the ICW Client System. Developed in the
IETF PINT Working Group for invoking telephone services from an IP network, the PINT Service Protocol 1.0 specifies a set of enhancements to SIP 2.0 and SDP. Summarized below are the elements of the PINT Service Protocol 1.0 relevant to the Korea Telecom ICW implementation: o REGISTER The REGISTER method is used to inform the SCP of the connection status of an ICW subscriber. With this method, the ICW Client sends to the ICW Server the IP address (of the PC) and phone number of the subscriber when the subscriber is first connected to the Internet. The ICW server relays the information to the SCP, which updates the data base (if the subscriber is authorized), and in the end sends a registration acknowledgment to the ICW Server and then the Client. After the subscriber is connected to the Internet, the ICW Client sends a REGISTER request to the ICW Server periodically at a pre-defined interval (e.g., 20 seconds) to indicate its connection status. The request is not relayed to the SCP. The ICW Server only checks if it is from the authorized subscriber. Finally, when the subscriber terminates the Internet connection, the Client sends the last REGISTER request to the SCP via the ICW Server. If the REGISTER request does not arrive during the pre-defined interval, the ICW Server can also detect the change of the connection status of the ICW Client. o INVITE The SCP uses the INVITE method to notify the ICW Client, via the ICW Server, of an incoming call. o ACK Both the SCP and the ICW Server use the ACK method to confirm the receipt of the final responses to their requests. o BYE The BYE method terminates a service session. In addition to this original usage, we use the value (success or failure) of the Subject header to indicate the result of the desired disposition of an incoming call in the PSTN.
o CANCEL When the calling party releases the call before the called party responds, the SCP sends a CANCEL request to the ICW Client to cancel the INVITE request that it sent previously. o OPTION This method is not used in the KT implementation. o Responses The SCP responds to a REGISTER request with one of the status codes and associated comments below: . 100 Trying: Trying . 200 OK: Registered The ICW Client responds to an INVITE request with one of the status codes and associated comments below: . 100 Trying: Trying . 200 OK: Accept the Call . 303 see other: Forward the Call to Another Number . 380 alternative service: Forward the Call to the VMS . 603 decline: Reject the Call
2A. The SCGF translates the user registration information from the SIP message to the SCP internal API message. 3. The SCGF relays the user registration message to the SCF/SDF. 3A. The SCF/SDF authorizes the subscriber with the directory number based on the user registration information. 3B. The SCF/SDF stores the IP address of the ICW Client and sets the status to "Internet on-line." 4. The SCF/SDF sends the result of registration to the SCF/SCGF. 4A. The SCGF translates the user registration response of the SCP internal API message to the PINT message. 5. The SCGF relays the user registration response to the ICW Server. 5A. The ICW Server records the user registration information and the Internet on-line status for the subscriber in the data base. 6. The ICW Server sends the user registration response to the ICW Client. 6A. The ICW Client notifies the subscriber that the registration is completed successfully and the ICW service is in the active state.
2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF. 2A. The SCF/SDF determines whether the user at DN1 is PSTN on-line or Internet on-line. (The SCF/SDF executes the KT Telephone Mail Service logic in the PSTN on-line case and the ICW service Logic in the Internet on-line case.) 2B. The SCF/SDF retrieves the IP address corresponding to DN1. 2C. The SCF/SDF may play an announcement to the calling party, while waiting for the response of the called party. 3. The SCF sends an incoming call notification to the SCGF. 3A. The SCGF translates the incoming call notification from the SCP internal format to the PINT format. 4. The SCGF relays the notification to the ICW Server. 4A. The ICW Server double-checks the subscriber's status using the ICW subscribers profile in its own data base. 5. The ICW Server sends trying message to the SCGF. 6. The ICW Server relays the notification to the ICW Client. 6A. The ICW Client consults the ICW service profile to see if there is a pre-defined call disposition for the incoming call. If so, then the procedure for automatic call processing is performed. 6B. If there is no pre-defined call disposition for the incoming call, the subscriber is notified of the call via a pop-up dialog box. 7. The ICW Client sends trying message to the ICW Server.
1B. The ICW Client terminates the subscriber's Internet connection. 2. The ICW Server sends an "Accept" message to the SCGF. 2A. The SCGF translates the "Accept" message to an SCP internal API message. 3. The SCGF sends an "ACK" message to the ICW Server. 4. The SCGF sends the "Accept" message to the SCF. 5. The SCF instructs the SSF/CCF to route the call to DN1. 6. The SSF/CCF initiates the connection setup to DN1. 6A. The bearer connection between the calling party (DN2) and the ICW subscriber(DN1) is set up. 7. The connection result is returned to the SCF through ERB. 8. The SCF sends a call completion message to the SCGF. 8A. The SCGF translates the call completion message to a PINT message. 9. The SCGF sends a "BYE" message to the ICW Server. 9A. The ICW Server records the call completion result in the log file.
2. The ICW Server sends an "ACK" message to the ICW Client. 3. The ICW Server relays the "Forward to another number" message to the SCGF. 3A. The SCGF translates the "Forward to another number" message to an SCP internal API message. 4. The SCGF sends an "ACK" message to the ICW Server. 5. The SCGF sends the "Forward to another number" message to the SCF. 6. The SCF instructs the SSF/CCF to route the call to DN3. 7. The SSF/CCF initiates the connection setup to DN3. 7A. The bearer connection between the calling party (DN2) and the new termination number (DN3) is set up. 8. The connection result is returned to the SCF through ERB. 9. The SCF sends a call completion message to the SCGF. 9A. The SCGF translates the call completion message to a PINT message. 10. The SCGF sends the call completion message to the ICW Server. 10A. The ICW Server records the call completion result in the log file. 11. The ICW Server sends the success of "Forwarding to another number" to the ICW Client. 11A. The ICW Client records the call completion result in the log file.
2. The SCGF sends the un-register message to the SCF. 2A. The SCF/SDF authorizes the subscriber with the directory number based on the un-registration information. 2B. The SCF/SDF records the Internet off-line status for that ICW Client. 3. The SCF/SDF sends a user un-registration response to the SCF/SCGF. 3B. The SCGF translates the user un-registration response to a PINT message. 4. The SCGF relays the user un-registration response to the ICW Server. 4A. The ICW Server records the Internet off-line status for the ICW Client (subscriber) in the data base. 2]. With the PC Client, the OCC Server interacts via encrypted SIP messages. The OCC Server run-time environment effectively consists of two multi-threaded processes responsible for Call Registration and Call Notification services, respectively. OCC call registration services are initiated from an end-user's PC (or Internet appliance). With those, a subscriber registers his or her end-points and activates the notification services. (The registration services are not, strictly speaking, SPIRITS services but rather have a flavor of PINT services.) All OCC call notification services are PSTN-initiated. One common feature of these services is that of informing the user of the incoming telephone call via the Internet, without having any effect on the line already used by the modem. (A typical call waiting tone would interrupt the Internet connection, and it is a standard practice to disable the "old" PSTN call waiting service for the
duration of the call in support of the Internet connection between the end-user and the ISP.) When a call comes in, the user is presented with a pop-up dialog box, which displays the caller's number (if available), name (again, if available), as well as the time of the call. If the called party does not initiate an action within a specified period of time the call is rejected. As far as the disposition of the call is concerned, OCC supports all the features described in Section 2.
Intelligent Network (AIN) Release 1.0) and equipped with other features. The Central Office (CO) may be any switch supporting the Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI) and the call forwarding feature that would allow it to interwork with the CSN. Alternatively, in order to interwork with the SCP, it needs to be an IN Service Switching Point (SSP). In the latter case, the central office is connected to the SCP via the signaling system No. 7 (SS7) and INAP at the application layer. The Service Management System (SMS) is responsible for provisioning of the SCPs, CSNs, and central offices. In particular, for IN support of the Internet Call Waiting, it must provision the Central Office to direct a terminating attempt query to the subsystem number corresponding to the OCC SCP SPA based on the Termination Attempt Trigger (TAT). In addition, the Subscriber Directory Number (DN), Personal Identification Number (PIN) and Language ID are provisioned for each subscriber into the OCC Subscriber entry of the SCP Real Time Data Base (RTDB). Figure 9 shows the structure of an RTDB entry. +-------------------------------------------------------+ |DN | PIN | IP Address | Session Key | CNF | Language ID| +-------------------------------------------------------+ Field Descriptions: (DN) Directory Number - the subscriber's telephone number (PIN) Personal Identification Number - the subscriber's password IP Address - Internet Protocol Address of the subscriber (CNF) Call Notification In Progress Flag (boolean) - the flag indicating if an attempt to notify the subscriber of a call is currently in progress Session Key - unique identifier for the current registration session of the subscriber Language ID - language identifier for the subscriber Figure 9: Structure of the RTDB Subscriber Record The Central Office, SMS, CSN, and SCP are the only PSTN elements of the architecture. The other elements are VoIP Gateway and Gatekeeper defined in the ITU-T Recommendation H.323, whose roles are to establish and provide the part of the voice path over IP. The Central Office is explicitly connected to the VoIP Gateway via the
ISDN PRI connection. In this architecture, CSN, VoIP Gateway, and VoIP Gatekeeper are the only entities connected to the Internet, with each respective connection protected by a firewall. The CSN and SCP are interconnected via a secure IP Intranet. There may be more than one CSN or SCP (or both) (and the SCPs come in mated pairs interconnected by X.25, anyway) in a network, but these details are not essential to the level of description chosen for this document. However, we note that load balancing and adaptation to failures by the use of alternative nodes is incorporated into the architecture. When someone attempts to call the subscriber, the central office serving that subscriber interrupts normal termination processing and notifies the SCP which, in turn, can check whether that subscriber has registered that he (or she) is logged onto the Internet. Exploiting the standardized layering of service logic that characterizes the intelligent network, the central office will do this without requiring the installation or development of any central office software specific to OCC. The central office is simply provisioned to query the SCP when there is a termination attempt (i.e., TAT) directed to the subscriber's directory number. (Note that the Central Office has no bearer circuit connection to the SCP, only a signaling one over SS7). TCP/IP communication between the SCP and CSN utilizes a secure intranet. The subscriber, of course, is assumed to have access only to the Internet. The intelligent network entities, the SCP and CSN, do have OCC related software. The OCC server is implemented on the CSN. In addition, one service package application (SPA) is installed on the SCP. Another SPA is located in the CSN and is needed only when the subscriber elects to accept an incoming call using voice over IP. The OCC Server is a collection of Java servers on the CSN whose responsibilities include: o Listening for incoming Call Notification (TCP/IP) messages from the SCP SPA. o De-multiplexing/multiplexing incoming Call Notification messages sent from the SCP SPA. o Relaying messages between the OCC Client and the SCP SPA. o Listening for and authentication of OCC Client requests for service registration.
o Handling encryption/decryption of messages exchanged with the OCC Client, and generating session-specific encryption/decryption keys. The OCC Client is a collection of software components that run on the Subscriber's PC. Its components include the SIP User Agent Server (which handles the exchange of SIP messages with the OCC Server and invokes the Call Notification pop-up window) and a daemon process that monitors the Point-to-Point Protocol (PPP) actions and is responsible for starting and stopping the SIP User Agent Server.
OCC Server. To exchange SIP messages with the OCC Server, the OCC Client dynamically opens a TCP/IP socket connection with the OCC Server using a pre-configured port number on the CSN and the CSN's IP address. For the VoIP Scenario, the CSN SPA, acting as a client, dynamically opens TCP/IP sessions with the SCP that handled the initial TAT query. As soon as the CSN SPA has successfully made the correlation and connected the two incoming call legs pertaining to a VoIP call back, the SIP 180 RINGING message will be sent back to the SCP SPA running on the actual SCP that instructed the SSP to forward the Caller to the CSN. This SIP message, which contains the VoIP Call Back DN dialed by one of the bridged call legs, is an indication to the SCP SPA that the VoIP Call Back DN is freed up. A typical subscription scenario works like as follows: 1. Each VoIP Gateway is provisioned with a list of authorized VoIP Call Back DNs, each terminating on a particular CSN. These special DNs are used when an on-line subscriber elects to receive an incoming call via VoIP. In particular, they assist in routing an outgoing call from the subscriber's NetMeeting to the particular CSN to which the SCP is (roughly concurrently) forwarding the incoming call. (These two calls are joined in the CSN to connect the incoming call to the subscriber's Netmeeting client.) Furthermore, these special DNs permits that CSN to associate, and hence bridge, the correct pair of call legs to join the party calling the subscriber to the call from the subscriber's NetMeeting client. 2. The subscriber calls a PSTN service provider and signs up for the service. 3. An active Terminating Attempt Trigger (TAT) is assigned to the subscriber's DN at the subscriber's central office. 4. The PSTN service provider uses the SMS to create a record for the subscriber and provision the Subscriber DN and PIN in the OCC RTDB table in the SCP. 5. The subscriber is provided with the OCC Client software, a PIN and a file containing the OCC Server IP Addresses. Finally, we describe the particular scenario of the OCC Call Disposition that involves voice over IP, which proceeds as follows: 1. The OCC subscriber clicks on "Accept VoIP".
2. The OCC Client sends a "SIP 380 Alternative Service" message to the OCC Server. This message includes a reference to the Call Back DN which will ultimately be used by the CSN to associate the call leg (soon to be initiated by the subscriber's NetMeeting) connecting to the subscriber (via the VoIP gateway) with the PSTN call leg connecting to the calling party. 3. The OCC Server closes the TCP/IP session with the OCC Client and sends to the SCP SPA the "SIP 380 Alternative Service" message which includes the Call Back DN. 4. The SCP SPA instructs the Central Office to forward the call incoming to the subscriber to the CSN. This instruction includes the Call Back DN. 5. The SSP forwards the Caller to the CSN referencing the Call Back DN. Note that the Call Back DN, originally assigned to the OCC client by the SCP when the subscriber was alerted to the presence of an incoming call attempt, flowed next to the OCC server when the client elected to receive the call via VoIP, then to the SCP, then to the central office in association with a SCP command to forward the incoming call to the CSN, then to the OCC server on the CSN in association with that forwarded call. 6. Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from the SIP INVITE message received during Call Notification and 2) the H323UID and H323PIN values from its properties file and updates the 'netmtg.cnf' file. 7. The NetMeeting application is launched and sets up a connection with the VoIP Gateway. 8. Once a connection is established between NetMeeting and the VoIP Gateway, NetMeeting initiates a phone call - passing to the VoIP Gateway the Call Back DN as the destination DN. 9. The VoIP Gateway consults the VoIP Gatekeeper and authenticates the NetMeeting call by verifying the H323UID and H323PIN values, and by ensuring the called DN (i.e., Call Back DN) is authorized for use. 10. After passing the authentication step, the VoIP Gateway dials (via PSTN) the Call Back DN and gets connected to the CSN. The CSN notes that it was reached by the particular Call Back DN. 11. The CSN bridges the Calling and Called parties together by matching on the basis of the Call Back DN.
12. The CSN notifies the SCP (SIP 180 Ringing) of status and references the Call Back DN so that the SCP can reuse it for other calls. 13. If the central office supports that two B-channel transfer (Lucent, Nortel, and perhaps other central office vender's do), an optimization is possible. The CSN can have the central office rearrange the topology of the newly connected call in such a way that it flows only through the central office and no longer through the CSN.
Interfaces: p0 : SPIRITS Server-SCP(SPIRITS Client) interface p1 : SPIRITS Server-ICW Client interface p2 : ICW Client-W3S interface (Web access through HTTP) p3 : SCP-SSP interface(INAP) p4 : SSP-CO interface(ISUP) Figure 10: the NEC ICW system The description below provides the necessary steps to initiate the ICW service on a CO line, and how the ICW service is applied to an incoming call based on the above architecture: 1. The CO line is primed for the ICW service when the customer connects to their ISP by inserting a special activation code (e.g., *54) prefix in front of the ISP Directory Number. 2. The ICW service is activated when the user opens a secured session from an ICW client to the SPIRITS server. Once a session is open, the SPIRITS server will know the relationship between the line and the PC (i.e., it will know the Directory Number of the user's Internet line and the user's IP Address). 3. When a call arrives at a busy Internet line, the SSP will trigger the ICW service. The SCP which acts as the SPIRITS client will inform the SPIRITS server that a call is terminating to a busy Internet line. The message will include the Caller ID and Calling Line Identify Restriction (CLIR) Status of the calling party, and DN of the busy line. 4. The SPIRITS server will verify that if an ICW session has been established for the busy line. If so, the SPIRITS server will communicate with the user's ICW client application. The user will receive a real-time pop-up dialogue box including the Calling Name and Number of the Calling Party if available. The user will then select one of the following call management options: - Answer the call (the Internet connection will be automatically dropped and the phone will ring) - Send the call to Voice Mail - Forward the call to another destination - Ignore the call 5. When the Internet user has made a selection, the ICW client application will transmit this to the SPIRITS server. The SPIRITS server will instruct the PSTN via the SCP how to handle the call.
The sequence for opening a connection is: 1. SCP will transmit a scfBind invokation message to the SPIRITS server. This message also carries the version information and activity test interval. 2. The SPIRITS server, upon receiving an invokation of the scfBind from a particular SCP, will reset all the data concerning the connection and then responds with either a return result containing the Web Server Identification number or a return error with a reason. 3. When the SCP receives a return result, if the ID number does not match the number configured in the SCP, then a scfUnbind will be sent indicating the wrong ID number. If the SCP receives nothing or a return error is received, then the scfBind will be retried after a pre-determined period of time. 4. Once the SCP has received a return result, the SCP will send Handling Information Request or Activity Test. Upon receiving an invokation of activityTest, the SPIRITS server should reply with a return result of activityTest. If the SPIRITS server does not receive any invokation messages of Handling Information Request or Activity Test from the SCP for four times the Activity Test Interval value in milliseconds, the SPIRITS server should then close the connection. To close a connection an invokation of the scfUnbind is sent by either the SCP or SPIRITS server to the remote end. When an invokation message of the scfUnbind is received, the receiving end should terminate the connection. scfBind The scfBind operation is used to open the connection between the SCP and the SPIRITS server. The SCP will send the SPIRITS server an invokation of the scfBind to establish an association. If the SPIRITS server is ready to handle the request then it should respond with a return result. The return result of scfBind contains the identifier of the SPIRITS server. If the SCP receives the return result where the identification of the SPIRITS server does not match that registered against the SPIRITS server, then the SCP will send an invokation of the scfUnbind indicating an incorrect identifier was received. If the SPIRITS server is not ready to handle the request or cannot handle the version, then it should respond with a return error.
scfUnbind The scfUnbind operation is used to close the connection between the SCP and the SPIRITS server. Either the SCP or the SPIRITS server can invoke this operation. Upon receiving an invokation message the receiving end should terminate the connection. activityTest If the SCP has not sent a Data Message for the time period specified by the "Activity Test Interval", it will send an invokation message of activityTest. When the SPIRITS server receives such an invokation, it will reply with a return result message of activityTest. Its contents should be retained by the SPIRITS server. They are to be echoed back in the return result so that the message reply time can be calculated.
The invoked operation has always a response which is either a return result of the operation or an invokation of another operation. If a Data Message is not replied to within a pre-determined time out period then the message will be resent a number of specified times. Once the number of times has been exceeded, if another node exists, the message will be sent to another node if it is available. If all available SPIRITS servers have been queried then Message Time out will be returned to the calling process. If an invokation of the handlingInformationResult is received with the cause=63 (Service not available), the handlingInformationRequest will be sent to another node if it is available. If all available SPIRITS severs have been queried then cause=63 will be returned to the calling process. section 5.3.3): o VersionInfo (ICW client -> SPIRITS server) Indicate the current version of ICW client software. The SPIRITS server uses this information to determine if the client software is out of date. o VersionInfoAck (SPIRITS server -> ICW client) If the VersionInfo message from an ICW client indicates to a SPIRITS server that it is an out of date version, the URL information is returned within the VersionInfoAck message for use in downloading the newer version. If the client software is up to date, the message simply indicates so and does not include any URL information. o CallArrival (SPIRITS server -> ICW client) Sent by the server to tell the client someone has called the DN. o CallID An identifier for this call. Unique in the domain of this client/server session.
o CallingNumber o CallingName The name of the calling party is sent to the Client Application from the SPIRITS server. When available, the name is sent as a 15-character string. If the name is unavailable it is sent as "Name Unavailable". If the calling party has CLIR set, it is sent as empty (" "). o CallConnect (ICW client -> SPIRITS server) If a corresponding CallConnect is not received within a certain period after sending a CallArrival, the SPIRITS server will behave as though a CallConnect, Handling=Ignore had been received. o CallLost (SPIRITS server -> ICW client) Sent by server to cancel a CallArrival before a CallConnect is received by the server.
5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use Between ICW Client Application and SPIRITS Server
The client then generates a symmetric key using the selected algorithm and transmits this to the server. The SSL session is then closed and the SRHDSP session is considered open. Section 2) have been developed to prove the concept.
In the Telia/Nortel architecture, services run on top of SIP Redirect Servers. The distributed nature of SIP enables these servers to be hosted, for example, by an enterprise server, a Service Provider's server cluster, a user's desktop PC, or even by a hand-held cordless device. The SIP Redirect Server receives a SIP INVITE message for each call regardless of which network the call is being set up in. The server MAY apply any kind of service logic in order to decide on how to respond to the invitation. Service logic may interact with the user to allow the user to specify how to handle a call such as described in Section 2. This, however, is not the focus of the Telia/Nortel system.
+-----------+ INAP +-----+ SIP +--------------------------+ | CSN node |--------| SCG |-------| NS (SIP Redirect Server) | +-----------+ +-----+ +--------------------------+ Figure 11: An Architecture for Number Portability The INAP IDP message that carries the number query is converted to a SIP INVITE message by the SCG and is then forwarded to the NS (SIP Redirect Server). If the called number is not registered, then the NS will return "404 Not Found". The SCG interprets this as "non ported number" and returns a CON message to the CSN network, making it connect the call to the called number. If the number is ported and hence registered, then the NS will return "301 Moved Permanently" with a TEL URL (routing number) in the contact field. The SCG then returns a CON message to the CSN network, making it connect the call to the number that was conveyed in the contact field. The solution above enables the same Number Server to provide Number Portability to multiple networks by means of using multiple SCGs. If we make the SIP server in the number portability example operate in proxy mode for selected numbers, then it will become a kind of service router, able to relay number queries to any SIP-Redirect- Server-based service anywhere, provided there is an IP connection to the host in concern. Figure 12 shows the arrangement. +------+ INAP +-----+ SIP +----------------+ SIP +----------+ | CSN |------| SCG |-----| NS |-----| Service | | node | | | |(redirect/proxy)| |(redirect)| +------+ +-----+ +----------------+ +----------+ Figure 12: SIP-Based Service Router Suppose that we connect a value-added service, such as a Personal Call Filtering service hosted by a user's desktop PC, to a certain telephone number. The INAP IDP message is converted to a SIP INVITE message by the SCG and is then forwarded to the NS, just as in the previous example. However, in this case, the number is registered with a reference to a SIP URL. This makes the Number Server proxy the SIP INVITE message to the registered URL, which is the address of the service.
The service responds as a SIP Redirect Server and the Personal Call Filtering service logic determines the response. The NS sends the response back to the SCG which converts the response to an appropriate INAP message. The response from the service is typically "302 Moved Temporarily" with a telephone number in the Contact field. If the response is 301 or 302, as the examples above suggest, then a telephone number is carried in the contact field. If the user can be reached via several different addresses, then all of them SHOULD be added to the response by means of multiple contact fields. The SCG then selects an address that is valid for the node or application that issued the number query. As illustrated by the service examples, the Telia/Nortel system aims to allow the introduction of multi-network services without requiring multi-protocol support. The services hence operate in the same way regardless of in which network the call is made and common IP services can be shared across heterogeneous networks. +-----------+ +-------+ SIP +----+ ...... SIP +-----------+ | Network 1 |---| SCG 1 |-----| |---: :-----| Service A | +-----------+ +-------+ | | : : +-----------+ | | : : +-----------+ +-------+ SIP | | : : SIP +-----------+ | Network 2 |---| SCG 2 |-----| NS |---: :-----| Service B | +-----------+ +-------+ | | : Any : +-----------+ | | : IP : +-----------+ +-------+ SIP | | : net- : SIP +-----------+ | Network n |---| SCG n |-----| |---: work :-----| Service C | +-----------+ +-------+ +----+ : : +-----------+ : : +--------+ SIP : : SIP +-----------+ | SIP UA |-----------------------------: :-----| Service x | +--------+ '......' +-----------+ Figure 13: Interconnecting Heterogeneous Networks via SIP
mechanism that can block a denial-of- service attack from an Internet user toward the PSTN. 3, 4], which include, for example: + Protection of the PSTN from attacks from the Internet. + Peer entity authentication to allow a communicating entity to prove its identity to another in the network. + Authorization and access control to verify if a network entity is allowed to use a network resource. + Confidentiality to avoid disclosure of information (e.g., the end user profile information and data) without the permission of its owner. + Non-repudiation to account for all operations in case of doubt or dispute. As seen in the previous sections, most implementations examined in this document have employed means (e.g., firewalls and encryption) to meet these requirements. The means are, however, different from implementation to implementation.
It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of SPIRITS services.  Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.  Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.  Lu, H. (Ed.), Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F., DeSimone, A., Tewani, F., Davidson, D., Schulzrinne, H. and K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking-- Pre-PINT Implementations", RFC 2458, November 1998.
John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd PO Box 3050 Naperville, IL, USA 60566-7050 Phone: +1 630 713 5538 EMail: firstname.lastname@example.org Mark Weissman Lucent Technologies Room NE406B 200 Lucent Lane Cary, NC, USA 27511-6035 Phone: +1 919 463 3258 EMail: email@example.com Weizhong Zhang Lucent Technologies Room 01-A5-17 2000 Regency Parkway Cary, NC, USA 27511-8506 Phone: +1 919 380-6638 EMail: firstname.lastname@example.org Sung-Yurn Rhim Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea Phone: +82 2 526 6172 EMail: email@example.com Jinkyung Hwang Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea Phone: +82 2 526 6830 EMail: firstname.lastname@example.org
Shinji. Ago NEC Corporation 1131, Hinode, Abiko, Chiba, 270-1198, Japan Phone: +81 471 85 7412 EMail: email@example.com S. Moeenuddin NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038 Phone: +1 972 518 5102 EMail: firstname.lastname@example.org S. Hadvani NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038 Phone: +1 972 518 3628 EMail: email@example.com Soren Nyckelgard Telia Research Chalmers Teknikpark 41288 Gothenburg Sweden EMail: firstname.lastname@example.org John Yoakum Nortel Networks 507 Airport Blvd, Suite 115, Morrisville, NC, USA 27560 EMail: email@example.com Lewis Robart Nortel Networks P.O. Box 402 Ogdensburg, NY, USA 13669 EMail: firstname.lastname@example.org
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.