RFC 4497
Interworking between the Session Initiation Protocol (SIP) and QSIG
RFC 4497: Interworking between the Session Initiation Protocol (SIP) and QSIG 💖
Okay bestie, the title block first, because these are the facts you need before anything else ✨
- RFC number: 4497
- Title: Interworking between the Session Initiation Protocol (SIP) and QSIG
- Authors: J. Elwell (Siemens), F. Derks (NEC Philips), P. Mourot and O. Rousseau (Alcatel) 🧚
- Category: Best Current Practice (BCP: 117) 🎀
- Date: May 2006 🌸
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙈
- Published by: the Network Working Group 🦋
Status of This Memo ✨
So this doc is a Best Current Practice for the Internet Community 💅 It's basically asking for discussion and suggestions for improvements, and the memo can be distributed without limits 🌈
Copyright Notice 📜
Copyright (C) The Internet Society (2006).
Abstract 💜
Okay so this doc is all about getting SIP and QSIG to talk to each other inside corporate telecom networks, which are also called enterprise networks 📞✨
SIP is an Internet application-layer control (signalling) protocol. It creates, modifies, and terminates sessions with one or more participants, and those sessions include phone calls, like, a lot of them 💖
QSIG is a signalling protocol that does the same kind of job for circuit-switched calls, which are phone calls inside Private Integrated Services Networks (PISNs) 🎀 It's specified in a bunch of Ecma Standards and also published as ISO/IEC standards, so it's very official and very legit 👑
Table of Contents 🗂️
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Definitions .....................................................5
3.1. External Definitions .......................................5
3.2. Other definitions ..........................................5
3.2.1. Corporate Telecommunication Network (CN) ............5
3.2.2. Gateway .............................................6
3.2.3. IP Network ..........................................6
3.2.4. Media Stream ........................................6
3.2.5. Private Integrated Services Network (PISN) ..........6
3.2.6. Private Integrated Services Network Exchange
(PINX) ..............................................6
4. Acronyms ........................................................6
5. Background and Architecture .....................................7
6. Overview .......................................................10
7. General Requirements ...........................................11
8. Message Mapping Requirements ...................................12
8.1. Message Validation and Handling of Protocol Errors ........12
8.2. Call Establishment from QSIG to SIP .......................14
8.2.1. Call Establishment from QSIG to SIP Using
En Bloc Procedures .................................14
8.2.2. Call Establishment from QSIG to SIP Using
Overlap Procedures .................................16
8.3. Call Establishment from SIP to QSIG .......................20
8.3.1. Receipt of SIP INVITE Request for a New Call .......20
8.3.2. Receipt of QSIG CALL PROCEEDING Message ............21
8.3.3. Receipt of QSIG PROGRESS Message ...................22
8.3.4. Receipt of QSIG ALERTING Message ...................22
8.3.5. Inclusion of SDP Information in a SIP 18x
Provisional Response ...............................23
8.3.6. Receipt of QSIG CONNECT Message ....................24
8.3.7. Receipt of SIP PRACK Request .......................25
8.3.8. Receipt of SIP ACK Request .........................25
8.3.9. Receipt of a SIP INVITE Request for a Call
Already Being ......................................25
8.4. Call Clearing and Call Failure ............................26
8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or
RELEASE COMPLETE ...................................26
8.4.2. Receipt of a SIP BYE Request .......................29
8.4.3. Receipt of a SIP CANCEL Request ....................29
8.4.4. Receipt of a SIP 4xx-6xx Response to an
INVITE Request .....................................29
8.4.5. Gateway-Initiated Call Clearing ....................32
8.5. Request to Change Media Characteristics ...................32
9. Number Mapping .................................................32
9.1. Mapping from QSIG to SIP ..................................33
9.1.1. Using Information from the QSIG Called
Party Number Information Element ...................33
9.1.2. Using Information from the QSIG Calling
Party Number Information Element ...................33
9.1.3. Using Information from the QSIG Connected
Number Information Element .........................35
9.2. Mapping from SIP to QSIG ..................................36
9.2.1. Generating the QSIG Called Party Number
Information Element ................................36
9.2.2. Generating the QSIG Calling Party Number
Information Element ................................37
9.2.3. Generating the QSIG Connected Number
Information Element ................................38
10. Requirements for Support of Basic Services ....................39
10.1. Derivation of QSIG Bearer Capability Information
Element ..................................................39
10.2. Derivation of Media Type in SDP ..........................39
11. Security Considerations .......................................40
11.1. General ..................................................40
11.2. Calls from QSIG to Invalid or Restricted Numbers .........40
11.3. Abuse of SIP Response Code ...............................41
11.4. Use of the To Header URI .................................41
11.5. Use of the From Header URI ...............................41
11.6. Abuse of Early Media .....................................42
11.7. Protection from Denial-of-Service Attacks ................42
12. Acknowledgements ..............................................43
13. Normative References ..........................................43
Appendix A. Example Message Sequences .............................451. Introduction ✨
Okay so this section is the main pitch 💅 It's about signalling interworking between QSIG and SIP, so basic services can work across a corporate telecom network (CN), which is also called an enterprise network 🎀
QSIG is the signalling protocol that runs between Private Integrated Services eXchanges (PINXs) inside a Private Integrated Services Network (PISN) 🧚 A PISN gives its users circuit-switched basic services and supplementary services. QSIG is specified in Ecma Standards, and the ones that matter most here are [2] (call control for basic services), [3] (the generic functional protocol for supplementary services), and a bunch of standards for individual supplementary services. Iconic, honestly 👑
NOTE: The name QSIG comes from the fact that it's used for signalling at the Q reference point. The Q reference point is the demarcation point between two PINXs 🦋
SIP is an application-layer protocol for setting up, ending, and changing multimedia sessions 💖 It's typically carried over IP [15], [16]. Phone calls count as a type of multimedia session where only audio gets exchanged, so yes, SIP is defined in [10] and it's giving everything 📞
Okay here's the real tea 🫶 Telephony inside corporate networks is moving from circuit-switched technology to Internet technology, and the two are going to coexist in lots of networks for a while, maybe several years. So we need to be able to set up, change, and end sessions where one person is on the SIP side and the other is on the QSIG side. These calls are handled by gateways that do the SIP-to-QSIG interworking 🌸
This document specifies SIP-QSIG signalling interworking for basic services that give a bi-directional transfer capability for speech, DTMF, facsimile, and modem media, between a PISN using QSIG and a corporate IP network using SIP 💜 Other parts of interworking, like the use of RTP and SDP, depend on the media type and are outside the scope of this spec 🙈
Call-related and call-independent signalling for supplementary services is also outside the scope here. Still, support for some of them (like call transfer and call diversion) could be future work 🔮
Interworking between QSIG and SIP means a call that starts with a PISN user can end at a corporate IP network user, and a call that starts with a corporate IP network user can end at a PISN user 📲✨
Interworking between a PISN using QSIG and a public IP network using SIP is outside the scope of this specification 🙃 That said, the functionality here is in principle applicable to that kind of scenario when it's deployed together with other relevant functionality, like number translation, security functions, and so on 🌈
This specification applies to any interworking unit that can act as a gateway between a PISN using QSIG and a corporate IP network using SIP 🎀
2. Terminology 💅
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant SIP implementations. Those words are the vocab for how strict each rule is, so read them carefully 🧐🫶
3. Definitions 🌸
For the purposes of this specification, the following definitions apply.
3.1. External Definitions 🦋
The definitions in [2] and [10] apply as appropriate.
3.2. Other definitions 💜
3.2.1. Corporate Telecommunication Network (CN) 🏢
Sets of privately-owned or carrier-provided equipment that are located at geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of users. Basically, a bunch of gear spread out over different places that works together as one telecom system for a specific group of people 💖
NOTE: A CN can comprise a PISN, a private IP network (intranet), or a combination of the two. So it can be one or the other, or both mixed together 🎀
3.2.2. Gateway 🌉
An entity that performs interworking between a PISN using QSIG and an IP network using SIP. This is the translator in the middle, and it's the one doing all the heavy lifting between the two worlds ✨
3.2.3. IP Network 🌐
A network (unless otherwise stated, a corporate network) offering connectionless packet-mode services based on the Internet Protocol (IP) as the network-layer protocol. So, a network that moves packets around using IP, by default inside a company 🧚
3.2.4. Media Stream 🎵
Audio or other user information transmitted in UDP packets, typically containing RTP, in a single direction between the gateway and a peer entity participating in a session established using SIP. Think of it as one one-way lane of media 🛣️
NOTE: Normally a SIP session establishes a pair of media streams, one in each direction. So, usually, you get two lanes, one going each way 👯♀️
3.2.5. Private Integrated Services Network (PISN) 🏛️
A CN or part of a CN that employs circuit-switched technology. So a PISN is the circuit-switched side of a corporate network 📞
3.2.6. Private Integrated Services Network Exchange (PINX) 🔁
A PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in accordance with [2]. So it's the box that does the switching and call handling, and it speaks QSIG while it does it 👑
4. Acronyms ✨
okay bestie, here's the acronym cheat sheet 💅 you'll see these all over the place, so save it 🎀
DNS Domain Name Service
IP Internet Protocol
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
RTP Real-time Transport Protocol
SCTP Stream Control Transmission Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
TU Transaction User
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol5. Background and Architecture 🌸
okay so picture the 1980s 📼 corporate phone systems were getting really into digital tech, kind of like ISDN 💖 Digital circuit switches, which people call Private Branch eXchanges (PBX) or, more formally, Private Integrated services Network eXchanges (PINX), got linked together with digital transmission systems to form Private Integrated Services Networks (PISN) ✨ These digital links carry voice or other payload in fixed-rate channels, typically 64 Kbit/s, and put the signalling in a separate channel 🦋 There's this technique called common channel signalling, where one signalling channel can be in charge of a bunch of payload channels, aka bearer channels 👑 A typical setup is a point-to-point facility at T1 or E1 rate, giving you a 64 Kbit/s signalling channel plus 23 or 30 bearer channels, respectively 🍓 Other setups are possible and have been deployed too, like using multiple transmission facilities for one signalling channel and its logically associated bearer channels. Also, there were setups with bearer channels under 64 Kbit/s, where voice needs codecs that do compression 🧚
Now, QSIG is the internationally-standardized, message-based signalling protocol for networks like the ones above 🔥 It runs in a signalling channel between two PINXs and controls calls on a number of logically associated bearer channels between those same two PINXs. The signalling channel plus its associated bearer channels are collectively called an inter-PINX link 💜 QSIG doesn't care what kind of transmission capabilities the signalling and bearer channels run over, and it doesn't care about the transport protocol used to carry QSIG messages reliably over the signalling channel either. Iconic independence 🙈
QSIG gives you a way to set up and clear calls that start and end on different PINXs 📞 A call can go over a single inter-PINX link between the originating and terminating PINX, or over several inter-PINX links in series, with switching at middle PINXs called transit PINXs 🌈 A call can also start or end in another network, and in that case it enters or leaves the PISN through a gateway PINX 🛸 Parties are identified by numbers, following either [17] or a private numbering plan. The basic call capability is specified in [2]. On top of that, QSIG specifies a bunch of extra capabilities for supplementary services in PISNs 💅
Lowkey, corporate telecom networks have started using IP in all sorts of ways 🌐 One way is migrating part of the network to IP using SIP 🎀 For example, a new branch office might have a SIP proxy and SIP endpoints instead of a PINX. Or SIP equipment might replace an existing PINX or PINXs 💖 The new SIP environment needs to interwork with the QSIG-based PISN so calls that start in one environment and end in the other still work. That interworking happens through a gateway 🫶
Interworking between QSIG and SIP at gateways can also be used where a SIP network connects different parts of a PISN, so calls can go between those parts ✨ A call can enter the SIP network at one gateway and leave at another. Each gateway would behave in accordance with this specification 🦋
Another way to connect two parts of a PISN would be to encapsulate QSIG signalling in SIP messages for calls between those two parts. That's outside the scope of this specification, but it could be future work 🧚 ngl this one's a whole new era 👑
Okay, so this document specifies the signalling protocol interworking aspects of a gateway between a PISN using QSIG signalling and an IP network using SIP signalling 💜 The gateway looks like a PINX to other PINXs in the PISN, and like a SIP endpoint to other SIP entities in the IP network 🌸 The environment is shown in Figure 1 ✨
+------+ IP network PISN
| |
|SIP | +------+
|Proxy | /| |
| | / |PINX |
+---+--+ *-----------+ / | |
| | | +-----+/ +------+
| | | | |
| | | |PINX |
---+-----+-------+--------+ Gateway +--------| |
| | | | | |\
| | | | +-----+ \
| | | | \ +------+
| | | | \| |
+--+---+ +--+---+ *-----------+ |PINX |
|SIP | |SIP | | |
|End- | |End- | +------+
|point | |point |
+------+ +------+
Figure 1: EnvironmentIn addition to the signalling interworking functionality specified here, it's assumed the gateway also includes the following functionality 🍓
- one or more physical interfaces on the PISN side supporting one or more inter-PINX links, each link providing one or more constant bit rate channels for media streams and a reliable layer 2 connection (e.g., over a fixed rate physical channel) for transporting QSIG signalling messages; and
- one or more physical interfaces on the IP network side supporting, through layer 1 and layer 2 protocols, IP as the network layer protocol and UDP [6] and TCP [5] as transport layer protocols, these being used for the transport of SIP signalling messages and, in the case of UDP, also for media streams;
- optionally the support of TLS [7] and/or SCTP [9] as additional transport layer protocols on the IP network side, these being used for the transport of SIP signalling messages; and
- a means of transferring media streams in each direction between the PISN and the IP network, including as a minimum packetization of media streams sent to the IP network and de-packetization of media streams received from the IP network.
NOTE: [10] mandates support for both UDP and TCP for the transport of SIP messages and allows optional support for TLS and/or SCTP for this same purpose. 🙈
The protocol model relevant to the signalling interworking functionality of a gateway is shown in Figure 2 🎀
+---------------------------------------------------------+
| Interworking function |
| |
+-----------------------+---------+-----------------------+
| | | |
| SIP | | |
| | | |
+-----------------------+ | |
| | | |
| UDP/TCP/TLS/SCTP | | QSIG |
| | | |
+-----------------------+ | |
| | | |
| IP | | |
| | | |
+-----------------------+ +-----------------------+
| IP network | | PISN |
| lower layers | | lower layers |
| | | |
+-----------------------+ +-----------------------+
Figure 2: Protocol modelIn Figure 2, the SIP box represents SIP syntax and encoding, the SIP transport layer, and the SIP transaction layer 💜 The Interworking function includes SIP Transaction User (TU) functionality 🌈
6. Overview 🦋
okay here's the big picture 🔥 The gateway maps received QSIG messages, where appropriate, to SIP messages and vice versa, and it keeps an association between a QSIG call and a SIP dialog 💖
So a call from QSIG to SIP kicks off when a QSIG SETUP message shows up at the gateway ✨ That SETUP message starts QSIG call establishment, and an initial response message (like CALL PROCEEDING) wraps up negotiation of the bearer channel for that call 👑 Then the gateway sends a SIP INVITE request, having translated the QSIG called party number into a URI that's suitable for the Request-URI 🎀 The SIP INVITE request and the resulting SIP dialog, if it's successfully set up, are associated with the QSIG call 💅 The SIP 2xx response to the INVITE gets mapped to a QSIG CONNECT message, which signals that the call has been answered 🫶 During establishment, the media streams set up by SIP and SDP get connected to the bearer channel 🧚
Now the reverse: a call from SIP to QSIG starts when a SIP INVITE request arrives at the gateway 🍓 The gateway sends a QSIG SETUP message to start QSIG call establishment, having translated the SIP Request-URI into a number that works as the QSIG called party number 🌸 The resulting QSIG call is associated with the SIP INVITE request and with the eventual SIP dialog. When an initial QSIG response message comes back, negotiation of the bearer channel to be used is complete, and the media streams set up by SIP and SDP can be connected to that bearer channel 🦋 Finally, the QSIG CONNECT message gets mapped to a SIP 200 OK response to the INVITE request 🌈
Appendix A has examples of typical message sequences that can come up 📖✨
7. General Requirements 🎀
Okay so, to count as a conforming gateway, the gateway SHALL support QSIG in accordance with [2] as a gateway, and it SHALL support SIP in accordance with [10] as a UA. Specifically, it SHALL support SIP syntax and encoding, the SIP transport layer, and the SIP transaction layer in accordance with [10]. On top of that, it SHALL support SIP TU behaviour for a UA in accordance with [10], except where stated otherwise in Sections 8, 9, and 10 of this specification. 💅
NOTE: [10] mandates that a SIP entity support both UDP and TCP as transport layer protocols for SIP messages. Other transport layer protocols can also be supported. 🧚
The gateway SHALL also support SIP reliable provisional responses in accordance with [11] as a UA. ✨
NOTE: [11] makes provision for recovering from loss of provisional responses (other than 100) to INVITE requests when using unreliable transport services in the IP network. This is important for ensuring delivery of responses that map to essential QSIG messages. 🔥
The gateway SHALL support SDP in accordance with [8] and its use in accordance with the offer/answer model in [12]. 🌸
Section 9 also specifies optional use of the Privacy header in accordance with [13] and the P-Asserted-Identity header in accordance with [14]. 🦋
The gateway SHALL support calls from QSIG to SIP and calls from SIP to QSIG. Both directions, no exceptions, periodt. 👑
SIP methods not defined in [10] or [11] are outside the scope of this specification, but they could be the subject of other specifications for interworking with QSIG, e.g., for interworking in support of supplementary services. Future-proofing is iconic 🌈
As a result of DNS lookup by the gateway in order to determine where to send a SIP INVITE request, a number of candidate destinations can be attempted in sequence. How the gateway handles this is outside the scope of this specification. Still, any behaviour specified in this document on receipt of a SIP 4xx or 5xx final response to an INVITE request SHOULD apply only when there are no more candidate destinations to try, or when overlap signalling applies in the SIP network (see 8.2.2.2). 🙈
8. Message Mapping Requirements 🍓
8.1. Message Validation and Handling of Protocol Errors 💀
The gateway SHALL validate received QSIG messages in accordance with the requirements of [2], and it SHALL act in accordance with [2] on detection of a QSIG protocol error. The requirements of this section for acting on a received QSIG message apply only to a received QSIG message that has been successfully validated and that satisfies one of the following conditions:
- the QSIG message is a SETUP message and indicates a destination in the IP network and a bearer capability for which the gateway is able to provide interworking; or
- the QSIG message is a message other than SETUP and contains a call reference that identifies an existing call for which the gateway is providing interworking between QSIG and SIP.
The processing of any valid QSIG message that does not satisfy any of these conditions is outside the scope of this specification. Also, the processing of any QSIG message relating to call-independent signalling connections or connectionless transport, as specified in [3], is outside the scope of this specification. 🙃
If segmented QSIG messages are received, the gateway SHALL await receipt of all segments of a message, and it SHALL validate and act on the complete reassembled message. Patience is a virtue 🫶
The gateway SHALL validate received SIP messages (requests and responses) in accordance with the requirements of [10], and it SHALL act in accordance with [10] on detection of a SIP protocol error.
Requirements of this section for acting on a received SIP message apply only to a received message that has been successfully validated and that satisfies one of the following conditions:
- the SIP message is an INVITE request that contains no tag parameter in the
Toheader field, does not match an ongoing transaction (i.e., is not a merged request; see Section 8.2.2.2 of [10]), and indicates a destination in the PISN for which the gateway is able to provide interworking; or - the SIP message is a request that relates to an existing dialog representing a call for which the gateway is providing interworking between QSIG and SIP; or
- the SIP message is a CANCEL request that relates to a received INVITE request for which the gateway is providing interworking with QSIG, but for which the only response sent is informational (1xx), no dialog having been confirmed; or
- the SIP message is a response to a request sent by the gateway in accordance with this section.
The processing of any valid SIP message that does not satisfy any of these conditions is outside the scope of this specification.
NOTE: These rules mean that an error detected in a received message will not be propagated to the other side of the gateway. However, there can be an indirect impact on the other side of the gateway, e.g., the initiation of call clearing procedures. 😬
The gateway SHALL run QSIG protocol timers as specified in [2], and it SHALL act in accordance with [2] if a QSIG protocol timer expires. Any other action on expiry of a QSIG protocol timer is outside the scope of this specification, except that if it results in the clearing of the QSIG call, the gateway SHALL also clear the SIP call in accordance with Section 8.4.5.
The gateway SHALL run SIP protocol timers as specified in [10], and it SHALL act in accordance with [10] if a SIP protocol timer expires. Any other action on expiry of a SIP protocol timer is outside the scope of this specification, except that if it results in the clearing of the SIP call, the gateway SHALL also clear the QSIG call in accordance with Section 8.4.5. ⏰
8.2. Call Establishment from QSIG to SIP 📞
8.2.1. Call Establishment from QSIG to SIP Using En Bloc Procedures 🧩
The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending Complete information element, or when the gateway receives a QSIG SETUP message and is able to determine that the number in the Called party number information element is complete.
NOTE: In the absence of a Sending Complete information element, the means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or use of inter-digit timer expiry. 🤓
8.2.1.1. Receipt of QSIG SETUP Message 📨
On receipt of a QSIG SETUP message containing a number that the gateway determines to be complete in the Called party number information element, or containing a Sending complete information element and a number that could potentially be complete, the gateway SHALL map the QSIG SETUP message to a SIP INVITE request. The gateway SHALL also send a QSIG CALL PROCEEDING message.
The gateway SHALL generate the SIP Request-URI, To, and From fields in the SIP INVITE request in accordance with Section 9. The gateway SHALL include in the INVITE request a Supported header containing option tag 100rel, to indicate support for [11]. 🎯
The gateway SHALL include SDP offer information in the SIP INVITE request as described in Section 10. It SHOULD also connect the incoming media stream to the user information channel of the inter-PINX link, so the caller can hear in-band tones or announcements and speech clipping on answer is prevented. 🎧 Because of forking, the gateway may receive more than one media stream, in which case it SHOULD select one (e.g., the first received). If the gateway is able to correlate an unselected media stream with a particular early dialog established using a reliable provisional response, it MAY use the UPDATE method [19] to stop that stream, and then use the UPDATE method to start that stream again if a 2xx response is received on that dialog. 🔄
On receipt of a QSIG SETUP message containing a Sending complete information element and a number that the gateway determines to be incomplete in the Called party number information element, the gateway SHALL initiate QSIG call clearing procedures using cause value 28, "invalid number format (address incomplete)". 🚫
If information in the QSIG SETUP message is unsuitable for generating any of the mandatory fields in a SIP INVITE request (e.g., if a Request-URI cannot be derived from the QSIG Called party number information element) or for generating SDP information, the gateway SHALL NOT issue a SIP INVITE request, and it SHALL initiate QSIG call clearing procedures in accordance with [2]. 🙅♀️
8.2.1.2. Receipt of SIP 100 (Trying) Response to an INVITE Request ⏳
A SIP 100 response SHALL NOT trigger any QSIG messages. It only serves the purpose of suppressing INVITE request retransmissions. Quiet, but useful 🤫
8.2.1.3. Receipt of SIP 18x provisional response to an INVITE request 🔔
The gateway SHALL map a received SIP 18x response to an INVITE request to a QSIG PROGRESS or ALERTING message based on the following conditions.
- If a SIP 180 response is received and no QSIG ALERTING message has been sent, the gateway SHALL generate a QSIG ALERTING message. The gateway MAY supply ring-back tone on the user information channel of the inter-PINX link, in which case the gateway SHALL include progress description number 8 in the QSIG ALERTING message. Otherwise, the gateway SHALL NOT include progress description number 8 in the QSIG ALERTING message unless the gateway is aware that in-band information (e.g., ring-back tone) is being transmitted.
- If a SIP 181/182/183 response is received, no QSIG ALERTING message has been sent, and no message containing progress description number 1 has been sent, the gateway SHALL generate a QSIG PROGRESS message containing progress description number 1.
NOTE: This will ensure that QSIG timer T310 is stopped if running at the Originating PINX. ⏱️
In all other scenarios, the gateway SHALL NOT map the SIP 18x response to a QSIG message.
If the SIP 18x response contains a Require header with option tag 100rel, the gateway SHALL send back a SIP PRACK request in accordance with [11]. 🙌
8.2.1.4. Receipt of SIP 2xx Response to an INVITE Request 🥳
If the gateway receives a SIP 2xx response as the first SIP 2xx response to a SIP INVITE request, the gateway SHALL map the SIP 2xx response to a QSIG CONNECT message. The gateway SHALL also send a SIP ACK request to acknowledge the 2xx response. The gateway SHALL NOT include any SDP information in the SIP ACK request. If the gateway receives further 2xx responses, it SHALL respond to each in accordance with [10], SHOULD issue a BYE request for each, and SHALL NOT generate any further QSIG messages. 🎉
Media streams will normally have been established in the IP network in each direction. If so, the gateway SHALL connect the media streams to the corresponding user-information channel on the inter-PINX link if it has not already done so, and it SHALL stop any local ring-back tone. 🎶
If the SIP 2xx response is received in response to the SIP PRACK request, the gateway SHALL NOT map this message to any QSIG message.
NOTE: A SIP 2xx response to the INVITE request can be received later on a different dialog as a result of a forking proxy. 🍴
8.2.1.5. Receipt of SIP 3xx Response to an INVITE Request ✨
Okay bestie, when a SIP 3xx response comes back for an INVITE request 🦋, the gateway SHALL act in accordance with [10].
NOTE: This will normally result in sending a new SIP INVITE request. 💅
Unless the gateway supports the QSIG Call Diversion Supplementary Service, no QSIG message SHALL be sent. The definition of Call Diversion Supplementary Service for QSIG to SIP interworking is beyond the scope of this specification. 🌸
8.2.2. Call Establishment from QSIG to SIP Using Overlap Procedures 🎀
SIP uses en bloc signalling, and it is strongly RECOMMENDED to avoid using overlap signalling in a SIP network. 💖 A SIP/QSIG gateway dealing with overlap signalling SHOULD perform a conversion from overlap to en bloc signalling method using one or more of the following mechanisms:
- timers;
- numbering plan information;
- the presence of a Sending complete information element in a received QSIG INFORMATION message.
If the gateway performs a conversion from overlap to en bloc signalling in the SIP network, then the procedures defined in Section 8.2.2.1 SHALL apply. ✨
However, for some applications it might be impossible to avoid using overlap signalling in the SIP network. 😭 In this case, the procedures defined in Section 8.2.2.2 SHALL apply.
8.2.2.1. En Bloc Signalling in SIP Network 🧚
8.2.2.1.1. Receipt of QSIG SETUP Message 🍓
On receipt of a QSIG SETUP message containing no Sending complete information element and a number in the Called party number information element that the gateway cannot determine to be complete, the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start QSIG timer T302, and await further number digits. 🔥
8.2.2.1.2. Receipt of QSIG INFORMATION Message 💜
On receipt of each QSIG INFORMATION message containing no Sending complete information element and containing a number that the gateway cannot determine to be complete, QSIG timer T302 SHALL be restarted. When QSIG timer T302 expires or a QSIG INFORMATION message containing a Sending complete information element is received, the gateway SHALL send a SIP INVITE request as described in Section 8.2.1.1. The Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages. The gateway SHALL also send a QSIG CALL PROCEEDING message. 👑
8.2.2.1.3. Receipt of SIP Responses to INVITE Requests 🌈
SIP responses to INVITE requests SHALL be mapped as described in 8.2.1. 🫶
8.2.2.2. Overlap Signalling in SIP Network 🌸
The procedures below for using overlap signalling in the SIP network are in accordance with the principles described in [18] for using overlap sending when interworking with ISDN User Part (ISUP). In [18], there is discussion of some potential problems arising from the use of overlap sending in the SIP network. These potential problems are applicable also in the context of QSIG-SIP interworking and can be avoided if overlap sending in the QSIG network is terminated at the gateway, in accordance with Section 8.2.2.1. Honestly, these procedures are only for when it's not feasible to use the procedures of Section 8.2.2.1. 🙈
8.2.2.2.1. Receipt of QSIG SETUP Message 🦋
On receipt of a QSIG SETUP message containing no Sending complete information element and a number in the Called party number information element that the gateway cannot determine to be complete, the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and start QSIG timer T302. If the QSIG SETUP message contains the minimum number of digits required to route the call in the IP network, the gateway SHALL send a SIP INVITE request as specified in Section 8.2.1.1. Otherwise, the gateway SHALL wait for more digits to arrive in QSIG INFORMATION messages. 💅
8.2.2.2.2. Receipt of QSIG INFORMATION Message 🎀
On receipt of a QSIG INFORMATION message, the gateway SHALL handle the QSIG timer T302 in accordance with [2].
NOTE: [2] requires the QSIG timer to be stopped if the INFORMATION message contains a Sending complete information element or to be restarted otherwise.
Further behaviour of the gateway SHALL depend on whether or not it has already sent a SIP INVITE request. If the gateway has not sent a SIP INVITE request and it now has the minimum number of digits required to route the call, it SHALL send a SIP INVITE request as specified in Section 8.2.2.1.2. If the gateway still does not have the minimum number of digits required, it SHALL wait for more QSIG INFORMATION messages to arrive. 🧚
If the gateway has already sent one or more SIP INVITE requests, whether or not final responses to those requests have been received, it SHALL send a new SIP INVITE request in accordance with Section 3.2 of [18]. The updated Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages.
NOTE: [18] requires the new request to have the same Call-ID and the same From header (including tag) as in the previous INVITE request. [18] recommends that the CSeq header should contain a value higher than that in the previous INVITE request. 🔥
8.2.2.2.3. Receipt of SIP 100 (Trying) Response to an INVITE Request 💖
The requirements of Section 8.2.1.2 SHALL apply. 🫶
8.2.2.2.4. Receipt of SIP 18x Provisional Response to an INVITE Request ✨
The requirements of Section 8.2.1.3 SHALL apply. 💜
8.2.2.2.5. Receipt of SIP 2xx Response to an INVITE Request 👑
The requirements of Section 8.2.1.4 SHALL apply. In addition, the gateway SHALL send a SIP CANCEL request in accordance with Section 3.4 of [18] to cancel any SIP INVITE transactions for which no final response has been received. 🌈
8.2.2.2.6. Receipt of SIP 3xx Response to an INVITE Request 🍓
The requirements of Section 8.2.1.5 SHALL apply. 🦋
8.2.2.2.7. Receipt of a SIP 4xx, 5xx, or 6xx Final Response to an INVITE Request 😭
On receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE request, the gateway SHALL send back a SIP ACK request. Unless the gateway is able to retry the INVITE request to avoid the problem (e.g., by supplying authentication in the case of a 401 or 407 response), the gateway SHALL also send a QSIG DISCONNECT message (8.4.4) if no further QSIG INFORMATION messages are expected and final responses have been received to all transmitted SIP INVITE requests. 💅
NOTE: Further QSIG INFORMATION messages will not be expected after QSIG timer T302 has expired or after a Sending complete information element has been received.
In all other cases, the receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE request SHALL NOT trigger the sending of any QSIG message.
NOTE: If further QSIG INFORMATION messages arrive, these will result in further SIP INVITE requests being sent, one of which might result in successful call establishment. For example, initial INVITE requests might produce 484 (Address Incomplete) or 404 (Not Found) responses because the Request-URIs derived from incomplete numbers cannot be routed, yet a subsequent INVITE request with a routable Request-URI might produce a 2xx final response or a more meaningful 4xx, 5xx, or 6xx final response. 🧚
8.2.2.2.8. Receipt of Multiple SIP Responses to an INVITE Request 🎀
Section 3.3 of [18] applies. 🌸
8.2.2.2.9. Cancelling Pending SIP INVITE Transactions 🙈
As stated in Section 3.4 of [18], when a gateway sends a new SIP INVITE request containing new digits, it SHOULD NOT send a SIP CANCEL request to cancel a previous SIP INVITE transaction that has not had a final response. This SIP CANCEL request could arrive at an egress gateway before the new SIP INVITE request and trigger premature call clearing. 💀
NOTE: Previous SIP INVITE transactions can be expected to result in SIP 4xx class responses, which terminate the transaction. In Section 8.2.2.2.5, there is provision for cancelling any transactions still in progress after a SIP 2xx response has been received. 🫶
8.2.2.2.10. QSIG Timer T302 Expiry ⭐
If QSIG timer T302 expires and the gateway has received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL send a QSIG DISCONNECT message. If T302 expires and the gateway has not received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL ignore any further QSIG INFORMATION messages but SHALL NOT send a QSIG DISCONNECT message at this stage. 😭
NOTE: A QSIG DISCONNECT request will be sent when all outstanding SIP INVITE requests have received 4xx, 5xx, or 6xx responses. 🔥
8.3. Call Establishment from SIP to QSIG 🌈
8.3.1. Receipt of SIP INVITE Request for a New Call ✨
okay so when a SIP INVITE request for a brand new call shows up 📞, if a suitable channel is free on the inter-PINX link, the gateway SHALL generate a QSIG SETUP message from that INVITE. this is the main event bestie 💅 The gateway SHALL generate the Called party number and Calling party number information elements in accordance with Section 9 and SHALL generate the Bearer capability information element in accordance with Section 10. if the gateway can tell that the number in the Called party number is complete, it MAY include the Sending complete information element 🎀
NOTE: How the gateway decides the number is complete is an implementation matter 🙈 It can involve knowing the numbering plan and/or using the inter-digit timer.
The gateway SHOULD send a SIP 100 (Trying) response 🫶
if the INVITE doesn't have what we need for the mandatory info elements in a QSIG SETUP message (like if a QSIG Called party number can't be derived from the SIP Request-URI field), or if there's no suitable channel on the inter-PINX link, the gateway SHALL NOT issue a QSIG SETUP message and SHALL send a SIP 4xx, 5xx, or 6xx response. if no suitable channel is available, the gateway should use response code 503 (Service Unavailable) 💀
if the SIP INVITE does not contain SDP information and does not contain either a Required header or a Supported header with option tag 100rel, the gateway SHOULD still proceed as above. an implementation can instead send a SIP 488 (Not Acceptable Here) response, and if it does, it SHALL NOT issue a QSIG SETUP message 🍓
NOTE: The absence of SDP offer information in the SIP INVITE request means that the gateway might need to send SDP offer information in a provisional response and receive SDP answer information in a SIP PRACK request (in accordance with [11]) in order to make sure tones and announcements from the PISN get transmitted. SDP offer information cannot be sent in an unreliable provisional response, because SDP answer information would need to come back in a SIP PRACK request. The recommendation above to still proceed with call establishment in this situation is about maximising the chances of a successful call. However, if important in-band information is likely to be denied in this situation, a gateway can choose not to proceed. 🧚
NOTE: If SDP offer information is present in the INVITE request, issuing a QSIG SETUP message doesn't depend on having a Required header or a Supported header with option tag 100rel. ✨
on receipt of a SIP INVITE request for a call that's already been established from SIP to QSIG, the procedures of 8.3.9 SHALL apply. main character energy 👑
8.3.2. Receipt of QSIG CALL PROCEEDING Message
ngl this one is simple 💅 The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any SIP message being sent.
8.3.3. Receipt of QSIG PROGRESS Message
okay so a QSIG PROGRESS message can show up when there's interworking on the remote side of the PISN, or when the PISN can't complete the call and plays an in-band tone or announcement 🎶 In that second case, a Cause information element comes along in the QSIG PROGRESS message.
The gateway SHALL map a received QSIG PROGRESS message to a SIP 183 (Session Progress) response to the INVITE request. if the SIP INVITE request had either a Require header or a Supported header with option tag 100rel, the gateway SHALL include a Require header with option tag 100rel in the SIP 183 response 🦋
NOTE: In accordance with [11], putting option tag 100rel in a provisional response tells the UAC to acknowledge it by sending a PRACK request. [11] also covers how to repeat a provisional response with option tag 100rel if no PRACK comes back. 🌸
if the QSIG PROGRESS message had a Progress indicator information element with Progress description number 1 or 8, the gateway SHALL connect the media streams to the matching user information channel of the inter-PINX link (if it hasn't done that already), as long as SDP answer information is in the SIP response sent to the INVITE request or has already been sent or received. Including SDP offer or answer information in the 183 provisional response SHALL be in accordance with Section 8.3.5. 🎀
if the QSIG PROGRESS message comes in with a Cause information element, the gateway SHALL either wait until the tone or announcement is finished (or has played for long enough) before starting call clearing, or wait for a SIP CANCEL request. if call clearing does start, the cause value in the QSIG PROGRESS message SHALL be used to work out the response to the SIP INVITE request in accordance with Table 1 🔥
8.3.4. Receipt of QSIG ALERTING Message
The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing) response to the INVITE request. if the SIP INVITE request had either a Require header or a Supported header with option tag 100rel, the gateway SHALL include a Require header with option tag 100rel in the SIP 180 response 🔔
NOTE: In accordance with [11], putting option tag 100rel in a provisional response tells the UAC to acknowledge it by sending a PRACK request. [11] also covers how to repeat a provisional response with option tag 100rel if no PRACK comes back. 🌸
if the QSIG ALERTING message had a Progress indicator information element with Progress description number 1 or 8, the gateway SHALL connect the media streams to the matching user information channel of the inter-PINX link (if it hasn't done that already), as long as SDP answer information is in the transmitted SIP response or has already been sent or received. Including SDP offer or answer information in the 180 provisional response SHALL be in accordance with Section 8.3.5. 🦋
8.3.5. Inclusion of SDP Information in a SIP 18x Provisional Response
so when the gateway sends a SIP 18x provisional response to the INVITE request, if a QSIG message with a Progress indicator information element (progress description number 1 or 8) has come in, the gateway SHALL include SDP information. otherwise, the gateway MAY include SDP information 🧚 If SDP information is included, it shall be in accordance with the following rules.
If the SIP INVITE request had a Required or Supported header with option tag 100rel, and SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 18x provisional response 🙅
If the SIP INVITE request had a Required or Supported header with option tag 100rel, and SDP offer information came in with the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 18x provisional response 💜
If the SIP INVITE request had a Required or Supported header with option tag 100rel, and no SDP offer information came in with the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 18x provisional response 🌈
NOTE: In this case, SDP answer information can be expected in the SIP PRACK.
If the SIP INVITE request had neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 18x provisional response ✨
NOTE: Because the provisional response is unreliable, SDP answer information needs to be repeated in each provisional response and in the final SIP 2xx response. 🫶
NOTE: If the SIP INVITE request had no SDP offer information and neither a Required nor a Supported header with option tag 100rel, it should have been rejected in accordance with Section 8.3.1. 💀
8.3.6. Receipt of QSIG CONNECT Message
The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final response for the SIP INVITE request. The gateway SHALL also send a QSIG CONNECT ACKNOWLEDGE message. ✅
If the SIP INVITE request had a Required or Supported header with option tag 100rel, and SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 200 response.
If the SIP INVITE request had a Required or Supported header with option tag 100rel, and SDP offer information came in with the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 200 response. 💖
If the SIP INVITE request had a Required or Supported header with option tag 100rel, and no SDP offer information came in with the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 200 response.
NOTE: In this case, SDP answer information can be expected in the SIP ACK.
If the SIP INVITE request had neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 200 response.
NOTE: Because the provisional response is unreliable, SDP answer information needs to be repeated in each provisional response and in the final 2xx response. 🌸
NOTE: If the SIP INVITE request had no SDP offer information and neither a Required nor a Supported header with option tag 100rel, it may have been rejected in accordance with Section 8.3.1.
The gateway SHALL connect the media streams to the matching user information channel of the inter-PINX link (if it hasn't done that already), as long as SDP answer information is in the transmitted SIP response or has already been sent or received. 🦋
8.3.7. Receipt of SIP PRACK Request
The receipt of a SIP PRACK request acknowledging a reliable provisional response SHALL NOT result in any QSIG message being sent. The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK request. 🙌
If the SIP PRACK contains SDP answer information and a QSIG message with a Progress indicator information element (progress description number 1 or 8) has been received, the gateway SHALL connect the media streams to the matching user information channel of the inter-PINX link. 🎶
8.3.8. Receipt of SIP ACK Request
The receipt of a SIP ACK request SHALL NOT result in any QSIG message being sent. 💅
If the SIP ACK contains SDP answer information, the gateway SHALL connect the media streams to the matching user information channel of the inter-PINX link if it hasn't done that already. 🌈
8.3.9. Receipt of a SIP INVITE Request for a Call Already Being Established 📞✨
okay so a gateway can totally receive a call from SIP using overlap procedures 💅 this should occur when the UAC for the INVITE request is a gateway from a network that uses overlap procedures (like an ISUP gateway or another QSIG gateway) and the gateway hasn't absorbed the overlap yet 🫶
for a call from SIP using overlap procedures, the gateway gets multiple SIP INVITE requests that all belong to the same call but have different Request-URI and To fields 🦋 each SIP INVITE request lives in its own dialog, so they're separate, but still the same call bestie 🌸
a SIP INVITE request counts as being for overlap sending if, compared to an INVITE it already got, it has:
- the same Call-ID header;
- the same From header (including the tag);
- no tag in the To header;
- an updated Request-URI that can give you a called party number with a superset of the digits from the previous INVITE;
and also:
- the gateway hasn't yet sent a final response other than 484 to the previous INVITE 🙈
if a gateway gets a SIP INVITE request for overlap sending, it SHALL generate a QSIG INFORMATION message using the call reference of the existing QSIG call instead of a brand new QSIG SETUP message 💖 that INFORMATION message contains only the additional digits in the Called party number information element. it SHALL also respond to the SIP INVITE request it got before with a SIP 484 Address Incomplete response 🎀
and if a gateway gets a SIP INVITE request that meets every condition for overlap sending except the one about the Request-URI, the gateway SHALL respond to the new request with a SIP 485 (Ambiguous) response 💀
8.4. Call Clearing and Call Failure 🧹
8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE Message 👋
when a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE message shows up as the first QSIG call clearing message, the gateway's behaviour SHALL depend on where call establishment is at 🔥 here's how it breaks down:
- if the gateway sent a SIP 200 (OK) response to a SIP INVITE request and got a SIP ACK request, or if it got a SIP 200 (OK) response to a SIP INVITE request and sent a SIP ACK request, the gateway SHALL send a SIP BYE request to clear the call 💜
- if the gateway sent a SIP 200 (OK) response to a SIP INVITE request (so call establishment is complete) but hasn't received a SIP ACK request, the gateway SHALL wait until a SIP ACK is received and then send a SIP BYE request to clear the call 🍓
- if the gateway sent a SIP INVITE request and got a SIP provisional response but not a SIP final response, the gateway SHALL send a SIP CANCEL request to clear the call 🧚
NOTE 1: In accordance with [10], if after sending a SIP CANCEL request a SIP 2xx response is received to the SIP INVITE request, the gateway will need to send a SIP BYE request.
- if the gateway sent a SIP INVITE request but received no SIP response at all, the gateway SHALL NOT send a SIP message 🙅♀️ if a SIP final or provisional response shows up later, the gateway SHALL then act in accordance with 1, 2, or 3 above, respectively.
- if the gateway received a SIP INVITE request but hasn't sent a SIP final response, the gateway SHALL send a SIP final response chosen according to the cause value in the received QSIG message, as mapped in Table 1 ✨ SIP response 500 (Server internal error) SHALL be used as the default for any cause values not shown in Table 1.
NOTE 2: It is not necessarily appropriate to map some QSIG cause values to SIP messages, because these cause values only make sense at the gateway. A good example is cause value 44, "Requested circuit or channel not available", which means the channel number in the transmitted QSIG SETUP message wasn't acceptable to the peer PINX. The appropriate behavior in this case is for the gateway to send another SETUP message indicating a different channel number. If that isn't possible, the gateway should treat it either as a congestion situation (no channels available; see Section 8.3.1) or as a gateway failure situation (in which case the default SIP response code applies).
In all cases, the gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively 🦋
Table 1: Mapping of QSIG Cause Value to SIP 4xx-6xx responses to an INVITE request 🗺️
QSIG Cause value SIP response
----------------------------------------------------------------
1 Unallocated number 404 Not found
2 No route to specified 404 Not found
transit network
3 No route to destination 404 Not found
16 Normal call clearing (NOTE 3)
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 603 Decline, if location field
in Cause information element
indicates user. Otherwise:
403 Forbidden
22 Number changed 301 Moved permanently, if
information in diagnostic field
of Cause information element is
suitable for generating a SIP
Contact header. Otherwise:
410 Gone
23 Redirection to new 410 Gone
destination
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
34 No circuit/channel 503 Service unavailable
available
38 Network out of order 503 Service unavailable
41 Temporary failure 503 Service unavailable
42 Switching equipment 503 Service unavailable
congestion
47 Resource unavailable, 503 Service unavailable
unspecified
55 Incoming calls barred 403 Forbidden
within CUG
57 Bearer capability not 403 Forbidden
authorized
58 Bearer capability not 503 Service unavailable
presently available
65 Bearer capability not 488 Not acceptable here (NOTE 4)
implemented
69 Requested facility not 501 Not implemented
implemented
70 Only restricted digital 488 Not acceptable here (NOTE 4)
information available
79 Service or option not 501 Not implemented
implemented, unspecified
87 User not member of CUG 403 Forbidden
88 Incompatible destination 503 Service unavailable
102 Recovery on timer expiry 504 Server time-outNOTE 3: A QSIG call clearing message containing cause value 16 will normally result in the sending of a SIP BYE or CANCEL request. However, if a SIP response is to be sent to the INVITE request, the default response code should be used.
NOTE 4: The gateway may include a SIP Warning header if diagnostic information in the QSIG Cause information element allows a suitable warning code to be selected. 💅
8.4.2. Receipt of a SIP BYE Request 👋
when a SIP BYE request comes in, the gateway SHALL send a QSIG DISCONNECT message with cause value 16 (normal call clearing) 🌈 the gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively.
NOTE: When responding to a SIP BYE request, in accordance with [10], the gateway is also required to respond to any other outstanding transactions, e.g., with a SIP 487 (Request Terminated) response. This applies in particular if the gateway has not yet returned a final response to the SIP INVITE request. 🙈
8.4.3. Receipt of a SIP CANCEL Request 🫶
when a SIP CANCEL request comes in to clear a call where the gateway hasn't sent a SIP final response to the received SIP INVITE request yet, the gateway SHALL send a QSIG DISCONNECT message with cause value 16 (normal call clearing) 🎀 the gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively. iconic behaviour, honestly 🦋
8.4.4. Receipt of a SIP 4xx-6xx Response to an INVITE Request ✨
okay bestie, this one is all about what happens when a SIP INVITE gets a final "nope" (anything 4xx-6xx) 💅 unless the gateway can retry the INVITE to dodge the problem (like adding auth creds after a 401 or 407 🔑), the gateway SHALL transmit a QSIG DISCONNECT message 💀. The cause value in that DISCONNECT SHALL be derived from the SIP 4xx-6xx response using Table 2 🎀. Cause value 31 (Normal, unspecified) SHALL be the default for any SIP response that isn't listed in Table 2. The gateway SHALL also disconnect media streams (if they were set up) and let QSIG and SIP signalling finish up per [2] and [10], respectively 🦋. This exception applies only where overlap sending (8.2.2.2) says otherwise.
When the gateway builds a QSIG Cause information element, the location field SHOULD be user if the response is a SIP 6xx, or Private network serving the remote user in every other case 🌸.
Table 2: Mapping of SIP 4xx-6xx responses to an INVITE request to QSIG Cause values 🍓
SIP response QSIG Cause value (NOTE 6)
------------------------------------------------------------------
400 Bad request 41 Temporary failure
401 Unauthorized 21 Call rejected (NOTE 5)
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, unspecified
406 Not acceptable 79 Service or option not
implemented, unspecified
407 Proxy Authentication required 21 Call rejected (NOTE 5)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
413 Request entity too large 127 Interworking, unspecified
(NOTE 6)
414 Request-URI too long 127 Interworking, unspecified
(NOTE 6)
415 Unsupported media type 79 Service or option not
implemented, unspecified
(NOTE 6)
416 Unsupported URI scheme 127 Interworking, unspecified
(NOTE 6)
420 Bad extension 127 Interworking, unspecified
(NOTE 6)
421 Extension required 127 Interworking, unspecified
(NOTE 6)
423 Interval too brief 127 Interworking, unspecified
(NOTE 6)
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
(NOTE 6)
485 Ambiguous 1 Unallocated Number
486 Busy here 17 User busy
487 Request terminated (NOTE 7)
488 Not Acceptable Here 65 Bearer capability not
implemented or 31 Normal,
unspecified (NOTE 8)
500 Server internal error 41 Temporary failure
501 Not implemented 79 Service or option not
implemented, unspecified
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Gateway time-out 102 Recovery on timer expiry
505 Version not supported 127 Interworking, unspecified
(NOTE 6)
513 Message too large 127 Interworking, unspecified
(NOTE 6)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable 65 Bearer capability not
implemented or
31 Normal, unspecified (NOTE 8)NOTE 5: In some cases, it may be possible for the gateway to provide credentials to the SIP UAS that is rejecting an INVITE due to authorization failure. If the gateway can authenticate itself, then obviously it should do so and proceed with the call. Only if the gateway cannot authorize itself should the gateway clear the call in the QSIG network with this cause value. 🔐
NOTE 6: For some response codes, the gateway may be able to retry the INVITE request in order to work around the problem. In particular, this may be the case with response codes indicating a protocol error. The gateway SHOULD clear the call in the QSIG network with the indicated cause value only if retry is not possible or fails. 🔁
NOTE 7: The circumstances in which SIP response code 487 can be expected to arise do not require it to be mapped to a QSIG cause code, since the QSIG call will normally already be cleared or in the process of clearing. If QSIG call clearing does, however, need to be initiated, the default cause value should be used. 🙈
NOTE 8: When the Warning header is present in a SIP 606 or 488 message, the warning code should be examined to determine whether it is reasonable to generate cause value 65. This cause value should be generated only if there is a chance that a new call attempt with different content in the Bearer capability information element will avoid the problem. In other circumstances, the default cause value should be used. 🧚
8.4.5 Gateway-Initiated Call Clearing
If the gateway starts clearing the QSIG call because of QSIG timer expiry, a QSIG protocol error, or use of the QSIG RESTART message per [2], the gateway SHALL also start clearing the SIP call per Section 8.4.1 🫶. If that involves sending a final response to a SIP INVITE request, the gateway SHALL use response code 480 (Temporarily Unavailable) if optional QSIG timer T301 has expired. Otherwise it uses 408 (Request timeout) or 500 (Server internal error), as appropriate ⏰.
If the gateway starts clearing the SIP call because of SIP timer expiry or SIP protocol error per [10], the gateway SHALL also start clearing the QSIG call per [2] using cause value 102 (Recovery on timer expiry) or 41 (Temporary failure), as appropriate 🌈.
8.5. Request to Change Media Characteristics
If, after a call has been successfully set up, the gateway gets a SIP INVITE request that tries to change the media characteristics in a way that clashes with the bearer capability in use within the PISN, the gateway SHALL send back a SIP 488 (Not Acceptable Here) response and SHALL NOT change the media characteristics of the existing call 🙅♀️.
9. Number Mapping ✨
In QSIG, users are identified by numbers, as defined in [1]. Those numbers ride along in the Called party number, Calling party number, and Connected number information elements. The Calling party number and Connected number elements also carry a presentation indicator, which can say that privacy is required (presentation restricted), plus a screening indicator that tells you where the number came from and whether it's been authenticated 🕵️♀️.
In SIP, users are identified by Universal Resource Identifiers (URIs). Those URIs show up in the Request-URI and in a bunch of headers, including the From and To headers from [10] and, optionally, the P-Asserted-Identity header from [14]. Privacy gets signalled through the Privacy header from [13] 🎀.
This section lays out the mapping between the QSIG Called party number, Calling party number, and Connected number information elements and their SIP counterparts 🦋.
A gateway MAY implement the P-Asserted-Identity header per [14]. If a gateway does implement the P-Asserted-Identity header, it SHALL also implement the Privacy header per [13]. If a gateway does not implement the P-Asserted-Identity header, it MAY implement the Privacy header 💜.
9.1. Mapping from QSIG to SIP
How a number gets turned into a URI is outside the scope of this specification 🤷♀️. Still, the gateway SHOULD take the Numbering Plan (NPI) and Type Of Number (TON) fields from the QSIG information element into account when it interprets a number.
Some parts of the mapping depend on whether the gateway sits in the same trust domain (as defined in [14]) as the next hop SIP node. That's the proxy or UA the INVITE request goes to, or the one it came from. This matters for honouring identity privacy requests in the Privacy header 🔒. It's network-dependent, so it is RECOMMENDED that gateways supporting the P-Asserted-Identity header keep a configurable list of next hop nodes that they trust in this respect 🌸.
9.1.1. Using Information from the QSIG Called Party Number Information Element
When the gateway maps a QSIG SETUP message to a SIP INVITE request, it SHALL convert the number in the QSIG Called party number information into a URI, then put that URI in the SIP Request-URI and in the To header 📞.
9.1.2. Using Information from the QSIG Calling Party Number Information Element
When the gateway maps a QSIG SETUP message to a SIP INVITE request, it SHALL use the Calling party number information element if it's there, as follows 👀.
If the information element contains a number, the gateway SHALL try to derive a URI from that number. What happens next depends on whether a URI was derived and on the value of the presentation indication 🧩.
9.1.2.1. No URI derived, and presentation indicator does not have value "presentation restricted"
In this case (including the case where the Calling party number information element is absent), the gateway SHALL put a URI that identifies the gateway itself in the From header. Also, if the gateway supports the mechanism defined in [14], the gateway SHALL NOT generate a P-Asserted-Identity header 🏠.
9.1.2.2. No URI derived, and presentation indicator has value "presentation restricted"
In this case, the gateway SHALL generate an anonymous From header. Also, if the gateway supports the mechanism defined in [14], the gateway SHALL generate a Privacy header field with parameter priv-value = "id" and SHALL NOT generate a P-Asserted-Identity header 🫥. Including other values of the priv-value parameter in the Privacy header is outside the scope of this specification 🌷.
9.1.2.3. URI derived, and presentation indicator has value "presentation restricted" 🎀
Okay bestie, so if the gateway supports the P-Asserted-Identity header AND trusts the next hop proxy to honour the Privacy header, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI, SHALL generate a Privacy header with parameter priv-value = "id", and SHALL generate an anonymous From header. Adding more values to the priv-value parameter in the Privacy header is outside the scope of this specification. 💅
If the gateway does not support the P-Asserted-Identity header, or it doesn't trust the proxy to honour the Privacy header, then the gateway SHALL behave as in Section 9.1.2.2. 🙈
9.1.2.4. URI derived, and presentation indicator does not have value "presentation restricted" 🌸
In this case, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI if the gateway supports this header, SHALL NOT generate a Privacy header, and SHALL include the derived URI in the From header. ✨ On top of that, the gateway MAY use S/MIME, as described in Section 23 of [10], to sign a copy of the From header included in a message/sipfrag body of the INVITE request as described in [20]. Very secure, very aesthetic. 🔐
9.1.3. Using Information from the QSIG Connected Number Information Element 🦋
When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an INVITE request, the gateway SHALL use the Connected number information element, if it's present, as follows. 💖
If the information element contains a number, the gateway SHALL attempt to derive a URI from that number. After that, what happens next depends on whether a URI got derived and what the presentation indication says. 👀
9.1.3.1. No URI derived, and presentation indicator does not have value "presentation restricted" 🍓
In this case (including the case where the Connected number information element is absent), the gateway SHALL NOT generate a P-Asserted-Identity header and SHALL NOT generate a Privacy header. Nothing extra, no drama. 🫶
9.1.3.2. No URI derived, and presentation indicator has value "presentation restricted" 🌈
In this case, if the gateway supports the mechanism defined in [14], the gateway SHALL generate a Privacy header field with parameter priv-value = "id" and SHALL NOT generate a P-Asserted-Identity header. Adding more values to the priv-value parameter in the Privacy header is outside the scope of this specification. 🔒
9.1.3.3. URI derived, and presentation indicator has value "presentation restricted" 💜
If the gateway supports the P-Asserted-Identity header and trusts the next hop proxy to honour the Privacy header, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI and SHALL generate a Privacy header with parameter priv-value = "id". Adding more values to the priv-value parameter in the Privacy header is outside the scope of this specification. 🧚
If the gateway doesn't support the P-Asserted-Identity header, or it doesn't trust the proxy to honour the Privacy header, then the gateway SHALL behave as in Section 9.1.3.2. 🙃
9.1.3.4. URI derived, and presentation indicator does not have value "presentation restricted" ⭐
In this case, the gateway SHALL generate a P-Asserted-Identity header containing the derived URI if the gateway supports this header and SHALL NOT generate a Privacy header. ✨ In addition, the gateway MAY use S/MIME, as described in Section 23 of [10], to sign a To header containing the derived URI, with the To header being included in a message/sipfrag body of the INVITE response as described in [20]. 🔏
NOTE: TheToheader in the message/sipfrag body may differ from thetoheader in the response's headers. Plot twist, but it's allowed. 👑
9.2. Mapping from SIP to QSIG 🦋
The method used to convert a URI to a number is outside the scope of this specification. BUT the NPI and TON fields in the QSIG information element concerned SHALL be set to appropriate values in accordance with [1]. 🌸
Some parts of mapping depend on whether the gateway trusts the next hop SIP node (meaning the proxy or UA that the INVITE request is sent to, or received from) to give accurate information in the P-Asserted-Identity header. This is network-dependent, and it is RECOMMENDED that gateways hold a configurable list of next hop nodes that are to be trusted in this respect. 📋
Some parts of mapping also depend on whether the gateway is prepared to use a URI in the From header to derive a number for the Calling party number information element. The default behaviour SHOULD be not to use an unsigned or unvalidated From header for this purpose, since in principle that info comes from an untrusted source (the remote UA). 🚫 However, some network administrations might think the benefits of supplying a calling party number outweigh the risk of supplying false information. So a gateway MAY be configurable to use an unsigned or unvalidated From header for this purpose. 🤷♀️
9.2.1. Generating the QSIG Called Party Number Information Element 📞
When mapping a SIP INVITE request to a QSIG SETUP message, the gateway SHALL convert the URI in the SIP Request-URI to a number and include that number in the QSIG Called party number information element. ✅
NOTE: The To header should not be used for this purpose. This is because re-targeting of the request in the SIP network can change the Request-URI but leave the To header unchanged. It is important that routing in the QSIG network be based on the final target from the SIP network. 🎯
9.2.2. Generating the QSIG Calling Party Number Information Element 💌
When mapping a SIP INVITE request to a QSIG SETUP message, the gateway SHALL generate a Calling party number information element as follows.
If the SIP INVITE request contains an S/MIME signed message/sipfrag body [20] containing a From header, and the gateway supports this capability and can verify the authenticity and trustworthiness of this information, the gateway SHALL attempt to derive a number from the URI in that header. If no number is derived from a message/sipfrag body, and the SIP INVITE request contains a P-Asserted-Identity header, and the gateway supports that header and trusts the info therein, the gateway SHALL attempt to derive a number from the URI in that header. If a number is derived from one of these headers, the gateway SHALL include it in the Calling party number information element and include value "network provided" in the screening indicator. 🔍✨
If no number is derivable as described above, and the gateway is prepared to use the unsigned or unvalidated From header, the gateway SHALL attempt to derive a number from the URI in the From header. If a number is derived from the From header, the gateway SHALL include it in the Calling party number information element and include value "user provided, not screened" in the screening indicator. 🫣
If no number is derivable, the gateway SHALL NOT include a number in the Calling party number information element. 🙅♀️
If the SIP INVITE request contains a Privacy header with value "id" in parameter priv-value and the gateway supports this header, or if the value in the From header indicates anonymous, the gateway SHALL include value "presentation restricted" in the presentation indicator. Based on local policy, the gateway MAY use the presence of other priv-values to set the presentation indicator to "presentation restricted". Otherwise the gateway SHALL include value "presentation allowed" if a number is present, or "not available due to interworking" if no number is present. 🕶️
If the resulting Calling party number information element contains no number and contains value "not available due to interworking" in the presentation indicator, the gateway MAY omit the information element from the QSIG SETUP message. 👋
9.2.3. Generating the QSIG Connected Number Information Element 🌷
When mapping a SIP 2xx response to an INVITE request to a QSIG CONNECT message, the gateway SHALL generate a Connected number information element as follows.
If the SIP 2xx response contains an S/MIME signed message/sipfrag [20] body containing a To header, and the gateway supports this capability and can verify the authenticity and trustworthiness of this information, the gateway SHALL attempt to derive a number from the URI in that header. If no number is derived from a message/sipfrag body, and the SIP 2xx response contains a P-Asserted-Identity header, and the gateway supports that header and trusts the information therein, the gateway SHALL attempt to derive a number from the URI in that header. If a number is derived from one of these headers, the gateway SHALL include it in the Connected number information element and include value "network provided" in the screening indicator. 🥰
If no number is derivable as described above, the gateway SHOULD NOT include a number in the Connected number information element. 🤐
If the SIP 2xx response contains a Privacy header with value "id" in parameter priv-value and the gateway supports this header, the gateway SHALL include value "presentation restricted" in the presentation indicator. Based on local policy, the gateway MAY use the presence of other priv-values to set the presentation indicator to "presentation restricted". Otherwise, the gateway SHALL include value "presentation allowed" if a number is present, or "not available due to interworking" if no number is present. 🎀
If the resulting Connected number information element contains no number and value "not available due to interworking" in the presentation indicator, the gateway MAY omit the information element from the QSIG CONNECT message. 💜
10. Requirements for Support of Basic Services 🍓
This document specifies signalling interworking for basic services that provide a bi-directional transfer capability for speech, facsimile, and modem media between the two networks. Speech, fax, AND modem, all in one place. Iconic. 👑🌈
10.1. Derivation of QSIG Bearer Capability Information Element ✨
okay so the gateway SHALL generate the Bearer Capability Information Element in the QSIG SETUP message based on the SDP offer info it gets along with the SIP INVITE request 🎀. If the INVITE doesn't have SDP offer info, or the media type in the SDP offer is only 'audio', then the Bearer capability information element SHALL BE generated according to Table 3 🦋. Coding for other media types is outside the scope of this spec, so we're not going there rn 🙈.
the gateway MAY also include a Low layer compatibility information element and/or High layer compatibility information in the QSIG SETUP message, but only if it can actually figure out the relevant info from the SDP offer 💜. The specific mappings are outside the scope of this spec too, bestie 💅.
Table 3: Bearer capability encoding for 'audio' transfer
Field Value
-----------------------------------------------------------------
Coding Standard "CCITT standardized coding" (00)
Information transfer "3,1 kHz audio" (10000)
capability
Transfer mode "circuit mode" (00)
Information transfer rate "64 Kbits/s" (10000)
Multiplier Octet omitted
User information layer 1 Generated by gateway based on
protocol Information of the PISN. Supported
values are
"CCITT recommendation G.711 mu-law"
(00010)
"CCITT recommendation G.711 A-law"
(00011)10.2. Derivation of Media Type in SDP 🌸
okay this one is giving reverse engineering 😭. The gateway SHALL generate SDP offer info to put in the SIP INVITE request, based on what's in the QSIG SETUP message 🧚. The gateway MAY take QSIG Low layer compatibility and/or High layer compatibility info into account if they're there in the SETUP, and if it does, the specific mappings are outside the scope of this spec 🫶. Otherwise, the gateway shall generate SDP offer info based only on the Bearer capability information element in the QSIG SETUP message, and then the media type SHALL be derived according to Table 4 ✨.
Table 4: Media type setting in SDP based on Bearer capability
information element
Information transfer capability in Media type in SDP
Bearer capability information element
---------------------------------------------------------------
"speech" (00000) audio
"3,1 kHz audio" (10000) audio11. Security Considerations 🔥
lowkey the most important part of this whole doc, so pay attention bestie 👑.
11.1. General 💀
Normal considerations apply for UA use of SIP security measures, including digest authentication, TLS, and S/MIME as described in [10] 🔐.
translating QSIG information elements into SIP headers can bring in some privacy and security concerns 😭. For example, you have to be careful to give adequate privacy to a user who asks for presentation restriction, if the Calling party number information element gets openly mapped to the From header 🙈. Procedures for dealing with this exact situation are specified in Section 9.1.2 💜. Still, the mapping in this doc is mainly about translating information elements into the headers and fields used to route SIP requests, so gateways end up revealing (through this translation process) the minimum possible amount of information 🦋.
There are some concerns, though, that come from the other direction, the mapping of SIP headers to QSIG information elements. They're listed in the following paragraphs 🌈.
11.2. Calls from QSIG to Invalid or Restricted Numbers 🚫
When end users dial numbers in a PISN, their selections fill in the Called party number information element in the QSIG SETUP message 📞. Same idea in reverse: the SIP URI or tel URL and its optional parameters in the Request-URI of a SIP INVITE request, which end users of a SIP device can create directly, map to that information element at a gateway 🎀. But in a PISN, policy can stop the user from dialing certain (invalid or restricted) numbers 🙅♀️. So gateway implementers may wish to give gateway administrators a means to apply policies that restrict the use of certain SIP URIs or tel URLs, or SIP URI or tel URL parameters, when authorizing a call from SIP to QSIG 🔒.
11.3. Abuse of SIP Response Code 💅
some extra risks can come from mapping SIP response codes to QSIG cause values 😬. SIP user agents could conceivably respond to an INVITE request from a gateway with any arbitrary SIP response code, which means they can dictate (within the boundaries of the mappings the gateway supports) the Q.850 cause code the gateway sends in the resulting QSIG call clearing message 🧨. Generally speaking, though, how a call gets rejected isn't likely to give anyone a way to commit fraud or denial of service (e.g., by signalling that a call should not be billed, or that the network should take critical resources off-line) 🙌. Still, gateway implementers may wish to provide for gateway administrators to modify the response code to cause value mappings, so they can avoid any undesirable network-specific behaviour resulting from the mappings recommended in Section 8.4.4 🛡️.
11.4. Use of the To Header URI 🎯
this spec requires the gateway to map the Request-URI, not the To header in a SIP INVITE request, to the Called party number information element in a QSIG SETUP message 📍. A SIP UA is expected to put the same URI in the To header and in the Request-URI, but other SIP entities don't police that 🤷♀️. So a To header URI that differs from the Request-URI received at the gateway can't be used as a reliable sign that the call was re-targeted in the SIP network, or as a reliable sign of the original target 😵. Gateway implementers who use the To header to map to QSIG elements (e.g., as part of QSIG call diversion signalling) may wish to provide for disabling this mapping when deployed in situations where the reliability of the QSIG elements concerned is important ✨.
11.5. Use of the From Header URI 🕵️♀️
the arbitrary population of the From header by SIP user agents has some well-understood security implications for devices that rely on the From header as an accurate representation of the originator's identity 🚨. So any gateway that wants to use an unsigned or unverified From header to fill in the Calling party number information element of a QSIG SETUP message should authenticate the originator of the request, and make sure they're authorized to assert that calling number (or use some more secure method to figure out who the caller is) 🔐. Note that gateways, like all other SIP user agents, MUST support Digest authentication as described in [10] 💜. Similar considerations apply to using the SIP P-Asserted-Identity header to map to the QSIG Calling party number or Connected number information element, i.e., the source of this information should be authenticated 🫶. Using a signed message/sipfrag body to derive a QSIG Calling party number or Connected number information element is another secure option 🌟.
11.6. Abuse of Early Media 📢
there's another kind of potential risk, tied to cutting the backwards media path through before the call is answered 🎶. Several practices in this doc involve connecting media streams to user information channels on inter-PINX links, and sending progress description number 1 or 8 in a backward QSIG message 🔊. This can cut media through end-to-end, and then the called user agent could play arbitrary audio to the caller for an indefinite period of time before sending a final response (a 2xx or higher response code) to an INVITE request 😳. This is actually useful, because it also lets network entities (especially legacy networks that can't transmit Q.850 cause values) play tones and announcements to indicate call failure or call progress, without triggering charging by sending a 2xx response 📞. Early cut-through can also help prevent clipping of the initial media when the call is answered 🌸. There are conceivable ways this capability could be used fraudulently by the called user agent, to transmit arbitrary information without answering the call or before answering it 🙃. But in corporate networks charging is often not an issue, and for calls arriving at a corporate network from a carrier network, the carrier network normally takes steps to prevent fraud 🏢.
The usefulness of this capability appears to outweigh any risks involved, which may in practice be no greater than in existing PISN/ISDN environments 💖. Still, gateway implementers may wish to provide for gateway administrators to turn off cut-through, or minimise its impact (e.g., by imposing a time limit), when deployed in situations where problems can arise ⏱️.
11.7. Protection from Denial-of-Service Attacks 🚨
Unlike a traditional PISN 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 INVITE requests at a 100 port gateway, which would tie up all of its ports 😱. A malicious user could choose to launch requests to telephone numbers that are known never to answer or, where overlap signalling is used, to incomplete addresses 👀. This could saturate the gateway's resources indefinitely, potentially without incurring any charges 💸. So gateway implementers may wish to provide means of restricting, according to policy, the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack 🛑.
12. Acknowledgements 🫶
this doc is a product of the authors' work in Ecma (www.ecma-international.org) on interoperability of QSIG with IP networks 🌍. An earlier version was published as Standard ECMA-339 📚. Ecma made this work available to the IETF as the basis for publishing an RFC 🎀.
The authors want to thank Francois Audet, Adam Roach, Jean-Francois Rey, Thomas Stach, and members of Ecma TC32-TG17 for helping prepare and comment on this document 💜✨.
13. Normative References ✨
Okay bestie, here's the reading list for anyone who wants the official sources. These are the specs the whole thing is built on, so no cap, you need them. 📚💖
[1] International Standard ISO/IEC 11571 "Private Integrated Services Networks (PISN) - Addressing" (also published by Ecma as Standard ECMA-155).
[2] International Standard ISO/IEC 11572 "Private Integrated Services Network - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol" (also published by Ecma as Standard ECMA-143).
[3] International Standard ISO/IEC 11582 "Private Integrated Services Network - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol" (also published by Ecma as Standard ECMA-165).
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[10] 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.
[11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[14] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[16] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[17] ITU-T Recommendation E.164, "The International Public Telecommunication Numbering Plan", (1997-05).
[18] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)", RFC 3578, August 2003.
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[20] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
Appendix A. Example Message Sequences 🧚
A.1. Introduction
Time for the picture book! This appendix shows some typical message sequences that can occur for an interworking between QSIG and SIP. It is informative. 🌸
NOTE: For all message sequence diagrams, there is no message mapping between QSIG and SIP unless explicitly indicated by dotted lines. Also, if there are no dotted lines connecting two messages, this means that these are independent of each other in terms of the time when they occur.
NOTE: Numbers prefixing SIP method names and response codes in the diagrams represent sequence numbers. Messages bearing the same number will have the same value in the CSeq header.
NOTE: In these examples, SIP provisional responses (other than 100) are shown as being sent reliably, using the PRACK method for acknowledgement.
A.2. Message Sequences for Call Establishment from QSIG to SIP
Below are typical message sequences for successful call establishment from QSIG to SIP 💜
A.2.1. QSIG to SIP, using en bloc procedures on both QSIG and SIP
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG SETUP | | 1-INVITE |
1|----------------------->|......|----------------------->| 2
| | | |
| | | |
| QSIG CALL PROCEEDING | | 1-100 TRYING |
3|<-----------------------| |<-----------------------+ 4
| | | |
| | | |
| QSIG ALERTING | | 1-180 RINGING |
8|<-----------------------|......|<-----------------------+ 5
| | | |
| | | 2-PRACK |
| | |----------------------->| 6
| | | 2-200 OK |
| | |<-----------------------+ 7
| | | |
| QSIG CONNECT | | 1-200 OK |
11|<-----------------------|......|<-----------------------+ 9
| | | |
| QSIG CONNECT ACK | | 1-ACK |
12|----------------------->| |----------------------->| 10
| | | |
|<======================>| |<======================>|
| AUDIO | | AUDIO |Figure 3: Typical message sequence for successful call establishment from QSIG to SIP, using en bloc procedures on both QSIG and SIP
1 The PISN sends a QSIG SETUP message to the gateway to begin a session with a SIP UA.
2 On receipt of the QSIG SETUP message, the gateway generates a SIP INVITE request and sends it to an appropriate SIP entity in the IP network based on the called number.
3 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no more QSIG INFORMATION messages will be accepted.
4 The IP network sends a SIP 100 (Trying) response to the gateway.
5 The IP network sends a SIP 180 (Ringing) response.
6 The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request.
7 The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request.
8 The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PISN.
9 The IP network sends a SIP 200 (OK) response when the call is answered.
10 The gateway sends a SIP ACK request to acknowledge the SIP 200 (OK) response.
11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message and sends it to the PISN.
12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message. 🎀
A.2.2. QSIG to SIP, using overlap receiving on QSIG and en bloc sending on SIP
+------------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +--------+-------+-------+ |
1|-------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2|<--------------------------| | |
| | | |
| QSIG INFORMATION | | |
3|-------------------------->| | |
| | | |
| QSIG INFORMATION | | 1-INVITE |
3a|-------------------------->|.......|----------------------->|4
| QSIG CALL PROCEEDING | | 1-100 TRYING |
5|<--------------------------| |<-----------------------|6
| | | |
| QSIG ALERTING | | 1-180 RINGING |
10|<--------------------------|.......|<-----------------------|7
| | | 2-PRACK |
| | |----------------------->|8
| | | 2-200 OK |
| | |<-----------------------|9
| QSIG CONNECT | | 1-200 OK |
13|<--------------------------|.......|<-----------------------|11
| | | |
| QSIG CONNECT ACK | | 1-ACK |
14|-------------------------->| |----------------------->|12
| AUDIO | | AUDIO |
|<=========================>| |<======================>|Figure 4: Typical message sequence for successful call establishment from QSIG to SIP, using overlap receiving on QSIG and en bloc sending on SIP
1 The PISN sends a QSIG SETUP message to the gateway to begin a session with a SIP UA. The QSIG SETUP message does not contain a Sending Complete information element.
2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. More digits are expected.
3 More digits are sent from the PISN within a QSIG INFORMATION message.
3a More digits are sent from the PISN within a QSIG INFORMATION message. The QSIG INFORMATION message contains a Sending Complete information element.
4 The Gateway generates a SIP INVITE request and sends it to an appropriate SIP entity in the IP network, based on the called number.
5 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no more QSIG INFORMATION messages will be accepted.
6 The IP network sends a SIP 100 (Trying) response to the gateway.
7 The IP network sends a SIP 180 (Ringing) response.
8 The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a Require header or a Supported header with option tag 100rel in the initial SIP INVITE request.
9 The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request.
10 The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PINX.
11 The IP network sends a SIP 200 (OK) response when the call is answered.
12 The gateway sends an SIP ACK request to acknowledge the SIP 200 (OK) response.
13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message and sends it to the PINX.
14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message. we're almost through the appendix bestie! 🦋
A.2.3. QSIG to SIP, using overlap procedures on both QSIG and SIP ✨
Okay so this one is the overlap version, where digits trickle in one batch at a time 🧚 The PISN and the gateway both do overlap, and the gateway keeps retrying the SIP INVITE with a longer number until the IP network is happy.
+----------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +-------+-------+------+ |
1 |------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2 |<-------------------------| | |
| | | |
| QSIG INFORMATION | | |
3 |------------------------->| | |
| QSIG INFORMATION | | 1-INVITE |
3 |------------------------->|.......|------------------------>|4
| | | 1-484 |
| | |<------------------------|5
| | | 1-ACK |
| | |------------------------>|6
| QSIG INFORMATION | | 2-INVITE |
7 |------------------------->|.......|------------------------>|4
| | | 2-484 |
| | |<------------------------|5
| | | 2-ACK |
| | |------------------------>|6
| | | |
| QSIG INFORMATION | | |
| Sending Complete IE | | 3-INVITE |
8 |------------------------->|.......|------------------------>|10
| QSIG CALL PROCEEDING | | 3-100 TRYING |
9 |<-------------------------| |<------------------------|11
| | | |
| QSIG ALERTING | | 3-180 RINGING |
15|<-------------------------|.......|<------------------------|12
| | | 4-PRACK |
| | |------------------------>|13
| | | 4-200 OK |
| | |<------------------------|14
| QSIG CONNECT | | 3-200 OK |
18|<-------------------------|.......|<------------------------|16
| | | |
| QSIG CONNECT ACK | | 3-ACK |
19|------------------------->| |------------------------>|17
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
Figure 5: Typical message sequence for successful call establishment
from QSIG to SIP, using overlap procedures on both QSIG and SIP- The PISN sends a QSIG SETUP message to the gateway to begin a session with a SIP UA. The QSIG SETUP message does not contain a Sending complete information element.
- The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. More digits are expected.
- More digits are sent from the PISN within a QSIG INFORMATION message.
- When the gateway receives the minimum number of digits required to route the call, it generates a SIP INVITE request and sends it to an appropriate SIP entity in the IP network based on the called number.
- Due to an insufficient number of digits, the IP network will return a SIP 484 (Address Incomplete) response.
- The SIP 484 (Address Incomplete) response is acknowledged.
- More digits are received from the PISN in a QSIG INFORMATION message. A new INVITE is sent with the same
Call-IDandFromvalues but an updatedRequest-URI. - More digits are received from the PISN in a QSIG INFORMATION message. The QSIG INFORMATION message contains a Sending Complete information element.
- The gateway sends a QSIG CALL PROCEEDING message to the PISN; no more information will be accepted.
- The gateway sends a new SIP INVITE request with an updated
Request-URIfield. - The IP network sends a SIP 100 (Trying) response to the gateway.
- The IP network sends a SIP 180 (Ringing) response.
- The gateway may send back a SIP PRACK request to the IP network based on the inclusion of a
Requireheader or aSupportedheader with option tag100relin the initial SIP INVITE request. - The IP network sends a SIP 200 (OK) response to the gateway to acknowledge the SIP PRACK request.
- The gateway maps this SIP 180 (Ringing) response to a QSIG ALERTING message and sends it to the PISN.
- The IP network sends a SIP 200 (OK) response when the call is answered.
- The gateway sends a SIP ACK request to acknowledge the SIP 200 (OK) response.
- The gateway maps this SIP 200 (OK) response to a QSIG CONNECT message.
- The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to the QSIG CONNECT message.
A.3. Message sequences for call establishment from SIP to QSIG 🦋
Okay now flip it around! Here are the typical message sequences for successful call establishment from SIP to QSIG, and this is where the call starts over in the IP network, bestie 💅
A.3.1. SIP to QSIG, using en bloc procedures
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| +-------+-------+------+ |
| | | |
| | | |
| 1-INVITE | | QSIG SETUP |
1 |------------------------->|.......|------------------------>|3
| 1-100 TRYING | | QSIG CALL PROCEEDING |
2 |<-------------------------| |<------------------------|4
| 1-180 RINGING | | QSIG ALERTING |
6 |<-------------------------|.......|<------------------------|5
| | | |
| | | |
| 2-PRACK | | |
7 |------------------------->| | |
| 2-200 OK | | |
8 |<-------------------------| | |
| 1-200 OK | | QSIG CONNECT |
11|<-------------------------|.......|<------------------------|9
| | | |
| 1-ACK | | QSIG CONNECT ACK |
12|------------------------->| |------------------------>|10
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |
Figure 6: Typical message sequence for successful call establishment
from SIP to QSIG, using en bloc procedures- The IP network sends a SIP INVITE request to the gateway.
- The gateway sends a SIP 100 (Trying) response to the IP network.
- On receipt of the SIP INVITE request, the gateway sends a QSIG SETUP message.
- The PISN sends a QSIG CALL PROCEEDING message to the gateway.
- A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted.
- The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response.
- The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a
Requireheader or aSupportedheader with option tag100relin the initial SIP INVITE request. - The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request.
- The PISN sends a QSIG CONNECT message to the gateway when the call is answered.
- The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the QSIG CONNECT message.
- The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
- The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
A.3.2. SIP to QSIG, using overlap receiving on SIP and en bloc sending on QSIG ✨
Okay bestie, this one flips the direction, so the IP network is calling into the PISN 📞🦋. Here's the picture:
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |------------------------->| | |
| 1-484 | | |
2 |<-------------------------| | |
| 1-ACK | | |
3 |------------------------->| | |
| 2-INVITE | | |
1 |------------------------->| | |
| 2-484 | | |
2 |<-------------------------| | |
| 2- ACK | | |
3 |------------------------->| | |
| 3-INVITE | | QSIG SETUP |
4 |------------------------->|.......|------------------------>|6
| 3-100 TRYING | | QSIG CALL PROCEEDING |
5 |<-------------------------| |<------------------------|7
| 3-180 RINGING | | QSIG ALERTING |
9 |<-------------------------|.......|<------------------------|8
| | | |
| | | |
| 4-PRACK | | |
10|------------------------->| | |
| 4-200 OK | | |
11|<-------------------------| | |
| 3-200 OK | | QSIG CONNECT |
14|<-------------------------|.......|<------------------------|12
| | | |
| 3-ACK | | QSIG CONNECT ACK |
15|------------------------->| |------------------------>|13
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |Figure 7: Typical message sequence for successful call establishment from SIP to QSIG, using overlap receiving on SIP and en bloc sending on QSIG
Here's the play-by-play 💅:
- The IP network sends a SIP INVITE request to the gateway.
- Due to an insufficient number of digits, the gateway returns a SIP 484 (Address Incomplete) response.
- The IP network acknowledges the SIP 484 (Address Incomplete) response.
- The IP network sends a new SIP INVITE request with the same
Call-IDand updatedRequest-URI. - The gateway now has all the digits required to route the call to the PISN. The gateway sends back a SIP 100 (Trying) response.
- The gateway sends a QSIG SETUP message.
- The PISN sends a QSIG CALL PROCEEDING message to the gateway.
- A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted.
- The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response.
- The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a
Requireheader or aSupportedheader with option tag100relin the initial SIP INVITE request. - The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request.
- The PISN sends a QSIG CONNECT message to the gateway when the call is answered.
- The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the CONNECT message.
- The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
- The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
A.3.3. SIP to QSIG, using overlap procedures on both SIP and QSIG 🌈
This is the full overlap experience, both sides going step by step, so get comfy 🫶:
+----------------------+
IP NETWORK | GATEWAY | PISN
| |
| 1-INVITE +-------+-------+------+ |
1 |------------------------->| | |
| 1-484 | | |
2 |<-------------------------| | |
| 1-ACK | | |
3 |------------------------->| | |
| 2-INVITE | | QSIG SETUP |
4 |------------------------->|.......|------------------------>|6
| 2-100 TRYING | | QSIG SETUP ACK |
5 |<-------------------------| |<------------------------|7
| 3- INVITE | | QSIG INFORMATION |
8 |------------------------->|.......|------------------------>|10
| 3-100 TRYING | | |
9 |<-------------------------| | QSIG CALL PROCEEDING |
| | |<------------------------|11
13| 3-180 RINGING | | QSIG ALERTING |
|<-------------------------|.......|<------------------------|12
| 2-484 | | |
14|<-------------------------| | |
| 2-ACK | | |
15|------------------------->| | |
| 4-PRACK | | |
16|------------------------->| | |
| 4-200 OK | | |
17|<-------------------------| | |
| 3-200 OK | | QSIG CONNECT |
20|<-------------------------|.......|<------------------------|18
| | | |
| 3-ACK | | QSIG CONNECT ACK |
21|------------------------->| |------------------------>|19
| AUDIO | | AUDIO |
|<========================>| |<=======================>|
| | | |Figure 8: Typical message sequence for successful call establishment from SIP to QSIG, using overlap procedures on both SIP and QSIG
Here's how it goes, step by step 🍓:
- The IP network sends a SIP INVITE request to the gateway.
- Due to an insufficient number of digits, the gateway returns a SIP 484 (Address Incomplete) response.
- The IP network acknowledges the SIP 484 (Address Incomplete) response.
- The IP network sends a new SIP INVITE request with the same Call-ID and updated Request-URI.
- The gateway now has all the digits required to route the call to the PISN. The gateway sends back a SIP 100 (Trying) response to the IP network.
- The gateway sends a QSIG SETUP message.
- The PISN needs more digits to route the call and sends a QSIG SETUP ACKNOWLEDGE message to the gateway.
- The IP network sends a new SIP INVITE request with the same Call-ID and From values and updated Request-URI.
- The gateway sends back a SIP 100 (Trying) response to the IP network.
- The gateway maps the new SIP INVITE request to a QSIG INFORMATION message.
- The PISN has all the digits required and sends back a QSIG CALL PROCEEDING message to the gateway.
- A QSIG ALERTING message is returned to indicate that the end user in the PISN is being alerted.
- The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) response.
- The gateway sends a SIP 484 (Address Incomplete) response for the previous SIP INVITE request.
- The IP network acknowledges the SIP 484 (Address Incomplete) response.
- The IP network can send back a SIP PRACK request to the IP network based on the inclusion of a
Requireheader or aSupportedheader with option tag100relin the initial SIP INVITE request. - The gateway sends a SIP 200 (OK) response to acknowledge the SIP PRACK request.
- The PISN sends a QSIG CONNECT message to the gateway when the call is answered.
- The gateway sends a QSIG CONNECT ACKNOWLEDGE message to acknowledge the QSIG CONNECT message.
- The QSIG CONNECT message is mapped to a SIP 200 (OK) response.
- The IP network, upon receiving a SIP INVITE final response (200), will send a SIP ACK request to acknowledge receipt.
A.4. Message Sequence for Call Clearing from QSIG to SIP 👋
Time to hang up! 📴 Here are the typical message sequences for clearing a call from the QSIG side over to SIP 🌸.
A.4.1. QSIG to SIP, subsequent to call establishment 💜
This is the one where the call is already up and the PISN decides it's time to go:
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 2- BYE |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | | 2-200 OK |
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |
| | | |Figure 9: Typical message sequence for call clearing from QSIG to SIP, subsequent to call establishment
Here's the breakdown 🎀:
- The PISN sends a QSIG DISCONNECT message to the gateway.
- The gateway sends back a QSIG RELEASE message to the PISN in response to the QSIG DISCONNECT message.
- The PISN sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released.
- The gateway maps the QSIG DISCONNECT message to a SIP BYE request.
- The IP network sends back a SIP 200 (OK) response to the SIP BYE request. All IP resources are now released.
A.4.2. QSIG to SIP, during establishment of a call from SIP to QSIG 🦋
Okay bestie, this one is about a call that's still ringing 📞 when the PISN decides to hang up. The gateway is mid-setup and hasn't sent a final answer to the SIP INVITE yet, so the teardown has to happen in a different order. It's giving multitasking 💅
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- 4XX / 6XX |
1|----------------------->|......|---------------------->|4
| QSIG RELEASE | | 1- ACK |
2|<-----------------------| |<----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | |
| | | |
| | | |Figure 10: Typical message sequence for call clearing from QSIG to SIP, during establishment of a call from SIP to QSIG (gateway has not sent a final response to the SIP INVITE request) 🌸
- The PISN sends a QSIG DISCONNECT message to the gateway 📤
- The gateway sends back a QSIG RELEASE message to the PISN in response to the QSIG DISCONNECT message 🔁
- The PISN sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released 🎀
- The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx response 🔄
- The IP network sends back a SIP ACK request in response to the SIP 4xx-6xx response. All IP resources are now released 🫶
A.4.3. QSIG to SIP, during establishment of a call from QSIG to SIP 🧚
Now the other direction, and honestly this one slaps 🔥. The gateway has already gotten a provisional response to the INVITE (so the call is in progress), but still no final response. The gateway has to send a CANCEL and wait for the 487 to come back before everything can be torn down, lowkey a whole production 💅
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG DISCONNECT | | 1- CANCEL |
1|----------------------->|......|----------------------->|4
| QSIG RELEASE | |1-487 Request Terminated|
2|<-----------------------| |<-----------------------|5
| QSIG RELEASE COMP | | |
3|----------------------->| | 1- ACK |
| | |----------------------->|6
| | | |
| | | 1- 200 OK |
| | |<-----------------------|7
| | | |Figure 11: Typical message sequence for call clearing from QSIG to SIP, during establishment of a call from QSIG to SIP (gateway has received a provisional response to the SIP INVITE request but not a final response) ✨
- The PISN sends a QSIG DISCONNECT message to the gateway. 📤
- The gateway sends back a QSIG RELEASE message to the PISN in response to the QSIG DISCONNECT message. 🔁
- The PISN sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released. 🎀
- The gateway maps the QSIG DISCONNECT message to a SIP CANCEL request (subject to receipt of a provisional response, but not of a final response). 🧾
- The IP network sends back a SIP 487 (Request Terminated) response to the SIP INVITE request. 🙈
- The gateway, on receiving a SIP final response (487) to the SIP INVITE request, sends back a SIP ACK request to acknowledge receipt. 💜
- The IP network sends back a SIP 200 (OK) response to the SIP CANCEL request. All IP resources are now released. 🦋
A.5. Message Sequence for Call Clearing from SIP to QSIG 🌈
Okay, now we flip it. These are the typical message sequences for call clearing when the teardown starts on the IP side and the PISN gets the news second, bestie 💖
A.5.1. SIP to QSIG, subsequent to call establishment 📞
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 2- BYE | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 2-200 OK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |Figure 12: Typical message sequence for call clearing from SIP to QSIG, subsequent to call establishment 🍓
- The IP network sends a SIP BYE request to the gateway. 📨
- The gateway sends back a SIP 200 (OK) response to the SIP BYE request. All IP resources are now released. 🫶
- The gateway maps the SIP BYE request to a QSIG DISCONNECT message. 🔄
- The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 🔁
- The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released. 🎀
A.5.2. SIP to QSIG, during establishment of a call from QSIG to SIP 🌷
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- 4XX / 6XX | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|3
| | | QSIG RELEASE |
| | |<-----------------------|4
| 1- ACK | | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|5
| | | |
| | | |
| | | |Figure 13: Typical message sequence for call clearing from SIP to QSIG, during establishment of a call from QSIG to SIP (gateway has not previously received a final response to the SIP INVITE request) 🧁
- The IP network sends a SIP 4xx-6xx response to the gateway. 📩
- The gateway sends back a SIP ACK request in response to the SIP 4xx-6xx response. All IP resources are now released. 🫶
- The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT message. 🔄
- The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 🔁
- The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released. 🎀
A.5.3. SIP to QSIG, during establishment of a call from SIP to QSIG 🌙
+-------------------+
| |
| GATEWAY |
IP NETWORK | | PISN
| +-----+------+------+ |
| | | |
| | | |
| 1- CANCEL | | QSIG DISCONNECT |
1|----------------------->|......|----------------------->|4
| | | QSIG RELEASE |
| | |<-----------------------|5
|1-487 Request Terminated| | QSIG RELEASE COMP |
2|<-----------------------| |----------------------->|6
| | | |
| 1- ACK | | |
3|----------------------->| | |
| | | |
| 1- 200 OK | | |
4|<-----------------------| | |Figure 14: Typical message sequence for call clearing from SIP to QSIG, during establishment of a call from SIP to QSIG (gateway has sent a provisional response to the SIP INVITE request but not a final response) 🪄
- The IP network sends a SIP CANCEL request to the gateway. 🛑
- The gateway sends back a SIP 487 (Request Terminated) response to the SIP INVITE request. 🙈
- The IP network, on receiving a SIP final response (487) to the SIP INVITE request, sends back a SIP ACK request to acknowledge receipt. 💜
- The gateway sends back a SIP 200 (OK) response to the SIP CANCEL request. All IP resources are now released. 🦋
- The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT message. 🔄
- The PISN sends back a QSIG RELEASE message to the gateway in response to the QSIG DISCONNECT message. 🔁
- The gateway sends a QSIG RELEASE COMPLETE message in response. All PISN resources are now released. 🎀
Authors' Addresses 💌
John Elwell
Siemens plc
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
EMail: john.elwell@siemens.com
Frank Derks
NEC Philips Unified Solutions
Anton Philipsweg 1
1223 KZ Hilversum
The Netherlands
EMail: frank.derks@nec-philips.com
Olivier Rousseau
Alcatel Business Systems
32,Avenue Kleber
92700 Colombes
France
EMail: Olivier.Rousseau@alcatel.fr
Patrick Mourot
Alcatel Business Systems
1,Rue Dr A. Schweitzer
67400 Illkirch
France
EMail: Patrick.Mourot@alcatel.frFull Copyright Statement 🌸
Copyright (C) The Internet Society (2006). 🎀
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the authors keep their rights, babe 💅
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ⚠️
Intellectual Property ✨
okay bestie, this part is about the legal stuff 📜💅 The IETF is basically saying it's not picking a side on whether any Intellectual Property Rights (IPR) or other rights apply to the technology in this document, or whether you can get a license for them. It also hasn't gone hunting for those rights itself 🕵️♀️ If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79, they cover all of it 🎀
IPR disclosures sent to the IETF Secretariat are a whole thing too 🗂️ So are any assurances that licenses will be available, and the results of anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🌐✨
And the IETF is literally inviting everyone to speak up 📢🦋 If you know about any copyrights, patents, patent applications, or other proprietary rights that might cover technology you'd need to implement this standard, tell them! Send it to ietf-ipr@ietf.org 💌 Being honest about this stuff is so iconic 🫶
Acknowledgement
And last but not least, a big thank-you 💖 Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🌸 Without that support, all these documents wouldn't exist, so iykyk 🙏✨
📦 where this page comes from
- ietf: rfc4497 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms