RFC 2995
Pre-Spirits Implementations of PSTN-initiated Services
RFC 2995: Pre-SPIRITS Implementations of PSTN-initiated Services 🎀
Okay bestie, this one is a whole mood. It's an Informational RFC from the Network Working Group, dated November 2000. Nothing in it is a standard. It's a "here's what people actually built" document. Lucent Technologies wrote the bulk of it, with H. Lu as the Editor. The other authors are I. Faynberg, J. Voelker, M. Weissman, and W. Zhang (all Lucent), plus S. Rhim and J. Hwang from Korea Telecom, S. Ago, S. Moeenuddin, and S. Hadvani from NEC, S. Nyckelgard from Telia, and J. Yoakum and L. Robart from Nortel Networks. Yes, that's a LOT of co-authors 😭🫶. The header doesn't list anything it obsoletes or updates, so it's a standalone doc. ✨
Status of this Memo 💅
This memo gives info to the Internet community. It is not a spec for any Internet standard, full stop. Distribution is unlimited, so share it with everyone. 🌈
Copyright Notice 📜
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🦋
Okay so this doc is basically the homework for the SPIRITS Working Group (The Services in the PSTN/IN Requesting InTernet Services, if you want the full cringe-free name 💀). It covers four existing implementations of SPIRITS-like services, from Korea Telecom, Lucent Technologies, NEC, and Telia, with Nortel Networks helping out. SPIRITS-like services are the ones that start on the phone network (the PSTN) and need the Internet and the PSTN to talk to each other. Iconic, honestly. 🔥
Here's the tea from surveying all of them:
- The ICW service is the benchmark, the main character of the group 👑. All four implementations can support ICW, and three were built specifically for it.
- Session Initiation Protocol (SIP) is the base communications protocol between the PSTN and the Internet in most of the implementations. NEC is the only one using a proprietary protocol 🙈. BUT NEC has a plan to support SIP together with the extensions for SPIRITS services, so it's not a permanent villain arc.
- All implementations use IN-based solutions for the PSTN side.
Not everything plays nicely, though. It's clear that not all of the pre-SPIRITS implementations inter-operate with each other. It's also clear that not all of the SIP-based ones inter-operate either, because they don't support the same version of SIP 😭. So the big job for the SPIRITS Working Group is defining the inter-networking interfaces that will let future SPIRITS implementations actually interoperate. ⭐
Table of Contents 🧚
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
3.6.5.1. Accept the Call ....................................... 16
3.6.5.2. 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
5.3.1.1. Connecting to SPIRITS Services ........................ 31
5.3.1.2. Message Types ......................................... 31
5.3.1.2.1 Connection Management Message Type ................... 31
5.3.1.2.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
5.3.3.1. Overview .............................................. 35
5.3.3.2. Session Initiation .................................... 35
5.3.3.3. Secure Reliable Datagram Transport .................... 36
5.3.3.4. 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 ................................... 441. Introduction ✨
Okay, intro time! This doc is all about the work happening in the SPIRITS Working Group (same name as before, we're committed 💅). It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia, in cooperation with Nortel Networks. Again, SPIRITS-like services are the ones that begin in the Public Switched Telephone Network (PSTN) and need the Internet and PSTN to work together.
Every single one of the implementations covered here supports the Internet Call Waiting (ICW) service 🎀. With ICW, subscribers can keep using their phone lines for Internet access and still get notified about incoming voice calls. Then they can decide how to handle those calls over those same phone lines. It's giving multitasking, and I'm obsessed 😭✨.
The doc goes in order. First it gives a detailed description of the ICW service 🦋. After that it walks through each of the four implementations one by one. The final sections cover security considerations, the conclusion, and references, so you can keep scrolling. 💖
Heads up, bestie: the term "SPIRITS server" shows up all over this doc, but it doesn't have one universal meaning 🙈. What it means depends on the context and changes from implementation to implementation. So don't assume it's the same thing everywhere!
2. Service Description of Internet Call Waiting ✨
okay so every implementation in question supports one specific service, and it's Internet call waiting (ICW) 💖 Picture this: you're online on your dial-up, someone calls your phone line, and instead of your internet just dying or the call going nowhere, you actually get told about it. Iconic.
In a nutshell, the service lets a subscriber who's in an Internet dial-up session:
- be notified of an incoming call to the very same telephone line that's being used for the Internet connection 📞
- specify the desirable treatment of the call 🎀
- have the call handled the way they specified ✨
The real details of ICW are all in how a waiting call can be treated, and that part varies from implementation to implementation 🌸 So in this section, we're looking at the features that at least one of the implementations supports. Here they are:
- Incoming Call Notification - The subscriber gets notified of an incoming call over the Internet, and it doesn't mess with the telephone line the modem is using 🦋 When a call comes in, a pop-up dialog box shows up on the PC. The dialog box can display any combination of the calling party number, calling party name, and calling time. Quick note: showing the calling party name (or number) needs the caller name (or number) delivery feature to be available 💅
- Online Incoming Call Disposition - Once the subscriber knows about the call, they get a bunch of options (shown in the pop-up window) for handling it. The possible options are:
- Accepting the call over the PSTN line, which ends the Internet (modem) connection
- Accepting the call over the Internet using Voice over IP (VoIP)
- Rejecting the call
- Playing a pre-recorded message to the calling party and then disconnecting the call
- Forwarding the call to voice mail
- Forwarding the call to another number
- Rejecting (or Forwarding) on no Response - If the subscriber doesn't respond within a certain period of time after the dialog box shows up, the call can be rejected, or handled based on the treatment the subscriber predefined 🙈
- Automatic Incoming Call Disposition - Calls get handled automatically based on dispositions the subscriber set up ahead of time, so no real-time input needed 🧚 The subscriber can set a default disposition for general calls (for example, sending them to voice mail), plus custom dispositions for calls from specific numbers. For the custom ones, the subscriber picks a disposition for each originating number and saves it in a profile. When a call comes in, the subscriber doesn't get shown it at all, but they can check how it was treated and what happened in the caller log (more on that in the call logging bullet). Of course, this feature also lets the subscriber choose the treatment for calls from private or unpublished numbers 🔒
- Multiple Call Handling - Multiple calls can arrive while call disposition processing is already going on. With multiple call handling, the subscriber gets notified about them one by one 💜
- Call Logging - A detailed log of the incoming calls processed during the ICW service is kept 📝 The typical information recorded in the log includes the incoming call date and time, calling party number, calling party name, and call disposition.
3. Korea Telecom's ICW Implementation 🇰🇷
3.1. Overview
Korea Telecom's ICW implementation supports most of the features from Section 2 🫶 (The big exception is receiving the incoming call over the Internet using voice over IP.) On top of that, the Korea Telecom version gives subscribers flexible activation and de-activation of the ICW service:
- Automatic Activation/De-activation - When the Internet dial-up connection is set up, the ICW service gets activated or de-activated automatically ⚡
- Manual Activation/De-activation - The subscriber can de-activate the ICW service manually when they don't want call notifications during the Internet dial-up session, and then activate it again when they need it 🌈
3.2. Network Architecture
Figure 1 shows the network architecture of the Korea Telecom ICW service 🗺️ The Service Switching Point (SSP), Service Control Point (SCP), and Intelligent Peripheral (IP) are legacy PSTN IN elements based on IN CS-1. The ICW Server System and the ICW Client System, on the other hand, are brand-new network elements installed in the Internet domain to support the ICW service 💅
+---------------------------+ | +--------------+
|+--------+propr-+---------+| PINT | |(Proxy Server)| PINT
||(ICW SL)|ietary|(UAC/UAS)||--- -||-----| ICW |----+
||SCF/SDF |------| SCGF || firewall |Server System | |
|+--------+ i/f +---------+| | +------------- + |
| SCP | | |
+------+--------------+-----+ | |
|INAP |INAP | firewall=====
| | | |
+---+---+ +---+---+ |
| IP | | SSP | |
+-------+ +---+---+ +-------------+
| +---+ | (UAC/UAS) |
+---+---+ || || | ICW |
|---------| LEX |-------------- + + |Client System|
+---+ +-------+ +++++----+-------------+
|| || (callee)
+ + ICW Subscriber's Phone and PC
+++++
(caller)
INAP : Intelligent Network Application Protocol
PINT : PSTN/Internet Interworking Protocol
SL : Service Logic
UAS : User Agent Server
UAC : User Agent ClientFigure 1: Network Architecture of the Korea Telecom ICW Service
3.3. Network Entities
3.3.1. SSP
The SSP runs the Service Switching Function (SSF) and Call Control Function (CCF) 🔀 When it detects that the called party is busy (T_Busy), the SSP sends a query to the SCP and then processes the call under the SCP's control.
3.3.2. SCP
The SCP runs the Service Control Function (SCF) and Service Data Function (SDF) 🧠 When queried, it tells the SSP how to process the call based on the service logic. For ICW, the service logic is what ultimately decides how a waiting call gets notified to an online ICW subscriber, and how the call gets disposed of ✨ The SCP also runs the Service Control Gateway Function (SCGF) for protocol inter-working between the PSTN/IN and the Internet 🌉 It translates SIP messages from the ICW Server into service control interface messages, and vice versa. The SCGF is an IP end point, and it behaves as a UAS (User Agent Server) or a UAC (User Agent Client).
3.3.3. IP
The IP contains the Service Resource Function (SRF) 🎙️ When it's needed, it plays announcements to the calling party during the ICW service, either before or after the response from the ICW subscriber comes in. It also records the calling party number, or a voice message from the calling party, when the call gets forwarded to the Voice Mail System (VMS).
3.3.4. ICW Server System
The ICW Server System acts as a SIP proxy or a redirect server, handling message routing between the ICW Client and SCGF 🚦 It also manages the ICW Clients connected to it. When an ICW Client (subscriber) sends a registration request for the ICW service, the ICW Server relays that request to the SCP, waits for the authorization result from the SCP, and then registers the authorized subscriber in its data base. The ICW Server also keeps an eye on the connection status of the registered ICW Clients 👀 The second a client deactivates the ICW service or ends the Internet connection, the ICW Server notices the status change and deactivates the ICW service for that client. Last but not least, the ICW Server manages the profiles for each ICW subscriber and logs all the call processing results 📚
3.3.5. ICW Client System
The ICW Client System is an application program running on the subscriber's PC 💻 It launches as soon as the subscriber powers on the PC, and it monitors the PC's (or subscriber's) Internet connection status. When the subscriber connects to the Internet, the ICW Client sends a REGISTRATION request to the SCGF via the ICW Server, and eventually on to the SCP. In this role, the ICW Client acts as a UAC toward the SCGF, which acts as a UAS. After that, it keeps notifying the ICW Server periodically about the subscriber's connection status 🔁
The ICW Client is also the one popping up the dialog box on the subscriber's PC to announce an incoming call 🎉 The dialog box displays the number and name of the calling party, the calling time, and the call processing options (including Accept, Reject, Forward to another number, or VMS). Once the subscriber picks an option, the ICW Client sends it to the SCP. In this role, the ICW Client acts as a UAS.
Depending on the predefined ICW Service Profile, the ICW Client may screen the incoming call before notifying the subscriber 🛡️
The ICW Client manages the ICW Service Profile, which contains the following fields:
- Subscriber Information (including Name, Directory Number, Password)
- Service Status (Activation/De-activation)
- Automatic Call Processing Method
- Call Processing Method on No Answer (Reject/Forward/VMS) - The call is handled automatically by this method if the subscriber doesn't respond after a predefined period of time ⏰
- Do Not Disturb Mode (On/Off) - When this is set to on, the subscriber won't be notified of incoming calls 🌙
- Call Processing Method on Do Not Disturb (Reject/Forward/VMS)
- Call Processing List by Calling Party Numbers (Accept/Reject/Forward/VMS) - Calls from a number on the list get handled by the associated call processing method 📋
The ICW Client also records the call processing method and the result for each incoming call in a log file on the subscriber's PC 🗒️ The call record in that 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)
3.3.6. Firewall
Packet Filtering Firewall Systems sit between the ICW server and the clients, and also between the SCGF and the ICW server, for accessing the Korea Telecom IN Nodes 🔥
3.4. Network Interfaces ✨
okay bestie, this is where all the pieces actually talk to each other 💅
- SCF-SDF, SCF-SSF, and SCF-SRF interfaces are the same as the existing PSTN IN Interfaces based on the KT INAP CS-1 🎀
- SCGF-SCF interface relays requests either from the IN or the Internet, and it's implemented based on the internal API of the SCP 🧚
- SCGF-ICW Server and ICW Server-ICW Client interfaces are implemented based on the PINT Service Protocol V.1. we adopted UAS-Proxy-UAC relationships as shown in Figure 2 🦋
+---------+ +-------------+ +---------+
|(UAC/UAS)|PINT 1.0| (Proxy) |PINT 1.0|(UAC/UAS)|
| |--------| ICW |--------| ICW |
| SCGF | | Server | | Client |
+---------+ +-------------+ +---------+
Figure 2: PINT Protocol Architecture3.5. Protocols 🌸
3.5.1. Intelligent Network Application Part Protocol (INAP)
the SCP, SSP, and IP support the KT INAP V1.0, which is based on ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [PRM (PromptAndReceiveMessage) and EM (EraseMessage)] for recording the voice message 🎙️
3.5.2. PINT Protocol
the ICW service uses the PINT Service Protocol 1.0 [1] for communications between the SCP and the ICW Server System, and between the ICW Server System and the ICW Client System 💜 it was developed in the IETF PINT Working Group for invoking telephone services from an IP network, and it specifies a set of enhancements to SIP 2.0 and SDP ✨
here are the elements of the PINT Service Protocol 1.0 that are relevant to the Korea Telecom ICW implementation, summarized for you 🫶
- REGISTER
- the REGISTER method informs the SCP of the connection status of an ICW subscriber. the ICW Client sends 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 that info to the SCP, which updates the data base (if the subscriber is authorized), and then 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 show its connection status 💓
- that request is not relayed to the SCP. the ICW Server only checks if it's from the authorized subscriber 👀
- when the subscriber ends the Internet connection, the Client sends the last REGISTER request to the SCP via the ICW Server 👋
- if the REGISTER request doesn't arrive during the pre-defined interval, the ICW Server can also detect the change of the connection status of the ICW Client 🕵️♀️
- INVITE
- the SCP uses the INVITE method to notify the ICW Client, via the ICW Server, of an incoming call 📞
- ACK
- both the SCP and the ICW Server use the ACK method to confirm receipt of the final responses to their requests 🧾
- BYE
- the BYE method terminates a service session 🛑
- on top of that 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 🎯
- 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 it sent previously 🙅♀️
- OPTION
- this method is not used in the KT implementation 🙈
- Responses
- the SCP responds to a REGISTER request with one of these status codes and comments:
100 Trying: Trying200 OK: Registered
- the ICW Client responds to an INVITE request with one of these status codes and comments:
100 Trying: Trying200 OK: Accept the Call303 see other: Forward the Call to Another Number380 alternative service: Forward the Call to the VMS603 decline: Reject the Call
- the SCP responds to a REGISTER request with one of these status codes and comments:
3.6. Example Scenarios 🧚
3.6.1. ICW Service Subscription
access to the Korea Telecom ICW service is by subscription 💳 here, Korea Telecom is both the PSTN operator and the IN-based ICW service provider. note that the subscription data needs to be loaded onto the relevant SSPs, including the local ones that may not be operated by Korea Telecom 📝
3.6.2. ICW Client Installation
an ICW subscriber should install the ICW Client program on their PC 💻 the ICW Client is automatically activated to run as a daemon process when the subscriber's PC is turned on, and it monitors the subscriber's Internet connection status 👁️✨
3.6.3. ICW Service Activation
when the subscriber starts the Internet connection or activates the ICW service manually, the ICW service gets activated 🔥 that's done by sending a REGISTER request with the directory number and IP address from the ICW Client to the SCP through the ICW Server 🚀
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A | | | | |
0BREG(DN1,IP1)| | | | |
1 |----------->|REG(DN1,IP1)| | | |
2 | |----------->| | | |
| | 2A | | |
| | |reg(DN1,IP1)| | |
3 | | |-.-.-.-.-.->| | |
| | | 3A | |
| | | reg ok 3B | |
4 | | |<-.-.-.-.-.-| | |
| | 200 OK 4A | | |
5 | |<-----------| | | |
| 200 OK 5A | | | |
6 |<-----------| | | | |
6A | | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 3: ICW Service Activationas shown in Figure 3, here's how the info flows go, step by step 🍓
(0A) the ICW subscriber dials the ISP access number and establishes a PPP connection 📲
(0B) the ICW Client detects the PPP connection 👀
- the ICW Client sends a registration request to the ICW Server so it can register the IP address-DN relationship for the dial-up connection 🙋♀️
- the ICW Server relays the registration request to the SCGF 🔁
2A. the SCGF translates the user registration information from the SIP message to the SCP internal API message 🔄
- 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." 🟢
- 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 🪄
- 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 🗂️
- the ICW Server sends the user registration response to the ICW Client 💌
6A. the ICW Client tells the subscriber that registration is completed successfully and the ICW service is in the active state 🎉💖
3.5.4. Incoming Call Notification ✨
okay so when a calling party rings the ICW subscriber, the SCP tells the ICW Client about the incoming call and then just waits for the subscriber to respond 📞💖. It's giving perfectly choreographed teamwork 💅.
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
| | | | setup(DN1,DN2)|
1 | | | | |<+++++++++++|
| | | | 1A |
| | | IDP(T-busy,DN1)| |
2 | | | |<--.--.--.--| |
| | | 2A | |
| | | 2B | |
| | | 2C | |
| | noti(DN1,IP1,DN2)| | |
3 | | |<-.-.-.-.-.-| | |
| | 3A | | |
| INV(DN1,IP1,DN2)| | | |
4 | |<-----------| | | |
| 4A | | | |
| | 100 Trying | | | |
5 | |----------->| | | |
INV(DN1,IP1,DN2)| | | | |
6 |<-----------| | | | |
6A | | | | |
| 100 Trying | | | | |
7 |----------->| | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> BearerFigure 4: Incoming Call Notification
As depicted in Figure 4, the relevant information flows are as follows, bestie 🎀:
1. The calling party at DN2 (a telephone user) makes a call to the ICW subscriber (PC user) at DN1 📱. The connection is set up using the existing ISDN signaling.
1A. The SSF/CCF detects that the callee (the ICW subscriber) is busy 🙈.
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 🫶.
3.6.5. Incoming Call Processing
okay the incoming call can be accepted, rejected, forwarded to another number, or forwarded to the VMS, depending on the on-the-fly or pre-defined choice of the subscriber 👑. This section walks through the information flows for the cases of "Accept the call" and "Forward the call to another number" 💅.
3.5.5.1. Accept the Call
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A 200 OK | | | | |
1 |----------->| | | | |
1A | | | | |
1B | 200 OK | | | |
2 | |----------->| | | |
| | ACK 2A | | |
3 | |<-----------| | | |
| | |Accept(DN1,IP1,DN2) | |
4 | | |-.-.-.-.-.->| | |
| | | |Connect(DN1,DN2) |
5 | | | |--.--.--.-->| |
| | | Setup(DN1,DN2)| |
6 |<++++++++++++++++++++++++++++++++++++++++++++++++++| |
|<==============================6A==============================>|
| | | | ERB | |
7 | | | |<--.--.--.--| |
| | | ok | | |
8 | | |<-.-.-.-.-.-| | |
| | 8A | | |
| | BYE | | | |
9 | |<-----------| | | |
| 9A | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> BearerFigure 5: Incoming Call Processing - Accept the Call
As depicted in Figure 5, the relevant information flows are as follows 🌈:
0A. The ICW subscriber chooses to "Accept" the incoming call 🥳.
1. The ICW Client sends the "Accept" indication to the ICW Server 📤.
1A. The ICW Client records the subscriber's selection for the incoming call in the call log 📝.
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 🗂️.
3.5.5.2. Forward the Call to Another Number
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling Another
ICW Client party Phone
(DN1/IP1) (IP2) (IP3) (DN2) (DN3)
| | | | | | |
0A | | | | | |
|303 SeeOther | | | | |
1 |--------->| | | | | |
1A ACK | | | | | |
2 |<---------|303 SeeOther | | | |
3 | |--------->| | | | |
| | ACK 3A | | | |
4 | |<---------|Connect(DN2,DN3) | | |
5 | | |-.-.-.-.->| | | |
| | | |Connect(DN2,DN3) | |
6 | | | |.--.--.-->| | |
| | | | |Setup(DN2,DN3) |
7 | | | | ++++++++++++++++++++>|
8 | | | | ERB | |<===5A==>|
| | | |<--.--.--.| | |
| | | ok | | | |
9 | | |<-.-.-.-.-| | | |
| | BYE 9A | | | |
10 | |<---------| | | | |
| BYE 10A | | | | |
11 |<---------| | | | | |
11A | | | | | |
| | | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> BearerFigure 6: Incoming Call Processing - Forward the Call to Another
As depicted in Figure 6, the relevant information flows are as follows 🦋:
0A. The ICW subscriber chooses to "Forward to another number (DN3)" for the incoming call 🔀.
1. The ICW Client sends the "Forward to another number" indication to the ICW Server 📤.
1A. The ICW Client records the subscriber's selection for the incoming call in the call log 📝.
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 💖.
3.6.6. ICW service De-activation ✨
Okay so the SCP turns off the ICW service for a subscriber either when their Internet connection ends or when they manually ask it to, bestie 💅 This part shows the first one, when the connection just drops 🦋
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A | | | | |
| 0B | | | |
| |Unreg(DN1,IP1) | | |
1 | |----------->| | | |
| | 1A | | |
| | |Unreg(DN1,IP1) | |
2 | | |-.-.-.-.-.->| | |
| | | 2A | |
| | | ok 2B | |
3 | | |<-.-.-.-.-.-| | |
| | 3A | | |
| | 200 OK | | | |
4 | |<-----------| | | |
| 4A | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal API
--.--> INAP Protocol +++++> ISUP Protocol
=====> Bearer
Figure 7: ICW Service De-activationSo, as Figure 7 shows, here's the flow of info, no cap 🎀
0A. The ICW subscriber ends the Internet connection 📵
0B. The ICW Server figures out the connection is gone when it stops getting the periodic on-line notification from the ICW Client 👀
1. The ICW Server sends an un-register message to the SCGF 💌
1A. The SCGF turns that un-register message into an SCP internal API message 🔄
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 info 🔐
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 into 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 🗂️
4. The Lucent Technologies Online Communications Center ✨
4.1 Overview
The Lucent Technologies Online Communications Center (OCC) is basically an Intelligent Network (IN)-based platform that powers the Internet call waiting service, and it's giving main character energy 👑 Its core pieces are the OCC Server and the OCC Client, which get the full breakdown in the Architecture section 🌸 The OCC Server talks to the PSTN entities over the secure intranet using plain-text Session Initiation Protocol (SIP) messages [2] 💜 But with the PC Client, the OCC Server uses encrypted SIP messages instead 🔐
The OCC Server's run-time environment is really just two multi-threaded processes, one for Call Registration and one for Call Notification 🧚
OCC call registration services start from an end-user's PC (or Internet appliance) 💻 This is where a subscriber registers their end-points and turns on the notification services 🫶 (Strictly speaking, the registration services aren't SPIRITS services. They have more of a PINT services vibe 🦋)
All OCC call notification services are PSTN-initiated 📞 The big perk is that they tell the user about an incoming call over the Internet, without messing with the line the modem is already using 🌈 (A regular call waiting tone would knock the Internet connection offline, so it's standard practice to turn off the "old" PSTN call waiting for the length of the call. That keeps the Internet connection between the end-user and the ISP alive 💖)
When a call comes in, the user gets a pop-up dialog box 🎀 It shows the caller's number (if it's available), the caller's name (also only if available), and the time of the call ⏰ If the called party doesn't do anything within a specified period of time, the call gets rejected 💀
As far as what happens to the call goes, OCC supports all the features described in Section 2 🔥
4.2. Architecture 🏗️
Okay bestie, let's look at the whole setup 👀✨ Figure 8 shows the joint PSTN/Internet physical architecture that the OCC runs on, and it's giving a lot of moving parts 💅
+------------+
| Compact | +-------------+
| Service | | Service |
+-----| Node (CSN) | | Management |
| | OCC Server | | System (SMS)|
| | OCC CSN SPA| +-------------+
| +-------:--|-+ |
| | +-------------[ IP INTRANET ]---------+
===== firewall : |
| | |
| +-------+ +-------+
| |Central|-..-..-..-..-..-..-..-..-..-..-|Service|
| +-%-|Office |-..-..-: |Control|
| | +---|---+ | |Point |
| % | : | (SCP) |
| | +--|---+ +-------+ +----------+ |OCC SCP|
| % | PC | | VoIP | | VoIP | | SPA |
| | |OCC Cl| |Gateway| |Gatekeeper| +-------+
| % +------+ +---|---+ +-----|----+
| | ===== firewall =====
| % | |
| | +---------------|---+ |
| +-%-| |----------+
+----------| I N T E R N E T |
| |
+-------------------+
Figure 8: The Lucent OCC Physical ArchitectureSo Figure 8 is the big picture 🌸 The Compact Service Node (CSN) and SCP are Lucent's versions of the ITU-T IN Recommendations (the ones where these entities actually get defined is Recommendation Q.1205 🤓), and they've been boosted by Bellcore's Advanced Intelligent Network (AIN) Release 1.0) requirements plus some extra features. The Central Office (CO) can be basically any switch that supports the Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI) and the call forwarding feature, so it can interwork with the CSN 🎀 If you'd rather it talk to the SCP instead, it needs to be an IN Service Switching Point (SSP). In that case the central office hooks up to the SCP over signaling system No. 7 (SS7), with INAP at the application layer 🧚
The Service Management System (SMS) is the boss that provisions the SCPs, CSNs, and central offices 👑 For the IN support of Internet Call Waiting, it must provision the Central Office to send a terminating attempt query to the subsystem number that matches the OCC SCP SPA, based on the Termination Attempt Trigger (TAT). The SMS also provisions each subscriber's Subscriber Directory Number (DN), Personal Identification Number (PIN), and Language ID into the OCC Subscriber entry of the SCP Real Time Data Base (RTDB) 💜 Figure 9 shows what one of those RTDB entries looks like:
+-------------------------------------------------------+
|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
So the PSTN side only has four pieces: the Central Office, SMS, CSN, and SCP 🍓 Then there's the VoIP Gateway and Gatekeeper, which are defined in the ITU-T Recommendation H.323 and handle setting up the part of the voice path that goes over IP 🦋 The Central Office is explicitly connected to the VoIP Gateway through the ISDN PRI connection. In this setup, the CSN, VoIP Gateway, and VoIP Gatekeeper are the only things touching the Internet, and each of those connections sits behind a firewall 🔥 The CSN and SCP talk to each other over a secure IP Intranet. You can have more than one CSN or SCP (or both) in a network, and the SCPs come in mated pairs interconnected by X.25, anyway 💀 Those details don't matter at the level this document is describing, but load balancing and adaptation to failures by using alternative nodes is built into the architecture, which is so smart 🫶
Now the main event ✨ When someone tries to call the subscriber, the central office serving that subscriber pauses its normal termination processing and notifies the SCP. The SCP can then check whether that subscriber has registered that he (or she) is logged onto the Internet 🙈 The really clever part is that the central office can do all this without installing or developing any central office software specific to OCC, because the intelligent network has a standardized layering of service logic. The central office is just provisioned to query the SCP whenever there's a termination attempt (i.e., TAT) aimed at 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 traffic between the SCP and CSN goes over a secure intranet 🔐 The subscriber is only assumed to have access to the Internet, nothing fancier 💖
The intelligent network entities, the SCP and CSN, are the ones with OCC related software 🧠 The OCC server lives on the CSN, and one service package application (SPA) is installed on the SCP. There's another SPA on the CSN too, but it's only needed when the subscriber chooses to accept an incoming call using voice over IP 📞
The OCC Server is a collection of Java servers on the CSN, and it's responsible for a lot 👑 Its responsibilities include:
- Listening for incoming Call Notification (TCP/IP) messages from the SCP SPA.
- De-multiplexing/multiplexing incoming Call Notification messages sent from the SCP SPA.
- Relaying messages between the OCC Client and the SCP SPA.
- Listening for and authentication of OCC Client requests for service registration.
- Handling encryption/decryption of messages exchanged with the OCC Client, and generating session-specific encryption/decryption keys.
And then there's the OCC Client, a collection of software components that runs 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 🎀 It also has a daemon process that watches the Point-to-Point Protocol (PPP) actions and is responsible for starting and stopping the SIP User Agent Server 🦋 Main character energy for sure 💅
4.3. Protocol and Operations Considerations 🔌✨
okay so the OCC Server uses separate TCP/IP ports configured on the CSN for two jobs 🎀:
- Listening for incoming SIP REGISTER messages (for registration service) sent from the OCC Client.
- Listening for incoming SIP INVITE messages (for call notification service) sent from the SCP.
During call notification, the SCP SPA is the client, so it gets started after the OCC Server has already been started 💅. They chat over TCP/IP (via the Secure Intranet) using a "nailed-up" connection that the SCP SPA initiates. That connection gets set up the moment the SCP SPA receives the very first SIP REGISTER request from the OCC Server, and it has to stick around for as long as the SPA is in the in-service state 🫶. The SCP SPA also knows how to restart the connection after any failure condition 🔁.
The OCC Server is multithreaded 🧵. Every Call Notification/Call Disposition event gets its own thread to handle the call. So each start message (SIP INVITE) from the SCP SPA gets its own thread of control, which is the "per message" vibe. Any follow-up messages with the same session Call-ID (that's the SPA's instance, known as call_index, plus the SCP hostname) get routed to the same thread that handled the original message 💖.
The OCC Server dynamically opens a new TCP/IP socket with the OCC Client for each Call Notification/Call Disposition session 💻. This socket uses the IP address and a pre-configured port on the PC running the OCC Client software.
For session registration, the OCC Server dynamically opens TCP/IP sessions with the SCP SPA 📡. The SCP SPA listens at a pre-configured port for incoming SIP REGISTER messages sent by OCC Clients via the OCC Server. To swap SIP messages with the OCC Server, the OCC Client dynamically opens a TCP/IP socket connection 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 🧚. Once the CSN SPA has made the correlation and connected the two incoming call legs for a VoIP call back, a SIP 180 RINGING message gets sent back to the SCP SPA on the actual SCP that told the SSP to forward the Caller to the CSN. That SIP message contains the VoIP Call Back DN dialed by one of the bridged call legs, which is the signal to the SCP SPA that the VoIP Call Back DN is freed up 🔓.
Here's how a typical subscription goes 📝:
- 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 chooses to receive an incoming call via VoIP 🎧. They help route an outgoing call from the subscriber's NetMeeting to the particular CSN that the SCP is (roughly concurrently) forwarding the incoming call to. (These two calls get joined in the CSN to connect the incoming call to the subscriber's Netmeeting client.) These special DNs also let that CSN 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 💜.
- The subscriber calls a PSTN service provider and signs up for the service 📞.
- An active Terminating Attempt Trigger (TAT) is assigned to the subscriber's DN at the subscriber's central office 🏢.
- 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 🗂️.
- The subscriber gets the OCC Client software, a PIN and a file containing the OCC Server IP Addresses 🎁.
Last but not least, here's the OCC Call Disposition scenario that involves voice over IP 🌸:
- The OCC subscriber clicks on "Accept VoIP".
- The OCC Client sends a
SIP 380 Alternative Servicemessage to the OCC Server. This message includes a reference to the Call Back DN that 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 🫧. - The OCC Server closes the TCP/IP session with the OCC Client and sends to the SCP SPA the
SIP 380 Alternative Servicemessage, which includes the Call Back DN 📤. - 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 🔀.
- The SSP forwards the Caller to the CSN referencing the Call Back DN. Note that the Call Back DN was originally assigned to the OCC client by the SCP when the subscriber was alerted to the presence of an incoming call attempt. It then flowed 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, and then to the OCC server on the CSN in association with that forwarded call 🛤️. the DN's whole journey is kinda iconic ✨
- Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from the SIP INVITE message received during Call Notification and 2) the
H323UIDandH323PINvalues from its properties file, and updates thenetmtg.cnffile 🛠️. - The NetMeeting application is launched and sets up a connection with the VoIP Gateway 🚀.
- Once a connection is established between NetMeeting and the VoIP Gateway, NetMeeting initiates a phone call, passing the Call Back DN to the VoIP Gateway as the destination DN 📲.
- The VoIP Gateway consults the VoIP Gatekeeper and authenticates the NetMeeting call by verifying the
H323UIDandH323PINvalues, and by ensuring the called DN (i.e., Call Back DN) is authorized for use 🔐. - 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 📶.
- The CSN bridges the Calling and Called parties together by matching on the basis of the Call Back DN 🌉.
- 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 ♻️. - If the central office supports the 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 🪄.
5. NEC's Implementation 🌟
5.1. Overview 💖
The NEC implementation of the ICW service is based on IN 🧠. Via a SPIRITS server and an ICW client, incoming calls get presented to the user in a pop-up screen dialogue box 🪟. This dialogue box tells the user the call arrival time and the calling party's number and name (if available) 📞. The arrival of the call is also flagged with an audible indication 🔔.
The pop-up dialogue box offers the user various call management options 🎛️. Picking one lets the user answer the call, forward it to another destination or to voice mail, or ignore it 🙈.
The user can customise their service through various service set-up options 💅. All calls presented to the user during an Internet session get recorded in a call log 📒.
Other features include Multiple call arrival management, where each new call arrival generates its own pop-up dialogue box and audible indication 🔥.
5.2. Architecture and Overall Call Flow 🎀
Okay bestie, here's the whole ICW picture 💅 Figure 10 shows the NEC ICW system, and it's giving full network drama 😭
====================================
|| I n t e r n e t ||
|| ||
====================================
/ | \
: (p1) : : (p2)
/ | \
+-------+ +------------+ +-----+
|SPIRITS| | ISP | | W3S |
|Server | | ISP | | W3S |
+-------+ +------------+ +-----+
: :
Internet | :
PSTN/IN |(p0) :
: :
| ============:======
+------+ (p3) || +-----+ : ||
| SCP |-..-..-..-| SSP | : ||
+------+ || +-----+ : ||
|| (p4)| : ||
+-------+ || : : ||
| ICW | (p1)+-----+ || | : ||
|Client |.....| M/D |............+------+ ||
+-------+ (p2)+-----+ || | CO | ||
--------------------| |-------
/ || +------+ || \
/--\ / || P S T N || \ /--\
()/\() / =================== \ ()/\()
_/__\___/ \______/__\_
ICW Subscriber Calling Party
Legend:
ISP : Internet Service Provider
W3S : WWW Server
SCP : Service Control Point(acts as SPIRITS Client)
SSP : Service Switching Point
CO : Central Office
M/D : Modem
Traffic:
--- : PSTN Voice Traffic
... : PPP(IP traffic)
-..-: Signaling Traffic
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 systemThe description below walks through the steps to switch on the ICW service on a CO line, and how that service gets applied to an incoming call using the architecture above ✨
- 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. 🌸
- 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). 🔐
- 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. 📞
- 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
- 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. 👑
5.3. Interfaces and Protocols 🦋
5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface 💜
5.3.1.1. Connecting to SPIRITS Services 🔌
The physical connection between the SCP and the SPIRITS server will be via a LAN/WAN. The logical connection will use the UDP/IP communications as defined in RFC 768 and RFC 1122.
If a socket connection is not currently established, the SCP will periodically try to open a connection. The SCP routing tables will be configured so that all available connections to a SPIRITS server are used.
5.3.1.2. Message Types 💌
Two different types of message are used between the SCP and the SPIRITS server: "Connection Management Message Type" and the "Data Message Type". These messages will carry the remote operation messages which are based on ITU-T Q.1228 SCF-SCF interface with some NEC proprietary extensions.
NEC also has a plan to support SIP/SDP-based protocols for the SPIR-ITS client-server interface in the near future. 🔮
5.3.1.2.1 Connection Management Message Type 🛠️
Connection management messages are to support functions related to the opening and closing of connections and monitoring connections to ensure reliable communications are maintained between the SCP and a SPIRITS server. The SCP is responsible for establishing a connection to a SPIRITS server. A connection can be closed by either the SCP or the SPIRITS server.
The "Connection Management Message Type" includes the following operations:
scfBind-scfUnbind-activitytest
Opening a Connection
If a connection is not open to an SPIRITS server, the SCP will periodically try to open a connection until it is opened. If after a pre-determined number of attempts the connection is not opened, the socket connection will be released and then re-established and then the attempt to open the connection will be repeated.
The sequence for opening a connection is:
- SCP will transmit a scfBind invokation message to the SPIRITS server. This message also carries the version information and activity test interval.
- 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.
- 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.
- 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.
5.3.1.2.2. Data Message Type 📨
SCPs use the following operations, which are sent to the SPIRITS server via a Data-Message-Type message, to request execution of some service procedure or notification of an event that takes place at the SCPs:
handlingInformationRequest
The handlingInformationRequest message will request a SPIRITS server the execution of some service procedure.
handlingInformationResult
The handlingInformationResult message will show the SCP the result of the execution, which was carried out by the SPIRITS server.
confirmedNotificationProvided
The confirmedNotificationProvided message will indicate to the SPIRITS server of an event, which takes place at the SCP. If the confirmedNotificationProvided indicating 'caller abandon' is received, the SPIRITS server will inform the client of the caller abandon and send the SCP a return result for the confirmedNotificationProvided.
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. 🌈
5.3.2. SPIRITS Server-ICW Client Application Interface ✨
okay so here's the list of app messages that get sent over the secure protocol (peep section 5.3.3 for that) 🔐
VersionInfo(ICW client -> SPIRITS server) 📱 The client tells the server which version of ICW client software it's running. The SPIRITS server uses this to figure out if the client is out of date 👀VersionInfoAck(SPIRITS server -> ICW client) 💅 If theVersionInfomessage shows the client is an out of date version, the server sends the URL inside theVersionInfoAckmessage so the client can download the newer version 📥. If the client is already up to date, the message just says so and doesn't include any URL info ✅CallArrival(SPIRITS server -> ICW client) 📞 The server sends this to let the client know someone has called the DN 🫶CallIDAn identifier for this call. It's unique within the domain of this client/server session 🆔CallingNumberCallingNameThe name of the calling party gets sent from the SPIRITS server to the Client Application. When it's available, the name comes as a 15-character string. If the name isn't available, it gets sent as"Name Unavailable". And if the calling party has CLIR set, it gets sent as empty (" ") 🙈CallConnect(ICW client -> SPIRITS server) 🎀 If a matchingCallConnectdoesn't come in within a certain period after the server sends aCallArrival, the server acts like it got aCallConnectwithHandling=Ignore🙃CallLost(SPIRITS server -> ICW client) 😭 The server sends this to cancel aCallArrivalbefore the server gets aCallConnect💔
5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use Between ICW Client Application and SPIRITS Server 🦋
5.3.3.1. Overview
okay so the big idea is this 🧠 the session starts over SSL (so it meets the standards-based security requirements), and then the SSL session gets closed. That means fewer TCP/IP sessions hanging around at the same time, which is so efficient 🙌 The rest of the session runs over UDP/IP, and it's secured with keys and other parameters that were swapped safely during the SSL session 🔑✨
5.3.3.2. Session Initiation
here's how the ICW client starts an SRHDSP session 🚀 First it reserves a UDP/IP port, then it opens an SSL session with the service (like ICW) on the service's well-known SSL/TCP port. Once the SSL session is up, the client sends the server its IP address, the reserved UDP port number, and the set of symmetric key algorithms it supports 📮
The server replies with a symmetric key algorithm picked from that set, its own UDP port for further communication, the heartbeat period, and the value to use for the sequencing window 💌
Then the client generates a symmetric key using the chosen algorithm and sends it over to the server 🔐 After that, the SSL session gets closed and the SRHDSP session is officially considered open 🎉
5.3.3.3. Secure Reliable Datagram Transport
bestie, the application and the later session management messages all use symmetric signaling 🪞 It's the same whether the client is sending a message or the server is sending one, so no special mode for either side 💖
The message packets get transmitted securely 🛡️ And the protocol handles lost, duplicated, and out-of-sequence packets, so it fixes all of that for you 🧚
5.3.3.4. Session closure
either the client or the server can close the session 👋
to close it, a Close message gets sent that includes the next sequence number, and it's encrypted with the agreed key 🔒
here's the tea 🍵 when the receiver processes a Close message (not just receives it), it should set a timer. When that timer runs out, all the details of the session should be forgotten. The timer is there so a retransmitted close can still happen if the Ack got lost. We still need to be able to decrypt that retransmission and re-acknowledge it 🔁 it's so thoughtful, honestly 🥹
and if any message other than a close comes in after a close has been processed, it gets ignored 🙅♀️
6. Telia/Nortel's Implementation 🌈
6.1. Overview
the system Telia built together with Nortel Networks is designed to support services that run before the end-to-end media sessions are set up 📡 Some examples are:
- call transfer and number portability for redirecting calls 🔀
- call waiting and call offering for announcing a pending call 🔔
- call screening and don't disturb for filtering incoming calls 🚫
- automatic call distribution and 800-services for picking the termination point 🎯
the Telia/Nortel system wants to let service providers develop the services listed above 💼 Right now, prototypes for online incoming call disposition and automatic incoming call disposition (described in Section 2) have been built to prove the concept 🧪✨
in the Telia/Nortel architecture, services run on top of SIP Redirect Servers 🖥️ SIP is so distributed that these servers can live pretty much anywhere: an enterprise server, a Service Provider's server cluster, a user's desktop PC, or even a hand-held cordless device 📱💜
the SIP Redirect Server gets a SIP INVITE message for every call, no matter which network the call is being set up in 📥 The server MAY apply any kind of service logic to decide how to respond to the invitation 🧠 That logic may interact with the user so they can say how a call should be handled, like in Section 2. But this isn't the focus of the Telia/Nortel system, so we're not going deep on it 🙈
6.2. Architecture and Protocols
the big goal of the architecture is to make services as if all communication was IP-based and all clients and servers were SIP enabled 🌸 Obviously that's not true in existing telecom networks, so there's a new kind of network element, the Service Control Gateway (SCG), that hides the real situation from the services 🫣
SCGs convert network-specific call control signaling into SIP messages and back again 🔄 An SCG acts like a regular SIP User Agent (UA) toward the services, and like a network-specific service control node in the network where the call is being set up 🎭 For example, when connecting to a GSM network, the SCG can play the role of an SCP, a MAP, or an ISUP proxy. Which role it plays depends on what service triggers are used in the GSM network 💅
SCGs handle protocol conversions but NOT address translation (like telephone number to SIP URL). That job goes to a regular SIP Server, so the SCG stays as simple as possible 🧼
let's look at a number portability example 🔢 A regular number portability setup in a mobile Circuit Switched Network (CSN) uses INAP messages to carry number queries to a network-internal database application. Here, an SCG and a high-performance SIP Redirect Server, called the Number Server (NS), have replaced the database that's usually in an SCP. (See Figure 11.)
+-----------+ INAP +-----+ SIP +--------------------------+
| CSN node |--------| SCG |-------| NS (SIP Redirect Server) |
+-----------+ +-----+ +--------------------------+
Figure 11: An Architecture for Number Portabilitythe SCG turns the INAP IDP message (the one with the number query) into a SIP INVITE message, then forwards it to the NS (SIP Redirect Server) 📨
if the called number isn't registered, the NS returns "404 Not Found" ❌ The SCG reads that as "non ported number" and sends a CON message back to the CSN network, so the call connects to the called number 📲
if the number is ported (so it's registered), the NS returns "301 Moved Permanently" with a TEL URL (routing number) in the contact field 🗺️ The SCG then sends a CON message back to the CSN network, so the call connects to the number that was in the contact field 💫
this whole setup means the same Number Server can provide Number Portability to multiple networks, just by using multiple SCGs 🌍✨
if we make the SIP server in the number portability example work in proxy mode for selected numbers, it turns into a kind of service router 🚏 It can relay number queries to any SIP-Redirect-Server-based service anywhere, as long as there's an IP connection to the host in question. Figure 12 shows how it's arranged 👇
+------+ INAP +-----+ SIP +----------------+ SIP +----------+
| CSN |------| SCG |-----| NS |-----| Service |
| node | | | |(redirect/proxy)| |(redirect)|
+------+ +-----+ +----------------+ +----------+
Figure 12: SIP-Based Service Routernow say we hook up a value-added service, like a Personal Call Filtering service hosted on a user's desktop PC, to a certain telephone number 📞🧚 The SCG turns the INAP IDP message into a SIP INVITE and forwards it to the NS, just like before. The difference is that this time the number is registered with a reference to a SIP URL. So the Number Server proxies the SIP INVITE to that registered URL, which is the address of the service 🎀
the service acts as a SIP Redirect Server, and the Personal Call Filtering service logic decides the response 🧠 The NS sends that response back to the SCG, which converts it into 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 (like the examples above suggest), a telephone number is carried in the contact field. If the user can be reached at several different addresses, then ALL of them SHOULD be added to the response using multiple contact fields 💌 The SCG then picks the address that's valid for the node or application that issued the number query 🎯
as the service examples show, the Telia/Nortel system lets you introduce multi-network services without needing multi-protocol support 🙌 So the services work the same way no matter which network the call is made in, 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 SIP6.3. Security ✨
Okay bestie, let's talk security 🔐. The Telia/Nortel setup uses the same security tools that ordinary SIP services already use, set up the same way they would be in a pure SIP network 💖. The architecture doesn't add any extra security considerations of its own 🦋.
That said, there are general security issues to think about, mainly when you hook two different networks together 🔗. So SCGs must therefore include mechanisms that stop destructive service control signaling from going from one network to the other 🚧. Picture a firewall-type mechanism that can block a denial-of-service attack from an Internet user heading toward the PSTN 🛡️. Iconic behaviour from the firewall, honestly 💅.
7. Security Considerations 🛡️
Overall, the SPIRITS security requirements are basically the same as the ones for PINT [3, 4] 🎀. Some of the big ones include:
- 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 we saw in the earlier sections, most of the implementations we looked at used things like firewalls and encryption to hit these requirements 🔥. The catch is that the means are different from one implementation to the next 🤷♀️, so no two of them do it exactly the same way 💀.
8. Conclusion 🌈
This document gave you the info you need to build inter-networking interfaces between the PSTN and the Internet for supporting SPIRITS services 🧚. Specifically, it described four existing implementations of SPIRITS-like services. Surveying them, here's what we can say:
- The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it 👑.
- SIP is used in most of the implementations as the base communications protocol between the PSTN and the Internet. (NEC's implementation is the only exception, since it uses a proprietary protocol. Still, NEC has a plan to support SIP together with the extensions for SPIRITS services 🌸.)
- All implementations use IN-based solutions for the PSTN part.
It's clear that not all pre-SPIRITS implementations inter-operate with each other 😭. It's also clear that not all SIP-based implementations inter-operate with each other, given that they don't support the same version of SIP 🙈. So it's the job of the SPIRITS Working Group to define the inter-networking interfaces that will support inter-operation of future SPIRITS implementations ✨.
9. References 📚
[1] 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.
[2] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[3] 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.
10. Authors' Addresses 💌
Igor Faynberg Lucent Technologies Room 4L-334 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
Phone: +1 732 949 0137 EMail: faynberg@lucent.com
Hui-Lan Lu Lucent Technologies Room 4L-317 101 Crawfords Corner Road Holmdel, NJ, USA 07733-3030
Phone: +1 732 949 0321 EMail: huilanlu@lucent.com
John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd PO Box 3050 Naperville, IL, USA 60566-7050
Phone: +1 630 713 5538 EMail: jvoelker@lucent.com
Mark Weissman Lucent Technologies Room NE406B 200 Lucent Lane Cary, NC, USA 27511-6035
Phone: +1 919 463 3258 EMail: maw1@lucent.com
Weizhong Zhang Lucent Technologies Room 01-A5-17 2000 Regency Parkway Cary, NC, USA 27511-8506
Phone: +1 919 380-6638 EMail: wzz@lucent.com
Sung-Yurn Rhim Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Phone: +82 2 526 6172 EMail: syrhim@kt.co.kr
Jinkyung Hwang Korea Telecom 17 Woomyun-dong Seocho-gu, Seoul, Korea
Phone: +82 2 526 6830 EMail: jkhwang@kt.co.kr
Shinji. Ago NEC Corporation 1131, Hinode, Abiko, Chiba, 270-1198, Japan
Phone: +81 471 85 7412 EMail: ago@ssf.abk.nec.co.jp
S. Moeenuddin NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
Phone: +1 972 518 5102 EMail: moeen@asl.dl.nec.com
S. Hadvani NEC America, Inc 1525 Walnut Hill Lane, Irving, TX, USA 75038
Phone: +1 972 518 3628 EMail: hadvani@asl.dl.nec.com
Soren Nyckelgard Telia Research Chalmers Teknikpark 41288 Gothenburg Sweden
EMail: soren.m.nyckelgard@telia.se
John Yoakum Nortel Networks 507 Airport Blvd, Suite 115, Morrisville, NC, USA 27560
EMail: yoakum@nortelnetworks.com
Lewis Robart Nortel Networks P.O. Box 402 Ogdensburg, NY, USA 13669
EMail: robart@nortelnetworks.com
11. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). 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 languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society 💜.
📦 where this page comes from
- ietf: rfc2995 2000-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms