RFC 3976
Interworking SIP and Intelligent Network (IN) Applications
RFC 3976: Interworking SIP and Intelligent Network (IN) Applications ✨
okay bestie, this one is RFC 3976 🎀 It's titled Interworking SIP and Intelligent Network (IN) Applications, and it came out from the Network Working Group in January 2005 🌸
The authors are three people: V. K. Gurbani from Lucent Technologies, Inc., F. Haerens from Alcatel Bell, and V. Rastogi from Wipro Technologies 👑 Its category is Informational, which means it's sharing info for the Internet community, not setting a standard 💅 The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🦋
Status of This Memo 📜
So this memo is just giving info to the Internet community. It is NOT a spec for any Internet standard, and it can be shared with literally anyone 🌈
Copyright Notice ©️
The Internet Society owns the copyright here, and the year is 2005 💜
IESG Note 🙈
This RFC is not up for any level of Internet Standard, ngl 💀 The IETF says it doesn't know if this RFC is fit for any purpose, and it especially isn't vouching for things like security, congestion control, or whether it plays nicely with protocols already out there, because the decision to publish wasn't based on IETF review for those things 😭 The RFC Editor picked to publish it at their own discretion. So if you're reading it, be careful about how much you trust it before you build or deploy anything. See RFC 3932 for more info 🫶
Abstract ✨
Okay so the PSTN has these cool services like 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private networks (where a private network number gets mapped into a public one). All of that is powered by the Intelligent Network (IN) 🔥 This doc is about how to get those existing IN services working from SIP endpoints, for a call that starts on an IP host and ends on a phone 📞 The call request begins on a SIP endpoint, but the services are actually run by the data and procedures that live in the PSTN/IN 🧚 To make IN services work transparently for SIP endpoints, the doc describes how to interwork SIP with the Intelligent Network Application Part (INAP) 💖
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Access to IN-Services from a SIP Entity. . . . . . . . . . . . 4
3. Additional SIN Considerations . . . . . . . . . . . . . . . . 7
3.1. The Concept of State in SIP. . . . . . . . . . . . . . . 7
3.2. Relationship between SCP and a SIN-Enabled SIP entity. . 7
3.3. SIP REGISTER and IN services . . . . . . . . . . . . . . 8
3.4. Support of Announcements and Mid-Call Signaling. . . . . 8
4. The SIN Architecture . . . . . . . . . . . . . . . . . . . . . 8
4.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IN Service Control Based on the SIN Approach . . . . . . 9
5. Mapping of the SIP State Machine to the IN State Model . . . . 10
5.1. Mapping SIP Protocol State Machine to O_BCSM . . . . . . 11
5.2. Mapping SIP Protocol State Machine to T_BCSM . . . . . . 16
6. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 251. Introduction 🦋
So the PSTN has these services: 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private networks (mapping a private network number into a public number) 💅 They're all run by the Intelligent Network. IN is an architectural concept for running network services and customer apps in real time [1] 🔥 It's by design decoupled from the call processing part of the PSTN 🫶 This doc shows how to use that decoupling to give SIP-based entities access to IN services ✨
First, the basics of IN. Figure 1 shows a simple IN architecture 🧚 Telephone switches called Service Switching Points (SSPs) connect over a packet network called Signaling System No. 7 (SS7) to Service Control Points (SCPs), which are general purpose computers 💻 At certain moments in a call, a switch can pause the call and ask an SCP how to continue ⭐ Those interruption points are standardized in the Basic Call State Model (BCSM) [1, 2]. The BCSM has two processes, one for the originating side of a call and one for the terminating side 💜
When an SCP gets a request for instructions, it can send back one simple answer, like a number translation plus criteria such as time of day or day of week 🌸 Or it can start a whole complex back-and-forth dialog with the switch 🌀 It gets even more complicated when other specialized devices need to get involved, like ones that collect digits, play recorded announcements, or do text-to-speech or speech-to-text conversion, and so on 🎀 (These devices aren't covered here.) The related protocol, along with the BCSM, is standardized by the ITU-T and is called the Intelligent Network Application Part protocol (INAP) [4] 👑 Only the protocol got standardized, not an SCP API 🙈
+-----------+
| |
| SCP |
| |
+-----------+
||
||
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
Figure 1. Simplified IN ArchitectureThe big goal is to make sure IN control of Voice over IP (VoIP) services can be easily specified and implemented by adapting the standards and software already used in today's networks 🌈 This way, services work the same whether a user connects to current or future networks, service evolution from today to tomorrow gets simpler, and implementation happens faster 🚀
Here's how the rest of this doc is laid out 🗺️ Section 2 has the architectural model of an IN-aware SIP entity. Section 3 covers some issues to think about when doing SIP/IN interworking (SIN). Section 4 talks about IN service control based on the SIN approach. The technique here focuses on the IN call models and the SIP protocol state machine, so Section 5 sets up a complete mapping between those two state machines that lets SIP endpoints access IN services 💖 Section 6 includes call flows of IN services running on SIP endpoints, and this technique readily enables those services ✨ Finally, Section 7 covers the security aspects of SIN 🔐
List of Acronyms 🔤
B2BUA Back-to-Back User Agent
BCSM Basic Call State Model
CCF Call Control Function
DP Detection Point
DTMF Dual Tone Multi-Frequency
IN Intelligent Network
INAP Intelligent Network Application Part
IP Internet Protocol
ITU-T International Telecommunications Union -
Telecommunications Standardization Sector
O_BCSM Originating Basic Call State Model
PIC Point in Call
PSTN Public Switched Telephone Network
RTP Real Time Protocol
R-URI Request URI
SCF Service Control Function
SCP Service Control Point
SIGTRAN Signal Transport Working Group in IETF
SIN SIP/IN Interworking
SIP Session Initiation Protocol
SS7 Signaling System No. 7
SSF Service Switching Function
SSP Service Switching Point
T_BCSM Terminating Basic Call State Model
UA User Agent
UAC User Agent Client
UAS User Agent Server
VoIP Voice over IP
VPN Virtual Private Network2. Access to IN-Services from a SIP Entity ✨
Okay so the whole point of this doc is to help existing IN-based apps keep working in a SIP [3] world 💖 One way to get IN services transparently from SIP, like through the same detection points (DPs) and point-in-call (PIC) that old-school switches use, is to map the SIP protocol state machine onto the IN call models [1] 🦋
From the SCP's point of view, it doesn't matter that the request came from a SIP entity instead of a call processing function on a traditional switch. Like, it's literally the same request to them 🤷♀️ So the SIP entity needs to be able to give you the same features as a traditional switch, including acting as an SSP for IN features 💅 It should also keep call state and trigger queries to IN-based services, just like traditional switches do 🫶
Now, this doc doesn't decide which SIP entity has to be the SSP. But fyi, it should be a SIP entity at (or near) the core of the network, not the SIP end points themselves 🌸 So proxy servers and Back-to-Back user agents (B2BUAs) can both be used. Generally, proxies work for IN services that happen during call setup and teardown ✨ But for IN services that need special media handling (like DTMF detection) or special call control (like putting parties on hold), you'll need B2BUAs 🔥
The fastest way to bring existing IN services into the IP world is to use the deployed IN infrastructure as much as possible 🚀 In SIP, the logical place to tap in is either the user agents or whichever proxy is physically closest to the user agent (and presumably in the same administrative domain) 💜 But SIP entities don't run an IN call model. So to access IN services transparently, the trick is to overlay the SIP entity's state machine with an IN layer 🧚 That way, call acceptance and routing still happen in the native state machine, and services get accessed through the IN layer using an IN call model. This IN-enabled SIP entity works in sync with events at the SIP transaction level and talks to the IN elements (SCP) 😭 It's shown in Figure 2:
+-------+
| SCP |
+---+---+
|
| INAP
|
+--------+
| SIN |
+........+
| SIP |
---------->| Entity |--------->
Requests | | Requests out
in +--------+ (after applying IN
services)
SIN: SIP/IN Interworking layer
Figure 2. SIP Entity Accessing IN ServicesSection 5 proposes this mapping between the IN layer and the SIP protocol state machine 💖 Basically, a SIP entity that uses this mapping becomes a SIN-enabled SIP entity 🎀
This document does not propose any extensions to SIP 🙈
Figure 3 zooms into the SIP entity from Figure 2 and gets more detailed about the IN and SIP interworking architecture 🔍 Events at the SIP layer get passed to the IN layer so services can be applied 🌈 Since IN services deal with E.164 numbers, it makes sense that a SIN-enabled SIP entity that wants to offer services on one of those numbers will check with the IN layer for further processing, which means it acts as a SIP-based SSP 👑 The IN layer goes through its BCSM states and, at the right points in the call, sends queries to the SCP for call disposition 💅 Once the call's disposition is decided, the SIP layer gets told and handles the transaction accordingly ✨
Heads up: the single SIP entity in this figure can actually stand for several physical instances in the network 🧚♀️ For example, one SIP entity could handle the terminal or access network/domain, while another handles the interface to the Switched Circuit Network (SCN) 🫶
+-------+
| SCP |
+---o---+
|
+-----+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF(IP) | | *
* |+-------------+ | *
* || CCF(IP) | | *
* |+------o------+ | *
* +-------|-------------------+ *
* | SIN-enabled *
* +-------o-------------------+ SIP *
* | SIP Layer | Entity *
* +---------------------------+ *
**********************************************
Figure 3. Functional Architecture of a SIN-Enabled SIP EntityThe following architecture entities from Figure 3 are defined in the Intelligent Network standards 📚
- Service Switching Function (SSF): IN functional entity that interacts with call control functions. 🎀
- Call Control Function (CCF): IN functional entity that refers to call and connection handling in the classical sense (i.e., that of an exchange). 💅
3. Additional SIN Considerations 🌸
When you're working between Internet Telephony and IN-PSTN networks, the big job is translating between the states made by Internet Telephony signaling and the ones used in traditional IN environments 💖 That translation needs attention to the considerations below ✨
3.1. The Concept of State in SIP 🧠
IN services happen inside the context of a call, so during call setup, call teardown, or in the middle of a call 📞 SIP entities like proxies, which may be where some of these services live, usually run in transaction-stateful (or stateless) mode 😬 In this mode, a SIP proxy that proxied the initial INVITE isn't guaranteed to get a later request, like a BYE 💀 Luckily, SIP has primitives that force proxies into call-stateful mode, namely the Record-Route header 🙌 This header makes the user agent client (UAC) and user agent server (UAS) create a "route set" made of all the intervening proxies that later requests must go through 🦋 So SIP proxies must run in call-stateful mode if they want to provide IN services on behalf of the UAs 💜
A B2BUA is another SIP element where IN services can be realized 🧚 Since a B2BUA is a true SIP UA, it keeps complete call state, which means it's totally capable of providing IN services 👑
3.2. Relationship between SCP and a SIN-Enabled SIP Entity 🫶
In the architecture model this document proposes, each SIN-enabled SIP entity is pre-configured to talk to one logical SCP server, using whatever communication mechanism fits 🔧 Different SIP servers (like ones in different administrative domains) may talk to different SCP servers, so there's no single SCP server in charge of all the SIP servers 🌈
As Figures 1 and 2 show, the IN part of the SIN-enabled SIP entity talks to the SCP 💅 This interface between the IN call handling layer and the SCP isn't specified by this document 🙈 It can be any of the following, depending on what the SCP supports: INAP over IP, INAP over SIGTRAN, or INAP over SS7 ✨
This document is only applicable when SIP-controlled Internet telephony devices need to work with PSTN devices 🚨 The SIP UAs using this interface would usually show up together with a media gateway. This document is not applicable in an all-IP network, and it's not needed when PSTN media gateways (which don't speak SIP) need to talk to SCPs 💀
3.3. SIP REGISTER and IN Services 📇
SIP REGISTER provisions a SIP Proxy or SIP Registration server 🧚♀️ The process is kinda similar to provisioning an SCP/HLR in the switched circuit network 🍓 SCPs that offer VoIP-based services can use this information directly 💖 However, this document neither endorses nor prohibits that kind of architecture. It considers it an implementation decision 🎀
3.4. Support of Announcements and Mid-Call Signaling 📢
IN services like credit-card calling usually play announcements and collect digits from the caller before a call is set up 📞 But playing announcements and collecting digits means manipulating media streams. In SIP, proxies don't have access to the media data path, so these services should run in a B2BUA 🙌
The SIP specification [3] lets endpoints be put on hold during a call, or lets media streams change, but it doesn't have any primitives to transport anything other than mid-call control information 😭 That might include DTMF digits, for example 🔢 Extensions to SIP, like the INFO method [5] or the SIP event notification extension [6], can be considered for services that need mid-call signaling 💅 Or, DTMF can be carried in RTP itself [7] 🦋
4. The SIN Architecture ✨
4.1. Definitions
okay so first, the SIP architecture has a bunch of functional elements, and they're all defined in [3]. Here's the crew:
- User agent client (UAC): The SIP functional entity that initiates a request.
- User agent server (UAS): The SIP functional entity that terminates a request by sending 0 or more provisional SIP responses and one final SIP response.
- Proxy server: An intermediary SIP entity that can act as both a UAS and a UAC. Acting as a UAS, it accepts requests from UACs, rewrites the Request-URI (R-URI), and, acting as a UAC, proxies the request to a downstream UAS. Proxies may retain significant call control state by inserting themselves in future SIP transactions beyond the initial INVITE.
- Redirect server: An intermediary SIP entity that redirects callers to alternate locations, after possibly consulting a location server to determine the exact location of the callee (as specified in the R-URI).
- Registrar: A SIP entity that accepts SIP REGISTER requests and maintains a binding from a high-level URL to the exact location for a user. This information is saved in some data-store that is also accessible to a SIP Proxy and a SIP Redirect server. A Registrar is usually co-located with a SIP Proxy or a SIP Redirect server.
- Outbound proxy: A SIP proxy located near the originator of requests. It receives all outgoing requests from a particular UAC, including those requests whose R-URIs identify a host other than the outbound proxy. The outbound proxy sends these requests, after any local processing, to the address indicated in the R-URI.
- Back-to-Back UA (B2BUA): A SIP entity that receives a request and processes it as a UAS. It also acts as a UAC and generates requests to determine how the incoming request is to be answered. A B2BUA maintains complete dialog state and must participate in all requests sent within the dialog.
4.2. IN Service Control Based on the SIN Approach
Figure 4 shows how IN service control can work with the SIN approach. ✨ On both the originating and terminating ends, a SIN-capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O SIP" entity is required for outgoing calls that require support for existing IN services. Likewise, on the callee's side (or terminating side), an equally configured entity ("T SIP") will be required to provide terminating side services. Note that the "O SIP" and "T SIP" entities correspond, respectively, to the IN O_BCSM and T_BCSM halves of the IN call model. 🧚
+---+ +---+
| S | (~~~~~~~~~~~~~) | S |
| C |<--+ ( ) +-->| C |
| P | | ( ) | | P |
+---+ | ( Switched ) | +---+
| ( Circuit ) |
V ( Network ) V
+-------+ ( ) +-------+
| SIN | +---------+ +---------+ | SIN |
+-------+----| Gateway | ... | Gateway |------+-------+
| O SIP | +---------+ +---------+ | T SIP |
+-------+ ( ) +-------+
( )
(.............)
O SIP: Originating SIP entity
T SIP: Terminating SIP entity
Figure 4. Overall SIN Architecture5. Mapping of the SIP State Machine to the IN State Model ✨
This section sets up the mapping of the SIP protocol state machine to the IN generic basic call state model (BCSM) [2], independent of any capability sets [8, 9]. 💖 The BCSM is split into two halves: an originating call model (O_BCSM) and a terminating call model (T_BCSM). There are a total of 19 PICs and 35 DPs between both the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for T_BCSM) [1]. The SSPs, SCPs, and other IN elements track a call's progress in terms of the basic call model. The basic call model provides a common context for communication about a call.
O_BCSM has 11 PICs:
O_NULL: Starting state; call does not exist yet.AUTH_ORIG_ATTEMPT: Switch detects a call setup request.COLLECT_INFO: Switch collects the dial string from the calling party.ANALYZE_INFO: Complete dial string is translated into a routing address.SELECT_ROUTE: Physical route is selected, based on the routing address.AUTH_CALL_SETUP: Switch ensures the calling party is authorized to place the call.CALL_SENT: Control of call sent to terminating side.O_ALERTING: Switch waits for the called party to answer.O_ACTIVE: Connection established; communications ensue.O_DISCONNECT: Connection torn down.O_EXCEPTION: Switch detects an exceptional condition.
T_BCSM has 8 PICS:
T_NULL: Starting state; call does not exist yet.AUTH_TERM_ATT: Switch verifies whether the call can be sent to terminating party.SELECT_FACILITY: Switch picks a terminating resource to send the call on.PRESENT_CALL: Call is being presented to the called party.T_ALERTING: Switch alerts the called party, e.g., by ringing the line.T_ACTIVE: Connection established; communications ensue.T_DISCONNECT: Connection torn down.T_EXCEPTION: Switch detects an exceptional condition.
The state machine for O_BCSM and T_BCSM is provided in [1] on pages 98 and 103, respectively. This state machine will be used for subsequent discussion when the IN call states are mapped into SIP.
The next two sections contain the mapping of the SIP protocol state machine to the IN BCSMs. Explaining all PICs and DPs in an IN call model is beyond the scope of this document. It is assumed that the reader has some familiarity with the PICs and DPs of the IN call model. More information can be found in [1]. For a quick reference, Appendix A contains a mapping of the DPs to the SIP response codes as discussed in the next two sections. 🌸
5.1. Mapping SIP Protocol State Machine to O_BCSM
The 11 PICs of O_BCSM come into play when a call request (SIP INVITE message) arrives from an upstream SIP client to an originating SIN-enabled SIP entity running the IN call model. This entity will create an O_BCSM object and initialize it in the O_NULL PIC. The next seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO, SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all be mapped to the SIP "Calling" state. 🎀
Figure 5 gives a visual map from the SIP protocol state machine to the originating half of the IN call model. Note that control of the call shuttles between the SIP protocol machine and the IN O_BCSM call model while it is being serviced. 🦋
SIP O_BCSM
| INVITE
V
+---------+ +---------------+
| Calling +=======================>+ O_NULL +<----+
+--+---/\-+ +-/\---+--------+ |
| | || +-------------+ | | |
| | ||<===+O_Exception +---------+ +--V-+ +--+-+
| | || +--/\---------+ |DP 1| |DP21|
| | || | +----+ +-----+----+------+ +--+-+
| | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 3| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 4|<-----+ Collect_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 5| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 6|<-----+ Analyze_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 7| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 8|<-----+ Select_Route +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 9| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP10|<-----+ Auth._Call_Setup+---->+
| | || +----+ +--------+--------+
+----+ | || |
| | || +--V-+
| | || |DP11|
| 1xx | || +-----+----+------+
| | ++========================+ Call_Sent |
| | +----/\----+------+
| | On 100,180,2xx process DP14 || |
| | On 3xx, process DP12 || |
| V On 486, process DP13 || |
| +--+-------+ On 5xx, 6xx and 4xx || |
| |Proceeding| (except 486) process DP21|| |
| +-+-+------+<=========================++ |
| | | |
| | | |
| | | |
| | +--200------------------+ |
| +----4xx to 6xx--------+ | |
| | | +--V-+
| On DPs 21, 2, 4, 6, 8, 10 | | |DP14|
| send 4xx-6xx final response | | +--------+----+--+
+-------+ | | | O_Alerting |
| | | +---------+------+
+--V-------+ | | |
|Completed |<------------+ | +--V-+
+--+-------+ | |DP16|
| | +------+----+----+
+--V-------+ | +-+ O_Active |
|Terminated|<---------------+ | +-------------+--+
+----------+ | |
+-----+ +--V-+
| |DP19|
+--V-+ +--------+----+
|DP17| | O_Disconnect|
+--+-+ +-------------+
|
V
To O_EXCEPTION
Legend:
| Communication between
| states in the same
V protocol
======> Communication between IN Layer and SIP Protocol
State machine to transfer call state
Figure 5. Mapping from SIP to O_BCSMThe SIP "Calling" protocol state has enough functionality to absorb the seven PICs as described below: 💅
O_NULL: This PIC is basically a fall through state to the next PIC, AUTHORIZE_ORIGINATION_ATTEMPT.
Okay so, the IN layer has to get through a bunch of little checkpoints (PICs) before a call can go anywhere, and each one can throw a detection point (DP) that hands control over to the SIP state machine. Let's go! 💖
AUTHORIZE_ORIGINATION_ATTEMPT 🔐: In this PIC, the IN layer has noticed that someone wants to make a call. Sometimes the call just can't happen, like if the user isn't allowed to call during certain hours 🙈. SIP can check the calling party using a set of policy directives that the SIP admin set up. If the caller is allowed, the IN layer moves on to the next PIC, COLLECT_INFO, through DP 3 (Origination_Attempt_Authorized). If the call can't be authorized for some reason, DP 2 (Origination_Denied) gets processed and control goes back to the SIP state machine. The SIP state machine needs to format and send a non-2xx final response (possibly 403) to the upstream entity. Rip 💀
COLLECT_INFO 📞: This PIC collects a dial string from the calling party and checks that the format is valid. If overlap dialing is being used, this PIC can trigger DP 4 (Collect_Timeout) and hand control to the SIP state machine, which will format and send a non-2xx final response (possibly a 484). If the dial string is valid, DP 5 (Collected_Info) gets processed and the IN layer moves on to the next PIC, ANALYZE_INFO. ✨
ANALYZE_INFO 🔍: This PIC turns the dial string into a routing number. A bunch of IN services happen right here, like freephone, LNP (Local Number Portability), and OCS (Originating Call Screening). The IN layer can use the R-URI of the SIP INVITE request for the analysis. If the analysis works, the IN layer moves on to the next PIC, SELECT_ROUTE. If it fails, DP 6 (Invalid_Info) gets processed and control goes back to the SIP state machine, which will generate a non-2xx final response (possibly 400, 401, 403, 404, 405, 406, 410, 414, 415, 416, 485, or 488) and send it to the upstream entity. Lowkey a lot of options 😭
SELECT_ROUTE 🛣️: In the circuit-switched network, this is where the actual physical route gets picked. The SIP version of that is figuring out the next hop SIP server. There are lots of ways to choose it. For example, if the Request URI in the incoming INVITE request is an E.164 number, the SIP entity can use a protocol like TRIP [10] to find the best gateway to send the request out onto the PSTN. If a route gets selected successfully, the IN call model moves to PIC AUTH_CALL_SETUP via DP 9 (Route_Selected). Otherwise, control goes to the SIP state machine via DP 8 (Route_Select_Failure), which will generate a non-2xx final response (possibly 488) and send it to the upstream entity. 🗺️
AUTH_CALL_SETUP 🔒: Some service features limit what kind of calls can start on a given line or trunk. This PIC is where those restrictions get checked. If there aren't any restrictions, the IN call model moves to PIC CALL_SENT via DP 11 (Origination_Authorized). If a restriction shows up that stops the call from going any further, DP 10 (Authorization_Failure) gets processed and control goes to the SIP state machine, which will generate a non-2xx final response (possibly 404, 488, or 502). Otherwise, DP 11 (Origination_Authorized) gets processed and the IN layer moves on to the next PIC, CALL_SENT. 🙌
CALL_SENT 📤: Now the request has to go to the downstream entity. The IN layer waits for a signal confirming either that the call has been shown to the called party or that the called party can't be reached for some reason. Control goes to the SIP state machine. The SIP state machine should now send the call to the next downstream server that was picked in PIC SELECT_ROUTE. The IN call model stays blocked until the SIP state machine unblocks it. 🚧
If all seven of those PICs get through successfully, the SIN-enabled SIP entity sends the SIP INVITE message to the next hop server. What happens next depends on any provisional responses and the final response the SIP protocol state machine gets. The core SIP spec doesn't guarantee that 1xx responses get delivered, so the IN layer needs some special processing to move from CALL_SENT to the next PIC, O_ALERTING. Here's that special processing for responses while the SIP state machine is in the "Proceeding" state and the IN layer is in the "CALL_SENT" state, bestie 🎀:
- A 100 response received at the SIP state machine doesn't trigger any special behavior in the IN layer. 🫧
- A 180 response received at the SIP entity enables the processing of DP 14 (O_Term_Seized), but the state doesn't move to O_ALERTING yet. Instead, the IN layer stays in the CALL_SENT PIC until a final response comes in. ⏳
- A 2xx response received at the SIP entity enables the processing of DP 14 (O_Term_Seized), and then it immediately moves to the next state, O_ALERTING (more on O_ALERTING later). 🎉
- A 3xx response received at the SIP entity enables the processing of DP 12 (Route_Failure). From here, the IN call model goes back to the SELECT_ROUTE PIC to pick a new route for the contacts in the 3xx final response (not shown in Figure 5 for brevity). 🔁
- A 486 (Busy Here) response received at the SIP entity enables the processing of DP 13 (O_Called_Party_Busy), and the resources for the call get released at the IN call model. 📵
- If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or 6xx final response, DP 21 (O_Calling_Party_Disconnect & O_Abandon) gets processed and control passes to the SIP state machine. Since no call was successfully set up, both the IN layer and the SIP state machine can release resources for the call. 💔
O_ALERTING 🔔: This PIC gets entered when a 200-class response comes in. A 200-class response to an INVITE means the call was accepted, so this PIC basically falls right through to the next PIC, O_ACTIVE, via DP 16 (O_Answer). Easy peasy 💅
O_ACTIVE 🎧: At this point the call is active 🥳. Once it's in this state, the call can only get disconnected when one of three things happens: (1) the network connection fails, (2) the called party disconnects the call, or (3) the calling party disconnects the call. If (1) happens, DP 17 (O_Connection_Failure) gets processed and call control goes to the SIP protocol state machine. Since the network failed, there's no point in trying to send a BYE request, so both the SIP protocol state machine and the IN call layer should release every resource tied to the call and reset themselves to the null state. ☠️ If (2) happens, DP 19 (O_DISCONNECT) gets processed and the call moves to the last PIC, O_DISCONNECT. Event (3) happens when the calling party deliberately ends the call. In that case, DP 21 (O_Abandon & O_Calling_Party_Disconnect) gets processed and control passes to the SIP protocol state machine. The SIP protocol state machine must send a BYE request and wait for a final response. The IN layer releases all of its resources and resets itself to the null state. 👋
O_DISCONNECT 🏁: When the SIP entity gets a BYE request, the IN layer moves to the last PIC, O_DISCONNECT, via DP 19. The SIP entity generates and sends a final response for the BYE, and both the SIP protocol state machine and the IN layer free up the call resources. The end, periodt 💜
5.2. Mapping SIP Protocol State Machine to T_BCSM 🦋
The T_BCSM object gets created when a SIP INVITE message makes its way to the terminating SIN-enabled SIP entity. That entity creates the T_BCSM object and sets it to the T_NULL PIC. 🌸
Figure 6 is a visual map from the SIP protocol state machine to the terminating half of the IN call model. It's giving diagram energy 📊✨
SIP T_BCSM
| INVITE
V
+----------+ +------------+
|Proceeding+=========================>+ T_Null +<-------+
+-+--+--/\-+ +/\----+-----+ |
| | || +-----------+ | | |
| | ||<=======+T_Exception+--------+ +--V-+ +--+-+
| | || +-/\--------+ |DP22| |DP35|
| | || | +----+ +---+----+------+ +--+-+
| | || +<---+DP23|<------+Auth._Term._Att+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP24| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP25|<------+Select_Facility+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP26| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP27|<------+ Present_Call +---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP28| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP29|<------+ T_Alerting +---->+
| | || | +----+ +-/\--+---------+ |
| | || +<--------------+ || | |
| | || | || | |
| | ++==========================|===++ | |
| | /\ +-------+ +--V-+ |
| | || | +DP30| |
| | || +-+--+ +---+----+------+ |
| | || |DP31+<-----| T_Active +---->+
| | || +----+ +-/\-----+------+
| | || || |
| | || || |
2xx | | ++==============================++ |
sent | | |
+----+ | 3xx - 6xx response +--V-+
| | sent |DP33|
| +----V-----+ +------+----+----+
| |Completed | | T_Disconnect |
| +----+-----+ +----------------+
| |
| | ACK received
| |
| +----V-----+
| |Confirmed |
| +----+-----+
| |
| |I'm still in the middle of Figure 6, so here's the rest of that diagram before the PIC walkthrough picks up.
+------>|
|
+----V-----+
|Terminated|
+----------+
Legend:
| Communication between
| states in the same
V protocol
======> Communication between IN call model and SIP
protocol state machine to transfer call state
Figure 6. Mapping from SIP to T_BCSMThe SIP "Proceeding" state is a total multitasker 💅 It can handle the first five PICs, T_Null, Authorize_Termination_Attempt, Select_Facility, Present_Call and T_Alerting, all on its own:
T_NULL: Okay, this is where it all starts 🎀 At this PIC, the terminating end creates the call at the IN layer. The incoming call triggers DP 22, Termination_Attempt, and then we move on to the next PIC, AUTHORIZE_TERMINATION_ATTEMPT. 🦋
AUTHORIZE_TERMINATION_ATTEMPT: This is the bouncer check 🙈 It gets confirmed that the called party actually wants the call and that the called party's facilities are compatible with the calling party's. If either condition fails, DP 23 (Termination_Denied) is invoked and call control goes over to the SIP protocol state machine. That state machine can format and send a non-2xx final response (possibly 403, 405, 415, or 480). If both conditions are met, DP 24 (Termination_Authorized) is processed and we move on to SELECT_FACILITY. ✨
SELECT_FACILITY: In circuit switched networks, this PIC picks a line or trunk to reach the called party. Lines and trunks don't really exist in an IP network, so a SIN-enabled SIP entity can use this PIC to work with a PSTN gateway and select a line/trunk to route the call. Creative, right? 🌈 If the called party is busy, or if a line/trunk can't be seized, DP 25 (T_Called_Party_Busy) is invoked and the call goes to the SIP protocol state machine. That state machine must format and send a non-2xx final response (possibly 486 or 600). If a line/trunk gets seized successfully, DP 26 (Terminating_Resource_Available) is invoked and we move on to PRESENT_CALL. 💖
PRESENT_CALL: Now the call is actually being presented, either through the ISUP ACM message, a Q.931 Alerting message, or simply by ringing a POTS phone. 📞 If something goes wrong while presenting the call, DP 27 (Presentation_Failure) is invoked and call control goes to the SIP protocol state machine, which must format and send a non-2xx final response (possibly 480). If the call is presented successfully, DP 28 (T_Term_Seized) is invoked and we move on to T_ALERTING. 🫶
T_ALERTING: The called party is being "alerted" at this point 🔔 Control briefly hands over to the SIP protocol state machine so it can generate and send a "180 Ringing" response to its peer. Also, since network resources have been allocated for the call, timers get set so those resources aren't held forever. 🍓 If those timers expire, DP 29 (T_No_Answer) is processed and call control goes to the SIP protocol state machine, which must format and send a non-2xx final response (possibly 408). If the called party answers, DP 30 (T_Answer) is processed and we move on to T_ACTIVE. 👑
Once those first five PICs are done, the rest get mapped like this:
T_ACTIVE: The call is live now 🎉 From here, the call can become inactive under one of three conditions: (1) the network fails the connection, (2) the called party disconnects, or (3) the calling party disconnects. Event (1) triggers DP 31 (T_Connection_Failure) and call control goes to the SIP protocol state machine. Since the network already failed, sending a BYE request doesn't really make sense, so both the SIP protocol state machine and the IN call layer should release all resources associated with the call and reset themselves to the null state. 💀 Event (2) triggers DP 33 (T_Disconnect) and we move on to T_DISCONNECT. Event (3) happens when a BYE request arrives at the SIP protocol state machine (not shown in Figure 6). Resources for the call should be deallocated, and the SIP protocol state machine must send a 200 OK for the BYE request (not shown in Figure 6). 🙌
T_DISCONNECT: Here, the disconnect treatment for the called party having hung up gets performed at the IN layer. The SIP protocol state machine sends out a BYE and waits for a final response to that BYE (not shown in Figure 6). 🌸
6. Examples of Call Flows ✨
Two examples are included here to show how the SIP protocol state machine and the IN call model work together, in sync. 🧚
In the first example, a SIP UAC originates a call request destined for an 800 freephone number:
INVITE sip:18005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITEThe request makes its way to the originating SIP network server running an IN call model. The SIP network server hands at least the To: field and the From: field to the IN layer for freephone number translation. The IN layer works through its PICs, and at the ANALYSE_INFO PIC it consults the SCP for the freephone translation. The translated number comes back to the SIP network server, which forwards the message to the next hop SIP proxy with the freephone number swapped out for the translated one. 🔄
INVITE sip:18475551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP ext-stn2.example.net
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITEIn the next example, a SIP UAC originates a call request destined for a 900 number. 📵
INVITE sip:19005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITEThe request makes its way to the originating SIP network server running an IN call model. The SIP network server hands at least the To: field and the From: field to the IN layer for 900 number translation. The IN layer works through its PICs, and at the ANALYSE_INFO PIC it consults the SCP for the translation. Plot twist 😭 During the translation, the SCP detects that the originating party isn't allowed to make 900 calls. It passes that info back to the originating SIP network server, which lets the SIP UAC know with a SIP "403 Forbidden" response status code:
SIP/2.0 403 Forbidden
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com;tag=78K-909II
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE7. Security Considerations 🔐
Security is the main character here, bestie 🫶 Security considerations for SIN services cover both networks in use, namely the PSTN and the Internet. SIN uses the security measures already in place for both of those networks. With reference to Figure 2, the INAP messages between the SCP and the SIN-enabled SIP entity must be secured by the signaling transport used between the SCP and the SIN-enabled entity. Likewise, requests coming into the SIN-enabled SIP entity must first be authenticated and, if need be, encrypted as well, using the means and procedures defined in [3] for SIP requests. 🛡️
Don't skip this section. Protecting the INAP messages and authenticating incoming SIP requests is what keeps the whole SIN setup from getting messed with 🚨
8. References
8.1. Normative References
[1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services," McGraw-Hill, 1997.
[2] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network Distributed Functional Plane Architecture," International Telecommunications Union Standardization Section, Geneva.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
8.2. Informative References
[4] ITU-T Q.1208: "General aspects of the Intelligent Network Application protocol"
[5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[8] ITU-T Q.1218: "Interface Recommendation for Intelligent Network Capability Set 1".
[9] ITU-T Q.1228: "Interface Recommendation for Intelligent Network Capability Set 2".
[10] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
Appendix A: Mapping of 4xx-6xx Responses in SIP to IN Detections Points 📊
This table shows how error responses in the 4xx-6xx range map to the possible Detection Points in PIC Originating and Terminating Call Handling. The reason phrase in each 4xx-6xx response is reproduced from [3].
SIP response code DP mapping to IN
----------------- ----------------------
200 OK DP 14
3xx DP 12
403 Forbidden DP 2, DP 21
484 Address Incomplete DP 4, DP 21
400 Bad Request DP 6, DP 21
401 Unauthorized DP 6, DP 21
403 Forbidden DP 6, DP 21, DP 23
404 Not Found DP 6, DP 21
405 Method Not Allowed DP 6, DP 21, DP 23
406 Not Acceptable DP 6, DP 21
408 Request Timeout DP 29
410 Gone DP 6, DP 21
414 Request-URI Too Long DP 6, DP 21
415 Unsupported Media Type DP 6, DP 21, DP 23
416 Unsupported URI Scheme DP 6, DP 21
480 Temporarily Unavailable DP 23, DP 27
485 Ambiguous DP 6, DP 21
486 Busy Here DP 13, DP 21, DP 25
488 Not Acceptable Here DP 6, DP 21Acknowledgments 🫶
Huge special shoutout to Hui-Lan Lu for chairing the SIN DT and making sure the focus of the DT didn't veer too far off course 👑 The authors also want to give special thanks to Mr. Ray C. Forbes from Marconi Communications Limited for his valuable contribution on the system and network architectural aspects as co-chair in the ETSI SPAN. 💜 Thanks also to Doris Lebovits, Kamlesh Tewani, Janusz Dobrowloski, Jack Kozik, Warren Montgomery, Lev Slutsman, Henning Schulzrinne, and Jonathan Rosenberg, who all contributed to the discussions on the relationship of IN and SIP call models. 🌈✨
Author's Addresses ✨
Okay, meet the squad 🫶 Here's where you can find each of our authors. Slide into their inbox if you've got questions 💌
Vijay K. Gurbani
Lucent Technologies, Inc.
2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566
USA
Phone: +1 630 224 0216
EMail: vkg@lucent.com
Frans Haerens
Alcatel Bell
Francis Welles Plein,1
Belgium
Phone: +32 3 240 9034
EMail: frans.haerens@alcatel.be
Vidhi Rastogi
Wipro Technologies
Plot No.72, Keonics Electronics City,
Hosur Main Road,
Bangalore 226 560 100
Phone: +91 80 51381869
EMail: vidhi.rastogi@wipro.comFull Copyright Statement 💅
Okay, the legal bit, but make it cute 🎀 The Internet Society owns the copyright here, and it's dated 2005. ✨
This document is subject to the rights, licenses and restrictions in BCP 78, which you can check out at www.rfc-editor.org. Except for what's set out there, the authors keep all their rights 🦋
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 💀
Intellectual Property 🌸
Okay, so the IETF doesn't pick a side on whether any patents or other proprietary rights covering this tech are valid, how far they reach, or whether you could get a license for them. It also doesn't claim it went hunting for those rights itself 🙈 If you want the ISOC rules on rights in ISOC Documents, they're spelled out in BCP 78 and BCP 79 🍓
Copies of IPR disclosures that were sent to the IETF Secretariat are available, along with any promises of licenses, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights. You can find all of that in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔥
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. Periodt 💖
Acknowledgement 🧚
Shoutout to the people keeping the RFC Editor function running! 👑 Funding for it is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3976 2005-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms