Request for Comments: 3398 Ericsson
Category: Standards Track A. B. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
December 2002
Integrated Services Digital Network (ISDN) User Part (ISUP)
to Session Initiation Protocol (SIP) Mapping
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes a way to perform the mapping between two
signaling protocols: the Session Initiation Protocol (SIP) and the
Integrated Services Digital Network (ISDN) User Part (ISUP) of
Signaling System No. 7 (SS7). This mechanism might be implemented
when using SIP in an environment where part of the call involves
interworking with the Public Switched Telephone Network (PSTN).
Table of Contents
1. Introduction............................................ 3
2. Scope................................................... 4
3. Terminology............................................. 5
4. Scenarios............................................... 5
5. SIP Mechanisms Required................................. 7
5.1 'Transparent' Transit of ISUP Messages.................. 7
5.2 Understanding MIME Multipart Bodies..................... 7
5.3 Transmission of DTMF Information........................ 8
5.4 Reliable Transmission of Provisional Responses.......... 8
5.5 Early Media............................................. 8
5.6 Mid-Call Transactions which do not change SIP state..... 9
5.7 Privacy Protection...................................... 9
5.8 CANCEL causes........................................... 10
6. Mapping................................................. 10
7. SIP to ISUP Mapping..................................... 11
7.1 SIP to ISUP Call flows.................................. 11
7.1.1 En-bloc Call Setup (no auto-answer)..................... 11
7.1.2 Auto-answer call setup.................................. 12
7.1.3 ISUP T7 Expires......................................... 13
7.1.4 SIP Timeout............................................. 14
7.1.5 ISUP Setup Failure...................................... 15
7.1.6 Cause Present in ACM Message............................ 16
7.1.7 Call Canceled by SIP.................................... 17
7.2 State Machine........................................... 18
7.2.1 INVITE received......................................... 19
7.2.1.1 INVITE to IAM procedures................................ 19
7.2.2 ISUP T7 expires......................................... 23
7.2.3 CANCEL or BYE received.................................. 23
7.2.4 REL received............................................ 24
7.2.4.1 ISDN Cause Code to Status Code Mapping.................. 24
7.2.5 Early ACM received...................................... 27
7.2.6 ACM received............................................ 27
7.2.7 CON or ANM Received..................................... 28
7.2.8 Timer T9 Expires........................................ 29
7.2.9 CPG Received............................................ 29
7.3 ACK received............................................ 30
8. ISUP to SIP Mapping..................................... 30
8.1 ISUP to SIP Call Flows.................................. 30
8.1.1 En-bloc call setup (non auto-answer).................... 31
8.1.2 Auto-answer call setup.................................. 32
8.1.3 SIP Timeout............................................. 33
8.1.4 ISUP T9 Expires......................................... 34
8.1.5 SIP Error Response...................................... 35
8.1.6 SIP Redirection......................................... 36
8.1.7 Call Canceled by ISUP................................... 37
8.2 State Machine........................................... 39
8.2.1 Initial Address Message received........................ 39
8.2.1.1 IAM to INVITE procedures................................ 40
8.2.2 100 received............................................ 41
8.2.3 18x received............................................ 41
8.2.4 2xx received............................................ 43
8.2.5 3xx Received............................................ 44
8.2.6 4xx-6xx Received........................................ 44
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping.............. 45
8.2.7 REL Received............................................ 47
8.2.8 ISUP T11 Expires........................................ 47
9. Suspend/Resume and Hold................................. 48
9.1 SUS and RES............................................. 48
9.2 Hold (re-INVITE)........................................ 50
10. Normal Release of the Connection........................ 50
10.1 SIP initiated release................................... 50
10.2 ISUP initiated release.................................. 51
10.2.1 Caller hangs up......................................... 51
10.2.2 Callee hangs up (SUS)................................... 52
11. ISUP Maintenance Messages............................... 52
11.1 Reset messages.......................................... 52
11.2 Blocking messages....................................... 53
11.3 Continuity Checks....................................... 53
12. Construction of Telephony URIs.......................... 54
12.1 ISUP format to tel URL mapping.......................... 56
12.2 tel URL to ISUP format mapping.......................... 57
13. Other ISUP flavors...................................... 58
13.1 Guidelines for sending other ISUP messages.............. 58
14. Acronyms................................................ 60
15. Security Considerations................................. 60
16. IANA Considerations..................................... 64
17. Acknowledgments......................................... 64
18. Normative References.................................... 64
19. Non-Normative References................................ 65
Authors' Addresses...................................... 67
Full Copyright Statement................................ 68
1. Introduction
SIP [1] is an application layer protocol for establishing,
terminating and modifying multimedia sessions. It is typically
carried over IP. Telephone calls are considered a type of multimedia
sessions where just audio is exchanged.
Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a
level 4 protocol used in Signaling System No. 7 (SS7) networks. It
typically runs over Message Transfer Part (MTP) although it can also
run over IP (see SCTP [19]). ISUP is used for controlling telephone
calls and for maintenance of the network (blocking circuits,
resetting circuits etc.).
A module performing the mapping between these two protocols is
usually referred to as Media Gateway Controller (MGC), although the
terms 'softswitch' or 'call agent' are also sometimes used. An MGC
has logical interfaces facing both networks, the network carrying
ISUP and the network carrying SIP. The MGC also has some
capabilities for controlling the voice path; there is typically a
Media Gateway (MG) with E1/T1 trunking interfaces (voice from Public
Switched Telephone Network - PSTN) and with IP interfaces (Voice over
IP - VoIP). The MGC and the MG can be merged together in one
physical box or kept separate.
These MGCs are frequently used to bridge SIP and ISUP networks so
that calls originating in the PSTN can reach IP telephone endpoints
and vice versa. This is useful for cases in which PSTN calls need to
take advantage of services in IP world, in which IP networks are used
as transit networks for PSTN-PSTN calls, architectures in which calls
originate on desktop 'softphones' but terminate at PSTN terminals,
and many other similar next-generation telephone architectures.
This document describes logic and procedures which an MGC might use
to implement the mapping between SIP and ISUP by illustrating the
correspondences, at the message level and parameter level, between
the protocols. It also describes the interplay between parallel
state machines for these two protocols as a recommendation for
implementers to synchronize protocol events in interworking
architectures.
2. Scope
This document focuses on the translation of ISUP messages into SIP
messages, and the mapping of ISUP parameters into SIP headers. For
ISUP calls that traverse a SIP network, the purpose of translation is
to allow SIP elements such as proxy servers (which do not typically
understand ISUP) to make routing decisions based on ISUP criteria
such as the called party number. This document consequently provides
a SIP mapping only for those ISUP parameters which might be used by
intermediaries in the routing of SIP requests. As a side effect of
this approach, translation also increases the overall
interoperability by providing critical information about the call to
SIP endpoints that cannot understand encapsulated ISUP, or perhaps
which merely cannot understand the particular ISUP variant
encapsulated in a message.
This document also only takes into account the call functionality of
ISUP. Maintenance messages dealing with PSTN trunks are treated only
as far as they affect the control of an ongoing call; otherwise these
messages neither have nor require any analog in SIP.
Messages indicating error or congestion situations in the PSTN (MTP-
3) and the recovery mechanisms used such as User Part Available and
User Part Test ISUP messages are outside the scope of this document
There are several flavors of ISUP. International Telecommunication
Union Telecommunication Standardization Sector (ITU-T) International
ISUP [12] is used through this document; some differences with the
American National Standards Institute (ANSI) [11] ISUP and the
Telecommunication Technology Committee (TTC) ISUP are also outlined.
ITU-T ISUP is used in this document because it is the most widely
known of all the ISUP flavors. Due to the small number of fields
that map directly from ISUP to SIP, the signaling differences between
ITU-T ISUP and specific national variants of ISUP will generally have
little to no impact on the mapping. Note, however, that the ITU-T
has not substantially standardized practices for Local Number
Portability (LNP) since portability tends to be grounded in national
numbering plan practices, and that consequently LNP must be described
on a virtually per-nation basis. The number portability practices
described in this document are presented as an optional mechanism.
Mapping of SIP headers to ISUP parameters in this document focuses
largely on the mapping between the parameters found in the ISUP
Initial Address Message (IAM) and the headers associated with the SIP
INVITE message; both of these messages are used in their respective
protocols to request the establishment of a call. Once an INVITE has
been sent for a particular session, such headers as the To and From
field become essentially fixed, and no further translation will be
required during subsequent signaling, which is routed in accordance
with Via and Route headers. Hence, the problem of parameter-to-
header mapping in SIP-T is confined more or less to the IAM and the
INVITE. Some additional detail is given in the population of
parameters in the ISUP messages Address Complete Message (ACM) and
Release Message (REL) based on SIP status codes.
This document describes when the media path associated with a SIP
call is to be initialized, terminated, modified, etc., but it does
not go into details such as how the initialization is performed or
which protocols are used for that purpose.
3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations.
4. Scenarios
There are several scenarios where ISUP-SIP mapping takes place. The
way the messages are generated is different depending on the
scenario.
When there is a single MGC and the call is from a SIP phone to a PSTN
phone, or vice versa, the MGC generates the ISUP messages based on
the methods described in this document.
+-------------+ +-----+ +-------------+
| PSTN switch +-------+ MGC +-------+ SIP UAC/UAS |
+-------------+ +-----+ +-------------+
The scenario where a call originates in the PSTN, goes into a SIP
network and terminates in the PSTN again is known as "SIP bridging".
SIP bridging should provide ISUP transparency between the PSTN
switches handling the call. This is achieved by encapsulating the
incoming ISUP messages in the body of the SIP messages (see [3]). In
this case, the ISUP messages generated by the egress MGC are the ones
present in the SIP body (possibly with some modifications; for
example, if the called number in the request Uniform Resource
Identifier - URI - is different from the one present in the ISUP due
to SIP redirection, the ISUP message will need to be adjusted).
+------+ +-------------+ +-----+ +------------+ +------+
| PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
+------+ +-------------+ +-----+ +------------+ +------+
SIP is used in the middle of both MGCs because the voice path has to
be established through the IP network between both MGs; this
structure also allows the call to take advantage of certain SIP
services. ISUP messages in the SIP bodies provide further
information (such as cause values and optional parameters) to the
peer MGC.
In both scenarios, the ingress MGC places the incoming ISUP messages
in the SIP body by default. Note that this has security
implications; see Section 15. If the recipient of these messages
(typically a SIP User Agent Client/User Agent Server - UAC/UAS) does
not understand them, a negotiation using the SIP 'Accept' and
'Require' headers will take place and they will not be included in
the next SIP message exchange.
There can be a Signaling Gateway (SG) between the PSTN and the MGC.
It encapsulates the ISUP messages over IP in a manner such as the one
described in [19]. The mapping described in this document is not
affected by the underlying transport protocol of ISUP.
Note that overlap dialing mechanisms (use of the Subsequent Address
Message - SAM) are outside the scope of this document. This document
assumes that gateways facing ISUP networks in which overlap dialing
is used will implement timers to insure that all digits have been
collected before an INVITE is transmitted to a SIP network.
In some instances, gateways may receive incomplete ISUP messages
which indicate message segmentation due to excessive message length.
Commonly these messages will be followed by a Segmentation Message
(SGM) containing the remainder of the original ISUP message. An
incomplete message may not contain sufficient parameters to allow for
a proper mapping to SIP; similarly, encapsulating (see below) an
incomplete ISUP message may be confusing to terminating gateways.
Consequently, a gateway MUST wait until a complete ISUP message is
received (which may involve waiting until one or more SGMs arrive)
before sending any corresponding INVITE.
5. SIP Mechanisms Required
For a correct mapping between ISUP and SIP, some SIP mechanisms above
and beyond those available in the base SIP specification are needed.
These mechanisms are discussed below. If the SIP UAC/UAS involved in
the call does not support them, it is still possible to proceed, but
the behavior in the establishment of the call may be slightly
different than that expected by the user (e.g., other party answers
before receiving the ringback tone, user is not informed about the
call being forwarded, etc.).
5.1 'Transparent' Transit of ISUP Messages
To allow gateways to take advantage of the full range of services
afforded by the existing telephone network when placing calls from
PSTN to PSTN across a SIP network, SIP messages MUST be capable of
transporting ISUP payloads from gateway to gateway. The format for
encapsulating these ISUP messages is defined in [3].
SIP user agents which do not understand ISUP are permitted to ignore
these optional MIME bodies.
5.2 Understanding MIME Multipart Bodies
In most PSTN interworking situations, SIP message bodies will be
required to carry session information (Session Description Protocol -
SDP) in addition to ISUP and/or billing information.
PSTN interworking nodes MUST understand the MIME type of
"multipart/mixed" as defined in RFC2046 [4]. Clients express support
for this by including "multipart/mixed" in an "Accept" header.
5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information
How DTMF tones played by the user are transmitted by a gateway is
completely orthogonal to how SIP and ISUP are interworked; however,
as DTMF carriage is a component of a complete gatewaying solution
some guidance is offered here.
Since the codec selected for voice transmission may not be ideally
suited for carrying DTMF information, a symbolic method of
transmitting this information in-band is desirable (since out-of-band
transmission alone would provide many challenges for synchronization
of the media stream for tone re-insertion). This transmission MAY be
performed as described in RFC2833 [5].
5.4 Reliable Transmission of Provisional Responses
Provisional responses (in the 1xx class) are used in the transmission
of call progress information. PSTN interworking in particular relies
on these messages for control of the media channel and timing of call
events.
When interworking with the PSTN, SIP messages MUST be sent reliably
end-to-end; reliability of requests is guaranteed by the base
protocol. One application-layer provisional reliability mechanism
for responses is described in [18].
5.5 Early Media
Early media denotes the capability to play media (audio for
telephony) before a SIP session has been established (before a 2xx
response code has been sent). For telephony, establishment of media
in the backwards direction is desirable so that tones and
announcements can be played, especially when interworking with a
network that cannot signal call status out of band (such as a legacy
MF network). In cases where interworking has not been encountered,
use of early media is almost always undesirable since it consumes
inter-machine trunk recourses to play media for which no revenue is
collected. Note that since an INVITE almost always contains the SDP
required to send media in the backwards direction, and requires that
user agents prepare themselves to receive backwards media as soon as
an INVITE transmitted, the baseline SIP protocol has enough support
to enable rudimentary unidirectional early media systems. However,
this mechanism has a number of limitations - for example, media
streams offered in the SDP of the INVITE cannot be modified or
declined, and bidirectional RTCP required for session maintenance
cannot be established.
Therefore gateways MAY support more sophisticated early media systems
as they come to be better understood. One mechanism that provides a
way of initiating a fully-featured early media system is described in
[20].
Note that in SIP networks not just switches but also user agents can
generate the 18x response codes and initiate early backwards media,
and that therefore some gateways may wish to enforce policies that
restrict the use of backwards media from arbitrary user agents (see
Section 15).
5.6 Mid-Call Transactions which do not change SIP state
When interworking with the PSTN, there are situations when gateways
will need to send messages to each other over SIP that do not
correspond to any SIP operations.
In support of mid-call transactions and other ISUP events that do not
correspond to existing SIP methods, SIP gateways MUST support the
INFO method, defined in RFC2976 [6]. Note that this document does
not prescribe or endorse the use of INFO to carry DTMF digits.
Gateways MUST accept "405 Method Not Allowed" and "501 Not
Implemented" as non-fatal responses to INFO requests - that is, any
call in progress MUST NOT be torn down if a destination so rejects an
INFO request sent by a gateway.
5.7 Privacy Protection
ISUP has a concept of presentation restriction - a mechanism by which
a user can specify that they would not like their telephone number to
be displayed to the person they are calling (presumably someone with
Caller ID). When a gateway receives an ISUP request that requires
presentation restriction, it must therefore shield the identity of
the caller in some fashion.
The base SIP protocol supports a method of specifying that a user is
anonymous. However, this system has a number of limitations - for
example, it reveals the identity of the gateway itself, which could
be a privacy-impacting disclosure. Therefore gateways MAY support
more sophisticated privacy systems. One mechanism that provides a
way of supporting fully-featured privacy negotiation (which interacts
well with identity management systems) is described in [9B].
5.8 CANCEL causes
There is a way in ISUP to signal that you would like to discontinue
an attempt to set up a call - the general-purpose REL is sent in the
forwards direction. There is a similar concept in SIP - that of a
CANCEL request that is sent in order to discontinue the establishment
of a SIP dialog. For various reasons, however, CANCEL requests
cannot contain message bodies, and therefore in order to carry the
important information in the REL (the cause code) end-to-end in sip
bridging cases, ISUP encapsulation cannot be used.
Ordinarily, this is not a big problem, because for practical purposes
the only reason that a REL is ever issued to cancel a call setup
attempt is that a user hangs up the phone while it is still ringing
(which results in a "Normal clearing" cause code). However, under
exceptional conditions, like catastrophic network failure, a REL may
be sent with a different cause code, and it would be handy if a SIP
network could carry the cause code end-to-end. Therefore gateways
MAY support a mechanism for end-to-end delivery of such failure
reasons. One mechanism that provides this capability is described in
[9].
6. Mapping
The mapping between ISUP and SIP is described using call flow
diagrams and state machines. One state machine handles calls from
SIP to ISUP and the second from ISUP to SIP. There are details, such
as some retransmissions and some states (waiting for the Release
Complete Message - RLC, waiting for SIP ACK etc.), that are not shown
in the figures in order to make them easier to follow.
The boxes represent the different states of the gateway, and the
arrows show changes in the state. The event that triggers the change
in the state and the actions to take appear on the arrow: event /
section describing the actions to take.
For example, 'INVITE / 7.2.1' indicates that an INVITE request has
been received by the gateway, and the procedure upon reception is
described in the section 7.2.1 of this document.
It is RECOMMENDED that gateways implement functional equivalence with
the call flows detailed in Section 7.1 and Section 8.1. Deviations
from these flows are permissible in support of national ISUP
variants, or any of the conservative policies recommended in Section
15.
7. SIP to ISUP Mapping
7.1 SIP to ISUP Call flows
The following call flows illustrate the order of messages in typical
success and error cases when setting up a call initiated from the SIP
network. "100 Trying" acknowledgements to INVITE requests are not
displayed below although they are required in many architectures.
In these diagrams, all call signaling (SIP, ISUP) is going to and
from the MGC; media handling (e.g., audio cut-through, trunk freeing)
is being performed by the MG, under the control of the MGC. For the
purpose of simplicity, these are shown as a single node, labeled
"MGC/MG."
7.1.1 En-bloc Call Setup (no auto-answer)
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node. This response may
contain SDP to establish an early media stream (as shown in the
diagram). If no SDP is present, the audio will be established in
both directions after step 8.
5. If the ISUP variant permits, the remote ISUP node may issue a
variety of Call Progress (CPG) messages to indicate, for example,
that the call is being forwarded.
6. Upon receipt of a CPG message, the gateway will map the event
code to a SIP provisional response (see Section 7.2.9) and send
it to the SIP node.
7. Once the PSTN user answers, an Answer (ANM) message will be sent
to the gateway.
8. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node.
9. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
7.1.2 Auto-answer call setup
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |
Note that this flow is not supported in ANSI networks.
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. Since the remote node is configured for automatic answering, it
will send a Connect Message (CON) upon receipt of the IAM. (For
ANSI, this message will be an ANM).
4. Upon receipt of the CON, the gateway will send a 200 message to
the SIP node.
5. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
7.1.3 ISUP T7 Expires
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network. The ISUP timer T7 is
started at this point.
3. The ISUP timer T7 expires before receipt of an ACM or CON
message, so a REL message is sent to cancel the call.
4. A gateway timeout message is sent back to the SIP node.
5. The SIP node, upon receiving an INVITE final response (504), will
send an ACK to acknowledge receipt.
7.1.4 SIP Timeout
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
5|<----------200------------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
7|<----------BYE------------|------------REL---------->|6
| |<-----------RLC-----------|8
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. Since the remote node is configured for automatic answering, it
will send a CON message upon receipt of the IAM. In ANSI flows,
rather than a CON, an ANM (without ACM) would be sent.
4. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node and set SIP timer T1.
5. The response is retransmitted every time the SIP timer T1
expires.
6. After seven retransmissions, the call is torn down by sending a
REL to the ISUP node, with a cause code of 102 (recover on timer
expiry).
7. A BYE is transmitted to the SIP node in an attempt to close the
call. Further handling for this clean up is not shown, since the
SIP node's state is not easily known in this scenario.
8. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
7.1.5 ISUP Setup Failure
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. Since the remote ISUP node is unable to complete the call, it
will send a REL.
4. The gateway releases the circuit and confirms that it is
available for reuse by sending an RLC.
5. The gateway translates the cause code in the REL to a SIP error
response (see Section 7.2.4) and sends it to the SIP node.
6. The SIP node sends an ACK to acknowledge receipt of the INVITE
final response.
7.1.6 Cause Present in ACM Message
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. Since the ISUP node is unable to complete the call and wants to
generate the error tone/announcement itself, it sends an ACM with
a cause code. The gateway starts an interwork timer.
4. Upon receipt of an ACM with cause (presence of the CAI
parameter), the gateway will generate a 183 message towards the
SIP node; this contains SDP to establish early media cut-through.
5. A final INVITE response, based on the cause code received in the
earlier ACM message, is generated and sent to the SIP node to
terminate the call. See Section 7.2.4.1 for the table which
contains the mapping from cause code to SIP response.
6. Upon expiration of the interwork timer, a REL is sent towards the
PSTN node to terminate the call. Note that the SIP node can also
terminate the call by sending a CANCEL before the interwork timer
expires. In this case, the signaling progresses as in Section
7.1.7.
7. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
8. The SIP node sends an ACK to acknowledge receipt of the INVITE
final response.
7.1.7 Call Canceled by SIP
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node. This response may
contain SDP to establish an early media stream.
5. To cancel the call before it is answered, the SIP node sends a
CANCEL request.
6. The CANCEL request is confirmed with a 200 response.
7. Upon receipt of the CANCEL request, the gateway sends a REL
message to terminate the ISUP call.
8. The gateway sends a "487 Call Cancelled" message to the SIP node
to complete the INVITE transaction.
9. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
10. Upon receipt of the 487, the SIP node will confirm reception
with an ACK.
7.2 State Machine
Note that REL can be received in any state; the handling is the same
for each case (see Section 10).
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+
7.2.1 INVITE received
When an INVITE request is received by the gateway, a "100 Trying"
response MAY be sent back to the SIP network indicating that the
gateway is handling the call.
The necessary hardware resources for the media stream MUST be
reserved in the gateway when the INVITE is received, since an IAM
message cannot be sent before the resource reservation (especially
TCIC selection) takes place. Typically the resources consist of a
time slot in an E1/T1 and an RTP/UDP port on the IP side. Resources
might also include any quality-of-service provisions (although no
such practices are recommended in this document).
After sending the IAM the timer T7 is started. The default value of
T7 is between 20 and 30 seconds. The gateway goes to the 'Trying'
state.
7.2.1.1 INVITE to IAM procedures
This section details the mapping of the SIP headers in an INVITE
message to the ISUP parameters in an Initial Address Message (IAM).
A PSTN-SIP gateway is responsible for creating an IAM when it
receives an INVITE.
Five mandatory parameters appear within the IAM message: the Called
Party Number (CPN), the Nature of Connection Indicator (NCI), the
Forward Call Indicators (FCI), the Calling Party's Category (CPC),
and finally a parameter that indicates the desired bearer
characteristics of the call - in some ISUP variants the Transmission
Medium Requirement (TMR) is required, in others the User Service
Information (USI) (or both). All IAM messages MUST contain these
five parameters at a minimum. Thus, every gateway must have a means
of populating each of those five parameters when an INVITE is
received. Many of the values that will appear in these parameters
(such as the NCI or USI) will most likely be the same for each IAM
created by the gateway. Others (such as the CPN) will vary on a
call-by-call basis; the gateway extracts information from the INVITE
in order to properly populate these parameters.
There are also quite a few optional parameters that can appear in an
IAM message; Q.763 [17] lists 29 in all. However, each of these
parameters need not to be translated in order to achieve the goals of
SIP-ISUP mapping. As is stated above, translation allows SIP network
elements to understand the basic PSTN context of the session (who it
is for, and so on) if they are not capable of deciphering any
encapsulated ISUP. Parameters that are only meaningful to the PSTN
will be carried through PSTN-SIP- PSTN networks via encapsulation -
translation is not necessary for these parameters. Of the
aforementioned 29 optional parameters, only the following are
immediately useful for translation: the Calling Party's Number (CIN,
which is commonly present), Transit Network Selection (TNS), Carrier
Identification Parameter (CIP, present in ANSI networks), Original
Called Number (OCN), and the Generic Digits (known in some variants
as the Generic Address Parameter (GAP)).
When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD
attempt to make use of encapsulated ISUP (see [3]), if any, within
the INVITE to assist in the formulation of outbound PSTN signaling,
but SHOULD also heed the security considerations in Section 15. If
possible, the gateway SHOULD reuse the values of each of the ISUP
parameters of the encapsulated IAM as it formulates an IAM that it
will send across its PSTN interface. In some cases, the gateway will
be unable to make use of that ISUP - for example, if the gateway
cannot understand the ISUP variant and must therefore ignore the
encapsulated body. Even when there is comprehensible encapsulated
ISUP, the relevant values of SIP header fields MUST 'overwrite'
through the process of translation the parameter values that would
have been set based on encapsulated ISUP. In other words, the
updates to the critical session context parameters that are created
in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases,
over the encapsulated ISUP. This allows many basic services,
including various sorts of call forwarding and redirection, to be
implemented in the SIP network.
For example, if an INVITE arrives at a gateway with an encapsulated
IAM with a CPN field indicating the telephone number +12025332699,
but the Request-URI of the INVITE indicates 'tel:+15105550110', the
gateway MUST use the telephone number in the Request-URI, rather than
the one in the encapsulated IAM, when creating the IAM that the
gateway will send to the PSTN. Further details of how SIP header
fields are translated into ISUP parameters follow.
Gateways MUST be provisioned with default values for mandatory ISUP
parameters that cannot be derived from translation(such as the NCI or
TMR parameters) for those cases in which no encapsulated ISUP is
present. The FCI parameter MUST also have a default, as only the 'M'
bit of the default may be overwritten during the process of
translation if the optional number portability translation mechanisms
described below are used.
The first step in the translation of the fields of an INVITE message
to the parameters of an IAM is the inspection of the Request-URI.
If the optional number portability practices are supported by the
gateway, then the following steps related to handling of the 'npdi'
and 'rn' parameters of the Request-URI should be followed.
If there is no 'npdi=yes' field within the Request-URI, then the
primary telephone number in the tel URL (the digits immediately
following 'tel:') MUST be converted to ISUP format, following the
procedures described in Section 12, and used to populate the CPN
parameter.
If the 'npdi=yes' field exists in the Request-URI, then the FCI
parameter bit for 'number translated' within the IAM MUST reflect
that a number portability dip has been performed.
If in addition to the 'npdi=yes' field there is no 'rn=' field
present, then the main telephone number in the tel URL MUST be
converted to ISUP format (see Section 12) and used to populate the
CPN parameter. This indicates that a portability dip took place, but
that the called party's number was not ported.
If in addition to the 'npdi=yes' field an 'rn=' field is present,
then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format
and used to populate the CPN. The main telephone number in the tel
URL MUST be converted to ISUP format and used to populate the Generic
Digits Parameter (or GAP in ANSI). In some other ISUP variants, the
number given in the 'rn=' field would instead be prepended to the
main telephone number (with or without a prefix or separator) and the
combined result MUST be used to populate the CPN. Once the 'rn=' and
'npdi=' parameters have been translation, the number portability
translation practices are complete.
The following mandatory translation practices are performed after
number portability translations, if any.
If number portability practices are not supported by the gateway,
then the primary telephone number in the tel URL (the digits
immediately following 'tel:') MUST be converted to ISUP format,
following the procedures described in Section 12, and used to
populate the CPN parameter.
If the primary telephone number in the Request-URI and that of the To
header are at variance, then the To header SHOULD be used to populate
an OCN parameter. Otherwise the To header SHOULD be ignored.
Some optional translation procedures are provided for carrier-based
routing. If the 'cic=' parameter is present in the Request-URI, the
gateway SHOULD consult local policy to make sure that it is
appropriate to transmit this Carrier Identification Code (CIC, not to
be confused with the MTP3 'circuit identification code') in the IAM;
if the gateway supports many independent trunks, it may need to
choose a particular trunk that points to the carrier identified by
the CIC, or a tandem through which that carrier is reachable.
Policies for such trunks (based on the preferences of the carriers
with which the trunks are associated and the ISUP variant in use)
SHOULD dictate whether the CIP or TNS parameter is used to carry the
CIC. In the absence of any pre-arranged policies, the TNS should be
used when the CPN parameter is in an international format (i.e., the
tel URL portion of the Request-URI is preceded by a '+', which will
generate a CPN in international format), and (where supported) the
CIP should be used in other cases.
When a SIP call has been routed to a gateway, then the Request-URI
will most likely contain a tel URL (or a SIP URI with a tel URL user
portion) - SIP-ISUP gateways that receive Request-URIs that do not
contain valid telephone numbers SHOULD reject such requests with an
appropriate response code. Gateways SHOULD however continue to
process requests with a From header field that does not contain a
telephone number, as will sometimes be the case if a call originated
at a SIP phone that employs a SIP URI user@host convention. The CIN
parameter SHOULD be omitted from the outbound IAM if the From field
is unusable. Note that as an alternative, gateway implementers MAY
consider some non-standard way of mapping particular SIP URIs to
telephone numbers.
When a gateway receives a message with (comprehensible) encapsulated
ISUP, it MUST set the FCI indicator in the generated IAM so that all
interworking-related bits have the same values as their counterparts
in the encapsulated ISUP. In most cases, these indicators will state
that no interworking was encountered, unless interworking has been
encountered somewhere else in the call path. If usable encapsulated
ISUP is not present in an INVITE received by the gateway, it is
STRONGLY RECOMMENDED that the gateway set the Interworking Indicator
bit of the FCI to 'no interworking' and the ISDN User Part Indicator
to 'ISUP used all the way'; the gateway MAY also set the Originating
Access indicator to 'Originating access non-ISDN' (generally, it is
not safe to assume that SIP phones will support ISDN endpoint
services, and the procedures in this document do not detail mappings
to translate all such services).
Note that when 'interworking encountered' is set in the FCI parameter
of the IAM, this indicates that ISUP is interworking with a network
which is not capable of providing as many services as ISUP does.
ISUP networks will therefore not employ certain features they
otherwise normally would, including potentially the use of ISDN cause
codes in failure conditions (as opposed to sending ACMs followed by
audible announcements). If desired, gateway vendors MAY provide a
configurable option, usable at the discretion of service providers,
that will signal in the FCI that interworking has been encountered
(and that ISUP is not used all the way) when encapsulated ISUP is not
present; however, doing so may significantly limit the efficiency and
transparency of SIP-ISUP translation.
Claiming to be an ISDN node might make the callee request ISDN user
to user services. Since user to user services 1 and 2 must be
requested by the caller, they do not represent a problem (see [14]).
User to user service 3 can be requested by the callee also. In non-
SIP bridging situations, the MGC should be capable of rejecting this
service request.
7.2.2 ISUP T7 expires
Since no response was received from the PSTN all the resources in the
MG are released. A '504 Server Timeout' SHOULD be sent back to the
SIP network. A REL message with cause value 102 (protocol error,
recovery on timer expiry) SHOULD be sent to the PSTN. Gateways can
expect the PSTN to respond with RLC and the SIP network to respond
with an ACK indicating that the release sequence has been completed.
7.2.3 CANCEL or BYE received
If a CANCEL or BYE request is received before a final SIP response
has been sent, a '200 OK' MUST be sent to the SIP network to confirm
the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE
transaction. All the resources are released and a REL message SHOULD
be sent to the PSTN with cause value 16 (normal clearing). Gateways