RFC 3398
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping 📞✨
RFC 3398 🎀 is the ISUP to SIP Mapping spec, and it's a Standards Track doc, so it's meant to be implemented 💅. It was written by G. Camarillo (Ericsson), A. B. Roach (dynamicsoft), J. Peterson (NeuStar), and L. Ong (Ciena), and it's dated December 2002. Its header doesn't list anything it obsoletes or updates, so it's a fresh start, no drama 🌸.
Status of this Memo 🫶
Okay so this is an Internet standards track protocol for the Internet community, and the authors are literally asking for your discussion and suggestions for improvements 🙈. If you want to know where this protocol stands, check the current edition of "Internet Official Protocol Standards" (STD 1), because that's where the official status lives. Also, distribution of this memo is unlimited, so share it with everyone 🦋.
Copyright Notice 🔥
Copyright (C) The Internet Society (2002). All Rights Reserved.Abstract 🌈
Okay, the vibe here is interworking 🧚. This doc describes a way to map between two signaling protocols: the Session Initiation Protocol (SIP) and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). You'd use this when you're running SIP in an environment where part of the call has to talk to the Public Switched Telephone Network (PSTN) 📞💜.
Table of Contents 🍓
1. Introduction............................................ 3
2. Scope................................................... 4
3. Terminology............................................. 5
4. Scenarios............................................... 5
5. SIP Mechanisms Required................................. 7
5.1 'Transparent' Transit of ISUP Messages.................. 7
5.2 Understanding MIME Multipart Bodies..................... 7
5.3 Transmission of DTMF Information........................ 8
5.4 Reliable Transmission of Provisional Responses.......... 8
5.5 Early Media............................................. 8
5.6 Mid-Call Transactions which do not change SIP state..... 9
5.7 Privacy Protection...................................... 9
5.8 CANCEL causes........................................... 10
6. Mapping................................................. 10
7. SIP to ISUP Mapping..................................... 11
7.1 SIP to ISUP Call flows.................................. 11
7.1.1 En-bloc Call Setup (no auto-answer)..................... 11
7.1.2 Auto-answer call setup.................................. 12
7.1.3 ISUP T7 Expires......................................... 13
7.1.4 SIP Timeout............................................. 14
7.1.5 ISUP Setup Failure...................................... 15
7.1.6 Cause Present in ACM Message............................ 16
7.1.7 Call Canceled by SIP.................................... 17
7.2 State Machine........................................... 18
7.2.1 INVITE received......................................... 19
7.2.1.1 INVITE to IAM procedures................................ 19
7.2.2 ISUP T7 expires......................................... 23
7.2.3 CANCEL or BYE received.................................. 23
7.2.4 REL received............................................ 24
7.2.4.1 ISDN Cause Code to Status Code Mapping.................. 24
7.2.5 Early ACM received...................................... 27
7.2.6 ACM received............................................ 27
7.2.7 CON or ANM Received..................................... 28
7.2.8 Timer T9 Expires........................................ 29
7.2.9 CPG Received............................................ 29
7.3 ACK received............................................ 30
8. ISUP to SIP Mapping..................................... 30
8.1 ISUP to SIP Call Flows.................................. 30
8.1.1 En-bloc call setup (non auto-answer).................... 31
8.1.2 Auto-answer call setup.................................. 32
8.1.3 SIP Timeout............................................. 33
8.1.4 ISUP T9 Expires......................................... 34
8.1.5 SIP Error Response...................................... 35
8.1.6 SIP Redirection......................................... 36
8.1.7 Call Canceled by ISUP................................... 37
8.2 State Machine........................................... 39
8.2.1 Initial Address Message received........................ 39
8.2.1.1 IAM to INVITE procedures................................ 40
8.2.2 100 received............................................ 41
8.2.3 18x received............................................ 41
8.2.4 2xx received............................................ 43
8.2.5 3xx Received............................................ 44
8.2.6 4xx-6xx Received........................................ 44
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping.............. 45
8.2.7 REL Received............................................ 47
8.2.8 ISUP T11 Expires........................................ 47
9. Suspend/Resume and Hold................................. 48
9.1 SUS and RES............................................. 48
9.2 Hold (re-INVITE)........................................ 50
10. Normal Release of the Connection........................ 50
10.1 SIP initiated release................................... 50
10.2 ISUP initiated release.................................. 51
10.2.1 Caller hangs up......................................... 51
10.2.2 Callee hangs up (SUS)................................... 52
11. ISUP Maintenance Messages............................... 52
11.1 Reset messages.......................................... 52
11.2 Blocking messages....................................... 53
11.3 Continuity Checks....................................... 53
12. Construction of Telephony URIs.......................... 54
12.1 ISUP format to tel URL mapping.......................... 56
12.2 tel URL to ISUP format mapping.......................... 57
13. Other ISUP flavors...................................... 58
13.1 Guidelines for sending other ISUP messages.............. 58
14. Acronyms................................................ 60
15. Security Considerations................................. 60
16. IANA Considerations..................................... 64
17. Acknowledgments......................................... 64
18. Normative References.................................... 64
19. Non-Normative References................................ 65
Authors' Addresses...................................... 67
Full Copyright Statement................................ 681. Introduction 🎀
Okay bestie, let's start with the basics 💖. SIP [1] is an application layer protocol for setting up, ending, and changing multimedia sessions 🦋. It's usually carried over IP. And here's the fun part: a telephone call is just a multimedia session where only audio gets exchanged 🎧✨.
Now meet ISUP [12], which is a level 4 protocol used in SS7 networks 👑. It usually runs over the Message Transfer Part (MTP), but it can also run over IP (see SCTP [19]) 🌈. ISUP is the thing that controls telephone calls and handles network maintenance, like blocking circuits and resetting circuits etc. 🔧💅.
So who does the translating? That's the MGC, which stands for Media Gateway Controller 🧚. People also call it a 'softswitch' or a 'call agent', and yes, all of those names mean the same iconic thing 🙈. An MGC has logical interfaces facing both networks: the one carrying ISUP and the one carrying SIP 💜. It also has some power over the voice path. Usually there's a Media Gateway (MG) with E1/T1 trunking interfaces (voice from the PSTN) and IP interfaces (Voice over IP, or VoIP) 🍓. The MGC and the MG can be merged into one physical box, or they can be kept separate, whichever is more your aesthetic 💅.
Why does any of this matter? MGCs are used a lot to bridge SIP and ISUP networks, so calls from the PSTN can reach IP phone endpoints and the other way around 📞🫶.
There's a whole list of reasons this is useful 😭. PSTN calls can take advantage of services that live in the IP world 🌸. IP networks can be used as transit networks for PSTN-to-PSTN calls 🛤️. Calls can start on desktop 'softphones' and end on PSTN terminals ☎️. And there are a bunch of other next-generation telephone architectures that are giving main character energy 👑✨.
Here's what this doc actually does 🧚💖. It describes the logic and procedures an MGC might use to do the SIP-ISUP mapping. It shows the correspondences at the message level and the parameter level between the two protocols 🦋. It also explains how the parallel state machines for these two protocols interplay, and that's offered as a recommendation for implementers who want to synchronize protocol events in interworking architectures 🔥.
Part 1 of 16 done, bestie 💅🌈 Next up: Section 2 (Scope) 🎀
2. Scope ✨
okay so bestie, this section is basically the "what are we even doing here" part 💅 The main focus is translating ISUP messages into SIP messages, and mapping ISUP parameters into SIP headers 🎀 For calls that go through a SIP network, the whole point is to let SIP stuff like proxy servers (which usually don't speak ISUP at all 💀) make routing decisions based on ISUP info, like the called party number 📞 So this document only gives a SIP mapping for the ISUP parameters that intermediaries might actually use when routing SIP requests. Lowkey smart, right? 🧚 As a bonus, translation also boosts overall interoperability by handing critical call info to SIP endpoints that can't read encapsulated ISUP, or that just can't handle the particular ISUP variant inside a message 🫶
This document also only cares about the call functionality of ISUP 🦋 Maintenance messages about PSTN trunks only get a look-in when they affect an ongoing call. Otherwise they neither have nor need a SIP analog, so no stress 🌸
Messages about error or congestion in the PSTN (MTP-3), plus the recovery stuff like User Part Available and User Part Test ISUP messages, are outside the scope of this document 🙈
There are several flavors of ISUP, and this document uses the ITU-T International ISUP [12] because it's the most widely known one 👑 Some differences from ANSI ISUP [11] and TTC ISUP are outlined too, though. Since only a small number of fields map straight from ISUP to SIP, the signaling differences between ITU-T ISUP and national variants will generally have little to no impact on the mapping 💖 Heads up though: the ITU-T hasn't really standardized Local Number Portability (LNP) practices, because portability is grounded in national numbering plans. So LNP has to be described on a virtually per-nation basis 🌈 The number portability practices in this document are presented as an optional mechanism ⭐
Mapping SIP headers to ISUP parameters focuses mostly on the ISUP Initial Address Message (IAM) and the headers tied to the SIP INVITE message 🔥 Both of these are used in their protocols to request call setup, so they're the main event. Once an INVITE has been sent for a session, headers like To and From become essentially fixed, and no further translation is needed during later signaling, which gets routed according to Via and Route headers 💜 So in SIP-T, parameter-to-header mapping is more or less confined to the IAM and the INVITE. There's some extra detail on populating parameters in the ISUP Address Complete Message (ACM) and Release Message (REL) based on SIP status codes too 🍓
This document also describes when the media path for a SIP call is initialized, terminated, modified, and so on 🦋 But it doesn't get into how that initialization is performed or which protocols are used for it, so that's a different convo 💅
3. Terminology 🎀
okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC2119 [2] 🫶 They indicate requirement levels for compliant SIP implementations, so they're not just vibes, they're rules 😭
4. Scenarios ✨
there are a few scenarios where ISUP-SIP mapping happens 🧚 And the way the messages get generated depends on which scenario you're in 🌸
When there's a single MGC and the call goes from a SIP phone to a PSTN phone (or the other way around), the MGC generates the ISUP messages using the methods in this document 📞
+-------------+ +-----+ +-------------+
| PSTN switch +-------+ MGC +-------+ SIP UAC/UAS |
+-------------+ +-----+ +-------------+Now the scenario where a call starts in the PSTN, goes into a SIP network, and ends up back in the PSTN is called "SIP bridging" 🌈 SIP bridging should give ISUP transparency between the PSTN switches handling the call 💖 This works by encapsulating the incoming ISUP messages in the body of the SIP messages (see [3]) 🦋 So in this case, the ISUP messages the egress MGC generates are the ones sitting in the SIP body, possibly with some modifications. For example, if the called number in the request Uniform Resource Identifier - URI - is different from the one in the ISUP because of SIP redirection, the ISUP message will need adjusting 🎀
+------+ +-------------+ +-----+ +------------+ +------+
| PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
+------+ +-------------+ +-----+ +------------+ +------+SIP sits in the middle of both MGCs because the voice path has to be set up through the IP network between both MGs 🫶 This structure also lets the call use certain SIP services 👑 And the ISUP messages in the SIP bodies give the peer MGC extra info, like cause values and optional parameters 💜
In both scenarios, the ingress MGC puts the incoming ISUP messages in the SIP body by default 🔥 Heads up that this has security implications, so see Section 15 🙈 If the recipient of these messages (usually a SIP User Agent Client/User Agent Server - UAC/UAS) doesn't understand them, a negotiation using the SIP 'Accept' and 'Require' headers takes place, and they won't be included in the next SIP message exchange 💅
There can be a Signaling Gateway (SG) between the PSTN and the MGC 🧚 It encapsulates the ISUP messages over IP in a way like the one described in [19] ✨ The mapping in this document isn't affected by the underlying transport protocol of ISUP 🌸
Note that overlap dialing (the use of the Subsequent Address Message - SAM) is outside the scope of this document 🦋 This document assumes that gateways facing ISUP networks that use overlap dialing will implement timers to make sure all digits have been collected before an INVITE gets sent to a SIP network ⭐
Sometimes gateways may receive incomplete ISUP messages that indicate segmentation because of excessive message length 😭 These are usually followed by a Segmentation Message (SGM) carrying the rest of the original ISUP message 💖 An incomplete message might not have enough parameters for a proper mapping to SIP, and encapsulating an incomplete ISUP message could confuse terminating gateways too 🙈 So, a gateway MUST wait until a complete ISUP message has been received (which may mean waiting for one or more SGMs to arrive) before sending any corresponding INVITE 🔥
5. SIP Mechanisms Required 💅
To get a correct mapping between ISUP and SIP, you need some SIP mechanisms beyond the ones in the base SIP specification 🎀 They're covered below 🫶 If the SIP UAC/UAS in the call doesn't support them, the call can still go ahead, but call establishment may be a little different from what the user expects 😭 For example, the other party might answer before the ringback tone is heard, or the user might not be told that the call got forwarded 💀
5.1 'Transparent' Transit of ISUP Messages 🦋
To let gateways take full advantage of the telephone network's services when placing PSTN-to-PSTN calls across a SIP network, SIP messages MUST be able to carry ISUP payloads from gateway to gateway 🌸 The format for encapsulating these ISUP messages is defined in [3] 💖
SIP user agents that don't understand ISUP are allowed to ignore these optional MIME bodies ✨
5.2 Understanding MIME Multipart Bodies 🧚
In most PSTN interworking situations, SIP message bodies are required to carry session information (Session Description Protocol - SDP) as well as ISUP and/or billing information 🌈
PSTN interworking nodes MUST understand the MIME type "multipart/mixed" as defined in RFC2046 [4] 👑 Clients show support for this by including "multipart/mixed" in an "Accept" header 💜
5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information 🍓
How DTMF tones the user plays get transmitted by a gateway is completely orthogonal to how SIP and ISUP are interworked 🙈 Still, DTMF carriage is part of a complete gatewaying solution, so some guidance is offered here 🫶
Since the codec picked for voice may not be ideally suited to carrying DTMF info, a symbolic method of sending this info in-band is desirable 🔥 (out-of-band transmission alone would make it tricky to keep the media stream in sync for tone re-insertion 😭) This transmission MAY be performed as described in RFC2833 [5] 💅
5.4 Reliable Transmission of Provisional Responses 🎀
Provisional responses (the 1xx class) carry call progress info 🦋 PSTN interworking in particular relies on these messages to control the media channel and time call events ✨
When interworking with the PSTN, SIP messages MUST be sent reliably end-to-end 💖 Reliability of requests is already guaranteed by the base protocol 🌸 One application-layer provisional reliability mechanism for responses is described in [18] 🧚
5.5 Early Media 🌈
Early media means being able to play media (audio, for telephony) before a SIP session is established, which is before a 2xx response code has been sent 👑 For telephony, establishing backwards media is desirable so tones and announcements can play, especially when interworking with a network that can't signal call status out of band (like a legacy MF network) 💜 When interworking hasn't been encountered, early media is almost always undesirable, since it eats up inter-machine trunk resources to play media nobody's paying for 🍓
Note that since an INVITE almost always contains the SDP needed to send backwards media, and requires user agents to get ready to receive backwards media as soon as an INVITE is transmitted, baseline SIP has enough support for rudimentary unidirectional early media systems 🙈 However, this mechanism has limits. For example, media streams offered in the SDP of the INVITE can't be modified or declined, and bidirectional RTCP (needed for session maintenance) can't be established 😭
So gateways MAY support more sophisticated early media systems as they're better understood 🫶 One mechanism that provides a way to start a fully-featured early media system is described in [20] 🔥
Note that in SIP networks, not just switches but also user agents can generate the 18x response codes and start early backwards media 💅 So some gateways may want to enforce policies that restrict backwards media from arbitrary user agents (see Section 15) 🎀
5.6 Mid-Call Transactions which do not change SIP state ✨
okay so when we're talking to the PSTN, gateways sometimes need to send each other messages over SIP that don't match any SIP operation 🫶 They just need to say something mid-call, no cap.
In support of mid-call transactions and other ISUP events that don't have an existing SIP method, SIP gateways MUST support the INFO method, defined in RFC2976 [6]. Note that this document does not prescribe or endorse the use of INFO to carry DTMF digits. So bestie, INFO is not the DTMF pipeline here 🙅♀️
Gateways MUST accept "405 Method Not Allowed" and "501 Not Implemented" as non-fatal responses to INFO requests. That means any call in progress MUST NOT be torn down if a destination rejects an INFO request sent by a gateway like that 💖
5.7 Privacy Protection 🎀
ISUP has this thing called presentation restriction, which is basically a way for a user to say "please don't show my number to the person I'm calling" (aka Caller ID) 🙈 When a gateway gets an ISUP request that requires presentation restriction, it must shield the caller's identity somehow.
The base SIP protocol can say a user is anonymous, but it's kind of limited. For example, it reveals the identity of the gateway itself, which could be a privacy-impacting disclosure 😬 So gateways MAY support more sophisticated privacy systems. One mechanism that gives you fully-featured privacy negotiation (and plays nicely with identity management systems) is described in [9B]. main character privacy energy 🦋
5.8 CANCEL causes 💅
In ISUP, the general-purpose REL is sent in the forwards direction when you want to stop trying to set up a call. SIP has a similar concept: a CANCEL request, used to discontinue establishing a SIP dialog. The catch is that CANCEL requests cannot contain message bodies. So to carry the important REL cause code end-to-end in SIP bridging cases, ISUP encapsulation can't be used 💀
Usually this isn't a big deal, because in practice the only reason a REL is ever sent to cancel a call setup is that a user hangs up while it's still ringing (which gives you a "Normal clearing" cause code). But under exceptional conditions, like catastrophic network failure, a REL might be sent with a different cause code. It would be so handy if a SIP network could carry that cause code end-to-end 🥺 So gateways MAY support a mechanism for end-to-end delivery of such failure reasons. One mechanism that provides this capability is described in [9].
6. Mapping 🗺️
The mapping between ISUP and SIP is described using call flow diagrams and state machines. One state machine handles calls from SIP to ISUP, and the second handles calls from ISUP to SIP. There are details, like some retransmissions and some states (waiting for the Release Complete Message - RLC, waiting for SIP ACK etc.), that aren't shown in the figures, because they'd make everything way harder to follow 🌈
The boxes are the different states of the gateway, and the arrows show changes in state. The event that triggers the change and the actions to take both appear on the arrow, written as event / section describing the actions to take.
For example, 'INVITE / 7.2.1' means an INVITE request has been received by the gateway, and the procedure for handling it is described in section 7.2.1 of this document ✨
It is RECOMMENDED that gateways implement functional equivalence with the call flows detailed in Section 7.1 and Section 8.1. Deviations from these flows are permissible to support national ISUP variants, or any of the conservative policies recommended in Section 15 🫶
7. SIP to ISUP Mapping 👑
7.1 SIP to ISUP Call flows 🌸
The following call flows show the order of messages in typical success and error cases when setting up a call that starts from the SIP network. "100 Trying" acknowledgements to INVITE requests aren't displayed below, even though they're required in many architectures 🙃
In these diagrams, all call signaling (SIP, ISUP) goes to and from the MGC. Media handling (like audio cut-through and trunk freeing) is done by the MG, under the control of the MGC. To keep things simple, they're shown as a single node labeled "MGC/MG." 🧚
7.1.1 En-bloc Call Setup (no auto-answer) 📞
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |- When a SIP user wants to start a session with a PSTN user, the SIP node issues an INVITE request.
- When the gateway receives an INVITE request, it maps it to an IAM message and sends it to the ISUP network.
- The remote ISUP node says the address is enough to set up a call by sending back an ACM message.
- The "called party status" code in the ACM message is mapped to a SIP provisional response (as described in Section 7.2.5 and Section 7.2.6) and returned to the SIP node. This response may contain SDP to set up an early media stream (as shown in the diagram). If no SDP is present, the audio will be established in both directions after step 8.
- If the ISUP variant allows it, the remote ISUP node may send a variety of Call Progress (CPG) messages to indicate things like the call being forwarded.
- When the gateway receives a CPG message, it maps the event code to a SIP provisional response (see Section 7.2.9) and sends it to the SIP node.
- Once the PSTN user answers, an Answer (ANM) message is sent to the gateway.
- When the gateway receives the ANM, it sends a 200 message to the SIP node.
- The SIP node, upon receiving an INVITE final response (200), sends an ACK to acknowledge receipt.
7.1.2 Auto-answer call setup 🤖
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |Heads up: this flow is not supported in ANSI networks. 🚫
- When a SIP user wants to start a session with a PSTN user, the SIP node issues an INVITE request.
- When the gateway receives an INVITE request, it maps it to an IAM message and sends it to the ISUP network.
- Since the remote node is set up to answer automatically, it sends a Connect Message (CON) as soon as it gets the IAM. (For ANSI, this message will be an ANM.)
- When the gateway receives the CON, it sends a 200 message to the SIP node.
- The SIP node, upon receiving an INVITE final response (200), sends an ACK to acknowledge receipt.
7.1.3 ISUP T7 Expires ⏰
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |- When a SIP user wants to start a session with a PSTN user, the SIP node issues an INVITE request.
- When the gateway receives an INVITE request, it maps it to an IAM message and sends it to the ISUP network. The ISUP timer T7 starts at this point.
- If the ISUP timer T7 expires before an ACM or CON message is received, a REL message is sent to cancel the call. 💔
- A gateway timeout message is sent back to the SIP node.
- The SIP node, upon receiving an INVITE final response (504), sends an ACK to acknowledge receipt.
7.1.4 SIP Timeout 💀
Okay bestie, this one is the "SIP node just ghosts us" situation 😭 Check the flow:
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
5|<----------200------------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
7|<----------BYE------------|------------REL---------->|6
| |<-----------RLC-----------|8- A SIP user wants to start a session with a PSTN user, so the SIP node sends an INVITE request 📞
- When the gateway gets that INVITE, it turns it into an IAM message and sends it off to the ISUP network 🚀
- The remote node is set up to auto-answer, so it sends a CON message as soon as it gets the IAM. In ANSI flows, an ANM (without ACM) gets sent instead of a CON 🤖
- When the ANM arrives, the gateway sends a 200 to the SIP node and starts SIP timer T1 ⏱️
- The response gets retransmitted every single time T1 expires 🔁
- After seven retransmissions, the call gets torn down. The gateway sends a REL to the ISUP node with a cause code of 102 (recover on timer expiry) 🙅♀️
- A BYE is sent to the SIP node to try and close the call. Any further cleanup isn't shown here, since the SIP node's state is hard to know in this situation 🤷♀️
- When the remote ISUP node gets the REL, it replies with an RLC 💅
7.1.5 ISUP Setup Failure 🥀
Here's the one where the far end just can't finish the call, and it's giving "try again never" 💔
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |- A SIP user wants to start a session with a PSTN user, so the SIP node sends an INVITE request 📞
- The gateway gets the INVITE, maps it to an IAM message, and sends it to the ISUP network 🚀
- The remote ISUP node can't complete the call, so it sends a REL 🚫
- The gateway lets go of the circuit and confirms it's free to reuse by sending an RLC 🔓
- The gateway translates the cause code in the REL into a SIP error response (see Section 7.2.4) and sends it to the SIP node 🔄
- The SIP node sends an ACK to confirm it got the INVITE final response 🫶
7.1.6 Cause Present in ACM Message 🎀
This one is kinda dramatic. The ISUP node wants to play its own error tone or announcement, so it sends an ACM with a cause code and the gateway has to keep up 🎭
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |- A SIP user wants to start a session with a PSTN user, so the SIP node sends an INVITE request 📞
- The gateway gets the INVITE, maps it to an IAM message, and sends it to the ISUP network 🚀
- The ISUP node can't finish the call and wants to make the error tone or announcement itself, so it sends an ACM with a cause code. The gateway starts an interwork timer ⏳
- When the ACM with cause shows up (that means the CAI parameter is there), the gateway sends a 183 to the SIP node. This one has SDP in it to set up early media cut-through 🎶
- A final INVITE response gets generated and sent to the SIP node to end the call, based on the cause code from the earlier ACM. See Section 7.2.4.1 for the table that maps cause codes to SIP responses 📋
- When the interwork timer expires, a REL gets sent toward the PSTN node to end the call. Heads up: the SIP node can also end things by sending a CANCEL before the interwork timer runs out. If that happens, the signaling goes the way of Section 7.1.7 💅
- When the REL arrives, the remote ISUP node replies with an RLC 🔁
- The SIP node sends an ACK to confirm it got the INVITE final response 🫶
7.1.7 Call Canceled by SIP 🙅♀️
Here the SIP side changes its mind before anyone picks up. Main character energy, but make it a cancel 💅
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |- A SIP user wants to start a session with a PSTN user, so the SIP node sends an INVITE request 📞
- The gateway gets the INVITE, maps it to an IAM message, and sends it to the ISUP network 🚀
- The remote ISUP node says the address has enough info to set up a call by sending back an ACM 👍
- The "called party status" code in the ACM gets mapped to a SIP provisional response (as described in Section 7.2.5 and Section 7.2.6) and sent back to the SIP node. This response might have SDP in it to set up an early media stream 🎧
- To cancel before anyone answers, the SIP node sends a CANCEL request 🛑
- The CANCEL request gets confirmed with a 200 response ✅
- When the gateway gets the CANCEL request, it sends a REL message to end the ISUP call 🔚
- The gateway sends a "487 Call Cancelled" message to the SIP node to finish the INVITE transaction 💀
- When the REL arrives, the remote ISUP node replies with an RLC 💜
- When the 487 arrives, the SIP node confirms it got it with an ACK 🫶
7.2 State Machine 🦋
Quick note: REL can be received in any state, and it's handled the same way every time (see Section 10) 💖
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+7.2.1 INVITE received 🎉
When the gateway gets an INVITE request, it MAY send a "100 Trying" response back to the SIP network. That's just the gateway saying "yup, I'm handling this call" 🫶
The hardware resources for the media stream MUST be reserved in the gateway as soon as the INVITE comes in, because an IAM message can't go out until the resource reservation is done (especially TCIC selection). Usually the resources are a time slot in an E1/T1 and an RTP/UDP port on the IP side 🔌. Resources might also include quality-of-service provisions, although no such practices are recommended in this document ✨
After the IAM goes out, timer T7 starts. The default T7 value is between 20 and 30 seconds ⏱️. The gateway then moves to the 'Trying' state 🦋
7.2.1.1 INVITE to IAM procedures ✨
okay bestie, this section is the whole recipe for turning a SIP INVITE into an ISUP IAM 📞💖 A PSTN-SIP gateway is the one responsible for building the IAM whenever an INVITE shows up 🧚
There are five mandatory parameters in every IAM: the Called Party Number (CPN), the Nature of Connection Indicator (NCI), the Forward Call Indicators (FCI), the Calling Party's Category (CPC), and then a parameter for the bearer characteristics the call wants. Depending on the ISUP variant that one is the Transmission Medium Requirement (TMR), the User Service Information (USI), or both 💅 All IAM messages MUST contain these five parameters at a minimum, so every gateway needs a way to fill in all five whenever an INVITE comes in. Lots of those values, like the NCI or USI, will probably be identical for every IAM the gateway makes 🌸 Others, like the CPN, change call by call, so the gateway has to pull that info out of the INVITE. It's giving organized 🎀
There are also a bunch of optional parameters, and Q.763 [17] lists 29 of them 🙈 But none of those have to be translated to hit the goals of SIP-ISUP mapping. Like we said above, translation is there so SIP network elements can understand the basic PSTN context of the session (who it's for, and so on) if they can't decode any encapsulated ISUP. Parameters that only matter to the PSTN get carried through PSTN-SIP-PSTN networks by encapsulation, so translating them isn't necessary 🦋 Out of those 29 optional ones, only these are immediately useful for translation: the Calling Party's Number (CIN, which is commonly present), Transit Network Selection (TNS), Carrier Identification Parameter (CIP, present in ANSI networks), Original Called Number (OCN), and the Generic Digits (known in some variants as the Generic Address Parameter (GAP)) 🍓
When a SIP INVITE lands at a PSTN gateway, the gateway SHOULD try to use encapsulated ISUP (see [3]), if there is any, inside the INVITE to help build the outbound PSTN signaling. It SHOULD also heed the security considerations in Section 15 🔥 If it can, the gateway SHOULD reuse the value of each ISUP parameter from the encapsulated IAM when it builds the IAM it sends out its PSTN interface. Sometimes the gateway can't use that ISUP at all, like when it doesn't understand the ISUP variant and has to ignore the encapsulated body 💀 Even when the encapsulated ISUP is comprehensible, the relevant SIP header field values MUST 'overwrite' the parameter values that would have been set from that encapsulated ISUP through translation. So in ISUP-SIP-ISUP bridging cases, the updates to the critical session context parameters made in the SIP network win over the encapsulated ISUP 👑 This is what lets a bunch of basic services, including different kinds of call forwarding and redirection, get built in the SIP network. Main character energy, literally ✨
Here's an example: say an INVITE arrives with an encapsulated IAM whose CPN field says +12025332699, but the Request-URI of the INVITE says tel:+15105550110. The gateway MUST use the telephone number in the Request-URI, not the one in the encapsulated IAM, when it creates the IAM it's sending to the PSTN 🫶 More details on how SIP header fields become ISUP parameters come next.
Gateways MUST be provisioned with default values for the mandatory ISUP parameters that can't be derived from translation (like the NCI or TMR parameters), for the cases where there's no encapsulated ISUP. The FCI parameter MUST also have a default, because only the 'M' bit of that default may be overwritten during translation if the optional number portability translation mechanisms described below are used 🎀
The first step in translating an INVITE's fields into the parameters of an IAM is inspecting the Request-URI 🔍
If the gateway supports the optional number portability practices, then the steps below for the 'npdi' and 'rn' parameters of the Request-URI should be followed.
If there's no 'npdi=yes' field in the Request-URI, then the primary telephone number in the tel URL (the digits right after 'tel:') MUST be converted to ISUP format, following the procedures in Section 12, and used to populate the CPN parameter.
If the 'npdi=yes' field is there, then the FCI parameter bit for 'number translated' in the IAM MUST reflect that a number portability dip has been performed 🦋
If there's an 'npdi=yes' field and no 'rn=' field, then the main telephone number in the tel URL MUST be converted to ISUP format (see Section 12) and used to populate the CPN parameter. This means a portability dip happened, but the called party's number wasn't ported 🌈
If there's an 'npdi=yes' field and an 'rn=' field, then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format and used to populate the CPN. The main telephone number in the tel URL MUST be converted to ISUP format and used to populate the Generic Digits Parameter (or GAP in ANSI) 😭 In some other ISUP variants, the number given in the 'rn=' field gets prepended to the main telephone number (with or without a prefix or separator), and the combined result MUST be used to populate the CPN. Once the 'rn=' and 'npdi=' parameters have been translated, the number portability translation practices are done ✨
The following mandatory translation practices happen after the number portability translations, if there were any 💅
If the gateway doesn't support number portability practices, then the primary telephone number in the tel URL (the digits right after 'tel:') MUST be converted to ISUP format, following the procedures in Section 12, and used to populate the CPN parameter.
If the primary telephone number in the Request-URI and the one in the To header are different, then the To header SHOULD be used to populate an OCN parameter. Otherwise the To header SHOULD be ignored 🍓
There are some optional translation procedures for carrier-based routing. If the 'cic=' parameter is in the Request-URI, the gateway SHOULD consult local policy to make sure it's okay to send this Carrier Identification Code (CIC, not to be confused with the MTP3 'circuit identification code') in the IAM. If the gateway supports many independent trunks, it may need to pick a particular trunk that points to the carrier named by the CIC, or a tandem through which that carrier can be reached 🔥 Policies for those trunks (based on what the carriers the trunks belong to prefer, and the ISUP variant in use) SHOULD dictate whether the CIP or TNS parameter carries the CIC. With no pre-arranged policies, TNS should be used when the CPN parameter is in an international format (that's when the tel URL portion of the Request-URI starts with a '+', which generates a CPN in international format), and (where it's supported) CIP should be used in other cases 🌸
When a SIP call gets routed to a gateway, the Request-URI will most likely contain a tel URL (or a SIP URI with a tel URL user portion). SIP-ISUP gateways that get Request-URIs without valid telephone numbers SHOULD reject those requests with an appropriate response code 🙅♀️ Gateways SHOULD however keep processing requests whose From header field doesn't contain a telephone number, which will sometimes happen if a call starts at a SIP phone using the SIP URI user@host convention 🫶 The CIN parameter SHOULD be left out of the outbound IAM if the From field isn't usable. As an alternative, gateway implementers MAY consider some non-standard way of mapping particular SIP URIs to telephone numbers 🧚
When a gateway gets a message with (comprehensible) encapsulated ISUP, it MUST set the FCI indicator in the generated IAM so that all the interworking-related bits match their counterparts in the encapsulated ISUP. Usually these indicators will say no interworking was encountered, unless interworking happened somewhere else in the call path 💖 If there's no usable encapsulated ISUP in an INVITE the gateway receives, it is STRONGLY RECOMMENDED that the gateway set the Interworking Indicator bit of the FCI to 'no interworking' and the ISDN User Part Indicator to 'ISUP used all the way'. The gateway MAY also set the Originating Access indicator to 'Originating access non-ISDN' (generally, it's not safe to assume SIP phones support ISDN endpoint services, and the procedures in this document don't detail mappings for translating all of those services 🙈)
Heads up: when 'interworking encountered' is set in the FCI parameter of the IAM, that means ISUP is interworking with a network that can't provide as many services as ISUP can. So ISUP networks won't use certain features they normally would, including maybe ISDN cause codes in failure conditions (instead of sending ACMs followed by audible announcements) 💀 If they want, gateway vendors MAY provide a configurable option, for service providers to use at their discretion, that signals interworking has been encountered (and that ISUP isn't used all the way) when there's no encapsulated ISUP. But doing that may seriously limit the efficiency and transparency of SIP-ISUP translation 😭
Claiming to be an ISDN node might make the callee ask for ISDN user to user services. Since user to user services 1 and 2 have to be requested by the caller, they aren't a problem (see [14]). User to user service 3 can also be requested by the callee. In non-SIP bridging situations, the MGC should be capable of rejecting that service request 🍓
7.2.2 ISUP T7 expires
7.2.2 ISUP T7 expires 💜
Since no response came back from the PSTN, all the resources in the MG get released 🧹 A '504 Server Timeout' SHOULD be sent back to the SIP network. A REL message with cause value 102 (protocol error, recovery on timer expiry) SHOULD be sent to the PSTN. Gateways can expect the PSTN to answer with RLC, and the SIP network to answer with an ACK, which means the release sequence is complete 🎀✨
7.2.3 CANCEL or BYE received ✨
okay so if a CANCEL or BYE shows up before any final SIP response has been sent, a 200 OK MUST go back to the SIP network to confirm the CANCEL or BYE 💅. A 487 MUST also go out to end the INVITE transaction 🥀. All the resources get released, and a REL message SHOULD be sent to the PSTN with cause value 16 (normal clearing) 🦋. Gateways can expect an RLC to come back from the PSTN, which means the release sequence is complete 🎀
In SIP bridging situations, a REL might be tucked inside the body of a BYE request 🧚. BYE usually maps to cause code 16 (normal clearing), but under exceptional circumstances the cause code in the REL message might be different 👀. So the Cause Indicator parameter of the encapsulated REL should be re-used in the REL sent to the PSTN 💜
Note that a BYE or CANCEL request may contain a Reason header that SHOULD be mapped to the Cause Indicator parameter (see Section 5.8) 🍓. If a BYE contains both a Reason header and encapsulated ISUP, the value in the Reason header MUST be preferred 👑
All the resources in the gateway SHOULD be released before the gateway sends any REL message 🫶
7.2.4 REL received 🌸
This section applies when a REL is received before a final SIP response has been sent. Typically, this happens when a call has been rejected by the PSTN 📞
Any gateway resources SHOULD be released immediately, and an RLC MUST be sent to the ISUP network to show that the circuit is free to be reused ♻️
If the INVITE that started this transaction contained a legit, comprehensible encapsulated ISUP message (i.e., an IAM using a variant the gateway supports, preferably with a digital signature), then encapsulated ISUP SHOULD be sent in the response to the INVITE when possible 🔥. This suggests an ISUP-SIP-ISUP bridging case, so the REL message just received SHOULD be included in the body of the SIP response 🌈. The gateway SHOULD NOT return a response with encapsulated ISUP if the originator of the INVITE did not enclose ISUP itself 🙈
Note that certain maintenance messages in response to an IAM, such as Blocking Message (BLO) or Reset Message (RSC) (or their circuit group message equivalents), may also result in the teardown of calls in this phase of the state machine 🧹. Behavior for maintenance messages is given below in Section 11 💜
7.2.4.1 ISDN Cause Code to Status Code Mapping 💅
The REL message in the SS7 network is super general, whereas SIP has a bunch of specific tools that together play the same role as REL. Those are BYE, CANCEL, and the various status/response codes 🧩. A REL can tear down a call that's already in progress (BYE), cancel a call setup request that hasn't finished yet (CANCEL), or reject a call setup request (IAM) that just came in (matching a SIP status code) 📲
Note that it is not necessarily appropriate to map some ISDN cause codes to SIP messages, because these cause codes only mean something to the ISUP interface of a gateway 🫠. A good example is cause code 44 "Request circuit or channel not available." 44 signifies that the CIC an IAM was sent for was believed by the receiving equipment to be in a state that's incompatible with a new call request 😭. The right move in this case is for the originating switch to re-send the IAM for a different CIC, not for the call to be torn down 🔁. There is not (and there should not be) a SIP status code that says a new CIC should be selected. That stuff is internal to the originating gateway 🤫. So receipt of cause code 44 should not result in any SIP status code being sent. Effectively, the cause code is untranslatable 🧃
If a cause value other than those listed below is received, the default response '500 Server internal error' SHOULD be used 🛠️
Finally, in addition to the ISDN Cause Code, the CAI parameter also contains a cause 'location' that gives a sense of which entity in the network was responsible for terminating the call (the big distinction being between the user and the network) 🕵️♀️. In most cases, the cause location doesn't change the mapping to a SIP status code. A few exceptions are noted below. A diagnostic field may also be present for some ISDN causes, and this diagnostic holds extra data about how the call got terminated 📝
The following mapping values are RECOMMENDED: ✨
Normal event 💖
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing --- (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable(*) ISDN Cause 16 will usually result in a BYE or CANCEL 🌟
(+) If the cause location is 'user' than the 6xx code could be given rather than the 4xx code (i.e., 403 becomes 603) 🌺
(=) ANSI procedure. In ANSI networks, 26 is overloaded to signify 'misrouted ported number'. Presumably, a number portability dip should have been performed by a prior network. Otherwise cause 26 is usually not used in ISUP procedures 🧐
A REL with ISDN cause 22 (number changed) might contain information about a new number where the callee might be reachable in the diagnostic field 📇. If the MGC is able to process this information, it SHOULD be added to the SIP response (301) in a Contact header 🎯
Resource unavailable 🌧️
This kind of cause value indicates a temporary failure. A 'Retry-After' header MAY be added to the response if appropriate ⏳
ISUP Cause value SIP response
---------------- ------------
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
41 temporary failure 503 Service unavailable
42 switching equipment congestion 503 Service unavailable
47 resource unavailable 503 Service unavailableService or option not available 🎀
This kind of cause value indicates that there's a problem with the request, rather than something that will resolve itself over time 🛑
ISUP Cause value SIP response
---------------- ------------
55 incoming calls barred within CUG 403 Forbidden
57 bearer capability not authorized 403 Forbidden
58 bearer capability not presently 503 Service unavailable
availableService or option not available 🎀
ISUP Cause value SIP response
---------------- ------------
65 bearer capability not implemented 488 Not Acceptable Here
70 only restricted digital avail 488 Not Acceptable Here
79 service or option not implemented 501 Not implementedInvalid message 🙃
ISUP Cause value SIP response
---------------- ------------
87 user not member of CUG 403 Forbidden
88 incompatible destination 503 Service unavailableProtocol error 🤖
ISUP Cause value SIP response
---------------- ------------
102 recovery of timer expiry 504 Gateway timeout
111 protocol error 500 Server internal errorInterworking 🔄
ISUP Cause value SIP response
---------------- ------------
127 interworking unspecified 500 Server internal error7.2.5 Early ACM received 🦋
An ACM message is sent in certain situations to say the call is in progress, just to satisfy ISUP timers. It's not about the callee being alerted 🔔. This happens in mobile networks, for example, where roaming can delay call setup a lot 🌍. The early ACM gets sent before the user is alerted, so the far side can reset T7 and start T9 ⏱️. An ACM counts as an 'early ACM' if the Called Party's Status Indicator is set to 00 (no indication) 🕊️
After sending an early ACM, the ISUP network can be expected to share how the call is progressing by sending CPGs 📬
When an early ACM is received, the gateway SHOULD send a 183 Session Progress response (see [1]) to the SIP network 🎶. In SIP bridging situations (where encapsulated ISUP was contained in the INVITE that started this call), the early ACM SHOULD also be included in the response body 💌
Note that sending 183 before a gateway has confirmation that the address is complete (ACM) creates known problems in SIP bridging cases, so it SHOULD NOT be sent 🚫💅
7.2.6 ACM received 📞
Okay so, most of the time when an ACM shows up, a provisional response in the 18x class SHOULD be sent to the SIP network 💖. If the INVITE that started this session had legit and comprehensible encapsulated ISUP in it, then the ACM the gateway got SHOULD be encapsulated in that provisional response 🎀.
If the ACM has a Backward Call Indicators parameter with a value of 'subscriber free', the gateway SHOULD send a '180 Ringing' response 🔔. When a 180 goes out, it's assumed (if there's no early media extension going on) that any ringback tones get generated locally by the SIP user agent the gateway is responding to, which might itself be a gateway 🎧.
If the Backward Call Indicators (BCI) parameter of the ACM says interworking has been encountered (basically meaning the ISUP network sending the ACM is talking to a less sophisticated network that can't report its status over out-of-band signaling) then there may be in-band announcements of call status, like an audible busy tone or a caller intercept message 📢. If that's possible, a backwards media transmission SHOULD be initiated 🦋. Backwards media SHOULD also be transmitted if the Optional Backward Call Indicators parameter field for in-band media is set 🌸. For more on early media (before 200 OK/ANM), check out Section 5.5 📖. Once early media transmission has been started, the gateway SHOULD send a 183 Session Progress response code 💅.
Gateways MAY have some way of figuring out what's going on with the in-band audio media 👀. For example, some ISUP variants let you tell by inspecting signaling, or you can listen to the audio to hear if ringing or a busy tone is playing over the circuit 🎶. Gateways like that MAY choose to discard the media and send the matching response code (such as 180 or 486) instead 🙅♀️. Honestly though, building a gateway like that means overcoming a bunch of known challenges that are outside the scope of this document 😭.
When they get an ACM, switches in lots of ISUP networks start a timer called "T9" that usually lasts between 90 seconds and 3 minutes (see [13]) ⏳. When early media is playing, this timer lets the caller hear backwards audio media (ringback, tones or announcements) from a remote switch in the ISUP network for that long without getting charged for the connection 💸. The closest possible local ISUP exchange to the callee is the one generating the ringback tone or voice announcements 📞. If longer announcements need to play, the network has to send an ANM, which kicks off bidirectional media of indefinite duration 🌈. In common ISUP network practice, billing starts when the ANM is received 🧾. Some networks don't support timer T9 🙈.
7.2.7 CON or ANM Received 🥳
When an ANM or CON message comes in, the call has been answered, so a '200 OK' response SHOULD be sent to the SIP network 🎉. That 200 OK SHOULD contain an answer to the media that was offered in the INVITE 💜. In SIP bridging situations (when the INVITE that started this call had legit and comprehensible encapsulated ISUP), the ISUP message gets included in the body of the 200 OK response 🫶. If that hasn't happened already, the gateway MUST establish a bidirectional media stream right now ✨.
With some legacy networks, an ISUP switch can get an ANM right after an early ACM (with no CPG or any other backwards messaging), or it might get no ACM at all (when an automaton answers the call) 🤖. In that situation the SIP user never received a 18x provisional response, so they won't hear any kind of ringtone before the callee answers 😬. That can cause some clipping of the caller's initial forward media, since forward media can't start until SDP has been acquired from the destination ✂️. In ISDN (see [12]), this gets solved by connecting the voice path backwards before sending the IAM 🧠.
7.2.8 Timer T9 Expires ⏰💀
When this timer expires (it isn't used in every network), it means an ANM hasn't shown up a long time after alerting started with the ACM for this call 😤. Usually that means the callee's terminal has been ringing for ages and nobody picked up 📱. It can also happen in interworking cases where the network is playing a status announcement (like one saying a number is not in service) and it has looped several times 🔁. Whatever caused the drawn-out incomplete call, when this timer expires the call MUST be released 🚫. All of the gateway resources related to the media path SHOULD be released 🧹. A '480 Temporarily Unavailable' response code SHOULD be sent to the SIP network, and a REL message with cause value 19 (no answer from the user) SHOULD be sent to the ISUP network 📨. The PSTN can be expected to reply with an RLC, and the SIP network should reply with an ACK, which means the release sequence is complete 🎀.
7.2.9 CPG Received 📣
A CPG is a provisional message that can indicate progress, alerting or in-band information 🔊. If a CPG suggests in-band information is available, the gateway SHOULD start transmitting early media and cut through the unidirectional backwards media path ⚡.
In SIP bridging situations (when the INVITE that started this session had legit and comprehensible encapsulated ISUP), the CPG SHOULD be sent in the body of a particular 18x response. Which one depends on the CPG Event Code, like this 👇
ISUP event code SIP response
---------------- ------------
1 Alerting 180 Ringing
2 Progress 183 Session progress
3 In-band information 183 Session progress
4 Call forward; line busy 181 Call is being forwarded
5 Call forward; no reply 181 Call is being forwarded
6 Call forward; unconditional 181 Call is being forwarded
- (no event code present) 183 Session progressJust note that if the CPG doesn't indicate "Alerting," the current state won't change 🧘♀️.
7.3 ACK received 🥂
Now the call is fully connected and the conversation can happen 🗣️💕. No ISUP message should be sent by the gateway when an ACK is received 🙅♀️.
8. ISUP to SIP Mapping 🗺️
8.1 ISUP to SIP Call Flows 🧭
These call flows show the order of messages in typical success and error cases when a call gets set up from the PSTN network 📞➡️💻. "100 Trying" acknowledgements to INVITE requests aren't drawn, since they're optional 🙈.
In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC, and media handling (for example, audio cut-through and trunk freeing) is done by the MG, under the control of the MGC 🎛️. To keep things simple, they're shown as a single node labeled "MGC/MG" 💅.
8.1.1 En-bloc call setup (non auto-answer) 🌟
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |=========================>|
| |------------ACM---------->|4
5|-----------18x----------->| |
| |------------CPG---------->|6
7|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|8
| |<=========Audio==========>|
9|<----------ACK------------| |- When a PSTN user wants to start a session with a SIP user, the PSTN network generates an IAM message towards the gateway 📞.
- When the gateway gets the IAM message, it generates an INVITE message and sends it to an appropriate SIP node 💌.
- When an event signifying that the call has sufficient addressing information occurs, the SIP node will generate a provisional response of 180 or greater 🔔.
- When the gateway receives a provisional response of 180 or greater, it will generate an ACM message. If the response isn't 180, the ACM will carry a "called party status" value of "no indication" 🤷♀️.
- The SIP node may use further provisional messages to show session progress 📈.
- After an ACM has been sent, all provisional responses will translate into ISUP CPG messages, as indicated in Section 8.2.3 🔁.
- When the SIP node answers the call, it will send a 200 OK message 🥳.
- When the gateway gets the 200 OK message, it will send an ANM message towards the ISUP node 🎊.
- The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response 🫶.
8.1.2 Auto-answer call setup 🤖💖
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |- When a PSTN user wants to start a session with a SIP user, the PSTN network generates an IAM message towards the gateway 📞.
- When the gateway gets the IAM message, it generates an INVITE message and sends it to an appropriate SIP node, based on called number analysis 🔍.
- Since the SIP node is set up to answer the call automatically, it will send a 200 OK message 🤖.
- When the gateway gets the 200 OK message, it will send a CON message towards the ISUP node 💫.
- The gateway will send an ACK to the SIP node to acknowledge receipt of the INVITE final response 🎀.
8.1.3 SIP Timeout ✨
Okay so this one is about what happens when the SIP side just... doesn't answer 😭 Here's the whole flow, bestie:
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
6|<--------CANCEL-----------| |
| |<-----------RLC-----------|7- When a PSTN user wants to start a session with a SIP user, the PSTN network sends an IAM message to the gateway. 💌
- When the gateway gets that IAM, it makes an INVITE message and sends it to the right SIP node, based on called number analysis. The ISUP timer T11 and the SIP timer T1 get set right then. ⏰
- The INVITE keeps getting sent to the SIP node every time T1 expires. The SIP standard says INVITE transmission happens 7 times if no response comes back. 🔁
- When T11 expires, an ACM message goes to the ISUP node so the remote node's ISUP T7 doesn't tear the call down. This ACM has a 'Called Party Status' value of 'no indication.' 🙈
- Once the max number of INVITE requests has been sent, the gateway sends a REL (cause code 18) to the ISUP node to end the call. 👋
- The gateway also sends a CANCEL message to the SIP node to stop any initiation attempts. 🛑
- When the remote ISUP node gets the REL, it sends back an RLC to acknowledge it. 🫶
8.1.4 ISUP T9 Expires 🌸
This one is giving ISUP timeouts, and the drama is real. Check the diagram:
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T9 Expires *** |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<--------CANCEL-----------| |- When a PSTN user wants to start a session with a SIP user, the PSTN network sends an IAM message to the gateway. 💌
- When the gateway gets that IAM, it makes an INVITE message and sends it to the right SIP node, based on called number analysis. The ISUP timer T11 and the SIP timer T1 get set right then. ⏰
- The INVITE keeps getting sent to the SIP node every time T1 expires. The SIP standard says INVITE transmission happens 7 times if no response comes back. Since SIP T1 starts at 1/2 second or more and doubles each time it gets retransmitted, it'll be at least a minute before SIP times out the INVITE request. And since SIP T1 is allowed to be larger than 500 ms at the start, it's possible that 7 x SIP T1 will be longer than ISUP T11 + ISUP T9. Wild, right? 🤯
- When T11 expires, an ACM message goes to the ISUP node so the remote node's ISUP T7 doesn't tear the call down. This ACM has a 'Called Party Status' value of 'no indication.' 🙈
- When ISUP T9 in the remote PSTN node expires, it sends a REL. 💥
- When the gateway gets the REL, it sends back an RLC to acknowledge it. 🫶
- The REL triggers a CANCEL request, which gets sent to the SIP node. 🛑
8.1.5 SIP Error Response 💅
When the SIP side throws an error, here's how the ISUP side gets the news:
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6- When a PSTN user wants to start a session with a SIP user, the PSTN network sends an IAM message to the gateway. 💌
- When the gateway gets that IAM, it makes an INVITE message and sends it to the right SIP node, based on called number analysis. 📞
- The SIP node flags an error by replying with a response code of 400 or greater. 🚩
- The gateway sends an ACK to confirm it got the INVITE final response. 👍
- An ISUP REL message gets generated from the SIP code, as specified in Section 8.2.6.1. 🔥
- The remote ISUP node confirms it got the REL with an RLC. 🫶
8.1.6 SIP Redirection 🦋
This is the call-forwarding plot twist 🍿 The SIP node says "wrong door, try this one," and the gateway follows along to the new address. Two SIP nodes, one call:
SIP node 1 MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------3xx+---------->| |
| |------------CPG---------->|4
5|<----------ACK------------| |
| |
| |
SIP node 2 | |
6|<--------INVITE-----------| |
7|-----------18x----------->| |
|<=========Audio===========| |
| |------------ACM---------->|8
9|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|10
| |<=========Audio==========>|
11|<----------ACK------------| |- When a PSTN user wants to start a session with a SIP user, the PSTN network sends an IAM message to the gateway. 💌
- When the gateway gets that IAM, it makes an INVITE message and sends it to the right SIP node, based on called number analysis. 📞
- The SIP node says the person being contacted is somewhere else now by sending a 3xx message. For this example, we assume the Contact URL is a valid URL that can be reached by a VoIP SIP call. 🗺️
- The gateway sends a CPG with an event indication that the call is being forwarded as soon as it gets the 3xx message. Heads up: this translation should be able to be turned off by configuration, because some ISUP nodes don't support getting CPG messages before ACM messages. ⚠️
- The gateway acknowledges the INVITE final response by sending an ACK to the SIP node. 👍
- The gateway re-sends the INVITE message to the address listed in the Contact: field of the 3xx message. 🔁
- When an event shows up that means the call has enough addressing information, the SIP node generates a provisional response of 180 or greater. 🔔
- When the gateway gets a provisional response of 180 or greater, it generates an ACM message with an event code as indicated in Section 8.2.3. ✨
- When the SIP node answers the call, it sends a 200 OK message. 🎉
- When the gateway gets the 200 OK message, it sends an ANM message towards the ISUP node. 🥳
- The gateway sends an ACK to the SIP node to acknowledge the INVITE final response. And that's a wrap on the call, periodt 💖
8.1.7 Call Canceled by ISUP 💅✨
okay bestie, this one is a total plot twist 😭 the PSTN caller hangs up before the SIP side picks up, so the gateway has to cancel the whole INVITE. here's the ladder 🦋
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
9|-----------487----------->| |
10|<----------ACK------------| |Here's the play-by-play 🎀
- a PSTN user wants to start a session with a SIP user, so the PSTN network sends an IAM message to the gateway 📞
- the gateway gets that IAM, makes an INVITE, and sends it to a suitable SIP node based on called number analysis 💌
- once the call has enough addressing info, the SIP node sends a provisional response of 180 or greater 🔔
- the gateway sees that 180-or-greater response and sends an ACM with an event code from Section 8.2.3 ✨
- if the calling party hangs up before the SIP node answers, a REL message gets generated 😬
- the gateway frees up the PSTN circuit and says it's good to reuse by sending an RLC 🫶
- if a REL shows up before the INVITE final response, the gateway sends a CANCEL toward the SIP node 🚫
- once the CANCEL arrives, the SIP node sends back a 200 response 🙆
- the remote SIP node sends "487 Call Cancelled" to wrap up the INVITE transaction 💀
- the gateway sends an ACK to the SIP node to confirm it got the INVITE final response 💖
8.2 State Machine 🧚
Quick note: REL can show up in any state. whenever that happens, the actions in section Section 8.2.7. get taken 🙈 not every transition is drawn in this diagram, so don't panic if something's missing 💜
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | IAM/7.2.1 |
| V |
| REL/7.2.7 +-------------------------+ 400+/7.2.6 |
+<----------------+ Trying |------------>|
| +-+--------+------+-------+ |
| | | | |
| | T11/ | 18x/ | 200/ |
| | 7.2.8 |7.2.3 | 7.2.4 |
| V | | |
| REL/7.2.7 +--------------+ | | 400+/7.2.6 |
|<----------| Progressing |-|------|-------------------->|
| +--+----+------+ | | |
| | | | | |
| 200/ | | 18x/ | | |
| 7.2.4 | | 7.2.3 | | |
| | V V | |
| REL/7.2.7 | +---------------+ | 400+/7.2.6 |
|<-------------|--| Alerting |-|-------------------->|
| | +--------+------+ | |
| | | | |
| | | 200/ | |
| | | 7.2.4 | |
| V V V |
| BYE/9.1 +-----------------------------+ REL/9.2 |
+<------------+ Connected +------------>+
+-----------------------------+8.2.1 Initial Address Message received 📩
okay so when an IAM comes in, the gateway SHOULD reserve the resources it needs for the IP side of the call 💪 think Digital Signal Processors (DSPs) and friends. it MAY also get things ready to connect audio going backwards, toward the caller 🎧
8.2.1.1 IAM to INVITE procedures 🎀
When an IAM shows up at a PSTN-SIP gateway, a SIP INVITE message MUST be created for sending to the SIP network 💌 this part walks through how the gateway fills in the INVITE fields using whatever's in the IAM. it's giving detail, bestie 🤓
The call setup info the gateway reads from the IAM gets mapped mainly to two URIs in the INVITE. one is the originator of the session and the other is its destination. the originator always lands in the From header (after it's converted from ISUP format using the procedure in Section 12), and the destination is almost always used for both the To header and the Request-URI ✨
Once the called party number has been read from the IAM, it SHOULD be translated into a destination tel URL, which becomes the Request-URI of the INVITE. or, a gateway MAY first try a Telephone Number Mapping (ENUM) [8] query to resolve the called party number to a URI 🔍 A few extra ISUP fields MAY also get added to the tel URL after translation, namely:
- If the gateway supports carrier-based routing (which is optional in this specification), it SHOULD check whether either the CIP (in ANSI networks) or TNS parameter is present in the IAM. If a value is there, the CIC SHOULD be pulled from that parameter and analyzed by the gateway 🧐 A
cic=field with the value of the CIC SHOULD be appended to the destination tel URL, if that fits local policy (so, as long as the CIC doesn't indicate the network that owns the gateway or some similar condition). Note that if it is created, thecic=parameter MUST be prefixed with the country code used or implied in the called party number, so CIC5062becomes, in the United States,+1-5062. For further information on thecic=tel URL field, see [21] 💅 - If the gateway supports number portability-based routing (which is optional in this specification), then the gateway will need to look at a few other fields 👀 To correctly map the FCI 'number translated' bit (which tells you an LNP dip was done in the PSTN), an
npdi=yesfield SHOULD be appended to the tel URL. If a GAP is present in the IAM, then the contents of the CPN (the Location Routing Number, or LRN) SHOULD be translated from ISUP format (as described in Section 12) and copied into anrn=field which must be appended to the tel URL. the GAP itself should be translated to ISUP format and used to fill in the primary telephone number field of the tel URL 🌈 Note that in some national numbering plans, both the LRN and the dialed number may be stored in the CPN parameter, in which case they must be separated out into different fields to be stored in the tel URL. Note that LRNs are necessarily national in scope, so they MUST NOT be preceded by a+in thern=field 🙅♀️ For further information on these tel URL fields, see [21] 🎀
In most cases, the resulting destination tel URL SHOULD be used in both the To field and the Request-URI sent by the gateway 💖 However, if the OCN parameter is present in the IAM, the To field SHOULD be constructed from the translation (from ISUP format following Section 12 of the OCN parameter, and hence the Request-URI and To field MAY be different 🦋
The construction of the From header field depends on whether a CIN parameter is present 🧩 If the CIN is not present, then the gateway SHOULD create a dummy From header field containing a SIP URI without a user portion, which only communicates the hostname of the gateway (e.g., 'sip:gw.sipcarrier.com). ) If the CIN is available, then it SHOULD be translated (following the procedure described above) into a tel URL, which should populate the From header field. Either way, local policy or requests for presentation restriction (see Section 12.1) MAY result in a different value for the From header field 🫶
8.2.2 100 received 🙌
okay so a 100 response SHOULD NOT trigger any PSTN interworking messages 🚫 its only job is to stop INVITE retransmissions, so it's kind of a background character here 🌸
8.2.3. 18x received 🎀
Okay so when a 18x provisional response shows up, first check the vibe: if no ACM has been sent yet and there's no legit and comprehensible ISUP in the body, the ISUP message SHOULD be generated using this table 💅
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing ACM (BCI = subscriber free)
181 Call is being forwarded Early ACM and CPG, event=6
182 Queued ACM (BCI = no indication)
183 Session progress message ACM (BCI = no indication)Also, if an early ACM gets sent, the call MUST enter state "Progressing" instead of state "Alerting." That's a main character move 🦋
If an ACM has already gone out and there's still no ISUP in the 18x body, the ISUP message SHOULD be generated with this one instead ✨
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing CPG, event = 1 (Alerting)
181 Call is being forwarded CPG, event = 6 (Forwarding)
182 Queued CPG, event = 2 (Progress)
183 Session progress message CPG, event = 2 (Progress)When a 180 comes in, the gateway SHOULD generate the ringback tone so the caller on the PSTN side can hear it 🔔 The one exception is if the gateway knows the network on the PSTN side is already providing ringback.
Now here's the plot twist 🙈 A gateway might get media at any time after it has sent an SDP offer in an INVITE, even before any 18x shows up. So the gateway MUST be ready to play that media to the caller on the PSTN side. If it needs to, it stops any ringback it started and plays the media instead. Also, the gateway might get SDP offers inside responses for an early media session using some SIP extension, see Section 5.5. And if a 183 arrives while the gateway is playing backwards media, then when it builds a mapping for that response and there's no encapsulated ISUP, the gateway SHOULD say in-band information is available. It can do that with the Event Information parameter of the CPG message or the Optional Backward Call Indicators parameter of the ACM 🎧
When an ACM goes out, the mandatory Backward Call Indicators parameter must be set, plus any optional parameters the gateway policy says to include. If legit and comprehensible ISUP is in the 18x response, the gateway SHOULD re-use the right parameters from that ISUP message in the body, including the value of the Backward Call Indicator parameter, when it builds the message it sends across its PSTN interface 🫶 If there's no usable encapsulated ACM, the BCI parameter SHOULD be set like this:
Message type: ACM
Backward Call Indicators
Charge indicator: 10 charge
Called party's status indicator: 01 subscriber free or
00 no indication
Called party's category indicator: 01 ordinary subscriber
End-to-end method indicator: 00 no end-to-end method
Interworking indicator: 0 no interworking
End-to-end information indicator: 0 no end-to-end info
ISDN user part indicator: 1 ISUP used all the way
Holding indicator: 0 no holding
ISDN access indicator: 0 No ISDN access
Echo control device indicator: It depends on the call
SCCP method indicator: 00 no indicationHeads up on the interworking stuff 🌸 When the ISUP Backward Call Indicator parameter's Interworking indicator field is set to 'interworking encountered', that means ISDN is talking to a network that can't offer as many services as ISDN does. So ISUP may not be able to use some of the features it normally would. Gateway vendors MAY however offer a configurable option, which service providers can use when they want extra ISUP services. With it on, the gateway will signal interworking in the BCI when there's no encapsulated ISUP, and say ISUP is not used all the way. Operators who'd rather run in that mode as a matter of policy can do so. For more on what interworking does, see Section 7.2.1.1 🍓
8.2.4. 2xx received 💖
Here's the happy one ✨
Response received Message sent by the MGC
----------------- -----------------------
200 OK ANM, ACKAfter a 200 OK comes in, the gateway MUST set up a directional media path inside the gateway, then send an ANM to the PSTN and an ACK to the SIP network 🎉
If the 200 OK shows up before the gateway has sent an ACM, a CON gets sent instead of the ANM, but only in those ISUP variants that support the CON message 🧚
When a legit and comprehensible ANM is encapsulated in the 200 OK, the gateway SHOULD re-use any relevant ISUP parameters in the ANM it sends to the PSTN 🩷
Note that gateways can sometimes get 200 OK responses to requests that aren't INVITE, like the ones used for managing provisional responses or the INFO method. The stuff in this section only applies to 200 OK responses that came back because of an INVITE. The gateway SHOULD NOT send any PSTN messages when it gets a 200 OK to a non-INVITE request it sent. Don't go sending PSTN messages for the wrong ones, bestie 🙅♀️
8.2.5. 3xx Received 🦋
When any 3xx response (a redirection) comes in, the gateway SHOULD try to reach the destination by sending one or more new call setup requests. It uses URIs found in any Contact header field(s) in the response, as the base SIP specification says it must 📬 These 3xx responses usually come from a redirect server, and you can think of them as kind of like a location register in mobile PSTN networks.
Now if a particular URI in the Contact header is best reached through the PSTN (going by the gateway's routing policies), the gateway SHOULD send a new IAM and from then on act as a normal PSTN switch, with no SIP involved. This usually happens when the URI in the Contact header is a tel URL, one the gateway can't reach locally, and there's no ENUM mapping for it 📞
Alternatively, the gateway MAY send a REL to the PSTN with a redirection indicator (23) and a diagnostic field that matches the telephone number in the URI. But if the new location is best reached using SIP (because the URI in the Contact header has no telephone number at all), the MGC SHOULD send a new INVITE with a Request-URI. It could also be a new IAM the MGC generates for the message body 💻
While the gateway is working through a long list of Contact header fields with SIP requests, it MAY send a CPG message with an event code of 6 (Forwarding) to the PSTN, to show the call is still moving along. This only works where the ISUP variant in question allows it ⏩
Redirection situations need extra care 💅 They involve special charging, because in the PSTN the caller usually pays for the first leg (to the gateway) and the callee pays for the second one (from the forwarding switch to the destination). Money stuff is serious, so be careful!
8.2.6. 4xx-6xx Received 💀
When the gateway gets a response code of 400 or higher, that means the INVITE it sent has been rejected 🙅♀️ In most cases the gateway SHOULD release its resources, send a REL to the PSTN with a cause value, and send an ACK to the SIP network.
There are a few specific situations where a gateway MAY try to fix a SIP-specific problem that a status code described, by retrying the request instead of releasing the call. Those are spelled out below 🔧
When a REL goes to the PSTN, the gateway waits for an RLC to come back, which tells it the release sequence is complete ✅
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping ✨
okay so when a REL message gets generated because of a SIP rejection response that's carrying an encapsulated REL message, the Cause Indicator (CAI) parameter in that generated REL SHOULD be set to the value of the CAI parameter from the encapsulated REL 💅. if there's no encapsulated ISUP, the mapping below between status code and cause codes are RECOMMENDED 🎀.
any SIP status codes that aren't listed below (because they're tied to SIP extensions, come from a later version of SIP than this document, or just got left out) should be mapping to cause code 31 "Normal, unspecified" 🌸. these mappings only cover responses. BUT, the BYE and CANCEL requests also tear down a dialog, and they SHOULD be mapped to 16 "Normal clearing" under most circumstances (although see Section 5.8) 🔥.
by default, the cause location tied to the CAI parameter should be encoded such that 6xx codes get the location 'user', whereas 4xx and 5xx codes get a 'network' location. the exceptions are marked below 🦋.
just like some ISDN cause codes are ISUP-specific and have no SIP action that matches them, there are also SIP status codes that should not simply be translated to ISUP. some SIP-specific action should be attempted first 🧚. check out the (+) tag note below for that 👀.
Response received Cause value in the REL
----------------- ----------------------
400 Bad Request 41 Temporary Failure
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option
unavailable
406 Not acceptable 79 Service/option not
implemented (+)
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
(w/o diagnostic)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not
implemented (+)
416 Unsupported URI Scheme 127 Interworking (+)
420 Bad extension 127 Interworking (+)
421 Extension Required 127 Interworking (+)
423 Interval Too Brief 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
481 Call/Transaction Does not Exist 41 Temporary Failure
482 Loop Detected 25 Exchange - routing error
483 Too many hops 25 Exchange - routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
487 Request Terminated --- (no mapping)
488 Not Acceptable here --- by Warning header
500 Server internal error 41 Temporary failure
501 Not implemented 79 Not implemented, unspecified
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Server time-out 102 Recovery on timer expiry
504 Version Not Supported 127 Interworking (+)
513 Message Too Large 127 Interworking (+)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable --- by Warning header(*) okay this one's a bit of a plot twist 🙈. in some cases, a SIP gateway might be able to give credentials to the SIP UAS that's rejecting an INVITE because of an authorization failure. if the gateway can authenticate itself, then obviously it SHOULD do that and proceed with the call. only if the gateway cannot authenticate itself should cause code 21 be sent 🔐.
(+) this is the big one 💀. if at all possible, a SIP gateway SHOULD respond to these protocol errors by fixing the unacceptable behavior and trying to re-originate the session 🛠️. only if that proves impossible should the SIP gateway fail the ISUP half of the call 😭.
when the Warning header shows up in a SIP 606 or 488 message, there may be specific ISDN cause code mappings that fit the Warning code 🎀. this document recommends that '31 Normal, unspecified' SHOULD by default be used for most currently assigned Warning codes. if the Warning code is about an unavailable bearer capability, then cause code '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping 💜.
8.2.7 REL Received
this one usually comes up when the user on the PSTN side hangs up before the call has been answered 📞. so the gateway aborts setting up the session. a CANCEL request MUST be issued here (a BYE isn't used, since no final response has come back from the SIP side) 🚫. the gateway can expect a 200 OK for the CANCEL, and then a 487 for the INVITE finally shows up, which the gateway ACKs in turn 🫶.
the gateway SHOULD store state information for this dialog for a certain period of time 🗂️. the reason is that a 200 final response for the INVITE that was originally sent might still arrive, even after the 200 OK for the CANCEL has been received 😳. in that situation, the gateway MUST send an ACK followed by an appropriate BYE request. no skipping this one, bestie 💅.
in SIP bridging situations, the REL message can't be encapsulated in a CANCEL message, since CANCEL can't have a message body 🙅♀️. usually, the REL message will contain a CAI value of 16 "Normal clearing" ✨. if the value is anything other than 16, the gateway MAY wish to use some other means of communicating the cause value (see Section 5.8) 🦋.
8.2.8 ISUP T11 Expires
so to keep the remote ISUP node's timer T7 from expiring, the gateway MAY keep its own supervisory timer 🕰️. ISUP calls this timer T11. T11's duration is carefully chosen so that it will always be shorter than the T7 of any node the gateway is talking to, which is honestly so smart 🧠✨.
to make it clear why T11 matters for SIP interworking, Q.764 [12] explains its use like this: "If in normal operation, a delay in the receipt of an address complete signal from the succeeding network is expected, the last common channel signaling exchange will originate and send an address complete message 15 to 20 seconds [timer (T11)] after receiving the latest address message." SIP nodes have no obligation to respond to an INVITE within 20 seconds, so SIP interworking totally qualifies as that kind of situation 🙌.
if the gateway supports this optional mechanism, then when its T11 expires, it SHOULD send an early ACM (meaning the called party status is set to "no indication") to stop the remote node's T7 from expiring (where the ISUP variant allows it) 🌈. see Section 8.2.3 for the values of the ACM parameters 📋.
if a "180 Ringing" message shows up later, it SHOULD be sent in a CPG, as shown in Section 8.2.3 📨.
see Section 8.1.3 for an example callflow that includes the expiration of T11 🎬.
9. Suspend/Resume and Hold ✨
9.1 Suspend (SUS) and Resume (RES) Messages
in ISDN networks, a user can generate a SUS (timer T2, user initiated) to unplug the terminal from the socket and plug it into another one 🔌. a RES gets sent once the terminal has been reconnected, as long as the T2 timer hasn't expired 💫. SUS is also used a lot to signal an on-hook state for a remote terminal before the timers that lead to sending a REL message go off (this is the more common case by far) 📴. while a call is suspended, no audio media gets passed end-to-end 🔇.
when a SUS is sent for a call that has a SIP leg, a gateway MAY suspend IP media transmission until a RES is received 🎧. putting the media on hold makes sure bandwidth is saved when no audio traffic needs to go out 💸.
if media suspension makes sense, then when a SUS arrives from the PSTN, the MGC MAY send an INVITE to ask that the far-end's transmission of the media stream be placed on hold ⏸️. a RES coming in from the PSTN afterwards SHOULD then trigger a re-INVITE that asks for the media stream to resume ▶️. note that the MGC may or may not choose to stop transmitting any media itself when it asks for the far end to stop sending 🤷♀️.
if the MGC that gets the SUS from the PSTN doesn't need media suspension, the SIP INFO [6] method MAY be used to send an encapsulated SUS instead of a re-INVITE 📦. careful though: the receiver of that INFO request might just be a simple SIP phone that doesn't understand ISUP, so it would take no action on this message 📱. if a possible destination for an INFO-encapsulated SUS hasn't used encapsulated ISUP in any messages it previously sent, the gateway SHOULD NOT relay the INFO method. instead it should handle the SUS and the matching RES without signaling their arrival to the SIP network 🤫.
in any case, subsequent RES messages MUST be sent using the same method that was used for the matching SUS (so if an INFO is used for a SUS, INFO should also be used for the RES that follows) 🔁. this is a must-follow rule, bestie 💖.
whether the INFO or re-INVITE mechanism is used to carry a SUS message, neither one means the originating side has to stop sending IP media 🎶. so the recipient of an encapsulated SUS message MAY therefore elect to send a re-INVITE itself, if it wants to suspend media transmission from the MGC side 🦋.
the following example uses the INVITE mechanism. note that this flow is informative, not proscriptive 📖. compliant gateways are free to implement functionally equivalent flows, as described in the paragraphs above 🧚♀️.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |how a network-initiated SUS right before call teardown gets handled is covered in Section 10.2.2 💅🌸.
9.2. Hold (re-INVITE) 🎀
okay so once a call is connected, the SIP side can send a re-INVITE to a gateway to put the call on hold 🌸 this re-INVITE carries an SDP offer that basically says "I don't want to receive media anymore" 🙈
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|<----------200------------| |
4|-----------ACK----------->| |when a gateway gets a re-INVITE like this, it SHOULD send a CPG to show the call is on hold ✨ that CPG SHOULD include a Generic Notification Indicator (or a Notification Indicator, if it's an ANSI network) with the value 'remote hold' 💅
if the SIP side changes its mind later and wants to receive media again, it SHOULD repeat the same flow with an INVITE whose SDP offer has an appropriate media destination 🦋 the Generic Notification Indicator in this case would be 'remote retrieval' (or 'remote hold released' in some variants) 🫶
one more thing: a gateway can also get a CPG with hold indicators from the PSTN 👀 to save bandwidth, the gateway SHOULD stop sending media until the call resumes, and it SHOULD send a re-INVITE to the SIP leg of the call asking the remote side to stop sending media too 💜
10. Normal Release of the Connection 👑
from a gateway's point of view, either the SIP side or the ISUP side can release a call, no matter which side started it 💁♀️ cancelling a call setup request (from either the ISUP or SIP side) is covered somewhere else in this doc, specifically in Section 8.2.7 and Section 7.2.3 respectively 📚
gateways SHOULD implement functional equivalence with the flows in this section ✨
10.1. SIP initiated release 📞
for a normal termination of the dialog (when a BYE request comes in), the gateway MUST immediately send a 200 response 💅 then it MUST release any media resources in the gateway (DSPs, TCIC locks, and so on) and send an REL with a cause code of 16 (normal call clearing) to the PSTN 🔥 the PSTN side confirms the release with an RLC message 🫶
in SIP bridging situations, the cause code of any REL encapsulated in the BYE request SHOULD be re-used in any REL that the gateway sends to the PSTN 🦋
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|410.2. ISUP initiated release 🌈
if the release was triggered by a REL coming in, the REL SHOULD be encapsulated in the BYE that the gateway sends 🎀 whether the caller or the callee hangs up first, the gateway SHOULD release any internal resources used for the call, and then it MUST confirm the circuit is ready for re-use by sending an RLC 💖
10.2.1. Caller hangs up 📱
when the caller hangs up, the SIP dialog MUST be terminated by sending a BYE request (which gets confirmed with a 200) 💫
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |10.2.2. Callee hangs up (SUS) 😤
in some PSTN scenarios, if the callee hangs up in the middle of a call, the local exchange sends a SUS instead of a REL and starts a timer (T6, since SUS is network initiated) 🕰️ when that timer expires, the REL gets sent 💀 this needs a slightly different SIP flow, so check out Section 9 for more on handling suspension 📖 it is RECOMMENDED that gateways implement functional equivalence with the following flow for this case 🧚
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| | *** T6 Expires *** |
| |<-----------REL-----------|5
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|6
7|<----------BYE------------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |11. ISUP Maintenance Messages 🛠️
ISUP has a set of messages for maintenance purposes, and they can show up during any ongoing call 👀 there are basically two kinds (not counting the continuity check): messages for blocking circuits and messages for resetting circuits 🍓
11.1. Reset messages 🔄
when an RSC comes in for a circuit the gateway is currently using for a call, the call MUST be released immediately 😱 this usually means there's a serious maintenance problem going on 💀 RSC MUST be answered with an RLC after the gateway resets the circuit 💅 group reset (GRS) messages that target a range of circuits get answered with a Circuit Group Reset ACK Message (GRA) once all the affected circuits are reset 🫶
the gateways SHOULD behave as if a REL had been received in order to release the dialog on the SIP side 📞 depending on the status of the call, a BYE or a CANCEL gets sent 🦋 see the procedures in Section 10 for the details ✨
11.2. Blocking messages 🚧
there are two kinds of blocking messages: maintenance messages or hardware-failure messages 🧐 maintenance blocking messages say the circuit is to be blocked for any future calls, but they don't touch any ongoing call, which lets circuits get gradually quiesced and taken out of service for maintenance 🌸
hardware-oriented blocking messages have to be treated like reset messages 😭 they're generally only sent when a hardware failure has happened 💔 media transmission for every call in progress on those circuits would be affected by the hardware problem, so all calls must be released immediately 🚨
BLO is always maintenance oriented, and the gateway answers it with a Blocking ACK Message (BLA) once the circuit is blocked, which needs no SIP actions at all 💜 Circuit Group Blocking (CGB) messages have a "type indicator" inside the Circuit Group Supervision Message Type Indicator, and that tells you whether the CGB is maintenance or hardware failure oriented 🔍 if the CGB comes from a hardware failure, then each call in progress in the affected range of circuits MUST be terminated immediately as if a REL had been received, following the procedures in Section 10 ⚡ CGBs MUST be answered with CGBAs 🫶
11.3. Continuity Checks 🧪
a continuity check is a test on a circuit where a tone generated at the originating switch gets reflected back by a loopback at the destination switch 🔁 ISUP has two variants: the implicit continuity check request inside an IAM (where the check happens as a precondition before call setup begins), and the explicit continuity check signalled by a Continuity Check Request (CCR) message 💁♀️ PSTN gateways in regions that support continuity checking generally SHOULD have some way of accommodating these tests (if they hope to get fielded by providers that interconnect with any major carrier) 🌈
when a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT send any corresponding SIP messages 🙅♀️ the scope of the continuity check only covers the PSTN trunks, not any IP media paths beyond the gateway 💖 CCR messages also don't designate any called party number, or any other way to figure out which SIP user agent server should be reached 🤷♀️
when an IAM with the Continuity Check Indicator flag set within the NCI parameter is received, the gateway MUST process the continuity check before sending an INVITE message (and then proceed normally with call setup) ✨ if the continuity check fails (that is, a COT with a Continuity Indicator of 'failed' is received), then an INVITE MUST NOT be sent 💀
12 Construction of Telephony URIs 🎀
okay bestie, so SIP proxy servers MAY route SIP messages on any signaling criteria network admins want 💅 but honestly the Request-URI is usually the main routing criterion 👑. The To and From headers are also super relevant when making routing decisions 🦋. SIP-ISUP mapping assumes proxies care about at least these three fields, and all three contain URIs ✨.
SIP-ISUP mapping keeps needing telephone numbers inside those URIs 📞. Sometimes the number shows up first in an ISUP message, so SS7-SIP gateways have to translate ISUP number formats into SIP URIs 🧚. Other times it's the reverse, and that's its own glow-up 💖.
The most common way SIP represents a telephone number is the tel URL [7] 🌸. When converting between formats, the tel URL MAY be the entire URI field in a SIP message, or it MAY appear as the user portion of a SIP URI 🫶. For example, a To field might look like this:
To: tel:+17208881000Or like this:
To: sip:+17208881000@level3.comWhether a gateway or endpoint builds URIs in tel or SIP format is up to local admin policy 📋. If a host portion would help the surrounding network route the call, go with the SIP format 🍓. A gateway MUST accept either tel or SIP URIs from its peers 🙌.
The '+' sign before the number in a tel URL means the digits that follow are a fully-qualified E.164 [16] number 🌍. Basically, that means a country code comes before any national area codes, exchange or city codes, or address codes 🧁. Leaving out the '+' sign MAY mean the number is only nationally significant, or that a private dialing plan is in use 🤷♀️. When there's no '+' but the telephone number sits in the user portion of the URI, the SIP URI SHOULD include the optional ;user=phone parameter 📱. For example:
To: sip:83000@sip.example.net;user=phoneNow, this part is important, so listen up 🚨. It is strongly RECOMMENDED that only internationally significant E.164 numbers get passed between SIP-T gateways, especially when those gateways sit in different regions or administrative domains 🌏. In a lot of SIP-T networks, gateways aren't in charge of end-to-end routing 🗺️. Realistically, gateways have no way of knowing whether a call will end up in a local or remote administrative domain or region, so gateways SHOULD always assume calls need an international numbering plan 💜. There's no guarantee that the recipients of SIP signaling understand the national dialing plans the call originators use 😬. If the originating gateway doesn't internationalize the signaling, far-end network elements can't work out the context the digits were dialed in 💀.
In ISUP signaling, telephone numbers show up in a shared format used by several parameters, including the CPN and CIN 📦. When the number is a calling party number, it comes with some extra info (more on that below) 🔍. For this document, we'll call this format 'ISUP format', and if that extra calling party info is there, the format gets called 'ISUP calling format' 🏷️. The format is a byte called the Nature of Address (NoA) indicator, then another byte holding the Numbering Plan Indicator (NPI) 🧩. Both of those come before a variable-length run of bytes with the digits in Binary Coded Decimal (BCD) format 🔢. In the calling party number case, the NPI byte also carries bit fields for the caller's presentation preferences and the status of any call screening checks run so far in the call 🕵️♀️.
H G F E D C B A H G F E D C B A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NoA | | | NoA |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NPI | spare | | | NPI |PrI|ScI|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| dig...| dig 1 | | dig...| dig 1 |
| ... | | ... |
| dig n | dig...| | dig n | dig...|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ISUP format ISUP calling format
ISUP numbering formatsThe NPI field is usually set to 'ISDN (Telephony) numbering plan (Recommendation E.164)' 🌈, but that doesn't mean the digits after it always include a country code 🙈. The NoA field is what tells you whether the number is national or international 🧭. When the number isn't designated as international, the NoA usually gives info specific to the national dialing plan, and from that you can usually work out how to convert the number to an international format 🪄. Heads up though: if the NPI holds a value other than 'ISDN numbering plan', the tel URL might not be suitable for carrying the address digits, and handling those calls is outside the scope of this document 🚧.
12.1 ISUP format to tel URL mapping 🦋
So, based on all that, converting ISUP format to a tel URL goes like this 💅. First, as long as the NPI field says the number uses E.164, you check the NoA 🔎. If the NoA says it's an international number, the telephone number digits SHOULD be added unmodified onto a 'tel:+' string 🌍. If the NoA has the value 'national (significant) number', then a country code MUST be prefixed to the digits before they go into a tel URL 🇺🇳. If the gateway doing this conversion connects to switches homed to several different country codes, the right country code SHOULD presumably get picked based on the originating switch or trunk group 🛤️. If the NoA has the value 'subscriber number', both a country code and any other numbering components the numbering plan needs (like area codes or city codes) MAY need to be added so the number is internationally significant 🌐. Honestly though, those procedures vary a ton from country to country, so they can't be spelled out in detail here 😭. A tel URL SHOULD only skip the '+' sign if a country or network-specific value is used for the NoA 🧃. In those cases, gateways SHOULD simply copy the provided digits into the tel URL and add a 'user=phone' parameter if a SIP URI format is being used 🫧. Any non-standard or proprietary mechanisms for passing extra call context in ISUP are outside the scope of this document 🤐.
If there's a nationally-specific parameter that carries the calling party's name (like the Generic Name Parameter in ANSI), then, as long as presentation isn't restricted, that info SHOULD be used to fill the display-name part of the From field 🎀.
If the gateway is converting ISUP calling format instead of plain ISUP format, two more things have to be considered: presentation indicators and screening indicators 🕵️. If the presentation indicators say 'presentation restricted', the gateway makes a special URI that tells the far end the caller's identity has been left out 🙈. That URI SHOULD be a SIP URI with a display-name and username of 'Anonymous', like this:
From: Anonymous <sip:anonymous@anonymous.invalid>For more on privacy in SIP, see Section 5.7 🔐.
If presentation is set to 'address unavailable', gateways should handle the IAM as if the CIN parameter was left out 🫥. Screening indicators should not be translated, since they're only meaningful end-to-end 🔄.
12.2 tel URL to ISUP format mapping 🌸
Going from tel URLs to ISUP format is way simpler 😌. If the URI is in international format, the gateway SHOULD check the leading country code 🌍. If that country code is local to the gateway (meaning the gateway has one or more trunks pointing to switches homed to that country code), the gateway SHOULD set the NoA to 'national (significant) number' and strip the country code from the URI before filling in the digits field ✂️. If the country code isn't local to the gateway, the gateway SHOULD set the NoA to 'international number' and keep the country code 🧳. Either way, the NPI MUST be set to 'ISDN numbering plan' 🧮.
If the URI isn't in international format, the gateway MAY try to treat the telephone number in the URI as if it fit its national or network-specific dialing plan 🤔. If doing that causes internal gateway errors, or the gateway doesn't support those procedures, then the gateway SHOULD respond with appropriate SIP status codes to say the URI couldn't be understood (if the URI in question is the Request-URI, that's a 484) 😵💫.
When converting from a tel URL to ISUP calling format, the procedure is the same as what's in the paragraphs above, with one extra thing: the presentation indicator SHOULD be set to 'presentation allowed' and the screening indicator to 'network provided' 💁♀️. The exception is if some service provider policy or user profile specifically disallows presentation 🙅♀️.
13 Other ISUP flavors 🌈
Other flavors of ISUP that aren't ITU-T ISUP have different parameters and more features 🧃. Some of those parameters have more possible values and give more info about the status of the call 📊.
The Circuit Query Message (CQM) and Circuit Query Response (CQR) show up in lots of ISUP variants 🔁. These messages have no SIP analog 🫤. Still, receiving a CQR can trigger state reconciliation if the originating and destination switches have gotten desynchronized 🔄. As states get reconciled, some calls might get terminated, and that can cause SIP or ISUP messages to get sent (as described in Section 10) 💫.
The message flows are where the real differences live 🦋. In ANSI [11] ISUP, the CON message MUST NOT be sent, and an ANM is sent instead (when no ACM was sent before the call was answered) 🚫. In call forwarding situations, CPGs MAY be sent before the ACM is sent 📞. SAMs MUST NOT be sent, since 'en-bloc' signaling is always used 🧱. The ANSI Exit Message (EXM) SHOULD NOT result in any SIP signaling in gateways 🙅. ANSI also uses the Circuit Reservation Message (CRM) and Circuit Reservation Acknowledgment (CRA) as part of its interworking procedures 🤝. If an MGC does receive a CRM, a CRA SHOULD be sent back (in some implementations, sending a CRA could conceivably be based on a resource reservation system) 🎟️. After a CRA is sent, the MGC SHOULD wait for a subsequent IAM and process it normally ⏳. Any further circuit reservation mechanism is outside the scope of this document 🚧.
Getting a Confusion (CFN) message is an indication of a protocol error, but corresponding SIP messages SHOULD NOT be sent when a CFN comes in 🙈. Instead, the gateway handles the CFN with ISUP-specific procedures (usually by retransmitting the packet the CFN responded to) 🔧. Only if the ISUP procedures fail repeatedly should this cause a SIP error condition (and call failure) to happen 💔.
In TTC ISUP, CPGs MAY be sent before the ACM is sent 🌷. Messages like a Charging Information Message (CHG) MAY be sent between the ACM and ANM 💸. 'En-bloc' signaling is always used, and there's no T9 timer ⏱️✨.
13.1 Guidelines for sending other ISUP messages ✨
okay so some ISUP variants send way more messages than the ones this doc covers 💅 so we're dropping some guidelines on how to transport and map those extras, bestie 🦋
From the caller to the callee, other ISUP messages SHOULD be encapsulated (see [3]) inside INFO messages, even if the INVITE transaction is still not finished. ngl this is giving "send it early, figure it out later" 🌸 SIP doesn't ensure that INFO requests arrive in order, so in adverse network conditions an egress gateway might process INFOs out of order 🙈 This isn't a big deal tho, since it's not likely to happen and the effects are negligible in most situations. The Information (INF) message and Information Response (INR) are examples of messages that should be encapsulated within an INFO. Gateway implementers might also consider building systems that wait for each INFO transaction to complete before starting a new INFO transaction 🧚
From the callee to the caller, if a message reaches a gateway before the call has been answered (aka ANM is received), it SHOULD be encapsulated in an INFO, as long as that won't be the first SIP message sent in the backwards direction. (If it IS the first one, it SHOULD be encapsulated in a provisional 1xx response instead 💖) Similarly, a message received on the originating side (probably in response to an INR) before the gateway has gotten a 200 OK should be carried within an INFO. For this to work in the forward direction, any necessary Contact or To-tag has to have shown up in a previous provisional response, or the message might not get routed to its destination 😭 So all SIP-T gateways MUST send all provisional responses with a Contact header and any necessary tags, so new requests issued before a final response has been received can be routed properly 🫶 Once the INVITE transaction is finished, INFO requests SHOULD also be used in this direction 🎀
14. Acronyms 💜
ACK Acknowledgment
ACM Address Complete Message
ANM Answer Message
ANSI American National Standards Institute
BLA Blocking ACK message
BLO Blocking Message
CGB Circuit Group Blocking Message
CGBA Circuit Group Blocking ACK Message
CHG Charging Information Message
CON Connect Message
CPG Call Progress Message
CUG Closed User Group
GRA Circuit Group Reset ACK Message
GRS Circuit Group Reset Message
HLR Home Location Register
IAM Initial Address Message
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
ITU-T International Telecommunication Union
Telecommunication Standardization Sector
MG Media Gateway
MGC Media Gateway Controller
MTP Message Transfer Part
REL Release Message
RES Resume Message
RLC Release Complete Message
RTP Real-time Transport Protocol
SCCP Signaling Connection Control Part
SG Signaling Gateway
SIP Session Initiation Protocol
SS7 Signaling System No. 7
SUS Suspend Message
TTC Telecommunication Technology Committee
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
VoIP Voice over IP15. Security Considerations 🔒✨
Okay bestie, security time, and it's giving serious drama 💀. Translating ISUP parameters into SIP headers can bring some privacy and security concerns above and beyond the ones already identified for other functions of SIP-T [9A] 🫣. Just locking down the encapsulated ISUP wouldn't be enough for someone who asked for presentation restriction, if the Calling Party Number parameter is openly mapped to the From header 🙅♀️. Section 12.2 shows how SIP Privacy [9B] should be used for this function 🎀. Also, the SIP-ISUP mapping only covers parameters that get translated into the headers and fields used to route SIP requests, so gateways reveal the minimum possible amount of information through translation 🤏🦋.
A full security analysis of ISUP is out of scope for this doc 🙈. ISUP bridging across SIP is covered more fully in [9A], but Section 7.2.1.1 talks about processing the translated ISUP values alongside any embedded ISUP in a request that arrives at a PSTN gateway 📞. Since nobody has done a full ISUP security analysis, embedded ISUP could cause real risks if it gets blindly interpreted 😬. So gateways SHOULD NOT blindly trust embedded ISUP unless the request was strongly authenticated [9A] and the sender is trusted, like another MGC that's authorized to use ISUP over SIP in bridge mode 🔐. When requests come in from arbitrary end points, gateways SHOULD filter any received ISUP 🧹. Specifically, only known-safe commands and parameters should be accepted or passed through ✨. Filtering by deleting the entries you think are dangerous doesn't work well, so don't do that 🙅♀️💅.
Mostly, the information translated from ISUP to SIP has no special security requirements 🌸. For translated parameters to be used to route requests, they should be legible to intermediaries, so end-to-end confidentiality of this data would be unnecessary and most likely detrimental 🙃. There are also lots of situations where intermediaries can legitimately overwrite the values that came from translation, so integrity over these headers isn't desirable either 🔄.
Now, some concerns come from the other direction, the mapping of SIP headers to ISUP parameters, and they're listed in the paragraphs below 👀. When end users dial numbers in the PSTN today, their selections fill in the telephone number portion of the Called Party Number parameter, plus the digit portions of the Carrier Identification Code and Transit Network Selection parameters of an ISUP IAM 📱. Similarly, the tel URL and its optional parameters in the Request-URI of a SIP request, which end users can create directly on a SIP device, map to those parameters at a gateway 🧚. But in the PSTN, policy can stop the user from dialing certain (invalid or restricted) numbers or selecting certain carrier identification codes 🚫. So gateway operators MAY wish to use corresponding policies to restrict the use of certain tel URLs or tel URL parameters when authorizing a call 🛡️.
The fields relevant to number portability, which include the LRN portion of the Generic Address Parameter and the 'M' bit of the Forward Call Indicators in ANSI ISUP, are used to route calls in the PSTN 🗺️. Since these fields are rendered as tel URL parameters in the SIP-ISUP mapping, users can set their values arbitrarily 😳. That means an end-user could change the end office a call gets routed to (though if the LRN value were chosen at random, it's more likely to stop the call from being delivered at all) 🙃. The PSTN is pretty resilient to calls misrouted because of local number portability, though 💪. In some networks, a REL message with some sort of "misrouted ported number" cause code gets sent backwards when this happens 🔙. Or the PSTN switch the call was misrouted to can forward it to the proper switch after making its own number portability query. This is an interim number portability practice that's still common in most segments of the PSTN that support portability 🔁. It's not anticipated that end users will typically set these SIP fields, and the risks of letting an adventurous or malicious user set the LRN don't seem grave, but network operators should still note them 📝. The limited degree to which SIP signaling contributes to the interworking indicators of the Forward Call Indicators and Backward Call Indicator parameters carries no foreseeable risks 🌈.
Some extra risks may come from the SIP response code to ISUP Cause Code parameter mapping 😤. SIP user agents could conceivably answer an INVITE from a gateway with any arbitrary SIP response code, so they can dictate (within the boundaries of the mappings the gateway supports) which Q.850 cause code the gateway sends in the resulting REL message 🎭. Generally speaking, the way a call gets rejected isn't likely to offer any avenue for fraud or denial of service 🙌. To the best knowledge of the authors, no cause code identified in this document would signal that a call shouldn't be billed or that the network should take critical resources offline ✅. Still, operators may want to scrutinize the set of cause codes that could be mapped from SIP response codes (listed in 7.2.6.1), to make sure no undesirable network-specific behavior can result from running a gateway with the recommended mappings 🔍. In some cases, operators MAY wish to implement gateway policies that use alternative mappings, maybe selectively based on authorization data 🎀.
If the Request-URI and the To header field of a request received at a gateway differ, Section 7.2.1.1 recommends that the To header (if it's a telephone number) should map to the Original Called Number parameter, and the Request-URI should map to the Called Party Number parameter 📬. But the user can pick a To header field value that's different from the Request-URI at the start of a request, because these two field values aren't required to be the same 🤷♀️. That basically lets a user set the ISUP Original Called Number parameter arbitrarily 😵. Any applications that rely on the Original Called Number for settlement purposes could be affected by this mapping recommendation 💸. It's anticipated that future SIP work in this space will arrive at a better general account of re-targeting SIP requests that might apply to the OCN mapping 🔮.
SIP user agents can fill in the From header of requests with whatever they like, and that has some well-understood security implications for devices that rely on the From header as an accurate representation of the originator's identity 🕵️♀️. Any gateway that plans to use the From header to populate the called party's number parameter of an ISUP IAM message should authenticate the originator of the request and make sure they're authorized to claim that calling number (or use some more secure method to figure out who the caller is) 🔑. Also, gateways, like all other SIP user agents, MUST support Digest authentication as described in [1] 🫶.
There's another kind of potential risk, related to cutting through the backwards media path before the call is answered 🎧. Several practices described in this document recommend that a gateway signal an ACM when a called user agent returns an 18x provisional response code 📣. At that point, backwards media is cut through end-to-end in the ISUP network. The called user agent could then play arbitrary audio to the caller for an indefinite period before sending a final response (a 2xx or higher response code) 😱. There are conceivable ways this could be used illegitimately by the called user agent 👿. It's also a useful feature, though, to let progress tones and announcements play backwards in the 'ACM sent' state. That way the caller won't get billed for calls that don't actually complete, even though failure conditions have to be rendered to the user as in-band audio 💖. In fact, ISUP commonly uses this backwards cut-through capability to pass tones and announcements about the status of a call when an ISUP network interworks with legacy networks that can't express Q.850 cause codes 📻.
The authors feel SIP introduces no risks with regard to backwards media that don't already exist in the Q.931-ISUP mapping 🧐. Still, gateway implementers MAY develop an optional mechanism (possibly something an operator could configure) that cuts off such 'early media' on a brief timer ⏱️. It's unlikely that more than 20 or 30 seconds of early media is necessary to convey status information about the call (see Section 7.2.6) ⭐. A more conservative approach would be to never cut through backwards media in the gateway until a 2xx final response has been received, provided the gateway has some way to prevent clipping of the initial media associated with the call ✂️🙅♀️.
Unlike a traditional PSTN phone, a SIP user agent can launch multiple simultaneous requests to reach a particular resource 📲. It would be trivial for a SIP user agent to launch 100 SIP requests at a 100 port gateway, tying up all of its ports 😭. A malicious user could also send requests to telephone numbers that are known never to answer, which would saturate these resources indefinitely and potentially without incurring any charges 💀. So gateways MAY support policies that restrict the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack 🛑💜.
16. IANA Considerations 📋
This document introduces no new considerations for IANA 🌷.
17. Acknowledgments 🫶🌈
This document lived as an Internet-Draft for four years, and it got innumerable contributions from members of the various Transport Area IETF working groups it called home (which included the MMUSIC, SIP and SIPPING WGs) 🥹. The authors would especially like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars Tovander, Al Varney and William T. Marshall for their help and feedback on this document 👑💕. The authors also want to thank ITU-T SG11 for their advice on ISUP procedures 🧚✨.
18. Normative References ✨
okay bestie, these are the must-read references, the ones the spec leans on so hard it can't function without them 🫶 the exact citations are below, every detail included
- [1] 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.
- [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
- [3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
- [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
- [5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
- [6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
- [7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
- [8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
- [9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header Field for the Session Initiation Protocol", RFC 3326, December 2002.
- [9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
- [9B] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
19. Non-Normative References 🌸
these ones are just for extra reading, the vibes are "good to know" not "you must know" 🤓
- [10] International Telecommunications Union, "Application of the ISDN user part of CCITT Signaling System No. 7 for international ISDN interconnection", ITU-T Q.767, February 1991, <http://www.itu.int>.
- [11] American National Standards Institute, "Signaling System No. 7; ISDN User Part", ANSI T1.113, January 1995, <http://www.itu.int>.
- [12] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, December 1999, <http://www.itu.int>.
- [13] International Telecommunications Union, "Abnormal conditions - Special release", ITU-T Q.118, September 1997, <http://www.itu.int>.
- [14] International Telecommunications Union, "Specifications of Signaling System No. 7 - ISDN supplementary services", ITU-T Q.737, June 1997, <http://www.itu.int>.
- [15] International Telecommunications Union, "Usage of cause location in the Digital Subscriber Signaling System No. 1 and the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998, <http://www.itu.int>.
- [16] International Telecommunications Union, "The international public telecommunications numbering plan", ITU-T E.164, May 1997, <http://www.itu.int>.
- [17] International Telecommunications Union, "Formats and codes of the ISDN User Part of Signaling System No. 7", ITU-T Q.763, December 1999, <http://www.itu.int>.
- [18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in SIP", RFC 3262, June 2002.
- [19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, October 2000.
- [20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
- [21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of Number Portability and Freephone Service", Work in Progress.
Authors' Addresses 💅
the squad behind this spec, with their contact info exactly as listed
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
URI: http://www.ericsson.com/
EMail: Gonzalo.Camarillo@Ericsson.com
Adam Roach
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
URI: sip:adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Lyndon Ong
Ciena
10480 Ridgeview Court
Cupertino, CA 95014
USA
URI: http://www.ciena.com/
EMail: lyOng@ciena.comFull Copyright Statement 🎀
this part is legal stuff, so I'm keeping the wording exactly as written so nothing gets lost in translation ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🫶
funding for the RFC Editor function is currently provided by the Internet Society ✨
that's the whole thing, bestie! 16 parts of pure protocol serotonin 🌈💖
📦 where this page comes from
- ietf: rfc3398 2002-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms