RFC 2458
Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations
RFC 2458: Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations 🎀
okay bestie, this one is from November 1998 and it's an Informational RFC, so it's not a standard, just a super detailed field guide 📖✨. The editor is H. Lu, and the crew is M. Krishnaswamy (Lucent Technologies), L. Conroy (Roke Manor Research), S. Bellovin, F. Burg, A. DeSimone, and K. Tewani (AT&T Labs), P. Davidson (Nortel), H. Schulzrinne (Columbia University), and K. Vishwanathan (Isochrome) 💜. It doesn't obsolete or update any other RFCs 🙅♀️. It's from the Network Working Group, which is the main character of this whole story 🌈.
Status of this Memo ✨
so this memo is just here to share info with the Internet community 🫶. it does NOT count as an Internet standard of any kind, and it can be shared freely with no limits 💅.
Copyright Notice 🎀
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract 🦋
okay so this doc is all about the info you need for building the inter-networking interfaces that the PINT Working Group is cooking up 🍳. PINT stands for PSTN/Internet Inter-Networking, and the PSTN is the Public Switched Telephone Network 📞. it covers technologies, architectures, and a bunch of existing pre-PINT implementations (but not literally all of them, bestie, it's not that deep 😭). these are the ways Internet apps can request PSTN telecom services and make them way more enriched 🔥.
the big idea is that PINT services mix the Internet and the PSTN together so the Internet handles the non-voice stuff, while voice and fax go entirely over the PSTN 📠. here's the tea: the pre-PINT implementations were all built on their own, so they do not inter-operate 💀. the PINT Working Group's job is to define the inter-networking interfaces so future PINT implementations can actually talk to each other 🫶✨.
Table of Contents 🍓
1. Introduction ....................................... 3
2. Terminology ....................................... 3
3. PINT Services ....................................... 4
4. Architectural Overview ............................... 5
4.1 Public Switched Telephone Network ............... 5
4.2 Pre-PINT Systems ............................... 9
5. IN-Based Solutions ............................... 20
5.1 The Lucent System ............................... 20
5.1.1 Roles of the Web Server, Service Node, and SMS ....... 20
5.1.2 A Click-to-Dial-Back Service Scenario ............... 21
5.1.3 Web Server-Service Node Interface ............... 22
5.1.4 Web Server-SMS Interface and SNMP MIB ............... 24
5.1.5 Security Considerations ........................... 26
5.2 Siemens Web Call Center ........................... 27
5.2.1 Service Description ............................... 27
5.2.2 Implementation ................................... 29
5.2.3 Derived Requirements/Lessons ..................... 35
6. Alternative Solutions ............................... 37
6.1 The AT&T System ..................................... 37
6.1.1 High Level Architecture ............................ 38
6.1.2 IP Client to CallBroker Interface .................. 39
6.1.3 Protocol ........................................... 40
6.1.4 APIs Exposed to the IP Client ..................... 41
6.1.5 Voice-Bridge Control API ........................ 41
6.2 Simple Computer Telephony Protocol ............... 41
6.2.1 Overview ........................................... 41
6.2.2 How SCTP Fits in with the Reference PINT Services .. 42
7. Session Initiation Protocol--An Emerging Standard .. 43
7.1 Overview ....................................... 43
7.2 SIP Protocol ....................................... 44
7.3 SIP Entities ....................................... 45
7.4 Providing Call Control Functionality ............... 46
8. Overall Security Considerations ..................... 47
9. Conclusion ....................................... 48
10. Acknowledgments ................................... 48
11. Appendix ....................................... 49
11.1 PSTN/IN 101 ....................................... 49
11.1.1 Public Switched Telephone Network ............... 49
11.1.2 Intelligent Network ............................... 51
11.2 Call Center Features ............................. 54
12. References ....................................... 56
Authors' Addresses ......................................... 57
Full Copyright Statement .................................. 601. Introduction 🌸
okay so the Abstract kinda already spilled the tea, but here's the full picture 🫖. this doc is all about the inter-networking interfaces being built by the PINT Working Group 🔧. PINT services combine the Internet and PSTN so that the Internet handles the non-voice interactions, and the voice and fax stay completely on the PSTN 📞✨.
the vibe of the doc goes like this 🗺️. first, you get the basic terminology plus a quick "intuitive" look at PINT services 🧠. then the rest of the doc looks at the pre-PINT support for those services, using them as a benchmark 📏. after that comes an architectural overview that covers every solution out there right now 🏗️. then the doc splits into two storylines 👯♀️. one is about IN-based solutions (Intelligent Network), and the other is about alternatives, like the CallBroker approach and the Computer-Telephony Integration (CTI) approach 💻. next up are the emerging standards, especially the Session Initiation Protocol (SIP), which is honestly giving elegant solution to the PINT problem 😍🦋. each of these developments gets its own section 🎀.
the last bits of the doc are the overall security considerations, the conclusion, acknowledgments, an appendix, and the references 📚. the security section sums up the PINT security requirements we learned from pre-PINT experiences 🔐, and the appendix is a tutorial on PSTN, IN, and Call Center functions 🎓. main character energy, honestly 👑.
2. Terminology 💜
okay so this doc uses a few key terms, and you need these to follow along 🫶:
- Authentication -- verification of the identity of a party 🪪.
- Authorization -- determination of whether or not a party has the right to perform certain activities 🔑.
- PINT Gateway -- the PSTN node that interacts with the Internet 🌉.
- User or Customer -- the person who asks for a service request to be issued. in the context of PINT Services, this person will use an Internet host to make his or her request 💅. the term "user" is also used to describe a host originating the PINT service request on behalf of this person 🤖.
3. PINT Services ✨
okay so this section is where the PINT Working Group's four services get introduced 🎀 these are the ones they'd already identified and that pre-PINT implementations were already running: click-to-dial-back, click-to-fax, click-to-fax-back and voice-access-to-content 💅
Now, the word "click" is NOT meant to be taken literally 🙈 it's just a nod to how people kick things off on the Internet, where point-and-click is basically the main move 🖱️🌸 so a service request could come from pretty much any kind of IP-based platform. Nobody is saying these services have to be run by a device on the PSTN or the Internet with a Web server, bestie 🧚
The big idea is that the Internet handles the non-voice stuff, and the voice (and fax) rides entirely over the PSTN 📞✨ Think of a Web-based Yellow Pages that lets customers and suppliers actually ring each other up through the PSTN, which is exactly the kind of combo this is about 💜
Why bother with the PSTN? Because it gives you high-quality voice 🎧, the ability to route calls differently based on pre-set rules (like time of day, day of the week, or where you are geographically) 🗺️, outstanding security and reliability 🔐, and flexible, low-cost, secure billing and charging systems 💸. Meanwhile the Internet brings uniform, well-defined, widely-used interfaces you can reach anywhere, anytime 🌈
3.1. Click-to-Dial-Back 📲
With this one, a user asks (through an IP host) for a PSTN call to be set up between another party and themselves 💖 The big prerequisite is that the user needs simultaneous access to both the PSTN and the Internet 🫶
Example time! 🛍️ Someone's browsing an online catalogue, clicks a button, and boom, they get a call from a sales rep 📞 Just like the all-PSTN Free-Phone (aka "800") service, flexible billing can be set up here on behalf of the service provider 💅 And similarly to Free-Phone/800, the PSTN could route the call based on time of day, day of week, agent availability in different locations, and so on 🦋
3.2. Click-to-Fax 📠
Here a user at an IP host asks for a fax to be sent to a particular fax number 🎀 This is especially meaningful when the recipient only has a fax machine and no Internet access at all 😭
Picture this: a Web user is booking a hotel room in Beijing from a travel service page that has hotel info for major cities around the world 🌏 The chosen Beijing hotel has no Internet connection, but it does have a fax machine 📠 So the user fills out the reservation form and clicks a button to send it to the travel service provider 💌 The provider then generates a fax request and sends it, along with the reservation form, to the PSTN 🧚 Once the PSTN gets the request and the data, it translates the data into the proper facsimile format and delivers it to the Beijing hotel, as the fax request specifies 👑
3.3. Click-to-Fax-Back 🔁
With this service, a user at an IP host can ask for a fax to be sent to them 💕 Remember our Beijing user? Now they want the confirmation from the Beijing hotel 🏨 Another iconic use case is when the info is SO big that downloading it over the Internet would take forever and eat up a ton of disk space on their PC 💀
3.4. Voice-Access-to-Content 🎧
With this one, a user at an IP host asks for certain Internet information to be accessed (and delivered) in audio form over the PSTN, using the telephone as an informational appliance 📞🌈 One application is giving the blind Web access 🫶 (This may need special PSTN resources to convert the Web data into speech, so it's not just a vibe, it's real infrastructure 🔥)
4. Architectural Overview 🏗️
4.1 Public Switched Telephone Network
okay so bestie, from an app's point of view, Internet nodes just connect directly to each other 🦋 ✨ When two machines want to talk, they already have the address of the destination end system, and they send network-level datagrams and trust that the underlying infrastructure will deliver them as needed 💅
_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.
\_____ _______/ |
__ \__./ __ .
[__] / [__] |
[----]-. [----]-.
Key: .-.-. Internet Access Link
Figure 1If every node is on the same (broadcast) network, you don't need any routers in the middle 🌸 They can send and deliver packets straight to each other. The Internet nodes handle their own communication requests and act as peers in the sessions that come out of it. no hierarchy, just vibes 🫶
This is giving a totally different energy from the PSTN 📞 In the PSTN, the end systems are set up like this:
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Figure 2The end systems tend to be locked into one type of traffic 📠 For example, most terminals are dedicated to speech (telephones) or to faxes (fax machines). All the terminals connect to Central Offices (COs) through access lines, and those COs are linked together into a network 🧚
Communication between terminals is "circuit switched," which means a dedicated synchronous data path (aka a circuit) has to be set up between the end terminals to carry all of the communication 🎀 The COs are the ones responsible for making that circuit and clearing (removing) it when it's done. A user makes a request from their terminal, and it gets passed to the "local" Central Office. The relationship between terminals and their local COs is strictly Client/Server 👑
The COs connect to each other using two different kinds of connections 💜 The first is a trunk connection (shown as a double line in the figure above), and it carries the data traffic generated by the terminals. The second acts as part of a separate network (shown as a dotted line in the figure above). This is the signaling network, and the COs use it to request that a connection be made between themselves and the destination of the circuit. That request gets carried across the trunk link to the "next" Central Office on the path. Once a path is in place through the PSTN, it always takes the same route 😭 The Internet is the opposite: because the infrastructure is datagram-based, data packets can take different routes depending on the combined traffic flowing through the network at that moment 🌈
Call setup can be split into two parts: first a connection is requested, and then the circuit gets made across the PSTN so call data can flow between the two parties ✨ Here's the next pair of figures (3a and 3b) showing that:
/--\
() ()
--____
/++\ \
/----\ \
A \ [-!-]
\->[CO ]
[---]
Time = 13:55
Figure 3a Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
/--\
() ()
-- .................................
/ \<--- ^ ! ! /--\
/----\ \ ! v ! () ()
A' \ [-!-] [-!-] ! --
\__[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B'
Time = 14:00 [---]
Figure 3bFigure 3 shows one kind of service you can get, called call booking 📅 With this service, you send a request for a connection between the A and B telephones at a set time. Then you hang up the phone (the request phase is over). At the scheduled time, the CO makes the connection across the network the normal way, but first it rings the "local" or A' telephone to let the user know their call is about to happen 🔔
For fancier services, the requesting telephone is often connected via its "local" CO to a Service Node (SN) 💅 That's where the user can hear prompts and specify the parameters of their request in a more flexible way. This is shown below, in Figures 4a and 4b. For more details on how the Service Node (and other Intelligent Network units) work, see the Appendix 📖
When the SN is involved in both the request and the call setup, it looks like just another PSTN terminal to the CO 🤖 So the initial request gets routed to the Service Node, which then, acting as an end system, makes two independent calls "out" to A' and B' 🙌
/--\ [---]
() () [SN ]
--___ [|--]
/++\ \ |
/----\ \ |
\ |
A \ [|-!]
\->[CO ]
[---]
Time = 13:55
Figure 4a Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
SN Service Node
/--\ [---]
() () [SN ]
-- [|--] /--\
/ \<-- | ............................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ] [CO ] [CO ] /
[---] [---] [---]___/ B'
Time = 14:00
Figure 4bHeads up, though 🙈 In both cases (Figures 3 and 4), you can get a similar service where the B' telephone is swapped out for an Intelligent Peripheral (or a Special Resource Functional entity inside a Service Node) that plays an announcement. That's how you can request a "wake up" call: the Intelligent Peripheral or Service Node Special Resource plays a suitable message to telephone A' at the time you asked for 🌅 Again, for more details on how Special Resources (and other Intelligent Network units) work, see the Appendix 🧚
4.2 Pre-PINT Systems
okay, so the pre-PINT systems covered here (the ones developed by AT&T, Lucent, Siemens and Nortel) each have their own quirks 🍓 but they're lowkey super similar in architecture 💖 This section is all about the shared features. The specific descriptions of these systems come later, so stay tuned ✨
All of these systems are pretty much like the diagram below 🦋 In each one, the service is split into two parts: one for the request and one for executing the service. Figure 5 sums up the whole process 🫶
_____
__ _____/ \_____
[__] / \
[-++-]-.-.>.-. Internet .-.-
\_____ _______/ .
\___/ v
[----] .
[PINT]-.-
[----]
%
v
[---]
[SN ]
[|--]
Figure 5a Key: CO Central Office (Telephone Exchange)
SN Service Node
PINT PSTN/Internet Gateway
.-.-. Internet Access Link
%%% Gateway/Service Node Link
___ PSTN Access Lines
=== PSTN Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.-
\_____ _______/ .
\___/ |
[----] .
[PINT]-.-
[-%--]
%
%
/--\ [-%-]
() () [SN ]
-- [|--] /--\
/ \<-- | .................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ]=======[CO ]======[CO ] /
[---] [---] [---]__/ B'
Figure 5bIf you compare Figure 4a with Figure 5a, the big difference is how the information specifying the request reaches the Service Node 🧐 In the PSTN/IN method from the earlier diagram, the user connects to the SN from telephone A, and that connection gets routed through the CO. In the Figure 5a case, the request comes from an Internet node, goes through the PINT gateway, and then reaches the Service Node over a "private" link 🔗 The effect is identical in that the request for service gets specified, although the actual parameters used to specify the service might be a bit different 💅
Looking at the execution phases (Figures 4b and 5b), the operation is again identical from the IN/PSTN perspective 🌸 The Service Node appears to start two independent calls "out" to telephones A' and B' 📞✨
Okay so picking up right where the AT&T and Nortel systems come in, bestie 💅✨ Those two took a different route: instead of hooking the PINT Gateway up to the PSTN through a Service Node (or some other Intelligent Network buddy), they let it plug straight into Central Offices that can do the stuff the gateway asks for 🦋 The commands get written at a "lower level," so they describe the call states needed for the service connection instead of a service identifier and addresses. The Intelligent Network pieces just handle the nitty-gritty of the service call for the gateway 🧚 So the commands sound more like what Central Offices already speak 🎀 The real difference is in the language used to describe the services, and every system can still use the overall architecture from Figure 5. The only open question is whether the Intelligent Network components are even needed in these other approaches 🤔
Here's Figure 6, which shows the interface architecture for the kind of service we just mentioned 💖
Internet __ __
Server [__] _______ [__]
[W3S-]-. ___/ .-.-.-[W3C-] Internet
_________________|/.-.-.-.-. \ Terminal
/ .. . \
| Internet / . \ |
\___________ . . . /
\/___|____\_________/
. . .
/ | \
(A) (B) (E)
. . .
_|_ _|_ _|_
[SN ]<-(D)--[SMS]--(H)->[SCP]
[|-|] --- [-!-]
/ \ !
(C) (I) ...........(F)...!.(G).
/ \ ! !
[--|] [|-!] [-!-]
[CO ] [MSC] [SSP]
[---] [---] \|/ [---]
/--\ | |____| | /--\
()/\() | | ()/\()
/--\___| 1 |___/--\
Fixed PSTN Terminal [] Fixed PSTN Terminal
Mobile TerminalKey: W3S HTTP (Web) Server
W3C HTTP (Web) Client/Browser
CO Central Office (Telephone Exchange)
MSC Mobile Switching Center (Mobile Network Telephone
Exchange)
SN Service Node
SSP Service Switching Point
SCP Service Control Point
SMS Service Management System
.-.-. Internet relationship
___ PSTN Access relationship
... PSTN "core" signaling relationship Figure 6Here's what each interface does 🫶
A: this is where Internet requests for service get delivered to the Service Node 🌸B: this is where Service Management requests get sent from the Internet to the Service Management System 💜C: this is where the Service Node sends call control requests to a connected Central Office 📞D: this is where the Service Management System manages the Service Node 🧚E: this is where Internet requests for service get delivered to the Service Control Point 🦋F: this is where the Service Control Point sends service call control requests to the Mobile Switching Center 🎀G: this is where the Service Control Point sends service control requests to the Service Switching Point 💅H: this is where the Service Management System manages the Service Control Point 👑I: this is where the Service Node sends service call control requests to the Mobile Switching Center ✨
Okay so in practice a bunch of these interfaces have really similar purposes 🙈 Their methods are different though, because some of them (C and I) are about access arrangements, while others (F and G) are about a "core" signaling relationship 💀 Still, you can group them by the "intent" of the messages sent across them, and that's the vibe we're going for 🌈
For example, Interfaces A and E are similar, and one of the main goals of PINT work is to make sure they end up being the same 🔥 Interfaces D and H imply similar actions, so they'll probably carry similar messages 🍓 And Interfaces C, F, G, and I all exist to ask for a call to be initiated, whether through access or core signaling relationships 📞✨
You can also look at the interfaces by the kinds of components involved and the bodies that codify them 💖 Interfaces A, B, and E are all going to be realized as Internet Protocols 🌐 Everything else uses existing protocols in the PSTN/IN 🫶 Those have traditionally been codified by different groups, and that's probably going to be the case for PINT work too 😭
The general setups for the different systems are shown next (Figures 7, 8, 9, and 10) 🦋 They differ in the details of their configurations, but they do pretty much the same main jobs, so the overall operation looks a lot like the generic architecture in Figures 5 and 6 💜 Here's the key for the following diagrams 🎀
Components:
W3C World Wide Web Client
W3S World Wide Web Server
WSA Web Server "Back End Program" Interface (CGI or Servlet
interface)
Srvlt Servlet "back end" program/objects
FS Finger Server
SCTPC Simple Computer Telephony Protocol Client
SCTPS Simple Computer Telephony Protocol Server
CBC CallBroker Client
CBS CallBroker Server
SSTPC Service Support Transport Protocol Client
SSF Service Switching Function
SCF Service Control Function
SRF Special Resource Function
CO Central Office/ Public Telephone Exchange
SSP Service Switching Point
SCP Service Control Point
SR/I.IP Special Resource/ "Internet" Intelligent Peripheral
SMS Service Management System
INAPAd Intelligent Network Application Part Adaptor
PktFlt Packet Filter (Firewall)
SNMPAg Simple Network Management Protocol Agent Protocols:
P0 HyperText Transfer Protocol
P1 HTTP Server <-> "Back End Program" internal protocol
P2 CallBroker Client <-> CallBroker Server protocol (AT&T system),
or SCTP Client <-> Server protocol (Nortel system)
P3 PINT User Agent <-> PINT Gateway protocol
P4 Intra-Intelligent Network protocol (e.g., INAP)
P5 Proprietary (INAP-based) Gateway-> I.IP protocol
P6 Finger protocol
P7 Digital Subscriber Signaling 1 protocol
P8 Simple Network Management Protocol
P9 SMS <-> Service Control Point/Service Node protocolNow here's Figure 7, the Siemens setup 🌸
_____ _______ _____
|[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]|
|[---]| | [WSA] | |[FS.]|
|-----| | ! | |[-!-]|
| (p1) | |--\--|
| ! | ^
| ! | (p6)
| ! | \
| (p1) | \
| ! | \
|[Srvlt]| \
|___!___| \
! \
(p3) \
Internet ! !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+.
PSTN/IN _______________!_________________ ____!_____ __________
|I [PktFlt] I| |[PktFlt]| |[PktFlt]|
|N Gateway N| | ! | | ! |
|A ___________________________ A| | ! | | ! |
|P | | P| | ! | |[SNMPAg]|
-(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] |
\ |d | [-^-] | d| |[------]| | [-^-] |
\ |__| ! |__| |________| |___!____|
\ ! !
[-v-] !-----------------(p9)-----------------!
[SSP]
[---]
___| |______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 7: The Siemens Web Call CenterAnd now Figure 8, the Lucent system 🦋
_____ _______
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
| ! |
| ! |
| (p1) |
| ! |
|[SSTPC]|-<----------------------------------
|___!___| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[-v-] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 8: The Lucent System _____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/CBS]|
|[Adaptr]|
|___!____|
^
(p2)
_____ ___v____
|[CBC]| | [CBS] |
|[---]|<---(p2)-->| [---] |-<---------------------------------
|-----| |___!____| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 9: The AT&T System
_____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/ ]|
|[ SCTPS]|
|[Adaptr]|
|___!____|
^
(p2)
_______ ___v___
|[SCTPC]| |[SCTPS]|
|[-----]| <-(p2)--> |[-----]|-<----------------------------------
|-------| |___!___| !
! (p8)
(p3) !
Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+.
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\
Figure 10: The Nortel SystemOkay bestie, so the three systems are totally different babies 🍓 Built by different groups, so of course the component names don't match 💀 Some features are on one system and missing from the others, but there's a bunch of stuff they ALL share ✨ Every one of them has a Web-based interface (at least as an option) that uses "back end" programs to build protocols and pass them onward to the Intelligent Network system 💻
Several Intelligent Network Functional Entities get bundled into one Service Node in the Lucent, AT&T, and Nortel systems, while Siemens keeps them as separate units 🧩 Honestly? Not a huge deal for the services they actually offer 💅
The big difference is whether the SCF is "aware" of the Internet interface and has been modified to be "complicit" in supporting these Internet requests 👀 Siemens went with reusing an existing SCP and adding a gateway function that translates as needed 🔁 Lucent used a "lighter weight" SCF adapter to terminate the Internet protocols, since the SCF was modified to support the Internet interface directly 🦋
The AT&T CallBroker and Nortel SCTP Servers bring in an intermediate protocol (labeled p2) that gives you an option beyond the Web interface the others use 🎀 It matches either the "CallBroker Client API" or the "SCTP Client API" 📱 These give you a bi-directional protocol, so the Call Broker or SCTP Server can send indications to the Client whenever needed 🔔 That's not easily doable with an HTTP-based scheme, which is why the Siemens side used a dedicated Finger client/server pair to fake that kind of interface 😭
The protocol between the Internet server and the Intelligent Network (labeled p3 in the diagrams above) is different in every system 🌈 A major goal for future work is to build a common protocol that supports the services offered, so the p3 interface lets different implementations interoperate 🫶 In the Lucent, Siemens, and Nortel systems, this was an "internal" protocol, carried between entities inside the Service Node or Gateway 🔒
The systems also differ in how they support Internet access to Service Management and to Special Resources 🧚 Lucent had the most developed Internet management access, with a Simple Network Management Protocol (SNMP) agent that lets it interoperate with the SMS controlling the Service Node 📊 In the Siemens scheme, the SMS had no direct Internet access, so any management actions happened within the normal PSTN management activities 📞 As for Internet access to special resources, only the Siemens system needed it, as part of supporting Call Center agent notification 📣 AT&T and Nortel would get equivalent functionality as mentioned above, and that would be tied to event notifications sent as part of their (p3) Internet/IN protocol 🔗 These differences come from the different emphases in each product as it was developed, and future work will have to make sure common protocols can fully support the chosen services 💜
5. IN-Based Solutions ✨
5.1 The Lucent System 💖
Okay so Figure 11 shows the overall interconnection architecture of the Lucent prototype, which supports the four PINT services 🌸 The IN-based architecture uses the Service Node and Service Management System on top of the Web server, which is what gives you Web-based access to the PINT services 💻 This section sums up what each of these pieces does (plus a click-to-dial-back service scenario), lays out the interfaces between Web Server and Service Node and between Web Server and Service Management System (the interfaces A & B), and covers the common security concerns 🔐
5.1.1 Roles of the Web Server, Service Node, and Service Management System 🎀
Web Server
The Web Server stores the profiles of content providers as well as pre-registered users 📇 A content provider profile holds stuff like the content provider ID, telephone number, and fax number 📠 The profile can also include service logic that says, for example, which telephone (or fax) number to reach based on time of day, day of week, or the user's geographical location, plus the conditions for accepting the charge of the calls 🌍
The pre-registered user profile is kind of similar, and holds things like user name, password, telephone number, and fax number 🔑 The last two can also be tied to time of day and day of week, so the user can be reached at the right telephone (or fax) number at the right time 🕰️
Service Node
Living in the PSTN, the SN is like the SCP and performs the service control function [1, 2, 3] 🏠 It runs the service logic and tells switches how to complete a call 📲 It also handles some switching jobs (like bridging calls) and a set of specialized stuff (like playing announcements, voice recognition, and text-to-speech conversion) 🗣️
Service Management System
The SMS handles the administration and management of service logic and customer-related data on the SN 🗂️ It's in charge of replicating content provider profiles and provisioning that data on the SN 📤 These functions are non-real time ⏳
Web Users
____________
O -------------------------- | Internet |-------------------
------------ |
|
|
---------------- -------------- ------------
| Service Node | D | Service | B |Web Server|
| (SN) |------------| Management |---------------| |
| | |System (SMS)| | |
| | A -------------- | |
| |-----------------------------------------| |
---------------- ------------
| |
| I | C
| |
----------- ---------
|Mobile | |Central|
|Switching| |Office |
| Center | ---------
----------- |
| |
| |
O O
Mobile Wireline PSTN
Users Users
Figure 11: Overall Interconnection Architecture of the Lucent System5.1.2 A Click-to-Dial-Back Service Scenario 📞💕
Picture this: a Web user has simultaneous access to the Web and telephone services (you can get that with an ISDN connection, for example) 💻📱 They're scrolling through a sales catalogue and decide they want to talk to a sales rep 🛍️
When the Web user clicks a button asking for a phone call from the sales office, the Web Server sends a message to the SN over the A interface, which means it's crossing the Internet-to-PSTN boundary 🚀 The SN matches the info it got from the Web Server against the content provider profile that the SMS loaded and activated earlier over the D interface, and that's how it recognizes the signal 🧠
Then the SN calls the Web user 📲 The user picks up, hears an announcement like "Please wait, while we are connecting you to the sale agent," and waits to get connected to a sales agent 🎶 Next, the SN invokes the service logic indicated in the profile 🧾
Here's where it gets iconic: that logic picks which sales agent to call based on the time of day 🌙 It's 8 P.M. in New York, where the Web user is, and the New York sales office is closed 🗽 But the San Francisco office is still open, so the SN calls an agent there 🌉 Finally, the SN bridges the two calls and sets up a two-party call between the sales agent and the Web user 👑
5.1.3 Web Server-Service Node Interface
okay bestie, this is where the Web Server and the SN actually talk to each other 💬✨ Lucent made a protocol called the Service Support Transfer Protocol (SSTP) for exactly this. It's request/response, so the Web Server sends a request to invoke a service and the SN sends back a message saying either success or failure. It runs on top of a reliable transport layer, like TCP 🦋 Also, SSTP only touches the service control function [1, 2, 3] of the SN, so that's its whole lane 💅
5.1.3.1 Web Server to Service Node
three kinds of messages can go from the Web Server to the SN: the Transaction Initiator message, the Data Message, and the End of Data message 🎀
the last two are only needed if the service involves data, like click-to-fax, click-to-fax-back and voice-access-to-content. this was designed on purpose to handle data of varying size, and to make sure each stream fits inside the allowable size of the underlying transport packet data unit (which some TCP/IP implementations impose) 🧚
a. Transaction Initiator
this message has everything needed to invoke a service, except the data itself. it includes these information elements:
- Transaction ID, which uniquely specifies a service request 🔑 The same transaction ID should be used for all the accompanying data-related messages, if the service request involves data. One way to generate unique transaction IDs is to concatenate: date, time, Web Server ID (uniquely assigned for each Web Server connected to the SN), and transaction sequence number (a cyclic counter incremented for each service request) 🌸
- Service ID, which specifies the service to be invoked. It can be click-to-dial-back, click-to-fax, click-to-fax-back or voice-access-to-content 📞
- Content Provider ID, which uniquely represents the content provider. This is the key to accessing the content provider's service logic and data on the SN 👑
- Content Provider Directory Number, which is the telephone or fax number of the content provider to be called through the PSTN ☎️
- User Directory Number, which is the telephone or fax number of the user requesting the service 💖
- Billed Party, which specifies the party (either the user or content provider) to be billed 💸
also, optional parameters may be sent from the Web Server to the SN. for example, a retry parameter may be sent to specify the number of times the SN will attempt to complete a service request upon failure, before the transport connection times out 🔁
b. Data Message
this message carries the (encapsulated) user data part of a service request. for example, with click-to-fax-back, this data is the content to be faxed to the user 📠 Each message is made of the transaction ID and a data segment. the transaction ID must be the same as that of the transaction initiator part that first invoked the service 🫶
c. End of Data Message
this message contains the transaction ID and the end of data delimiter. the transaction ID is the same as that of the relevant transaction initiator message 🏁
5.1.3.2 Service Node to Web Server
the SN must respond to a service request from the Web Server 🙈 The response message consists of these information elements:
transaction ID, service type, result, time, and error code.
- Transaction ID, which is the same as that of the original service request.
- Service Type, which is the same as that of the original service request.
- Result, which is either success or failure.
- Time, which indicates the time of day the request was completed ⏰
- Error Code, which gives the reason for failure. The possible reasons are: content provider telephone (or fax) busy, content provider telephone (or fax) no answer, user telephone busy, user refusal to complete, user no answer, nuisance control limit reached, and content provider telephone (or fax) not in the SN database 💀
5.1.3.3 Usage Scenarios: Click-to-Fax and Click-to-Fax-Back
for click-to-fax and click-to-fax-back, the Lucent system only implemented the case where the data to be sent as a facsimile lives on the Web server 🖨️ At least three messages need to go from the Web server to the Service Node for these services 🌈
the first one is the Transaction Initiator, which identifies the service type and a unique Transaction ID. It also includes the sender/receiver fax number 📇
next up is one or more messages carrying the data to be faxed. Each one carries the same unique Transaction ID as above 🧾
last comes the end of message. It has the Transaction ID (again, the same as the messages before it) and the end of data delimiter 🔚
once the SN gets these messages, the Service Node (equipped with a special fax card resource) converts the data into the G3 format, calls the receiver's fax, and sends the result back to the Web server immediately ⚡ Note that a receiver fax that's busy or doesn't answer is interpreted as failure 😭 While a receiver fax answering the call is interpreted as success, that does not necessarily mean the fax will go through successfully 🙃
5.1.4 Web Server-SMS Interface and SNMP MIB
this interface is responsible for uploading the content provider profile from the Web Server to the SMS, and for managing that information against any possible corruption 🛡️ The SN verifies the Content Provider ID and the Content Provider Directory Number sent by the Web Server against the content provider profile pre-loaded from the SMS ✅
the content provider profile was based on an ASN.1 [4] structure, and SNMP [5] was used to set/get the object identifiers in the SMS database 🧩
here's an example of the simple MIB available on the SMS 🌸
inwebContProviderTable OBJECT-TYPE
SYNTAX SEQUENCE OF InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A table containing Content Provider profiles "
:= { inweb 1}
inwebContProviderEntry OBJECT-TYPE
SYNTAX InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A conceptual row of the inweb. Each row
contains profile of one Content Provider"
INDEX { inwebSmsNumber }
:= { inwebContProviderTable 1 }
InwebContProviderEntry := SEQUENCE {
inwebSmsNumber Integer32,
inwebContentProviderId Integer32,
inwebContentProviderPhoneNumber Integer32,
inwebContentProviderFaxNumber Integer32
}
inwebSmsNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" Serial number of the SMS - used for SNMP indexing "
:= { inwebContProviderEntry 1 }
inwebContentProviderId OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" A number that uniquely identifies each Content
Provider "
:= { inwebContProviderEntry 2 }
inwebContentProviderPhoneNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" Content Provider's Phone Number "
:= { inwebContProviderEntry 3 }
inwebContentProviderFaxNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" Content Provider's Fax Number "
:= { inwebContProviderEntry 4 }5.1.5 Security Considerations
okay, security time, and we are taking this seriously 🔐😤
The Lucent prototype addressed the security issues concerning the interface between the Web Server and the SN. The issues concerning the interface between the Web Server and the SMS, which was based on SNMP, were handled by the built-in security features of SNMP 🛡️
- Secure Communication Links
If the Network Operator (PSTN provider) is also the Web Service provider, the Web Server and SN/SMS will communicate over a corporate intranet. This network is almost always protected by the corporation's firewall, so it can be deemed secure. This was the case handled by the Lucent prototype 🏢
Nevertheless, if different corporations serve as the Network Operator and the Web Service Provider, then it's likely there may not be a dedicated secure communication link between the Web Server and SN/SMS. This raises serious security considerations. 🚨 One possible solution is to use Virtual Private Networks (VPN). VPN features support authentication of the calling and called parties, and encryption of the messages sent over insecure links (such as those on the Internet) 🔒
- Non-Repudiation
All transactions were logged on both the Web Server and the Service Node, to account for all operations in case of doubt or dispute 📝 The log information on the SN may also be used to generate bills 🧾
- Malicious Requests of Users
A user may make repeated requests to a content provider directory number maliciously. This scenario was handled by setting a Nuisance Control Limit (NCL) on either the SN or the Web Server, or both 🚫 The NCL has two parameters: one defining the number of requests from a user, and the other the period over which those requests take place ⏳
A user may also attempt to request a call from a directory number other than that of a content provider. This scenario was handled by verifying the directory number (and the content provider ID) against the database on the SN containing all the content provider information 🕵️ If the directory number (or the content provider ID) was not in the database, the request would be rejected 🙅♀️
5.2 Siemens Web Call Center
5.2.1 Service Description ✨
okay so bestie, the Web Call Center is an Intelligent Network System that takes requests from Internet nodes for services to be provided on the PSTN 📞💖. As the name suggests, it was built to support a cluster of services that together give you a subset of the features of a Call Center, with almost all user interactions happening through World Wide Web requests and responses 🌸. There's a background description of Call Center Features in the appendix if you want the full tea 🍵.
From an Intelligent Network perspective, a bunch of services work together to deliver those Call Center features 💅. The features as implemented supported this scenario: a customer asks to be called back by an agent at a time they pick, to talk about an item they care about 🦋. The agent gets selected based on their availability and expertise in that topic. The agent is told who they're calling and what the topic is, and then they get connected to the customer 🫶.
The individual services deployed for this also managed the list of available agents 📋. The agent could "log into" and "log out of" the system, and could indicate whether they were ready to handle calls to the customer 🎀. Here's the list of services from a user's point of view, and honestly it's giving very organized 😭.
The services support:
- i) Customer Request service 💌: The customer explores a corporate Web site and clicks a link offering to have an agent call them back. That redirects them to the Web Call Center server, which shows a form asking for their name, the telephone number they want to be called on, and the time the call should happen ⏰. The service also notes the page the customer was referred from when they were redirected. Once the form is submitted, the customer gets an acknowledgment page listing the parameters they entered 🧚.
- ii) Agent Registration/Logon 🔐: An agent requests the "login" page on the Web Call Center server. The service checks whether it has a record of an agent at the Internet node the request came from. If not, the caller gets a form to enter the service identity, the company's agent identifier, and a password. When that comes back, the service identity and company agent identifier are checked against a list of known identities. If they're found, the password is checked, and if it matches the record held by the service, a new session record is made linking this identity to the Internet node the call was made from 🔥.
NB: This is very similar to the Universal Personal Telecommunications (UPT) service feature "register for incoming calls" 💜. It implies the identified person has exclusive use of the Internet node from that point onwards, so messages for them can be directed there 👑.
- iii) Agent Ready ✅: An agent who's already logged on can say they're ready by requesting the appropriate "ready" page on the Web Call Center server 🙌. The service matches the agent using the Internet node Identifier and Agent Identity passed along with the Web request, checking them against its list of "active" agents. It then marks them as ready to handle calls in its list of available agents, along with their pre-defined skill set 🍓.
- iv) Agent Not Ready 😴: An agent can request an appropriate "ready" page on the Web Call Center server to say they're temporarily not ready to handle calls 🌙.
- v) Agent Logoff 👋: An agent can request the "Logout" page on the Web Call Center server to say they're no longer associated with a particular Internet node 💀. The service matches the agent using the Internet Node Identifier and Agent Identity passed along with the Web request, checking against its list of "active" agents. Once found, that agent's session record is removed and the caller is told so with an acknowledgment page ✨.
NB: This is very similar to the UPT "unregister" service feature 🙈.
- vi) Call Center Agent Selection and Notification 🔔: When the time the customer picked has arrived and an available agent with the right skills has been selected from the appropriate list, this service sends a notification to the Internet node associated with that agent 📣. A dedicated server is assumed to be running on the agent's machine. When it gets the notification, it triggers the agent's browser to request the "Agent Call In" page from the Web Call Center server. Once the agent's machine has made that request, the agent is told there's a customer to call 🥳.
NB: This is similar to a "Message Waiting" or "Wake Up Call" service 💅.
Note: As implemented, the agent is led automatically into the following service, because the returned Web page includes an automatic reload command 🔄.
- vii) Agent Instruction 📝: A selected agent makes a request to the "Customer Processing" page on the Web Call Center server. The Internet node Identifier and Agent Identity the agent uses are matched against a list of agents expected to handle calls, and the instructions for the calls are returned to the agent 💜.
NB: This is similar to a "Voice Mail Replay" message service, but here the message is automatically generated, and there's no associated voice mail record feature you can access 🎧.
Note: As implemented, the instructions page includes a number of buttons. They let the agent view the page the customer was looking at when they made the request, and trigger the customer callback (described next) 🫶.
- ix) Agent/Customer Telephony Callback 📞✨: The agent makes a request to the "dial-back" page on the Web Call Center server. The Internet node Identifier and Agent Identity they use are matched against a list of agents expected to handle calls. When the appropriate records have been found, the service makes the telephone call through to the customer and then connects the agent to that call, using the telephone number in the respective Call Center service record 🦋👑.
5.2.2 Implementation 🛠️
5.2.2.1 Introduction 🌈
The Siemens Web Call Center used an existing IN system and service logic that supported Call Center features 💖. The scenario it supports is very similar to the Siemens IN-based Call Center it was based on, and one of the goals was to minimize changes to the service offered 🎀. It's also virtually identical to the service "Internet Requested Telephony Dial-back" provided by the Lucent system 🍓.
As provided via the Internet, the services are mostly the same as those provided via the PSTN and IN alone 💅. The main differences are that the World Wide Web is the interface to the services instead of a telephone, SSP, and Intelligent Peripheral 🌸. Also, the feature that places a telephone call between the agent and the customer is implemented within the IN system in a different way. That's the only element where the PSTN is involved 📞.
5.2.2.2 Web Call Center Configuration 🧩
The general arrangement for the Web Call Center system is shown in Figure 7 🗺️. The components that were added to an existing IN system to handle the Internet interface are described next ✨.
In addition to the SCP, SSP and SMS that were part of the original IN-based system, another unit was included to send notification messages to agents 🔔. In the IN system, agents got "wake up" telephone calls when they were needed to handle their next customer's call back 😭. This unit is called the "Internet Intelligent Peripheral", and its use is described later under "Non-World Wide Web Interactions" 🫶.
Since there was a need to reuse as many of the existing IN components unchanged as possible, a Gateway unit was provided to deal with the interface between the Internet and the SCP 🚪. It injected INAP (Intelligent Network Application Protocol) messages into the SCP, making it think it had received an Initial DP trigger from an SSP 🤯. It also intercepted the "Connect To Resource" and "Prompt and Collect" INAP messages sent from the SCP, and acted on them to return the parameters the Internet users generated when they filled in the forms that triggered the service transaction 📋. It translated the "Play Announcement" message sent to the Intelligent Peripheral into a form that the Intelligent Peripheral could use 🔧. Finally, it passed on the INAP message the SCP used to trigger the SSP into making the telephone call back 📞💅.
5.2.2.3 User Interaction 🎀
In the IN/PSTN-based system, the services had contact with customers and agents through their telephones, SSPs, and Intelligent Peripherals. Those were programmed to play announcements to them and to capture their responses 🎙️. These responses were indicated by DTMF tones sent by pressing keys on the telephones ☎️.
In this case, almost all interactions happen through World Wide Web requests and responses 🌐. The sequence of announcements and responses for each service is "collapsed" into individual form-filling transactions, and the requests aren't limited to digits (or "star" and "hash") 🙌. The implications of using forms on service operation are covered in more detail later, under HTTP/IN Service mapping 🦋.
5.2.2.4 Service/Caller Identifiers ✨
okay so when the services come in through the IN/PSTN system, they get the Calling Line Identity (CLI) of the caller AND the number the caller dials (the DN) 📞. The CLI gets used EVERYWHERE to identify the caller and (for the agent) to index into service data tables so the system knows what to do next 💅. Web transactions get an equivalent value to the DN as the requested Universal Resource Locator (URL) 🦋, but the CLI cannot be given reliably 😭. The nearest equivalent is the IP Address of the customer's or agent's machine. BUT, HTTP proxies mean that this "original" Internet node Address may not be available. If a proxy is used, then its IP Address is the one associated with the request 🙈.
In providing these Call Center features, the customer only has ONE Web-based transaction: the initial request for a PSTN telephone callback 📱. To do that, they have to fill in a form that specifies not only the time to be called back, but also the telephone number to be reached 🎀. Those values can be used to identify the customer if needed, so the problem of originating Internet Node ambiguity is not relevant here 🫶.
With the agents, though, there are sequences of coupled transactions, and the particular sequence has to be identified 🧚. A bunch of these are running at once, so there needs to be some identifier that shows which agent is being handled in each case 🔥.
Such an identifier is NOT part of a sequence of basic Web transactions, sis 💀. In a Web transaction, the HTTP Client/Web Browser makes a request, and the HTTP Server responds, usually including some content in its reply that the browser processes. After that, it closes the TCP connection. That's the end of the transaction, and the HTTP client and server normally can't keep state information beyond this point. Any sequence just gets reduced to a set of unrelated transactions. Lowkey tragic 😭.
A result of this simple pattern is that any state information reflecting longer or more complex interactions has to be stored (at least partly) on the client system 💜. One approach is the use of cookies [6]. HTTP servers can set these as part of their response to a request, and they get sent back with all later requests for appropriate URLs as extra HTTP headers 🍓. The cookies let the HTTP server identify the client in following requests, so it can continue an extended session with them ✨.
Cookies are used in providing the Internet Call Center 🌸. Persistent cookies are installed into the Web Browser on machines that are going to be used by call center agents, as a service management (pre-service) task. The cookie value is unique to the machine and is used to index into a list of machine IP addresses that's stored as part of the service data 💖.
Also, a session cookie gets stored on the agent's machine when the agent registers, and it's cleared when they de-register 🌈. This is used to identify the agent, and so the IP address of the node the agent is associated with (and where the agent's later requests should come from). The services that interact with Call Center agents use the agent session cookie value as an identifier. In principle this isn't necessary, but it does simplify the session data lookup procedure 🧠. The rest of the services use the persistent machine identifier in place of the CLI, and index into their service data with it. Both cookies get sent with each agent request. If they're not present, the request is redirected to other services (for example, to the agent Logon service) 🚪.
5.2.2.5 Mapping from HTTP Transactions to IN-Based Service Features 🦋
all of the client-initiated services need user interaction 🗣️. In the IN/PSTN system, most of the services look like this: callers get connected to an announcement unit that plays them a list of choices and captures their selection 🎧. The caller can pre-dial the digits they need. In that case, the prompts aren't needed, so they're not made 🙅♀️.
The pattern is a bit different on the Internet side, because the initial HTTP request returns a response, and then the Web transaction is over 😤. When that first response returns a form for the caller to fill in, submitting the form starts a NEW HTTP transaction 💅. It's all still one instance of the service though. The service is made up of two request/response pairs in tandem 👑.
It IS possible to design a service that handles this pair of Web transactions as a single unit, but it may be better to reconfigure it 🤔. Designing a service that deals with two Web exchanges as one extended transaction is seriously complex 🤯. It has to maintain state across the pair of Web exchanges, and it has to handle a bunch of failure cases, including time-outs and "out of time" submission of forms 😵. The alternative is to split the service into two sub-features. The first one covers the initial request and the delivery of the form back, and the second one deals with processing the submitted form and returning any confirmation in reply 🎀.
Not all of the services need form-filling, so they can be treated as a single IN feature. There are two cases where forms ARE required 📝. The first is the Customer Request service, and the other is the "Agent Registration" service. In both cases, the initial Web transaction (where the form is requested and returned to the client) doesn't need any specific service logic processing. The initial delivery of the form to a customer or agent can be handled by a "normal" Web Server 🌷. In both cases, the service logic only gets triggered when the form is submitted. So, again, each of these services can be treated as a single IN feature 🫶.
The IN service logic that deals with these requests has a general pattern of action 🧩. An HTTP request comes in, and that triggers the IN service logic into action. The service logic "sees" this as an Initial DP message and starts processing as if it had been sent from an SSF 🧚♀️. The SCF uses what looks to it like an Intelligent Peripheral to collect the parameters of the request, and then sends back final announcements to the requesting entity 📢.
The main difference, from the point of view of the IN service logic running on the SCF, is that the service doesn't need to tell the SSF to make a temporary connection to the Intelligent Peripheral. It's as if that connection has already been made 🔌. Similarly, there's no need to close the service transaction by sending an explicit Continue Execution message to the SSF 🚫.
The sequence of "prompt/collect" instructions used to collect service parameters from a caller in an IN service maps pretty well to a sequence of requests that pull a data value out of the HTTP request, based on a tag 🏷️. This is a fairly standard feature of Web Server CGI or Servlet processing. Using this mapping minimizes the changes to the service design, since the service logic "sees" an Intelligent Peripheral that it sends normal Request Report Prompt & Collect messages to, and that it receives data values back from 💞.
ALL services have to fit in with the underlying HTTP interaction pattern, so they're expected to send a final Announce instruction to the Intelligent Peripheral at the end of the service 🎬. This is done in many IN services anyway, and in ALL of the service features described here. These announcements form the content returned to the Web Client 💌.
5.2.2.6 Non-World Wide Web Interactions 🕸️
there are TWO exceptions to the sole use of the World Wide Web for interaction 😳. The first one happens in the "Message Waiting"/"Wake Up Call" service, where the selected agent gets informed of a callback request ⏰. World Wide Web transactions are very simple: the client browser requests content associated with a particular HTTP URL, and the server sends back a response, which marks the end of the transaction. The server can't spontaneously associate with a client. It has to be initiated by a client request 🙅♀️.
It would be possible for the server to delay closing an earlier transaction (by not sending back all of the content specified and leaving the TCP connection open). But it was decided that an alternative scheme would be more convenient 💭. The "wake up call" was arranged by an "Internet Intelligent Peripheral" sending a request to a daemon process running on the selected agent's machine, using the Finger protocol [7]. The daemon sent back a standard response, but ALSO, the Web Browser on the agent's machine got triggered into making a further HTTP request to the server 🔔. That way, the "Agent Instruction" transaction starts automatically, while still using a normal HTTP request/response pattern 🎉.
The second exception is in the final "Agent/Customer Telephony Callback" service 📞. This transaction is started when the agent selects a link on the "call instructions page" that was returned to them, and it includes a "confirmation" page being sent back to them in an HTTP response. But the actual purpose of this service is to make a telephone connection over the PSTN between the agent's telephone and the customer's telephone 💕. It's the only service element that involves the PSTN directly. From the IN/PSTN perspective, the resulting telephone connection is different from the one in the scheme that uses the IN and PSTN alone. Here, a PSTN call is made out to the agent's telephone, another call is made out to the customer's telephone, and the two calls get bridged 🌉. That's different from the earlier scheme, where the agent originated a call to the voice mail replay system, and that call was redirected to a new destination (the customer's telephone). Since this feature differs in purpose from the other services, and needs a different implementation within the IN and PSTN system, it was organized as a separate service 🧁.
5.2.2.7 Security Considerations 🔐
okay this part is SERIOUS, bestie 😭🔐 read it carefully!
In this system, the assumption was made that the interface presented to requesting agents and customers was provided via a fire wall, to deal with most attacks on the IN components 🧱. The interface appeared as a Web Server, and there was NO direct access to the HTTP documents served, or to the servlets providing the service logic 🙅♀️.
The Callback service was considered to have simpler security requirements than other IN services, because it was akin to a free phone "1-800" service access number 📠. The agents work for the service subscriber and aren't charged directly. Similarly, the requesting customer isn't charged for their request, or for the resulting call back 💸. Service subscribers would be willing to pay the costs of the telephone calls generated by this cluster of services, and the costs of running the agent services could be charged directly to them. So, the authorization for service is defined by the contract between the service subscriber and the service provider 📜.
Authentication of agents was seen as a problem 💀. As an interim measure, cookies were used. But this scheme delivers the cookie data as a plain text item (a header of the Web request) 👀. Secure Socket Layer connections were REQUIRED for communication with the agent services, and this had an impact on the performance of the IN system 🐢.
5.2.3. Derived Requirements/Lessons ✨
okay so security is literally the first thing everyone talks about 🔒 A firewall was used to control access to the IN Components, and SSL was used for talking to the Agents so the cookie values they were sending with their requests stayed protected 🍪 no cap, that's giving main character energy for security.
For other services, the entity that the requests seem to come from is probably going to get charged for the service 💸 So authentication and authorization of service provision at the time of the request is a whole thing. The service needs to be authorized in a way that makes non-repudiation ensured 🫶 That probably means the person making the request provides a certificate of identity, and that certificate gets tied to a financial account they have with the service provider. The certificate can then be stored as part of the billing record 🧾 Electronic commerce is out of scope for this work, ngl, but the way a request for confirmation of identity gets passed out to the requesting user and delivered back to the service logic still has to be considered 👀
When you go from a "pure" IN/PSTN system to one that supports requests over the Internet, the way clients interact with the services is so different that the service logic had to be redesigned 🎀 It was realized that keeping track of a service's state while it's processing was going to be a problem 😭 but this got side-stepped by re-engineering the services as form processors, so they could handle fully specified requests as a single (Web) transaction ✨ Also, a "normal" Web Server was used to deliver the forms to the users. This is a big change from the IN system, where the equivalent of the form (the prompts) got sent in sequence as part of the same service process 💅
The Call Center features suited this change perfectly 💖 But it may not be the same for other IN services. It's pretty common for services to be designed so the user gets prompted for a response, and the service keeps going depending on that response 🙈 The Web form shows all of the options at once, so this kind of variant prompt/collect sequence is not possible. Honestly, it's hard to see how an IN service could be reused without some amount of modification 🥺
An intermediate "gateway" system was provided to "cocoon" the service logic as far away as possible from the details of the components it was working with 🦋 When needed, this unit translated calls from the service logic into commands that worked with the Internet (and the Web Server that acted as the interface). Our experience was that an SCP could be "spoofed" into thinking it was operating with other IN components in the normal way 🧚 Within the limits of the service used, this turned out to be simpler than originally expected, which is iconic 👑
Choosing this simple approach still lets a considerable range of services be provided while keeping any investment in existing IN systems 🌸 Modifying existing IN service logic was also easier than feared. All of the services examined provided announcements at the end of the service transaction, and that could be used to trigger a Web response being sent back to the requesting Internet user ⭐ The changes to the Call Center service logic ended up being minor. It took as long to analyze the service and see how it could be arranged as a sequence of "form processing" transactions as it did to make the changes to the service logic 🙌
In the Siemens Web Call Center, the "Internet Intelligent Peripheral" that the service logic talked to was running as a separate program on the same node 🖥️ Where more complex behavior is needed from it (like converting text to speech data and interfacing with the PSTN), it would almost certainly be on a separate node 🌈 If data gets transferred from the Internet in a scheme like this, any intermediate gateway would be involved in relaying the data to that node 🫧
6. Alternative Solutions 🦋
6.1. The AT&T System 💜
AT&T developed a framework for controlling voice and voice-band data (e.g., fax) and for providing PINT services 📞 The key to the framework is CallBroker, a logical entity that acts on behalf of a user to set up sessions and make requests for PSTN resources. The sessions typically include initiating calls between two or more end points the user specified 🎀 Besides its interactions with the PSTN for call setup, the CallBroker is responsible for other functions when necessary, like authentication and usage recording 🔐
This section briefly discusses the protocol at the two interfaces that need to be defined, plus the matching APIs that provide the services above ✨ The two interfaces are (1) the one between the CallBroker (or Web Server) and the Service Control Function in the Service Node in the PSTN, and (2) the one between the IP client and the CallBroker. The second one is the big deal, because it lets service providers extend this architecture into a platform for other advanced/value-added services (to be identified later) 🚀 The view taken here is that the IP client is more general, and implements a protocol for talking to the CallBroker that allows full two-way communication 💬 That's needed when a called party hangs up and the IP Client has to be told about that status/progress. It's also needed when conferencing, to show which parties are joining the call 🙋♀️
6.1.1. High Level Architecture 🏗️
A high level architecture showing the various logical entities and the Interfaces among these logical Entities and the IP Client is in Figure 12 👇
________________
/
1 _____ / 2 _____
/|________________| |________| | PSTN
|____| \ |____|
Call \ / SCF\
Broker \ / SN \
\_____________
/ \
/ \
/ \
__ __
/\ /\
Calling Participant
Party (Called Party)
Figure 12: The CallBroker ArchitectureThe CallBroker does more than start and control calls for the user 🧠 It also authenticates the IP Client, does usage recording, and manages the session for the IP Client for the telephony call. The idea of a session means a client state machine has to be kept in the CallBroker 🔁 This also helps notify the IP Client about the status/progress of the requests it generated.
From the IP Client's point of view, the logical entities needed for the above functions live inside the CallBroker and look like Figure 13 below 👀 These match the functions we already talked about: Usage Recording Function, Session Management Function, Voice Bridge, and the Authentication Function. The fact that some of these functions may be physically separate from the CallBroker (like the Voice Bridge being in the PSTN) doesn't clash with the general view taken here 🫶 So the CallBroker Model mediates requests for network services and lets us define various value added services in the future 🌟
llllllllllllllll
l l
l Call Broker l Authentication
l Server l Function
l ______ l Interface 2a ______
l | |x x xlx x x x x x x x x | |
l |______|x l |____|
l x x l
l x xl Interface 2b
lSession State lx
l Mnmgt. x l x Usage Recording
l Function l x Function
l _______ x l x ______
l | | l x x x | |
l |_____| xl |____|
llllllllllllllll
x
x Interface 2c
x
_______
| |
|_____|
Bridge
Figure 13: Functional Entities in the Call BrokerVarious interfaces (i.e., 2a, 2b, 2c in Figure 13) between different functional entities in the CallBroker may also be standardized 🧩 The Session State Management Function may be physically realized as part of the CallBroker Server 🖲️
6.1.2. IP Client to CallBroker Interface 📡
Communication on the IP Client to CallBroker Interface (Interface 1 in Figure 12) is a simple ASCII based protocol running directly on TCP 🔤 The messages on this interface are mostly requests from the client to the CallBroker, responses from the CallBroker to the IP client answering those requests, and unsolicited events from the CallBroker to the IP client. Since the communication isn't strictly transaction oriented, traditional encapsulation protocols like HTTP can't be used 🙅♀️ There's been some ongoing work trying to use multiple concurrent HTTP POST requests to support event delivery, but without too much difficulty, the ASCII protocol specified here can easily be mapped to the POST payload of HTTP 💌
6.1.3. Protocol 🎀
Basic Format
The basic format of the protocol looks like this 👇
[header]<<LF>
<<LF>
[body]<<LF>
<<LF>
<<LF>The header and body of the protocol are separated by 2 line feed characters 💫 The format of the header and the body is described below. Line feed characters in the header or body get escaped using simple URL encoding 🍓
Header
[session-id | 0]<<LF>
[message-id]<<LF>
[version-info]<<LF>All CallBroker transactions are identified by sessions 🪪 A session doesn't have to match one-to-one with a TCP session. If the IP client is trying to start a new session with the CallBroker, the session-id field gets filled with '0' to signal a session creation request 🌱 Every session request needs to come with enough authentication information for the CallBroker to create the session 🔑
Message-id represents the operation of the message 🎯
Version-info contains optional version information for the protocol. This helps with possible version mismatch detection and graceful error recovery 🛟
Body
The body of the protocol messages is made up of name value pairs 📝 These name-value pairs are interpreted with reference to the message-id, which signifies the operation the CallBroker has to perform 🥰
6.1.4. APIs Exposed to the IP Client 🌷
The APIs of the CallBroker exposed to the IP client are distinct and different from the APIs the CallBroker uses from the different supporting subsystems, including the authentication subsystem and the usage recording subsystem 🙌 The IP client APIs let clients effectively control voice conferencing 🎙️✨
6.1.5 Voice-Bridge Control API
okay so the Voice Bridge Control API is what CallBroker applications use to get at the voice bridging stuff 🎀 and there are two things to keep straight: sessions and calls 💅. Calls are the actual voice calls going to or from the voice bridge. Calls can get grouped together into sessions, and every call in a session gets bridged with the others 🦋. But calls also mean something outside of sessions, and a single call can belong to multiple sessions at once, each with a different weight ✨. This is what makes stuff like whispering in a conference call possible 🤫. Calls can also get dropped out of a conference session and bridged together in a brand new session, which gives you a sub-conference 🌸. And the best part: those calls can later get re-added to the main conference session. iconic, honestly 👑
6.2 Simple Computer Telephony Protocol
6.2.1 Overview
okay bestie, the Simple Computer Telephony Protocol (SCTP) is a third party call control protocol 💀, which means it does NOT fit the PINT charter. Nobody's kicking it out though 🫶. It's in here so we can see how PINT services could be built on top of SCTP, and where SCTP slots into the PINT architecture 🧩.
SCTP does more than third party call control ✨. It also handles subscriber (aka user) feature management, like letting someone set do not disturb or call forwarding parameters 📞. And it can monitor the status of a subscriber's terminal, line, and address 👀. It's strictly client/server, no peer to peer drama 🙅♀️. It runs as a TCP application protocol, it's ASCII-based, and it uses sockets 🔌. The SCTP Server is usually hooked up to a switch through a CTI (Computer-Telephony Integration) connection. Because of that, feature interactions only happen within a single call, not between PSTN services 🍓. The SCTP Server inside a PINT Gateway could also connect to an SN or an SCP. Check the figures below 🎀. And again, SCTP does NOT carry media 🙈.
6.2.2 How SCTP Fits in with the Reference PINT Services
SCTP Client as Part of a Web Server
+------+ +--------+ +--------+ +------+
| | | | SCTP | | | |
| |----| |-------| |----| |
| | | | | | | |
+------+ +--------+ +--------+ +------+
User's PC Web Server/ PINT Gateway SN/SCP/Switch
CGI
Figure 14: SCTP Client as Part of a Web Serverso in this setup, the SCTP Client lives inside the Web Server 🏠. Its whole job is starting calls to the PSTN whenever a user asks for it 📲. The SCTP Server sits in the PINT Gateway 💖. Okay, now let's run through the classic PINT examples, they're so good 😭:
Click-to-dial-back: the SCTP Client sends an SCTP MakeCall to the SCTP Server. The calling number comes from the Web page, and the called number comes from the user 📞.
Click-to-fax-back: the SCTP Client sends an SCTP MakeCall to the SCTP Server with the called number set to the user's fax machine, and the calling number set to the Web Server's fax machine 📠. The treatment is set to the URI for the file that needs faxing. The SCTP Server grabs the file and feeds it into the call just like a fax machine would 🖨️.
Click-to-fax: the SCTP Client sends an SCTP MakeCall with the calling number set to the user's fax machine, and the called number set to the Web Server's fax machine 💜. How the file gets to the user's fax machine is outside the scope of SCTP, so that's not on us 🤷♀️.
Voice-access-to-content: the SCTP Client sends an SCTP MakeCall with the called number set to the user's telephone number, and the calling number set to the Web Server 🎧. The treatment is a URI for the file of the particular Web page to be read out to the called number. The SCTP Server handles the file to voice conversion, and that gets fed into the call as if it were voice 🗣️.
In all of these cases, the SCTP Client can generate a bunch of different Web pages to send to the Web Server through CGI (Common Gateway Interface) 🌈. What goes on those pages depends on the call completion status of the CallMake SCTP action ✨.
SCTP Client Running on the User's PC
+------+
HTML | | INTERNET
+-----+ /--------------| |
| |---/ +------+
| | Web Server
| |---\
+-----+ \
User's PC \ SCTP +------+ +------+
\------------| |-------| | PSTN
| | | |
+------+ +------+
PINT Gateway SN/SCP/Switch
Figure 15: SCTP Client Running on the User's PCin this one, the user has an SCTP Client sitting right on their own PC 💻. If they're using their telephone line to connect to a Web Server and a call comes in, the SCTP Server in the PINT Gateway posts that event to the SCTP Client 🔔. A window pops up on their screen with options for handling the incoming call 🪟. They can take the call, send it to voice mail, or send it to another number 📱. It's giving personal assistant energy 🧚.
For the Fax back service, for example, if the user has a separate fax machine from their PC, the SCTP Server would tell the SCTP Client there's an incoming fax 📠. The user would then end or suspend their Internet connection so the fax can come through, and once that's done they can resume the Internet connection 🔁. Literally a whole choreography 💃
7. Session Initiation Protocol--An Emerging Standard
7.1 Overview
SIP, the Session Initiation Protocol, is a simple signaling protocol for Internet conferencing and telephony 📞. It's still being developed within the IETF MMUSIC (Multiparty Multimedia Session Control) Working Group 🌸.
SIP gives you the mechanisms to support these services ✨:
- call forwarding, including the equivalent of 700-, 800- and 900-type calls;
- call-forwarding no answer;
- call-forwarding busy;
- call-forwarding unconditional;
- other address-translation services;
- callee and calling "numbers" delivery, where the numbers can be of any (preferably unique) naming scheme;
- personal mobility, i.e., the ability to reach a called party under a single, location-independent address, even when the user changes terminals;
- terminal-type negotiation and selection: a caller can be given a choice of how to reach a party, e.g., via Internet telephony, mobile, phone, and an answering service;
- caller and callee authentication;
- blind and supervised call transfer;
- user location; and
- invitation to multicast conferences.
Extensions of SIP exist that let you do third-party signaling 🦋. That covers click-to-dial-back services, fully meshed conferences, and connections to Multipoint Control Units (MCUs), plus mixed modes and the transition between them 🌈.
SIP addresses (URLs) can be embedded in Web pages 🕸️. SIP is addressing-neutral, meaning addresses are expressed as URLs of various types, like SIP, H.323, or telephone (E.164) 💅. A purely representational example of a SIP URL might be sip:+12125551212@foo.example.com, where foo.example.com is the host serving as a gateway into the PSTN 🚪.
SIP is independent of the packet layer and only requires an unreliable datagram service, because it brings its own reliability mechanism 💪. While SIP usually runs over UDP or TCP, it could, without technical changes, run over IPX, or carrier pigeons, ATM AAL5 or X.25, in rough order of desirability 🕊️😂.
SIP can set up calls "out-of-band" 🎟️. For example, the SIP protocol exchanges use IP plus UDP or TCP, but the actual data transport can happen over the PSTN. That makes it possible to use SIP to control a PBX or send requests to a Service Control Point, and the PINT services make use of this flexibility 🧠.
7.2 SIP Protocol
SIP is a textual client-server protocol, similar in syntax to HTTP and RTSP 📝. Requests consist of a method (INVITE, BYE, ACK, or REGISTER), a list of parameter-value pairs describing the request, and an optional request body 🎀. Parameters include the origin and destination of the call and a unique call identifier. They may also indicate the caller's organization, along with the call's subject and priority 💼. The request body contains a description of the call to be established or the conference to be joined. SIP doesn't prescribe the description format; SDP is one possibility being standardized within the IETF 🌟. For the purposes of PINT services, an additional phone number address format is to be added to SDP 📞.
Responses tell you whether a request is still being processed, was successful, can possibly be satisfied by another node, or failed 🚦. When a call is redirected, the response indicates the name of the node to be tried. Unsuccessful calls may also return a better time to try again ⏰.
In a typical successful call, the caller sends an INVITE request to the callee 💌. The callee accepts the call by returning a response code to the callee, which then confirms receipt of that acceptance with an ACK request 🤝. Either side can end the call by sending a BYE request 👋.
Requests can be authenticated using standard HTTP password and challenge-response mechanisms 🔐. Requests and responses may also be signed and encrypted 🔒.
7.3 SIP entities
SIP distinguishes three kinds of entities 👑:
User agents receive and initiate calls, and may forward the call 📲.
A proxy server is an intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients 🎭. Requests are serviced internally or passed on, possibly after translation, to other servers. A proxy must interpret, and if necessary rewrite, a request message before forwarding it ✍️. A proxy server may, for example, locate a user and then attempt one or more possible network addresses 🔍.
A redirect server accepts a SIP request, maps the address into zero or more new addresses, and returns these addresses to the client 🗺️. Unlike a proxy server, it does not initiate its own SIP request. Unlike a user agent server, it does not accept calls 🙅♀️.
Proxy and redirect servers may make use of location servers that determine the current likely location of the callee 📍.
A PSTN gateway initiates phone calls between two parties 📞. This may be a server that sends requests to an SCP in an IN environment, or it may be a CTI-controlled PBX 🏢.
A SIP call may traverse one or more proxy servers 🌐.
The servers that control a PBX or an SCP act as user agents 🎛️. And a Web server may also act as a SIP user agent 🕸️✨.
7.4 Providing Call Control Functionality 💅
Okay so, the SIP for PINT spec explains how to use SIP to start phone calls between two PSTN end points 📞. (SIP can also set up calls between Internet end points, and between an Internet and a PSTN end point, but that's beyond the scope of this doc, so we're not going there today 🫖.)
The SIP client that starts these calls can be at the user's location (their workstation), or it can be a Web server that calls up a SIP client through a CGI program 🌐. There's no difference in operation or functionality between the two, except that the owner of the Web server might be legally responsible for the calls made 😬.
A SIP client needs to convey two addresses to the PSTN gateway: the party making the call and the party being called 📱. (The party to be billed also needs to be identified. This can be done with a SIP header, or by having the server look up the right party based on the two parties. This aspect is for further study 🔮.)
Here are three ways these addresses can be conveyed in SIP ✨. In the examples, the address of party A is +1-212-555-1234 and the address of party B is +1-415-555-1200. (The URL types in this and other examples are representational. They may but do not have to exist 🌸.)
(1) The two PSTN addresses are contained in the To header (and request-URI) and an Also header. For example:
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
Also: phone:+1-415-555-1200
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0In that case, the gateway connects to party A first and then party B 📲. It doesn't wait for A to accept the call before calling B 🙈.
(2) Parties A and B are indicated by separate invitations 🎀. This lets the gateway make sure party A is actually available before it calls party B 💖. After calling party A, the gateway could play an announcement saying the call is being connected, using, for example, RTSP with an appropriate Conference header indicating the call 🎶.
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...
INVITE sip:+1-415-555-1200@pbx.example.com SIP/2.0
To: phone:+1-415-555-1200
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...(3) The two PSTN addresses are conveyed in the To header of the SIP request, and the address in the SDP media description 🧚. So a request might look like this:
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0Here, pbx.example.com is the name of the PSTN gateway, and the call will be established between 1-212-555-1234 and +1-415-555-1200 🍓.
Users can be added to an existing call by method (1) or (2) 🫶.
8. Overall Security Considerations 🔒
Okay, this part is serious, bestie 😭. Inter-networking the Internet and the PSTN necessitates new interfaces, like the A, B and E interfaces in Figure 6. To make sure their use doesn't put the networks, especially the PSTN, at any extra security risk, these interfaces need to be designed with proper security considerations 🛡️. Sections 5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations, the Lucent and Siemens systems, handle the security aspect, respectively 👑.
Worth noting are the security requirements suggested by pre-PINT experiences. They are:
- Peer entity authentication, to allow a communicating entity to prove its identity to another in the network (e.g., the requesting IP-host to the PINT gateway, and the PINT gateway to the PSTN node providing the service control function) 🪪.
- Authorization and access control, to verify whether a network entity (e.g., the requesting IP-host) is allowed to use a network resource (e.g., requesting services from the PINT gateway) 🚪.
- Non-repudiation, to account for all operations in case of doubt or dispute 🧾.
- Confidentiality, to avoid disclosure of information (e.g., the end user profile information and data) without the permission of its owner 🤫.
In the course of PINT interface development, additional requirements are likely to arise. It is imperative that the resulting interfaces include specific means to meet all the security requirements 🚨.
Bestie, this is the part that matters most. Every one of these needs real, specific mechanisms, not vibes 💀.
9. Conclusion 🎉
This document has provided the information relevant to developing inter-networking interfaces between the PSTN and the Internet, to support PINT services 🌈. Specifically, it covered technologies, architectures, and several existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services ✨. The key takeaway is that the pre-PINT implementations were developed independently, so they do not inter-operate 🥲. It's the job of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of future PINT service implementations 🦋.
10. Acknowledgments 🙏
The authors would like to acknowledge Scott Bradner, Igor Faynberg, Dave Oran, Scott Petrack, and Allyn Romanow for their insightful comments in the PINT Working Group discussions that led to the creation of this document 💜.
11. Appendix 📚
11.1 PSTN/IN 101 ☎️
11.1.1 Public Switched Telephone Network 🏢
What is normally considered "the Telephone Network" is actually a set of interconnected networks 🕸️. Potentially, each of these networks could be owned by a different Network Operator. The official name for such a network is Public Switched Telecommunications Network (PSTN). A simple PSTN consists of a set of Switches (called Central Offices or Telephone Exchanges) with links interconnecting them to make up the network, along with a set of access connections by which terminals are attached. The PSTN is used to deliver calls between terminals connected to itself or to other PSTNs it is interconnected with. Calls on the PSTN are circuit switched, which means a bi-directional connection is made between the calling and called terminals for the duration of the call 📼. In PSTNs the connection is usually carried through the network in digital format, occupying a fixed bandwidth, usually 56 or 64 Kbps. The overall configuration of the PSTN is shown in Figure 16 🗺️.
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
Figure 16Messages are sent between the Switches to make and dissolve connections through the network on demand, and to indicate the status of terminals involved in a call 📨. These "signaling" messages are carried over a separate (resilient) data network dedicated to this purpose. This signaling network is also known as the Common Channel Signaling (CCS) or Signaling System Number 7 (or SS7) network, after the names of the signaling protocol suite used 📡.
As yet, the majority of access connections to a PSTN carry analogue signals, with simple (analogue) telephones or Facsimile machines as terminals 📠. Call requests are indicated to the Central Office a telephone is connected to, either by a sequence of pulses or tone pairs being sent. Notifications about the status of the request are sent back to the telephone in the form of tones 🔔. A Central Office indicates that a call is being offered to a telephone by sending an alternating voltage down the access connection, which makes the ringer in the telephone sound 🛎️. These access lines have a unique address associated with them and can support a single call 🎯.
However, with analogue or digital multi-line connections, or Integrated Service Digital Network (ISDN) Basic or Primary Rate Interfaces (BRI or PRI), several concurrent calls are possible and a set of addresses are associated with them 🧩. The new ISDN access connections are designed so that data exchanged with the network is in multiplexed digital form. There's an individual channel for each of the potential connections, plus a separate channel dedicated to sending and receiving call request and call alert data, as well as carrying packet switched user data 🪄. These call request and call alert messages act as the equivalent of the pulses or tones sent when dialing, and the ringing signal sent to a telephone when a call is being made to it 🔊.
The operation of the call request is fairly simple in most cases, and is shown in Figure 17 🧠.
/--\
() ()
--____
/++\ \ ................................. /--\
/----\ \ ^ v ! () ()
A \ [-!-] [-!-] ! --
\->[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B
[---]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
CO Central Office (Telephone Exchange)
Figure 17The user presses a sequence of numbers on a telephone handset (labeled A), and the telephone passes a sequence of digits (either as pulses or tone pairs) to the Central Office via the access line 📞. The Central Office contains a processor that is notified that the user has made a request, along with the digit string that is the sole parameter of the request 🔢. This digit string is taken to be the unique address of an access line connected either to that Central Office or to another one. There is a hierarchical addressing scheme, so the digit string can be parsed easily 🪜. A call request to a terminal (labeled B) connected to a remote Central Office can be routed by examining the digit string passed. The Central Office extracts the part of the passed address that corresponds to the remote Central Office in question, and can route the request onward, forming an inter-Switch call request and passing it via the signaling network 🚀. At the same time, it allocates one of its available transmission channels towards the remote Central Office 💫.
11.1.2 Intelligent Network ✨
okay so this scheme has been around since the 1950s 🕰️ and honestly it handles the majority of calls just fine 💅 but there's a whole range of extra services that can be (and have been) layered on top of that basic call processing 🎀 the big ones are Freephone and Premium Rate services (aka the 1-800 and 1-900 numbers) 📞 the vibe is that the cost changes, so the caller doesn't pay for a freephone call, or pays extra for a premium rate call 💸 they also share a thing: the number you dial has to be translated to find the "real" address of the destination terminal 🔁 that's why they're called number translation services, and they make up the bulk of all the supplementary services delivered today 👑
these were originally programmed into each Central Office 🏢 but maintaining the data tables on every single processor got super cumbersome 😩 so a more general solution was sought 🔍 after a considerable gestation period, the answer was the Intelligent Network 🧠 it takes the separation of Central Offices and the network links that connect them one step further ✨
the Central Offices are considered to provide the Call Control Function (CCF) 🎛️ on top of that, the Service Switching Function (SSF) "enhances" these Switches by spotting when a particular request has been made (like dialing 1-800) 👀 when that pattern shows up, the SSF equipment sends a specialized request message over the signaling network to a separate computer that implements the Service Control Function (SCF) 📨 the SCF is responsible for querying service specific data (held in a unit providing the Service Data Function, or SDF), performing any digit translations that are needed, and sending the details of how to proceed back to the SSF 🧩 the SSF then obeys those instructions and puts the call through to the "real" destination 📲 in lots of implementations the SDF is closely coupled to the SCF 🫶 this configuration is shown in Figure 18 🖼️
[---] [---] [---]
/--\ [SRF] [SCF] [SDF]
()/\()__ [|-!] [-!-] [-!-]
/__\ \ || \.............!......!........
\ || / ! ! /--\
__ \ [|-!] [-!-] ! ()/\()
\ \ \__[SSF] [CCF] ! ___/__\
[Fax]________[CCF]=========[---]==\\ [!--] / __
\\========[CCF]__/ \ \
[---]_______[Fax]
Key: ___ access relationship
=== trunk relationship
... signaling relationship
Figure 18the advantage here is that you can have a much smaller number of physical units dedicated to the SCF 🙌 and since they're connected to the signaling network, they can be contacted by, and can send instructions back to, all of the units providing the SSF (and therefore the CCF) 🦋
another upgrade is a separate entity called the Special Resource Function (SRF) 🌈 equipment implementing this function includes announcement units that play recorded messages (like prompts to enter digits) to callers 🎙️ it also includes the tone decoders needed to capture any digits the caller presses in response to those prompts 🔢 the SRF is usually connected to the rest of the PSTN via trunk data links 🔗 and it also has a signaling connection (directly or indirectly) back to the SCF, through the PSTN's core signaling network 📡
here's how these functional entities work together 🧚 the SCF can ask an SSF handling a call to route the caller temporarily through to an SRF 🛤️ following instructions sent from the SCF over the signaling network, the SRF plays announcements and collects the digits the user presses on their terminal in response to prompts 🎹 once those digits are collected, they can be passed on to the SCF in a signaling message for further processing 💌 in normal operation, the SCF then asks the SSF to dissolve the temporary connection between the user's terminal and the SRF 🧹 this is how collecting account numbers or passwords (or PINs) works, and it's the heart of many "Calling Card" services 💳✨
this pattern of user interaction is also used in a wide variety of other services that need extra account information and PINs 🔐 the info is collected just like we described, and can be checked against the correct values stored in the service database before the call is allowed to proceed ✅
the Intelligent Network functional entities can be realized as physical units in a number of different combinations 🧩 a common configuration is shown in Figure 19 🖼️
[---] [---] [---] [---]
/--\ [I.P] [SCP] [SDP] [SN ]
()/\()__ [|-!] [-!-] [-!-] [--|]
/__\ \ || \.............!.....!..... |
\ || / ! \ | /--\
__ \ [|-!] [-!-] \ | ()/\()
\ \ \__[SSP]=========[CO ]==\\ \ | ___/__\
[Fax]________[---] [---] \\ [!-|] / __
\\=======[CO ]__/ \ \
[---]_______[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
SSP Service Switching Point - a unit that implements the
Service Switching Function
CCP Call Control Point - a unit that performs call control
functions.
This is normally a kind of Central Office (shown as CO
above)
SCP Service Control Point - a unit implementing the Service
Control Function. NOTE that this is connected to the SS7
Network and uses this connection for all of its
communications.
I.P Intelligent Peripheral - a unit that contains specialized
resources (like announcement units, tone decoders).
In effect, it implements Special Resource Functions.
SN Service Node
Figure 19this diagram also shows a unit called a Service Node, or SN 🏠 it contains components that realize all of the operational Intelligent Network functions (SSF, SCF, SDF, and SRF) 🎁 sometimes it's just more convenient to have all of these elements in one node (for operations and maintenance reasons, for example), especially within smaller PSTNs or where there's a relatively low level of requests for particular services 🥰 another difference is that, since they're all co-located, proprietary protocols can be used for internal communication, instead of the full Intelligent Network Application Part (INAP) protocol that's used over the core signaling network between discrete units 🤫 it also differs from the "unbundled" approach in that it's connected to the COs within a PSTN as a peripheral, having only an access connection to a Central Office; there is no connection to the core signaling network 🙅♀️ other than that, it operates in a similar way and can provide the same kinds of services 💖
if you want the full specification of the Intelligent Network, check out the ITU recommendations [1] 📚 and for the system, its history, how it operates, and the philosophy behind it, two books ([2] and [3]) cover it all 🍓
11.2 Call Center Features 📞✨
okay bestie, so a Call Center is a system that lets a company organize a group of similar people (called agents) who can either make calls to customers or take calls from them 💁♀️ The system spreads incoming calls out to the agents based on who is available, and it automates outgoing calls too. It picks an agent for the call and only routes the call to them once the call request has been made of the PSTN 🎀
The incoming call distribution feature ("automatic call distribution", or ACD) usually comes with a call queuing scheme 🎶 Callers get temporarily connected to an announcement unit that normally plays music. Calls get handled in sequence, so once you're at the front of the queue, the ACD system picks the next available agent and puts you through to them 💖
Another feature connects an incoming caller to a unit that asks what their call is about 🧚 Then it picks the agent based on the exact area of expertise they need. To make this work, the agents get sorted by what they know (their "Skill Set") 🧠 If skill set sorting is used, then by implication there will be separate queues for each skill set 🌈 This selection scheme can be used on its own too. For example, these so-called "voice navigation systems" can pick a particular department extension number based on what the customer needs, so they can automate the job of a company telephone receptionist when it comes to routing incoming calls 💅
Where possible, the info gleaned from the customer can be passed to the selected agent, usually over a separate networked computer connection 🖥️ It's the same deal for outgoing calls: if the call is going to one customer on a list, info about that customer and the purpose of the call can go to the agent handling it 🦋 These setups are generally called "Computer Telephony Integration" or CTI systems. Strictly speaking, a CTI system can just handle routing of incoming calls and automation of outgoing calls (also known as computer integrated telephony features), without the agents having access to a network of computers 🙈 But ngl, the business case for combining the call center's telephony with agents who have customer info on their computers is seriously compelling 🔥
This is often combined even further with a company's order and service processing computer system 💼 In this case, a call is treated as part of a business transaction, and the info being exchanged gets captured as fields of a computer form 📝 A computer system like that isn't technically part of a call center, but hooking the company computer system up to the call center is super common 🫶 It lets the details of the call get stored in a centralized database, which allows for more automated order processing, for example. It also lets a call be transferred from one agent to another when needed, so the new agent already has the info captured 💜 This can be really useful if someone with a different area of expertise is needed to handle the customer's requirements 👑
Traditionally, Call Centers were used to support teams of agents working at a single site (or a small number of sites with private telephony trunks connecting them) 🏢 The site Private Automatic Branch eXchange (PABX) was integrated with a computer system to provide these features to people at that site ✨ There can also be a business case for giving these features to distributed teams of workers 🌸 Support for people working from home has been seen as especially important 🏡 Some Call Center features have been built into public telephone exchanges, or Central Offices (COs), from many manufacturers as part of their "Centrex" service offerings 🎀
There are practical limits to providing these features on COs 😭 Apart from the procedures needed to configure the features for any telephone line that's going to use them, the basic requirement that every agent must have a connection to the supporting CO can limit how useful it is 🙃 Another approach is to provide Call Center features via the Intelligent Network 🌐 The features could then be provided over a Telephone Operator's entire network, and the Call Center could be configured centrally while still letting agents be located anywhere within the telephone network 🧚 It also means the supported company can pay for the Call Center features "as they go" instead of having a high "up front" cost 🤑
12. References 📚
[1] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The
Intelligent Network Standards, their Application to Services",
McGraw-Hill, 1996.
[3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic
Technology, Standards and Evolution", Intl. Thomson Computer
Press, 1996.
[4] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December, 1987.
[5] McCloghrie, K., Editor, "Structure of Management Information for
Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1902, January 1996.
[6] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
RFC 2109, February 1997.
[7] Zimmerman, D., "The Finger User Information Protocol", RFC 1288
December 1991.Authors' Addresses 🫶
Here's where you can find the people behind this doc 💖
Steve Bellovin
AT&T Labs
Room E-215
180 Park Ave. Bldg. 103
Florham Park, NJ 07932-0000
USA
Phone: +1 973 360 8656
Fax: +1 973 360 8077
EMail: smb@research.att.comFred M. Burg
AT&T Labs
Room 1N-117
307 Middletown Lincroft Road
Lincroft, NJ 07738
USA
Phone: +1 732 576 4322
Fax: +1 732 576 4317
EMail: fburg@hogpb.att.comLawrence Conroy
Roke Manor Research Limited
IT&N-INIA Group
Roke Manor, Old Salisbury Lane,
Romsey, Hampshire SO51 0ZN
U.K.
Phone: +44 1794 833666
Fax: +44 1794 833434
EMail: lwc@roke.co.ukPaul Davidson
Nortel
P.O.Box 3511 Station "C"
Mail Stop 242
Ottawa, Ontario, Canada K1Y 4H7
Phone: +1 613 763 4234
EMail: pauldav@nortel.caA. DeSimone
Lucent Technologies
Room 6H510
600-700 Mountain Avenue
Murray Hill, NJ 07974-0636
USA
Phone: +1 908 582 2382
Fax: +1 908 582 1086
E-Mail:tds@lucent.comMurali Krishnaswamy
Bell Laboratories
Lucent Technologies
Room 2G-527a
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Phone: +1 732 949 3611
Fax: +1 732 949 3210
EMail: murali@bell-labs.comHui-Lan Lu
Bell Laboratories
Lucent Technologies
Room 4K-309
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Phone: +1 732 949 0321
Fax: +1 732 949 1196
EMail: hui-lan.lu@bell-labs.comHenning Schulzrinne
Dept. of Computer Science
Columbia University
New York, NY 10027
USA
Phone: +1 212 939 7042 (@Bell Labs: 732 949 8344)
Fax: +1 212 666 0140
EMail: schulzrinne@cs.columbia.eduKamlesh T. Tewani
AT&T Labs
Room 1K-334
101, Crawfords Corner Rd.
Holmdel, NJ 07733
USA
Phone: +1 732 949 5369
Fax: +1 732 949 8569
EMail: tewani@att.comKumar Vishwanathan
Isochrone
EMail: kumar@isochrone.comFull Copyright Statement ⚖️
Here's the legal stuff, kept exactly as written 🌈
Copyright (C) The Internet Society (1998). 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. 💜
📦 where this page comes from
- ietf: rfc2458 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms