Internet Engineering Task Force Gonzalo Camarillo/Adam Roach
Internet Draft Ericsson
<draft-ietf-sip-isup-03.txt> Jon Peterson
Category: Informational NeuStar, Inc
August 2001 Lyndon Ong
Expires: February 2001 Ciena
ISUP to SIP Mapping
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document describes a way to perform the mapping between two
signaling protocols: the Session Initiation Protocol (SIP) and the
ISDN User Part (ISUP) of 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.................................................. 3
3. Scenarios.............................................. 5
4. SIP Mechanisms Required................................ 6
Camarillo/Roach/Peterson/Ong [Page 1]
ISUP to SIP Mapping August 2001
4.1. "Transparent" Transit of ISUP messages................. 6
4.2. Understanding of Multipart Bodies...................... 6
4.3. Transmission of DTMF information....................... 7
4.4. Reliable Transmission of Provisional Responses......... 7
4.5. Provisional Media Streams.............................. 7
4.6. Mid-Call Transactions Which do not Change SIP State.... 7
5. Mapping................................................ 7
6. SIP to ISUP mapping.................................... 8
6.1. Call Flows............................................. 8
6.1.1. En-bloc Call Setup (non auto-answer)................... 8
6.1.2. Auto-answer call setup................................. 10
6.1.3. ISUP T7 expires........................................ 10
6.1.4. SIP Timeout............................................ 11
6.1.5. ISUP Setup Failure..................................... 12
6.1.6. Cause present in ACM message........................... 13
6.1.7. Call cancelled by SIP node............................. 14
6.2. State Machine.......................................... 15
6.2.1. INVITE received........................................ 16
6.2.1.1 INVITE to IAM procedures............................... 17
6.2.2. ISUP T7 expires........................................ 19
6.2.3. CANCEL or BYE received................................. 19
6.2.4. REL received........................................... 20
6.2.4.1 ISDN Cause Code to SIP Status Code mapping............. 20
6.2.5. Early ACM received..................................... 23
6.2.6. ACM received........................................... 23
6.2.7. CON or ANM received.................................... 24
6.2.8. Timer T9 expires....................................... 24
6.2.9. CPG received........................................... 24
6.2.10. ACK received........................................... 25
7. ISUP to SIP mapping.................................... 25
7.1. Call Flows............................................. 25
7.1.1. En-bloc call setup (non auto-answer)................... 25
7.1.2. Auto-answer call setup................................. 27
7.1.3. SIP Timeout............................................ 27
7.1.4. ISUP T9 Expires........................................ 28
7.1.5. SIP Error Response..................................... 30
7.1.6. SIP Redirection........................................ 30
7.1.7. Call Cancelled by ISUP................................. 32
7.2. State Machine.......................................... 33
7.2.1. Initial Address Message received....................... 34
7.2.1.1 IAM to INVITE procedures............................... 34
7.2.2. 100 received........................................... 36
7.2.3. 18x received........................................... 36
7.2.4. 200 received........................................... 37
7.2.5. 3xx received........................................... 38
7.2.6. 4xx - 6xx received..................................... 38
7.2.6.1 SIP Status Code to ISDN Cause Code mapping............. 38
7.2.7. REL received........................................... 40
Camarillo/Roach/Peterson/Ong [Page 2]
ISUP to SIP Mapping August 2001
7.2.8. ISUP T11 Expires....................................... 40
8. Suspend/Resume and hold................................ 41
8.1. SUS and RES............................................ 41
8.2. Hold (re-INVITE)....................................... 41
9. Normal Release of the Connection....................... 42
9.1. SIP initiated.......................................... 42
9.2. ISUP Initiated......................................... 43
9.2.1. Caller hangs up........................................ 43
9.2.2. Callee hangs up........................................ 43
10. ISUP maintenance messages.............................. 43
10.1. Reset messages......................................... 44
10.2. Blocking messages...................................... 44
10.3. Continuity checks...................................... 44
11. Construction of Telephony URIs......................... 45
12. Other ISUP flavors..................................... 48
12.1. Guidelines to send other ISUP messages................. 49
13. Acronyms............................................... 50
14. Acknowledgments........................................ 51
15. Revision History....................................... 51
16. References............................................. 51
17. Security Considerations................................ 53
18. Authors' Addresses..................................... 53
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.
ISUP [2] is a level 4 protocol used in SS7 networks. It typically
runs over MTP although it can also run over IP [15]. 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 PSTN) and with IP
interfaces (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
Camarillo/Roach/Peterson/Ong [Page 3]
ISUP to SIP Mapping August 2001
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 protcols. It also describes the interplay between parallel state
machines for these two protocols as a recommendation for implementors
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. The
purpose of translation in ISUP-SIP interworking is twofold: for ISUP
calls that traverse a SIP network, translation allows SIP elements
such as proxy servers to make routing decisions based on ISUP
criteria such as the called party number; translation also provides
critical information about the call to SIP endpoints that cannot
understand encapsulated ISUP (or perhaps which merely cannot
understand the particular ISUP variant in use).
This document 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
message 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. ITU-T Q.767 International ISUP [2]
is used through this document; some differences with ANSI ISUP [3]
and TTC ISUP are outlined. ISUP Q.767 [2] is used in this document
because it is the least complex of all the ISUP flavors. Due to the
small number of fields that map directly from ISUP to SIP, the
signaling differences between Q.767 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 standarized practices
for Local Number Portability since portability tends to be grounded
in national numbering plan practices, and that consequently LNP must
be described on a virtually per-nation basis.
Mapping of SIP headers to ISUP parameters in this document focuses
Camarillo/Roach/Peterson/Ong [Page 4]
ISUP to SIP Mapping August 2001
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 ACM and REL messages 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. 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 [4]). 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 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
Camarillo/Roach/Peterson/Ong [Page 5]
ISUP to SIP Mapping August 2001
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 17. If the recipient of these messages (typically a SIP
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 [15]. 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.
4. 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.).
4.1. "Transparent" Transit of ISUP messages
To provide users the ability to take advantage of the full range of
services afforded by the existing telephone network when placing
Camarillo/Roach/Peterson/Ong [Page 6]
ISUP to SIP Mapping August 2001
calls from PSTN to PSTN across a SIP network, SIP messages will need
to carry ISUP payloads from gateway to gateway. The format for
carrying these messages is defined in "MIME media types for ISUP and
QSIG Objects" [4] .
SIP clients and servers which do not understand ISUP are permitted to
ignore these (and other) optional MIME bodies.
4.2. Understanding of Multipart Bodies
In most PSTN interworking situations, the SIP body will be required
to carry session information (SDP) in addition to ISUP and/or billing
information.
PSTN interworking nodes should understand the MIME type of
"multipart/mixed" as defined in RFC2046 [5] . Clients express support
for this by including "multipart/mixed" in an "Accept" header.
4.3. Transmission of DTMF information
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 should
be performed as described in "RTP Payload for DTMF Digits, Telephony
Tones and Telephony Signals" [6], and is in all respects orthogonal
to the mapping of ISUP and SIP.
4.4. Reliable Transmission of Provisional Responses
Provisional responses are used in the transmission of various call
progress information. PSTN interworking in particular relies on these
messages for control of the media channel and timing of messages.
PSTN interoperation nodes should implement the extension defined in
"Reliability of Provisional Responses in SIP" [8] .
4.5. Provisional Media Streams
To allow the transmission of messages and tones before a final
connection has been established, SIP nodes which interwork with the
PSTN need to be able to establish temporary media connections during
this period.
PSTN interoperating nodes should support the establishment of
temporary provisional media streams using the 183 status code
(described in [9]).
Camarillo/Roach/Peterson/Ong [Page 7]
ISUP to SIP Mapping August 2001
4.6. Mid-Call Transactions Which do not Change SIP State
When interworking with PSTN, there are situations when PSTN nodes
will need to send messages which do not correspond to any SIP
operations to each other across a SIP network.
The method for performing this transit will be in the INFO method,
defined in "The SIP INFO Method" [10] .
Nodes which do serve as PSTN interworking points should accept "405
Method Not Allowed" and "501 Not Implemented" responses to INFO
requests as non-fatal.
5. 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 RLC, waiting for
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 / 6.2.1' indicates that an INVITE request has
been received by the gateway, and the procedure upon reception is
described in the section 6.2.1 of this document.
6. SIP to ISUP mapping
6.1. 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, since their presence is optional.
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."
Camarillo/Roach/Peterson/Ong [Page 8]
ISUP to SIP Mapping August 2001
6.1.1. En-bloc Call Setup (non auto-answer)
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
5|----------PRACK---------->| |
6|<----------200------------| |
| |<-----------CPG-----------|7
8|<----------18x------------| |
9|----------PRACK---------->| |
10|<----------200------------| |
| |<-----------ANM-----------|11
| |<=========Audio==========>|
12|<----------200------------| |
|<=========Audio==========>| |
13|-----------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 6.2.5 and 6.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 12.
(5) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed.
(7) If the ISUP variant permits,
the remote ISUP node may issue a variety of CPG messages to
indicate, for example, that the call is being forwarded.
Camarillo/Roach/Peterson/Ong [Page 9]
ISUP to SIP Mapping August 2001
(8) Upon receipt of a CPG message, the gateway will map the event
code to a SIP provisional response (see section 6.2.9. ) and
send it to the SIP node.
(9) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(10) The PRACK is confirmed
(11) Once the PSTN user answers, an ANM message will be sent to
the gateway.
(12) Upon receipt of the ANM, the gateway will send a 200 message
to the SIP node.
(13) The SIP node, upon receiving an INVITE final response (200),
will send an ACK to acknowledge receipt.
6.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 CON message 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.
Camarillo/Roach/Peterson/Ong [Page 10]
ISUP to SIP Mapping August 2001
6.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.
6.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 *** | |
Camarillo/Roach/Peterson/Ong [Page 11]
ISUP to SIP Mapping August 2001
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.
6.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.
Camarillo/Roach/Peterson/Ong [Page 12]
ISUP to SIP Mapping August 2001
(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 6.2.4.) and sends it to the SIP
node.
(6) The SIP node sends an ACK to acknowledge receipt of the
INVITE final response.
6.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===========| |
5|----------PRACK---------->| |
6|<----------200------------| |
** Interwork timer expires **
7|<----------4xx+-----------| |
| |------------REL---------->|8
| |<-----------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) 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
Camarillo/Roach/Peterson/Ong [Page 13]
ISUP to SIP Mapping August 2001
establish early media cut-through.
(5) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed.
(7) 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 6.2.4. for the table
which contains the mapping from cause code to SIP response.
(8) 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 6.1.7.
(9) Upon receipt of the REL message, the remote ISUP node will
reply with an RLC message.
(10) The SIP node sends an ACK to acknowledge receipt of the
INVITE final response.
6.1.7. Call cancelled by SIP node
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
5|----------PRACK---------->| |
6|<----------200------------| |
| ** MG Releases IP Resources ** |
7|----------CANCEL--------->| |
8|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|9
10|<----------487------------| |
| |<-----------RLC-----------|11
12|-----------ACK----------->| |
(1) When a SIP user wishes to begin a session with a PSTN user,
the SIP node issues an INVITE request.
Camarillo/Roach/Peterson/Ong [Page 14]
ISUP to SIP Mapping August 2001
(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 6.2.5 and 6.2.6)
and returned to the SIP node. This
response may contain SDP to establish an early media stream.
(5) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed.
(7) To cancel the call before it is answered, the SIP node sends
a CANCEL request.
(8) The CANCEL request is confirmed with a 200 response.
(9) Upon receipt of the CANCEL request, the gateway sends a REL
message to terminate the ISUP call.
(10) The gateway sends a "487 Call Cancelled" message to the SIP
node to complete the INVITE transaction.
(11) Upon receipt of the REL message, the remote ISUP node will
reply with an RLC message.
(12) Upon receipt of the 487, the SIP node will confirm reception
with an ACK.
6.2. State Machine
Note that REL can be received in any state; the handling is the same
for each case (see section 6.2.4. ).
Camarillo/Roach/Peterson/Ong [Page 15]
ISUP to SIP Mapping August 2001
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ |
| | 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 +------------>+
+-------------------------+
6.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 MGC
is handling the call.
The resources for the media stream have to be reserved at this stage,
since an IAM message cannot be sent before the resource reservation
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 QoS or/and security provisions. Before sending the IAM the
Camarillo/Roach/Peterson/Ong [Page 16]
ISUP to SIP Mapping August 2001
MG generally connects the backward media path.
After sending the IAM the timer T7 is started. The default value of
T7 is between 20 and 30 seconds. The MGC goes to the `Trying' state.
6.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 IAM.
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).
There are quite a few optional parameters that can appear in an IAM
message; Q.763 [20] 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 PSTN context of the session 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 any encapsulated ISUP (see [4]) to assist in
the formulation of outbound PSTN signaling. However, three conditions
can complicate this process:
o There is no ISUP encapsulated in the SIP INVITE - the SIP INVITE
originated at a device other than an ISUP-SIP gateway.
o There is encapsulated ISUP, but the gateway cannot understand
the ISUP variant and therefore the ISUP must be discarded.
o There is encapsulated ISUP, but there is more recent session
context information available in the SIP headers, and consequently
the SIP headers must 'overwrite' the encapsulated ISUP.
In all of these cases translation must be performed. Gateways should
use default values for mandatory ISUP parameters that are not derived
Camarillo/Roach/Peterson/Ong [Page 17]
ISUP to SIP Mapping August 2001
from translation or encapsulation (such as the NCI or TMR
parameters). The FCI parameter should also have a default, although
its 'M' bit may be overwritten during the process of translation.
First, the Request-URI should be inspected.
If there is no 'npdi=yes' field within the Request-URI, then the main
telephone number in the tel URL (the digits immediately following
'tel:') should be converted to ISUP format, following the procedure
described in section 11, and used to populate the CPN parameter.
In ANSI networks, if the 'npdi=yes' field exists in the Request-URI,
then the FCI parameter bit for 'number translated' within the IAM
should 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 should be
converted to ISUP format (see section 11) and used to populate the
CPN parameter.
If in addition to the 'npdi=yes' field an 'rn=' field is present,
then in ANSI networks the 'rn=' field should be converted to ISUP
format and used to populate the CPN. The main telephone number in the
tel URL should be converted to ISUP format and used to populate the
Generic Digits Parameter (or GAP in ANSI). In some networks the
number given in the 'rn=' field should be prepended to the main
telephone number and the combined result should be used to populate
the CPN.
If main 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.
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 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) may dictate whether the CIP or TNS parameter should be
used (although note that in non-ANSI networks the CIP will never be
used). 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
NoA field of the CPN indicates that this is an international number),
and the CIP should be used in other cases.
If a SIP call has arrived at a gateway, then the Request-URI will
Camarillo/Roach/Peterson/Ong [Page 18]
ISUP to SIP Mapping August 2001
most likely contain a tel URL (or a SIP URI with a tel URL user
portion). However, if the call originated at a native IP endpoint
such as a SIP phone, the From field may not reflect any telephone
number - it may be a simple user@host construction. The CIN parameter
should be omitted from the outbound IAM if the From field is
unusable.
Note that when the ISUP parameters regarding interworking are set in
the Forward Call Indicators (FCI) parameter of the IAM , this
indicates that ISDN is interworking with a network which is not
capable of providing as many services as ISDN does. ISUP will
therefore not employ certain features it otherwise normally uses.
Thus, `interworking encountered' must not be specified so that ISUP
behaves normally. SIP is considered as an SS7 network and a SIP phone
is considered as ISDN access since the SIP network is supposed to
provide at least as many services as ISUP.
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 [13] . 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.
6.2.2. ISUP T7 expires
Since no response was received from the PSTN all the resources in the
MG are released. A `504 gateway timeout' is sent back to the SIP
network. A REL message with cause value 102 (protocol error, recovery
on timer expiry) is sent to the PSTN. The PSTN responds with RLC and
the SIP network responds with an ACK indicating that the release
sequence has been completed.
6.2.3. CANCEL or BYE received
If a CANCEL or BYE request is received, a `200 OK' is sent to the SIP
network to confirm the CANCEL or BYE; a 487 is also sent to terminate
the INVITE transaction. All the resources are released and a REL
message is sent to the PSTN with cause value 16 (normal clearing). A
RLC from the PSTN is received indicating that the release sequence is
complete.
It is important that all the resources are released before the
gateway sends any REL message.
In SIP bridging situations, a REL might arrive in the CANCEL or BYE
request body. This REL is sent to the PSTN.
Camarillo/Roach/Peterson/Ong [Page 19]
ISUP to SIP Mapping August 2001
This section ( 6.2.3. ) applies every time that a CANCEL or a BYE is
received before a final SIP response has been sent.
6.2.4. REL received
This section applies every time that a REL is received before a final
SIP response has been sent.
The resources are released in the MG and a RLC is sent to the ISUP
network to indicate that the circuit is available for reuse.
If the INVITE originating this transaction contained an ISUP message
in its body (such as an IAM), the MGC is handling a SIP bridging
situation. Therefore, the REL message just received should be
included in the body of the response.
Note that the receipt of certain maintenance messages in response to
IAM such as BLO or RSC (or their circuit group message equivalents)
may also result in the teardown of calls in this phase of the state
machine. Behavior for maintenance messages is given below in section
10.
6.2.4.1 ISDN Cause code to SIP Status Code mapping
An REL message contains an ISDN Cause Code (see [16]) in the Cause
Indicator (CAI) parameter. Most ISUP variants (including ANSI and
ETSI) use these cause codes to represent conditions surrounding the
termination of a call.
In addition to the ISDN Cause Code, the CAI parameter also contains a
cause 'location' that gives some sense of which entity in the network
was responsible for terminating the call (the most important
distinction being between the user and the network). In most cases,
the cause location does not affect the mapping to a SIP status code;
some exceptions are noted below. A diagnostic field may also be
present for some ISDN causes; this diagnostic will contain additional
data pertaining to the termination of the call.
The use of the REL message in the SS7 network is very general,
whereas SIP has a number of specific tools that, collectively, play
the same role as REL - namely BYE, CANCEL, and the status codes. An
REL can be sent to tear down a call that is already in progress
(BYE), to cancel a previously sent call setup request (IAM) that has
not yet been completed (CANCEL), or to reject a call setup request
(IAM) that has just been received (corresponding to a SIP status
code).
If a cause value other than what is listed below is received, the
Camarillo/Roach/Peterson/Ong [Page 20]
ISUP to SIP Mapping August 2001
default response `500 Server internal error' would be used.
Note that it is not necessarily appropriate to map some ISDN cause
codes to SIP messages because these cause codes are only meaningful
to the ISUP interface of a gateway. A good example of this is cause
code 44 "Request circuit or channel not available." 44 signifies that
the Circuit Identification Code (CIC) for which an IAM had been sent
was believed by the receiving equipment to be in a state incompatible
with a new call request - however, the appropriate behavior in this
case is for the originating switch to re-send the IAM for a different
CIC, not for the call to be torn down. Clearly, there is not (nor
should there be) an SIP status code indicating that a new CIC should
be selected - this matter is internal to the originating gateway.
Hence receipt of cause code 44 should not result in any SIP status
code being sent; effectively, the cause code is untranslatable.
Normal event
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing --- (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 302 Moved Temporarily
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable
(*) ISDN Cause 16 will usually result in a BYE or CANCEL
(+) If the cause location is 'user' than the 6xx code could be given
rather than the 4xx code (i.e. 403 becomes 603)
(=) ANSI procedure - in ANSI networks, 26 is overloaded to
signify 'misrouted ported number'. Presumably, a number portability
dip should have been performed by a prior network.
A REL with ISDN cause 22 (number changed) might contain information
about a new number where the callee might be reachable in the
Camarillo/Roach/Peterson/Ong [Page 21]
ISUP to SIP Mapping August 2001
diagnostic field. If the MGC is able to parse this information it
might be added to the SIP response (301) in a Contact header.
Resource unavailable
This kind of cause value indicates a non permanent situation. A
`Retry-After' header has to be added to the response.
ISUP Cause value SIP response
---------------- ------------
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
41 temporary failure 503 Service unavailable
42 switching equipment congestion 503 Service unavailable
47 resource unavailable 503 Service unavailable
Service or option not available
This kind of cause value indicates a permanent situation
ISUP Cause value SIP response
---------------- ------------
55 incoming calls barred within CUG 403 Forbidden
57 bearer capability not authorized 403 Forbidden
58 bearer capability not presently 503 Service unavailable
available
Service or option not implemented
ISUP Cause value SIP response
---------------- ------------
65 bearer capability not implemented 501 Not implemented
79 service or option not implemented 501 Not implemented
Invalid message
ISUP Cause value SIP response
---------------- ------------
87 user not member of CUG 503 Service unavailable
88 incompatible destination 503 Service unavailable
95 invalid message 503 Service unavailable
Protocol error
Camarillo/Roach/Peterson/Ong [Page 22]
ISUP to SIP Mapping August 2001
ISUP Cause value SIP response
---------------- ------------
102 recovery of timer expiry 408 Request timeout
111 protocol error 500 Server internal error
Interworking
ISUP Cause value SIP response
---------------- ------------
127 interworking unspecified 500 Server internal error
6.2.5. Early ACM received
This message is sent in certain situations for resetting the timers.
In these cases this message indicates that the call is in progress
but callee is not being alerted. This occurs for example in mobile
networks, where roaming can take a long time. The early ACM is sent
before the user is alerted to reset T7 and start T9.
An ACM is considered an `early ACM' if the Called Party's Status
Indicator is set to 00 (no indication).
After receiving an early ACM the progress of the call is indicated by
the network sending CPGs.
When there is interworking with some old systems, it is possible to
receive an ANM immediately after an early ACM (without CPG). In this
situation the SIP user will not hear any kind of ringback tone before
the callee answers. In ISDN [11] this is solved by connecting the
voice path backwards before sending the IAM.
The MGC sends a 183 Session Progress [9] to the SIP network with a
media description inside. In SIP bridging situations the early ACM is
included in the response body. Thus, the problem of missing the ring
back tone is solved and the early ACM is transported transparently
through the SIP network.
6.2.6. ACM received
Upon reception of an ACM timer T9 is started. T9 typically lasts
between 90 seconds and 3 minutes [12] . It allows the caller to hear
announcements from the network for that period of time without being
charged for the connection. If longer announcements have to be played
the network has to send an ANM. When the ANM is sent the call begins
being charged.
Camarillo/Roach/Peterson/Ong [Page 23]
ISUP to SIP Mapping August 2001
The nearest local exchange to the callee generates the ringback tone
and may send voice announcements.
Usually on receipt of an ACM a `180 Ringing' is sent to the SIP
network. It should generally contain a session description in order
to allow SIP UAs to prevent clipping of initial callee media. The
ringback tone or the proper announcements will be generated by the
PSTN exchange, and not by the callers SIP UAC/UAS.
If the Backwards Call Indicator (BCI) parameter of the ACM indicates
that interworking has been encountered (generally designating that
the ISUP network sending the ACM is interworking with a less
sophisticated network which cannot support cause codes), then there
may be in-band announcements of call status such as an audible busy
tone or caller intercept message. In this case rather than a 180
status code, a 183 Session Progress message should be sent in order
to allow pre-ANM media to flow in the backwards direction.
In SIP bridging situations, the ACM is included in the body of the
180 response.
6.2.7. CON or ANM received
A `200 OK' response is sent to the SIP network. In SIP bridging
situations, the ISUP message is included in the body of the 200 OK
response. This is also the point at which a two-way media stream will
be established.
6.2.8. Timer T9 expires
This indicates that the ANM has not arrived in time specified. This
results in the call being aborted. All the resources related to the
media path are released. A `480 temporarily unavailable' is sent to
the SIP network. A REL message with cause value 19 (no answer from
the user) is sent to the ISUP part. The PSTN responds with RLC and
the SIP network responds with an ACK indicating that the release
sequence has been completed.
6.2.9. CPG received
A CPG can indicate progress, alerting or in-band information. If the
CPG comes after an ACM, there is already a one-way voice path open,
so there is no need of taking further action in the media path.
In SIP bridging situations, the CPG is sent in the body of a 18x
response, determined from the CPG event code.
ISUP event code SIP response
Camarillo/Roach/Peterson/Ong [Page 24]
ISUP to SIP Mapping August 2001
---------------- ------------
1 Alerting 180 Ringing
2 Progress 183 Call progress
3 In-band information 183 Call progress
4 Call forward; line busy 181 Call is being forwarded
5 Call forward; no reply 181 Call is being forwarded
6 Call forward; unconditional 181 Call is being forwarded
- (no event code present) 183 Call progress
Note that, if the CPG does not indicate "Alerting," the current state
will not change.
6.2.10. ACK received
At this stage, the call is connected and the conversation can take
place.
7. ISUP to SIP mapping
7.1. 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
PSTN network. "100 Trying" acknowledgements to INVITE requests are
not explained, since their presence is optional.
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 (non auto-answer)
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |=========================>|
| |------------ACM---------->|4
5|<---------PRACK-----------| |
6|-----------200----------->| |
7|-----------18x----------->| |
| |------------CPG---------->|8
9|<---------PRACK-----------| |
Camarillo/Roach/Peterson/Ong [Page 25]
ISUP to SIP Mapping August 2001
10|-----------200----------->| |
11|-----------200----------->| |
|<=========Audio==========>| |
| |------------ANM---------->|12
| |<=========Audio==========>|
13|<----------ACK------------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node.
(3) When an event signifying that the call has sufficient
addressing information occurs, the SIP node will generate a
provisional response of 180 or greater.
(4) Upon receipt of a provisional response of 180 or greater, the
gateway will generate an ACM message. If the response is not
180, the ACM will carry a "called party status" value of "no
indication."
(5) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) The SIP node may use further provisional messages to indicate
call progress.
(8) After an ACM has been sent, all provisional responses will
translate into ISUP CPG messages as indicated in 7.2.3.
(9) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(10) The PRACK is confirmed
(11) When the SIP node answers the call, it will send a 200 OK
message.
(12) Upon receipt of the 200 OK message, the gateway will send an
ANM message towards the ISUP node.
(13) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
Camarillo/Roach/Peterson/Ong [Page 26]
ISUP to SIP Mapping August 2001
7.1.2. Auto-answer call setup
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
on called number analysis.
(3) Since the SIP node is set up to automatically answer the
call, it will send a 200 OK message.
(4) Upon receipt of the 200 OK message, the gateway will send a
CON message towards the ISUP node.
(5) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.1.3. SIP Timeout
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
Camarillo/Roach/Peterson/Ong [Page 27]
ISUP to SIP Mapping August 2001
|<--------INVITE-----------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
6|<--------CANCEL-----------| |
| |<-----------RLC-----------|7
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
on called number analysis. The ISUP timer T11 and SIP timer
T1 are set at this time.
(3) The INVITE message will continue to be sent to the SIP node
each time the timer T1 expires. The SIP standard specifies
that INVITE transmission will be performed 7 times if no
response is received.
(4) When T11 expires, an ACM message will be sent to the ISUP
node to prevent the call from being torn down by the remote node's
ISUP T7. This ACM contains a `Called Party Status' value of
`no indication.'
(5) Once the maximum number of INVITE requests has been sent, the
gateway will send a REL (cause code 18) to the ISUP node to
terminate the
call.
(6) The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.
(7) Upon receipt of the REL, the remote ISUP node will send an
RLC to acknowledge.
7.1.4. ISUP T9 Expires
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
Camarillo/Roach/Peterson/Ong [Page 28]
ISUP to SIP Mapping August 2001
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T9 Expires *** |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<--------CANCEL-----------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
on called number analysis. The ISUP timer T11 and SIP timer
T1 are set at this time.
(3) The INVITE message will continue to be sent to the SIP node
each time the timer T1 expires. The SIP standard specifies
that INVITE transmission will be performed 7 times if no
response is received. Since SIP T1 starts at 1/2 second or
more and doubles each time it is retransmitted, it will be at
least a minute before SIP times out the INVITE request; since
SIP T1 is allowed to be larger than 500 ms initially, it is
possible that 7 x SIP T1 will be longer than ISUP T11 + ISUP
T9.
(4) When T11 expires, an ACM message will be sent to the ISUP
node to prevent the from being torn down by the remote node's
ISUP T7. This ACM contains a `Called Party Status' value of
`no indication.'
(5) When ISUP T9 in the remote PSTN node expires, it will send a
REL.
(6) Upon receipt of the REL, the gateway will send an RLC to
acknowledge.
(7) The REL will trigger a CANCEL request, which gets sent to the
SIP node.
Camarillo/Roach/Peterson/Ong [Page 29]
ISUP to SIP Mapping August 2001
7.1.5. SIP Error Response
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
on called number analysis.
(3) The SIP node indicates an error condition by replying with a
response with a code of 400 or greater.
(4) The gateway sends an ACK message to acknowledge receipt of
the INVITE final response.
(5) An ISUP REL message is generated from the SIP code, as
specified in section 7.2.6.
(6) The remote ISUP node confirms receipt of the REL message with
an RLC message.
7.1.6. SIP Redirection
SIP node 1 MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------3xx+---------->| |
| |------------CPG---------->|4
5|<----------ACK------------| |
| |
| |
SIP node 2 | |
6|<--------INVITE-----------| |
7|-----------18x----------->| |
|<=========Audio===========| |
| |------------ACM---------->|8
Camarillo/Roach/Peterson/Ong [Page 30]
ISUP to SIP Mapping August 2001
9|<---------PRACK-----------| |
10|-----------200----------->| |
11|-----------200----------->| |
|<=========Audio==========>| |
| |------------ANM---------->|12
| |<=========Audio==========>|
13|<----------ACK------------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
on called number analysis.
(3) The SIP node indicates that the resource which the user is
attempting to contact is at a different location by sending a
3xx message.
(4) The gateway sends a CPG with event indication that the call
is being forwarded upon receipt of the 3xx message. Note that
this translation should be able to be disabled by
configuration, as some ISUP nodes do not support receipt of
CPG messages before ACM messages.
(5) The gateway acknowledges receipt of the INVITE final response
by sending an ACK message to the SIP node.
(6) The gateway re-sends the INVITE message to the address
indicated in the Contact: field of the 3xx message.
(7) When an event signifying that the call has sufficient
addressing information occurs, the SIP node will generate a
provisional response of 180 or greater.
(8) Upon receipt of a provisional response of 180 or greater, the
gateway will generate an ACM message with an event code as
indicated in section 7.2.3.
(9) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(10) The PRACK is confirmed
(11) When the SIP node answers the call, it will send a 200 OK
message.
Camarillo/Roach/Peterson/Ong [Page 31]
ISUP to SIP Mapping August 2001
(12) Upon receipt of the 200 OK message, the gateway will send an
ANM message towards the ISUP node.
(13) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.1.7. Call Cancelled by ISUP
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
5|<---------PRACK-----------| |
6|-----------200----------->| |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|7
| |------------RLC---------->|8
9|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
10|-----------200----------->| |
11|-----------487----------->| |
12|<----------ACK------------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
on called number analysis.
(3) When an event signifying that the call has sufficient
addressing information occurs, the SIP node will generate a
provisional response of 180 or greater.
(4) Upon receipt of a provisional response of 180 or greater, the
gateway will generate an ACM message with an event code as
indicated in section 7.2.3.
(5) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) If the calling party hangs up before the SIP node answers the
Camarillo/Roach/Peterson/Ong [Page 32]
ISUP to SIP Mapping August 2001
call, a REL message will be generated.
(8) The gateway frees the PSTN circuit and indicates that it is
available for reuse by sending an RLC.
(9) Upon receipt of a REL message before an INVITE final
response, the gateway will send a CANCEL towards the SIP
node.
(10) Upon receipt of the CANCEL, the SIP node will send a 200
response.
(11) The remote SIP node will send a "487 Call Cancelled" to
complete the INVITE transaction.
(12) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.2. State Machine
Note that REL may arrive in any state. Whenever this occurs, the
actions in section 7.2.7. are taken. Not all of these transitions are
shown in this diagram.
Camarillo/Roach/Peterson/Ong [Page 33]
ISUP to SIP Mapping August 2001
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | IAM/7.2.1 |
| V |
| REL/7.2.7 +-------------------------+ 400+/7.2.6 |
+<----------------+ Trying |------------>|
| +-+--------+------+-------+ |
| | | | |
| | T11/ | 18x/ | 200/ |
| | 7.2.8 |7.2.3 | 7.2.4 |
| V | | |
| REL/7.2.7 +--------------+ | | 400+/7.2.6 |
|<----------| Progressing |-|------|-------------------->|
| +--+----+------+ | | |
| | | | | |
| 200/ | | 18x/ | | |
| 7.2.4 | | 7.2.3 | | |
| | V V | |
| REL/7.2.7 | +---------------+ | 400+/7.2.6 |
|<-------------|--| Alerting |-|-------------------->|
| | +--------+------+ | |
| | | | |
| | | 200/ | |
| | | 7.2.4 | |
| V V V |
| BYE/9.1 +-----------------------------+ REL/9.2 |
+<------------+ Connected +------------>+
+-----------------------------+
7.2.1. Initial Address Message received
Upon the reception of an IAM, resources are reserved in the media
gateway and it connects audio in the backwards direction (towards the
caller).
7.2.1.1 IAM to INVITE procedures
When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message will
be created for transmission to the SIP network. This section details
the process by which a gateway populates the INVITE based on
parameters found within the IAM.
The session context information discovered by the gateway in the IAM
will be stored primarily in two URIs in the INVITE, one representing
the originator of the session and the other the destination. The
former will always appear in the From header (after it has been
Camarillo/Roach/Peterson/Ong [Page 34]
ISUP to SIP Mapping August 2001
converted from ISUP format by the procedure described in section 11),
and the latter is almost always used for both the To header and the
Request-URI.
The construction of destination URI begins with determining which
ISUP parameter currently contains the called party number. Usually,
this will be the CPN parameter. However, if the destination number
has been ported (see [x]) and a dip to the relevant LNP database has
already been performed, then the called party number will, in some
ISUP variants include ANSI, in fact appear in the Generic Digits
Parameter or GAP. Generally in such variants the 'number translated'
bit of the FCI parameter should be consulted to determine whether the
called party number is in the CPN parameter or the GAP parameter. In
other variants, if a portability dip has been performed the routing
number may be founded prepended to the called party number in the CPN
parameter.
Once the location of the called party number has been determined, it
should be translated into a tel URL through the mechanism described
above. Some additional fields may need to be added to the tel URL
after translation has been completed, namely:
o If (in ANSI networks) the FCI 'number translated' bit indicated
that an LNP dip had been performed, or (in other variants) if a
routing number has been prepended to the CPN, then an 'npdi=yes'
field must be appended to the tel URL. If the routing number is not
present in the CPN, then if a Generic Digits Parameter (or GAP in
ANSI) is present in the IAM, then the contents of the CPN should be
translated from ISUP format (as described above) and copied into an
'rn=' field which must be appended to the tel URL. Note that
Location Routing Numbers (LRNs) stored in CPN for calls to ported
numbers are necessarily national in scope, and consequently they
will not be preceded by a '+' in the 'rn=' field. For further
information on these tel URL fields see [17].
o If either the CIP (in ANSI networks) or TNS is present, the
carrier identification code (CIC) should be extracted from the
parameter and analyzed by the gateway. If doing so is in keeping
with local policy (i.e. provided that the CIC does not indicate
the network which owns the gateway or some similar condition), a
'cic=' field with the value of the CIC should be appended to the
tel URL. Note that the CIC should be prefixed with the country code
used or implied in the called party number, so that CIC '5062'
becomes, in the United States, '+1-5062'. For further information
on the 'cic=' tel URL field see [17].
In most cases, the resulting URI should be used in the To field and
Request-URI sent by the gateway. However, if the OCN parameter is
Camarillo/Roach/Peterson/Ong [Page 35]
ISUP to SIP Mapping August 2001
present in the IAM, the To field constructed from the translation of
the OCN parameter, and hence the Request-URI and To field will be
different.
The construction of the From field is dependent on the presence of a
CIN parameter. If the CIN is not present, then the gateway should
create a dummy From header containing a SIP URI without a user
portion which communicates only the hostname of the gateway (e.g.
'sip:gw.level3.net'). If the CIN is available, then it should be
translated (in accordance with the procedure described above) into a
tel URL which should populate the From field.
7.2.2. 100 received
A 100 response does not trigger any PSTN interworking messages; it
only serves the purpose of suppressing INVITE retransmissions.
7.2.3. 18x received
If no ACM has been sent yet and no ISUP is present in the 18x message
body, and ISUP message is generated according to the following table.
Note that, if an early ACM is sent, the call enters state
"Progressing" instead of state "Alerting."
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing ACM
181 Call is being forwarded Early ACM and CPG, event=6
182 Queued ACM
183 Session progress message ACM
If an ACM has already been sent and no ISUP is present in the 18x
message body, an ISUP message is generated according to the following
table.
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing CPG, event = 1 (Alerting)
181 Call is being forwarded CPG, event = 6 (Forwarding)
182 Queued CPG, event = 2 (Progress)
183 Session progress message CPG, event = 2 (Progress)
If the reception of a `180 Ringing' response without media
description, the MG generates the ringback tone to be heard by the
caller.
If the MGC receives any 1xx response (except 100) with a session
description present for media setup, it sets up the session being
Camarillo/Roach/Peterson/Ong [Page 36]
ISUP to SIP Mapping August 2001
described. The call progress media (e.g. ringback tone or
announcement) is generated by an entity downstream (in the SIP
network or by a PSTN exchange in SIP bridging situations).
If an ACM has not been sent yet, one is generated and sent. The
mandatory parameters of the ACM are described below:
Message type: ACM
Backward Indicators
Charge indicator: 10 charge
Called party's status indicator: 01 subscriber free or
00 no indication (E.ACM)
Called party's category indicator: 01 ordinary subscriber
End-to-end method indicator: 00 no end-to-end method
Interworking indicator: 0 no interworking
End-to-end information indicator: 0 no end-to-end info
ISDN user part indicator: 1 ISUP all the way
Holding indicator: 0 no holding
ISDN access indicator: 1 ISDN access
Echo control device indicator: It depends on the call
SCCP method indicator: 00 no indication
In SIP bridging situations the MGC sends the ISUP message contained
in the response body.
Note that sending 183 before a gateway has confirmation that the
address is complete (ACM) creates known problems in SIP bridging
cases, and it should therefore be avoided.
7.2.4. 200 received
Response received Message sent by the MGC
----------------- -----------------------
200 OK ANM, ACK
After receiving a 200 OK response the MGC establishes a two-way voice
path in the MG and it sends an ANM to the PSTN and an ACK to the SIP
network.
If the `200 OK' response arrives before the MGC has sent the ACM, a
CON is sent instead of the ANM.
In SIP bridging situations the MGC sends the ANM or the CON in the
response body.
Camarillo/Roach/Peterson/Ong [Page 37]
ISUP to SIP Mapping August 2001
7.2.5. 3xx received
When any 3xx response is received ,the MGC should try to contact the
user using the `Contact' header or headers present in the response.
These 3xx responses are typically sent by a re-direct server. This is
a similar device to the HLR in mobile networks. It provides another
address where the callee may be reached.
A CPG message with an event code of 2 (Progress) may be sent to
indicate that the call is proceeding. Note that some ISUP nodes may
not support CPG before ACM, so this feature should be configurable.
If the new location presented in the Contact header of a 3xx is best
reachable (according to the gateway's routing policies) via the PSTN,
the MGC sends a new IAM and from that moment on acts as a normal PSTN
switch (no SIP involved). If the new location is best reachable using
SIP, the MGC sends an INVITE with possibly a new IAM generated by the
MGC in the message body.
All redirection situations have to be treated very carefully because
they involved special charging situations. In PSTN the caller
typically pays the first call leg and the callee pays the second.
7.2.6. 4xx - 6xx received
The MGC releases the resources in the MG, send a REL to the PSTN with
a cause value and send an ACK to the SIP network. An RLC arrives
indicating that the release sequence is complete.
7.2.6.1 SIP Status Code to ISDN Cause Code mapping
By default, the cause location associated with the CAI parameter
should be encoded such 6xx codes are given the location 'user',
whereas 4xx and 5xx codes are given a 'network' location. Exceptions
are marked below.
Any SIP status codes not listed below (associated with SIP
extensions, versions of SIP subsequent to the issue of this document,
or simply omitted) should be mapping to cause code 31 "Normal,
unspecified".
Just as there are certain ISDN cause codes that are ISUP-specific and
have no corollary SIP action, so there are SIP status codes that
should not be translated to ISUP. Examples are flagged with (+)
below.
Response received Cause value in the REL
----------------- ----------------------
Camarillo/Roach/Peterson/Ong [Page 38]
ISUP to SIP Mapping August 2001
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option
unavailable
406 Not acceptable 79 Service/option not
implemented
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
409 Conflict 48 Temporary failure
410 Gone 22 Number changed
(w/o diagnostic)
411 Length required 127 Interworking (+)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not
implemented (+)
420 Bad extension 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
483 Too many hoops 25 Exchange - routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
488 Not Acceptable here --- by Warning header
500 Server internal error 41 Temporary failure
501 Not implemented 38 Network out of order
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Server time-out 102 Recovery on timer expiry
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable --- by Warning header
(*) In some cases, it may be possible for a SIP 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 cause code 21 be sent.
(+) If at all possible, a SIP gateway should respond to these protocol
errors by remedying unacceptable behavior and attempting to re-originate
the session. Only if this proves impossible should the SIP gateway fail
the ISUP half of the call.
When the Warning header is present in a SIP 606 or 488 message, there
may be specific ISDN cause code mappings appropriate to the Warning
Camarillo/Roach/Peterson/Ong [Page 39]
ISUP to SIP Mapping August 2001
code. This document assumes that sending '31 Normal, unspecified'
will be sufficient for all currently assigned Warning codes.
7.2.7. REL received
The MGC should abort the establishment of the session. A CANCEL
request has to be issued. A BYE is not used, since no final response
has arrived from the SIP side. A 200 OK for the CANCEL arrives, and a
487 for the INVITE arrives.
The MGC has to store state information for a certain period of time,
since a 200 final response for the INVITE originally sent might
arrive (even after the reception of the 200 OK for the CANCEL). In
this situation, the MGC sends an ACK and then a BYE.
In SIP bridging situations, the REL message may be included in the
CANCEL message body. CANCEL requests are answered with a final
response (such as 200 OK) by the first proxy. Therefore, the MGC does
not know if the CANCEL has arrived to the end user (egress MGC in
this scenario). Hence, if a 200 OK response for the previously sent
INVITE arrives the MGC sends an ACK and then a BYE with the REL in
the message body.
7.2.8. ISUP T11 Expires
In order to prevent the remote ISUP node's timer T7 from expiring,
the gateway may choose to keep its own supervisory timer; ISUP
defines this timer as T11. T11's duration is carefully chosen so that
it will always be shorter than the T7 of any node to which the
gateway is communicating.
To clarify timer T11's relevance with respect to SIP interworking,
Q.764 [14] explains its use as: "If in normal operation, a delay in
the receipt of an address complete signal from the succeeding network
is expected, the last common channel signaling exchange will
originate and send an address complete message 15 to 20 seconds
[timer (T11)] after receiving the latest address message." Since SIP
nodes have no obligation to respond to an INVITE request within 20
seconds, SIP interworking inarguably qualifies as such a situation.
If the gateway's T11 expires, it will send an early ACM (i.e. called
party status set to "no indication") to prevent the expiration of the
remote node's T7. See section 7.2.3. for the value of the ACM
parameters.
If a "180 Ringing" message arrives subsequently, it will be sent in a
CPG, as shown in section 7.2.3.
Camarillo/Roach/Peterson/Ong [Page 40]
ISUP to SIP Mapping August 2001
See 7.1.3. for an example callflow that includes the expiration of
T11.
8. Suspend/Resume and hold
8.1. SUS and RES
In ISDN networks, a user can generate a SUS (timer T2, user
initiated) in order to unplug the terminal from the socket and plug
it in another one. A RES is sent once the terminal has been
reconnected and the T2 timer has not expired.
When a SUS arrives from the PSTN, the MGC should send an INVITE to
put the media stream on hold. The reception of a RES triggers a re-
INVITE that resumes the media stream. For the SIP UAC/UAS the result
is an interruption in the voice path until the other party picks up
the phone again. Putting the media on hold insures that bandwidth is
conserved when no audio traffic needs to be transmitted.
In some instances it may be undesirable to put the media for a call
on hold when a SUS is received. In these instances a re-INVITE should
still be used to carry the SUS message; however, the SDP within the
INVITE should repeat the last SDP given rather than substituting the
'null' SDP used to put calls on hold (i.e. in which the c= line or
port in the m= line indicates '0').
In SIP bridging situations, the SUS and RES messages can be
transferred in the body of the INVITE.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
The handling of a network-initiated SUS immediately prior to call
teardown is handled in section 9.2.2.
8.2. Hold (re-INVITE)
After a call has been connected, a re-INVITE may be sent to a gateway
from the SIP side in order to place the call on hold. This re-INVITE
will have an SDP indicating that the originator of the re-INVITE no
longer wishes to receive media.
Camarillo/Roach/Peterson/Ong [Page 41]
ISUP to SIP Mapping August 2001
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|-----------200----------->| |
4|<----------ACK------------| |
When such a re-INVITE is received, the gateway should send a Call
Progress Message (CPG) in order to express that the call has been
placed on hold. The CPG should contain a Generic Notification
Indicator (or, in ANSI networks, a Notification Indicator) with a
value of 'remote hold'.
If subsequent to the sending of the re-INVITE the SIP side wishes to
take the remote end off hold, and to begin receiving media again, it
may repeat the flow above with an INVITE that contains an SDP with a
reachable media destination. The Generic Notification Indicator would
in this instance have a value of 'remote retrieval' (or in some
variants 'remote hold released').
Finally, note that a CPG with hold indicators may be received by a
gateway from the PSTN. In the interests of conserving bandwidth, the
gateway may wish to stop sending media until the call is resume,
and/or send a re-INVITE to the SIP leg of the call requesting that
the remote side stop sending media.
9. Normal Release of the Connection
Either the SIP side or the ISUP side may release a call, regardless
of which side initiated the call.
9.1. SIP initiated
For a normal release of the call (reception of BYE), the MGC
immediately sends a 200 response. It then releases the resources in
the MG and sends an REL with a cause code of 16 (normal call
clearing) to the PSTN. Release of resources is confirmed by the PSTN
with a RLC.
In SIP bridging situations, the REL contained in the BYE is sent to
the PSTN.
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|4
Camarillo/Roach/Peterson/Ong [Page 42]
ISUP to SIP Mapping August 2001
9.2. ISUP Initiated
If the release of the connection was caused by the reception of a
REL, the REL is included in the BYE sent by the MGC.
9.2.1. Caller hangs up
For a normal release of the call (reception of REL from the PSTN),
the MGC first releases the resources in the MG and then confirms that
they are ready for re-use by sending an RLC. The SIP connection is
released by sending a BYE (which is confirmed with a 200).
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
9.2.2. Callee hangs up
In analog PSTN, if the callee hangs up in the middle of a call, the
local exchange sends a SUS instead of a REL and starts a timer (T6,
SUS is network initiated). When the timer expires, the REL is sent.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| | *** T6 Expires *** |
| |<-----------REL-----------|5
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|6
7|<----------BYE------------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
10. ISUP maintenance messages
ISUP contains a set of messages used for maintenance purposes. They
can be received during an ongoing call. There are basically two kinds
of maintenance messages (apart from the continuity check): message
for blocking circuits and messages for resetting circuits.
Camarillo/Roach/Peterson/Ong [Page 43]
ISUP to SIP Mapping August 2001
10.1. Reset messages
Upon reception of a reset message for the circuit being used, the
call has to be released. RSC messages are answered with RLC after
resetting the circuit in the MG. GRS messages are answered with GRA
after resetting all the circuits affected by the message.
The MGC acts as if a REL had been received in order to release the
connection on the SIP side. The session will be terminated. A BYE or
a CANCEL are sent depending of the status of the call.
10.2. Blocking messages
There are two kinds of blocking messages: maintenance oriented or
hardware failure oriented. Maintenance oriented blocking messages
indicates that the circuit has to be blocked for subsequent calls.
Therefore, these messages do not affect any ongoing call.
Hardware oriented blocking messages have to be treated as reset
messages. The call is released.
BLO is always maintenance oriented and it is answered by the MGC with
BLA when the circuit is blocked. CGB messages have a "type indicator"
inside the "circuit group supervision message type indicator". It
indicates if the CGB is maintenance or hardware failure oriented.
CGBs are answered with CGBAs.
10.3 Continuity Checks
A continuity check is a test performed on a circuit that involves the
reflection of a tone generated at the originating switch by a
loopback at the destination switch. Two variants of the continuity
check appear in ISUP: the implicit continuity check request within an
IAM (in which case the continuity check takes place before call setup
begins), and the explicit continuity check signaled by a Continuity
Check Request (CCR) message.
When a CCR is received by a PSTN-SIP gateway, the gateway should not
send any SIP messages; the scope of the continuity check applies only
to the PSTN trunks, not to any IP media paths.
When an IAM with the Continuity Check Indicator flag set within the
Nature of Connection Indicators (NCI) parameter is received, the
gateway should process the continuity check before sending an INVITE
message; if the continuity check fails (a COT with Continuity
Indicator of 'failed' is received), then an INVITE should not be
sent.
Camarillo/Roach/Peterson/Ong [Page 44]
ISUP to SIP Mapping August 2001
11. Construction of Telephony URIs
SIP proxy servers may route SIP messages on any signaling criteria
desired by network administrators, but generally the Request-URI is
the foremost routing criterion. The To and From headers are also
frequently of interest in making routing decisions. SIP-ISUP mapping
assumes that proxy servers are interested in at least these three
fields of SIP messages, all of which contain URIs.
SIP-ISUP mapping frequently requires the representation of telephone
numbers in these URIs. In some instances these numbers will be
presented first in ISUP messages, and SS7-SIP gateways will need to
translate the ISUP formats of these numbers into SIP URIs. In other
cases the reverse transformation will be required.
The most common format used in SIP for the representation of
telephone numbers is the tel URL, defined in [18]. The tel URL may
constitute the entirety of a URI field in a SIP message, or it may
appear as the user portion of a SIP URI. For example, a To field
might appear as:
To: tel:+17208881000
Or
To: sip:+17208881000@level3.com
Whether or not a particular gateway or endpoint should formulate URIs
in the tel or SIP format is a matter of local administrative policy -
if the presence of a host portion would aid the surrounding network
in routing calls, the SIP format should be used. A gateway should
accept either tel or SIP URIs from its peers.
The '+' sign preceding the number in these examples indicates that
the digits which follow constitute a fully-qualified E.164 [19]
number; essentially, this means that a country code is provided
before any national-specific area codes, exchange/city codes, or
address codes. The absence of a '+' sign could mean that the number
is nationally significant, or perhaps that a private dialing plan is
in use. When the '+' sign is not present, but a telephone number is
represented by the user portion of the URI, the SIP URI should
contain the optional ';user=phone' parameter; e.g.
To: sip:83000@sip.example.net;user=phone
However, it is highly recommended that only internationally
significant E.164 numbers be passed between SIP-T gateways,
especially when such gateways are in different regions or different
Camarillo/Roach/Peterson/Ong [Page 45]
ISUP to SIP Mapping August 2001
administrative domains. In many if not most SIP-T networks, gateways
are not responsible for end-to-end routing of SIP calls; practically
speaking, gateways have no way of knowing if the call will terminate
in a local or remote administrative domain and/or region, and hence
gateways should always assume that calls require an international
numbering plan. There is no guarantee that recipients of SIP
signaling will be capable of understanding national dialing plans
used by the originators of calls - if the originating gateway does
not internationalize the signaling, the context in which the digits
were dialed cannot be extrapolated by far-end network elements.
In ISUP signaling, a telephone number appears in a common format that
is used in several parameters, including the Called Party's Number
(CPN) and Calling Party's Number (CIN); when it represents a calling
party number it sports some additional information (detailed below).
For the purposes of this document, we will refer to this format as
'ISUP format' - if the additional calling party information is
present, the format shall be referred to as 'ISUP- calling format'.
The format consists of a byte called the Nature of Address (NoA)
indicator, followed by another byte which contains the Numbering Plan
Indicator (NPI), both of which are prefixed to a variable-length
series of bytes that contains the digits of the telephone number in
binary coded decimal (BCD) format. In the calling party number case,
the NPI's byte also contains bit fields which represent the caller's
presentation preferences and the status of any call screening checks
performed up until this point in the call.
H G F E D C B A H G F E D C B A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NoA | | | NoA |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NPI | spare | | | NPI |PrI|ScI|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| dig...| dig 1 | | dig...| dig 1 |
| ... | | ... |
| dig n | dig...| | dig n | dig...|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ISUP format ISUP calling format
Figure 1. ISUP numbering formats
The NPI field is generally set to the value 'ISDN (Telephony)
numbering plan (Recommendation E.164)', but this does not mean that
the digits which follow necessarily contain a country code; the NoA
field dictates whether the telephone number is in a national or
international format. When the represented number is not designated
Camarillo/Roach/Peterson/Ong [Page 46]
ISUP to SIP Mapping August 2001
to be in an international format, the NoA generally provides
information specific to the national dialing plan - based on this
information one can usually determine how to convert the number in
question into an international format. Note that if the NPI contains
a value other than 'ISDN numbering plan', then the tel URL may not be
suitable for carrying the address digits, and the handling for such
calls is outside the scope of this document.
Based on the above, conversion from ISUP format to a tel URL is as
follows. First, provided that the NPI field indicates that the
telephone number format uses E.164, the NoA should be consulted. If
the NoA indicates that the number is an international number, then
the telephone number digits should be appended unmodified to a
'tel:+' string. If the NoA has the value 'national (significant)
number', then a country code must be prefixed to the telephone number
digits before they are committed to a tel URL; if the gateway
performing this conversion interconnects with switches homed to
several different country codes, presumably the appropriate country
code should be chosen based on the originating switch. If the NoA has
the value 'subscriber number', both a country code and any other
numbering components necessary for the numbering plan in question
(such as area codes or city codes) may need to be added in order for
the number to be internationally significant - however, such
procedures vary greatly from country to country, and hence they
cannot be specified in detail here. Only if a country or network-
specific value is used for the NoA should a tel URL not include a '+'
sign; in these cases, gateways should simply copy the provided digits
into the tel URL and append a 'user=phone' parameter if a SIP URI
format is used. Any non-standard or proprietary mechanisms used to
communicate further context for the call in ISUP are outside the
scope this document.
If a nationally-specific parameter is present that allows for the
transmission of the calling party's name (such as the Generic Name
Parameter in ANSI), then generally, if presentation is not
restricted, this information should be use to populate the display-
name portion of the From field.
If ISUP calling format is used rather than ISUP format, then two
additional pieces of information must be taken into account:
presentation indicators and screening indicators. If the presentation
indicators are set to 'presentation restricted', then a special URI
should be created by the gateway which communicates to the far end
that the caller's identity has been elided. This URI should be a SIP
URI with the hostname of the gateway but with a display name of
'Anonymous' username of 'restricted', e.g.:
Camarillo/Roach/Peterson/Ong [Page 47]
ISUP to SIP Mapping August 2001
From: Anonymous <sip:restricted@gw.level3.net>
As further general-purpose privacy mechanisms are developed for the
SIP protocol, they may also be used to protect the identity of a
caller.
If presentation is set to 'address unavailable', then gateways should
treat the IAM as if the CIN parameter was omitted. Screening
indicators should not be translated, as they are only meaningful end-
to-end.
Conversion from tel URLs to ISUP format is simpler. If the URI is in
international format, then the gateway should consult the leading
country code of the URI. If the country code is local to the gateway
(the gateway has one or more trunks that point to switches which are
homed to the country code in question), the gateway should set the
NoA to reflect 'national (significant) number' and strip the country
code from the URI before populating the digits field. If the country
code is not local to the gateway, the gateway should set the NoA to
'international number' and retain the country code. In either case
the NPI should be set to 'ISDN numbering plan'.
If the URI is not in international format, the gateway should attempt
to treat the telephone number within the URI as if it were
appropriate to its national or network-specific dialing plan; if
doing so gives rise to internal gateway errors, then this condition
is most likely best handled with appropriate SIP status codes (e.g.
484).
When converting from a tel URL to ISUP calling format, the procedure
is identical to that described in the preceding paragraphs, but
additionally, the presentation indicator should be set to
'presentation allowed' and the screening indicator to 'network
provided', unless some service provider policy or user profile
specifically disallows presentation.
12. Other ISUP flavors
Other flavors of ISUP different than Q.767 [2] have more parameters
and more features. Some of the parameters have more possible values
and provide more information about the status of the call.
The Circuit Query Message (CQM) and Circuit Query Response (CQR) are
used in many ISUP variants. These messages have no analog in SIP,
although receipt of a CQR may cause state reconciliation if the
originating and destination switches have become desynchronized; as
states are reconciled some calls may be dropped, which may cause SIP
or ISUP messages to be sent.
Camarillo/Roach/Peterson/Ong [Page 48]
ISUP to SIP Mapping August 2001
However, differences in the message flows are more important. In ANSI
ISUP [3], there is no CON message; an ANM is sent instead (with no
ACM). In call forwarding situations, CPGs can be sent before the ACM
is sent. SAMs are never used; `en bloc' signaling is always used. The
ANSI Exit Message (EXM) should not result in any SIP signaling in
gateways. ANSI also uses the Circuit Reservation Message (CRM) and
Circuit Reservation Acknowledgment (CRA) as part of its interworking
procedures - although a SIP gateway should not ever receive these
messages, if it does receive such a message there is no appropriate
SIP action to be taken (the recommended behavior is sending a REL in
response to the CRM).
Although receipt of a Confusion (CFN) message is an indication of a
protocol error, no SIP message should be sent on receipt of a CFN -
the CFN should be handled internally by the gateway (usually by
retransmission of the packet to which the CFN responded). Only if
this fails repeatedly should this cause a SIP error condition to
arise.
In TTC ISUP CPGs can be sent before the ACM is sent. Messages such as
CHG can be sent between ACM and ANM. `En bloc' signaling is always
used and there is no T9 timer.
12.1. Guidelines to send other ISUP messages
Some ISUP flavors send more messages than the ones described in this
document. It is good to follow some guidelines to transport these
ISUP messages inside SIP bodies.
From the caller to the callee ISUP messages should be encapsulated
(see [4]) inside INFO messages, even if the INVITE transaction is
still not finished. Note that SIP does not ensure that INFO requests
are delivered in order. Therefore, an egress gateway might process
first an INFO request that was sent after another INFO request. This
issue, however, does not represent an important problem since it is
not likely to happen and its effects are negligible in most of the
situations. The Information (INF) message and Information Response
(INR) are examples of messages that should be encapsulated within an
INFO.
Note that if an INR is received before call establishment is complete
(i.e. ANM is received) it should be encapsulated in a an INFO, rather
than any provisional 1xx response. Similarly an INF is received on
the originating side (probably in reponse to an INR) before a 200 has
been received should be carried within an INFO. In order for this
mechanism to function properly in the forward direction, any
necessary Contact or To-tag must have appeared in a previous
provisional response or the message might not be correctly routed to
Camarillo/Roach/Peterson/Ong [Page 49]
ISUP to SIP Mapping August 2001
its destination. As such all SIP-T gateways should send provisional
responses with a Contact header and any necessary tags in order to
enable proper routing of new requests issued before a final response
has been received.
ISUP messages from the callee to the caller should be sent inside
provisional responses. SIP ensures that provisional responses
transmitted reliably are delivered in order. When the INVITE
transaction is finished INFO requests should be used also in this
direction.
13. Acronyms
ACK Acknowledgment
ACM Address Complete Message
ANM Answer Message
ANSI American National Standards Institute
BLA Blocking ACK message
BLO Blocking Message
CGB Circuit Group Blocking Message
CGBA Circuit Group Blocking ACK Message
CHG Charging Information Message
CON Connect Message
CPG Call Progress Message
CUG Closed User Group
GRA Circuit Group Reset ACK Message
GRS Circuit Group Reset Message
HLR Home Location Register
IAM Initial Address Message
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
ITU-T International Telecommunication Union
Telecommunication Standardization Sector
MG Media Gateway
MGC Media Gateway Controller
MTP Message Transfer Part
REL Release Message
RES Resume Message
RLC Release Complete Message
RTP Real-time Transport Protocol
SCCP Signaling Connection Control Part
SG Signaling Gateway
SIP Session Initiation Protocol
SS7 Signaling System No. 7
SUS Suspend Message
TTC Telecommunication Technology Committee
Camarillo/Roach/Peterson/Ong [Page 50]
ISUP to SIP Mapping August 2001
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
VoIP Voice over IP
14. Acknowledgments
The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill
Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada,
Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir,
Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, and
Jan Van Geel for their help and feedback on this document.
15. Revision History
Changes from draft-ietf-sip-isup-00:
- Merged draft-jfp-sip-isup-header-00 into this draft
- Removed overlap signaling component (now
draft-ietf-sip-overlap-00)
- Adjusted cause code to status code mappings
Changes from draft-ietf-sip-isup-01:
- Added procedures for placing calls on hold
- Generalized language and procedures for LNP, removing ANSI bias
- Fixed usage of 'user=phone'
- Added handling for Segmentation Message in ISUP
- Updated SUS/RES handling to use INFO consistently (rather than
183)
Changes from draft-ietf-sip-isup-02:
- Fixed some more ANSI-specific references (GNI, screening)
- Fixed timer expiry cause code values (6.2.2)
- Removed some bis04 incompatibilities (6.2.10)
- Added motivational text to abstract and introduction
Camarillo/Roach/Peterson/Ong [Page 51]
ISUP to SIP Mapping August 2001
16. References
[1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, IETF; March 1999.
[2] "Application of the ISDN user part of CCITT signaling system
No. 7 for international ISDN interconnections" ITU-T Q.767
recommendation, February 1991.
[3] "Signaling System No. 7; ISDN User Part" T1.113-1995 ANSI.
January 1995.
[4] E Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M.
Watson, M. Zonoun, "MIME media types for ISUP and QSIG
Objects", Internet Draft <draft-ietf-sip-isup-mime-10.txt>,
IETF; April 2001. Work in progress.
[5] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, IETF;
November 1996.
[6] H. Schulzrinne, S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, IETF; May
2000.
[8] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional
Responses in SIP", Internet Draft <draft-ietf-sip-100rel-03.txt>,
IETF; March 2001. Work in progress.
[9] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
Session Initiation Protocol", Internet Draft
<draft-ietf-sip-rfc2543bis-04.txt>, IETF; August 2001. Work in
progress.
Former reference placeholder for 183 work:
S. Donovan, M. Cannon, H. Schulzrinne, J. Rosenberg, A. Roach,
"SIP 183 Session Progress Message", Internet Draft, IETF
October 1999. (expired I-D)
[10] Steven R. Donovan, "The SIP INFO Method", RFC 2976, IETF;
February 2000.
[11] "Signaling System No. 7; ISDN User Part Signaling
procedures", ITU-T Q.764 recommendation, September 1997.
[12] Abnormal conditions - Special release ITU-T Q.118
recommendation, September 1997.
Camarillo/Roach/Peterson/Ong [Page 52]
ISUP to SIP Mapping August 2001
[13] "Specifications of Signaling System No. 7 - ISDN
supplementary services" ITU-T Q.737 recommendation, June
1997.
[14] "Specifications of Signaling System No. 7 - ISDN User Part
Signaling Procedures" ITU-T Q.764 recommendation, March
1993.
[15] R. Stewart et al, "Stream Control Transmission Protocol".
RFC 2960, IETF; October 2000.
[16] "Usage of cause location in the Digital Subscriber Signaling
System No. 1 and the Signaling System No. 7 ISDN User Part" ITU-T
Q.850 Recommendation, May 1998
[17] J. Yu, "Extensions to the 'tel' and 'fax' URLs to Support Number
Portability and Freephone Service", Internet-Draft
<draft-yu-tel-url-02.txt>, IETF, Feb 2001. (Work in progress)
[18] A. Vaha-Sipila, "URLs for Telephone Calls", RFC2806, IETF, April
2000.
[19] "The international public telecommunication number plan", ITU-T
E.164 Recommendation, May 1997
[20] "Formats and codes of the ISDN User Part of Signaling System No.
7", ITU-T Q.763 recommendation, March 1993.
17. Security Considerations
The transit of ISUP in SIP bodies may provide may opportunities for
abuse and fraud. In particular, SIP users may be able to interpret
"private" (i.e. caller-id-blocked) numbers by examining the ISUP.
Similarly, if care is not taken, SIP clients would be able to send
ISUP messages into the SS7 network with invalid calling line
identification and spoofed billing numbers.
For these reasons, it is absolutely necessary that any ISUP sent
through an IP network be strongly encrypted and authenticated. The
keys used for encryption should not be static, to prevent replay
attacks. A challenge-response model is recommended. As an extra layer
of security, it is recommended that ISUP be sent and received only to
and from nodes that are known to have an established trust
relationship with the gateway.
Camarillo/Roach/Peterson/Ong [Page 53]
ISUP to SIP Mapping August 2001
18. Authors' Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com
Adam Roach
Ericsson Inc.
Mailstop L-04
851 International Pkwy.
Richardson, TX 75081
USA
Phone: +1 972-583-7594
Fax: +1 972-669-0154
E-Mail: Adam.Roach@ericsson.com
Jon Peterson
NeuStar, Inc
1800 Sutter Street, Suite 570
Concord, CA 94520
USA
Phone: +19253638700
E-Mail: jon.peterson@neustar.com
Lyndon Ong
Ciena
10480 Ridgeview Court
Cupertino, CA 95014
E-Mail: lyOng@ciena.com
Full Copyright Statement
Copyright (c) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
Camarillo/Roach/Peterson/Ong [Page 54]
ISUP to SIP Mapping August 2001
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Camarillo/Roach/Peterson/Ong [Page 55]
