Network Working Group G. Camarillo
Internet-Draft Ericsson
Expires: December 30, 2002 A. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
July 1, 2002
ISUP to SIP Mapping
draft-ietf-sipping-isup-03
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 to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes a way to perform the mapping between two
signaling protocols: the Session Initiation Protocol (SIP) and the
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).
Camarillo, et al. Expires December 30, 2002 [Page 1]
Internet-Draft ISUP to SIP Mapping July 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7
4. SIP Mechanisms Required . . . . . . . . . . . . . . . . . 9
4.1 'Transparent' Transit of ISUP Messages . . . . . . . . . . 9
4.2 Understanding MIME Multipart Bodies . . . . . . . . . . . 9
4.3 Transmission of DTMF Information . . . . . . . . . . . . . 9
4.4 Reliable Transmission of Provisional Responses . . . . . . 9
4.5 Provisional Media Streams . . . . . . . . . . . . . . . . 10
4.6 Mid-Call Transactions which do not change SIP state . . . 10
5. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. SIP to ISUP Mapping . . . . . . . . . . . . . . . . . . . 12
6.1 Call flows . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1 En-bloc Call Setup (no auto-answer) . . . . . . . . . . . 12
6.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 13
6.1.3 ISUP T7 Expires . . . . . . . . . . . . . . . . . . . . . 14
6.1.4 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.5 ISUP Setup Failure . . . . . . . . . . . . . . . . . . . . 16
6.1.6 Cause Present in ACM Message . . . . . . . . . . . . . . . 17
6.1.7 Call Canceled by SIP . . . . . . . . . . . . . . . . . . . 18
6.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 19
6.2.1 INVITE received . . . . . . . . . . . . . . . . . . . . . 20
6.2.1.1 INVITE to IAM procedures . . . . . . . . . . . . . . . . . 20
6.2.2 ISUP T7 expires . . . . . . . . . . . . . . . . . . . . . 23
6.2.3 CANCEL or BYE received . . . . . . . . . . . . . . . . . . 23
6.2.4 REL received . . . . . . . . . . . . . . . . . . . . . . . 23
6.2.4.1 ISDN Cause Code to Status Code Mapping . . . . . . . . . . 24
6.2.5 Early ACM received . . . . . . . . . . . . . . . . . . . . 26
6.2.6 ACM received . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.7 CON or ANM Received . . . . . . . . . . . . . . . . . . . 28
6.2.8 Timer T9 Expires . . . . . . . . . . . . . . . . . . . . . 28
6.2.9 CPG Received . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 ACK received . . . . . . . . . . . . . . . . . . . . . . . 28
7. ISUP to SIP Mapping . . . . . . . . . . . . . . . . . . . 29
7.1 Call Flows . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1 En-bloc call setup (non auto-answer) . . . . . . . . . . . 29
7.1.2 Auto-answer call setup . . . . . . . . . . . . . . . . . . 30
7.1.3 SIP Timeout . . . . . . . . . . . . . . . . . . . . . . . 31
7.1.4 ISUP T9 Expires . . . . . . . . . . . . . . . . . . . . . 32
7.1.5 SIP Error Response . . . . . . . . . . . . . . . . . . . . 33
7.1.6 SIP Redirection . . . . . . . . . . . . . . . . . . . . . 34
7.1.7 Call Canceled by ISUP . . . . . . . . . . . . . . . . . . 35
7.2 State Machine . . . . . . . . . . . . . . . . . . . . . . 36
7.2.1 Initial Address Message received . . . . . . . . . . . . . 37
7.2.1.1 IAM to INVITE procedures . . . . . . . . . . . . . . . . . 37
7.2.2 100 received . . . . . . . . . . . . . . . . . . . . . . . 38
Camarillo, et al. Expires December 30, 2002 [Page 2]
Internet-Draft ISUP to SIP Mapping July 2002
7.2.3 18x received . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.4 2xx received . . . . . . . . . . . . . . . . . . . . . . . 40
7.2.5 3xx Received . . . . . . . . . . . . . . . . . . . . . . . 40
7.2.6 4xx-6xx Received . . . . . . . . . . . . . . . . . . . . . 41
7.2.6.1 SIP Status Code to ISDN Cause Code Mapping . . . . . . . . 41
7.2.7 REL Received . . . . . . . . . . . . . . . . . . . . . . . 42
7.2.8 ISUP T11 Expires . . . . . . . . . . . . . . . . . . . . . 43
8. Suspend/Resume and Hold . . . . . . . . . . . . . . . . . 44
8.1 SUS and RES . . . . . . . . . . . . . . . . . . . . . . . 44
8.2 Hold (re-INVITE) . . . . . . . . . . . . . . . . . . . . . 45
9. Normal Release of the Connection . . . . . . . . . . . . . 46
9.1 SIP initiated . . . . . . . . . . . . . . . . . . . . . . 46
9.2 ISUP initiated . . . . . . . . . . . . . . . . . . . . . . 46
9.2.1 Caller hangs up . . . . . . . . . . . . . . . . . . . . . 46
9.2.2 Callee hangs up . . . . . . . . . . . . . . . . . . . . . 47
10. ISUP Maintenance Messages . . . . . . . . . . . . . . . . 48
10.1 Reset messages . . . . . . . . . . . . . . . . . . . . . . 48
10.2 Blocking messages . . . . . . . . . . . . . . . . . . . . 48
10.3 Continuity Checks . . . . . . . . . . . . . . . . . . . . 48
11. Construction of Telephony URIs . . . . . . . . . . . . . . 50
12. Other ISUP flavors . . . . . . . . . . . . . . . . . . . . 54
12.1 Guidelines to send other ISUP messages . . . . . . . . . . 54
13. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 56
14. Security Considerations . . . . . . . . . . . . . . . . . 57
15. IANA Considerations . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 61
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 62
References . . . . . . . . . . . . . . . . . . . . . . . . 59
References . . . . . . . . . . . . . . . . . . . . . . . . 60
B. Revision History . . . . . . . . . . . . . . . . . . . . . 63
Full Copyright Statement . . . . . . . . . . . . . . . . . 65
Camarillo, et al. Expires December 30, 2002 [Page 3]
Internet-Draft ISUP to SIP Mapping July 2002
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 [10] is a level 4 protocol used in SS7 networks. It typically
runs over MTP although it can also run over IP (see SCTP [17]). 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
and vice versa. This is useful for cases in which PSTN calls need to
take advantage of services in IP world, in which IP networks are used
as transit networks for PSTN-PSTN calls, architectures in which calls
originate on desktop 'softphones' but terminate at PSTN terminals,
and many other similar next-generation telephone architectures.
This document describes logic and procedures which an MGC might use
to implement the mapping between SIP and ISUP by illustrating the
correspondences, at the message level and parameter level, between
the protocols. It also describes the interplay between parallel
state machines for these two protocols as a recommendation for
implementers to synchronize protocol events in interworking
architectures.
Camarillo, et al. Expires December 30, 2002 [Page 4]
Internet-Draft ISUP to SIP Mapping July 2002
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
[8] is used through this document; some differences with ANSI [9]
ISUP and TTC ISUP are outlined. ISUP Q.767 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 standardized 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
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
Camarillo, et al. Expires December 30, 2002 [Page 5]
Internet-Draft ISUP to SIP Mapping July 2002
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.
Camarillo, et al. Expires December 30, 2002 [Page 6]
Internet-Draft ISUP to SIP Mapping July 2002
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 [2]). 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
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 14. 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 [17]. The mapping described in this document is not
affected by the underlying transport protocol of ISUP.
Camarillo, et al. Expires December 30, 2002 [Page 7]
Internet-Draft ISUP to SIP Mapping July 2002
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.
Camarillo, et al. Expires December 30, 2002 [Page 8]
Internet-Draft ISUP to SIP Mapping July 2002
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
calls from PSTN to PSTN across a SIP network, SIP messages will need
to transport ISUP payloads from gateway to gateway. The format for
encapsulating these ISUP messages is defined in [2].
SIP clients and servers which do not understand ISUP are permitted to
ignore these optional MIME bodies.
4.2 Understanding MIME 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 [3]. 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 RFC2833 [4] 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 call progress
information. PSTN interworking in particular relies on these
messages for control of the media channel and timing of messages.
Camarillo, et al. Expires December 30, 2002 [Page 9]
Internet-Draft ISUP to SIP Mapping July 2002
PSTN interworking should occur over a reliable transport layer end-
to-end. One application-layer provisional reliability mechanism is
described in [16].
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.
MGCs should support the establishment of temporary provisional media
streams using the 183 status code (described in [1]). A more
detailed analysis of the problem of early media is given in [18].
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 RFC2976 [5]. Note that this document does not prescribe
or endorse the use of INFO to carry DTMF digits.
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.
Camarillo, et al. Expires December 30, 2002 [Page 10]
Internet-Draft ISUP to SIP Mapping July 2002
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.
Camarillo, et al. Expires December 30, 2002 [Page 11]
Internet-Draft ISUP to SIP Mapping July 2002
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 below although they are required in many architectures.
In these diagrams, all call signaling (SIP, ISUP) is going to and
from the MGC; media handling (e.g. audio cut-through, trunk freeing)
is being performed by the MG, under the control of the MGC. For the
purpose of simplicity, these are shown as a single node, labeled
"MGC/MG."
6.1.1 En-bloc Call Setup (no auto-answer)
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 6.2.5 and
Section 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
Camarillo, et al. Expires December 30, 2002 [Page 12]
Internet-Draft ISUP to SIP Mapping July 2002
both directions after step 12.
5. 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.
6. 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.
7. Once the PSTN user answers, an ANM message will be sent to the
gateway.
8. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node.
9. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
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.
Camarillo, et al. Expires December 30, 2002 [Page 13]
Internet-Draft ISUP to SIP Mapping July 2002
5. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
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.
Camarillo, et al. Expires December 30, 2002 [Page 14]
Internet-Draft ISUP to SIP Mapping July 2002
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 *** | |
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).
Camarillo, et al. Expires December 30, 2002 [Page 15]
Internet-Draft ISUP to SIP Mapping July 2002
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.
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.
Camarillo, et al. Expires December 30, 2002 [Page 16]
Internet-Draft ISUP to SIP Mapping July 2002
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===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. Since the ISUP node is unable to complete the call and wants to
generate the error tone/announcement itself, it sends an ACM with
a cause code. The gateway starts an interwork timer.
4. Upon receipt of an ACM with cause (presence of the CAI
parameter), the gateway will generate a 183 message towards the
SIP node; this contains SDP to establish early media cut-through.
5. A final INVITE response, based on the cause code received in the
earlier ACM message, is generated and sent to the SIP node to
terminate the call. See Section 6.2.4.1 for the table which
contains the mapping from cause code to SIP response.
6. Upon expiration of the interwork timer, a REL is sent towards the
PSTN node to terminate the call. Note that the SIP node can also
terminate the call by sending a CANCEL before the interwork timer
expires. In this case, the signaling progresses as in Section
6.1.7.
7. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
8. The SIP node sends an ACK to acknowledge receipt of the INVITE
final response.
Camarillo, et al. Expires December 30, 2002 [Page 17]
Internet-Draft ISUP to SIP Mapping July 2002
6.1.7 Call Canceled by SIP
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 6.2.5 and
Section 6.2.6) and returned to the SIP node. This response may
contain SDP to establish an early media stream.
5. To cancel the call before it is answered, the SIP node sends a
CANCEL request.
6. The CANCEL request is confirmed with a 200 response.
7. Upon receipt of the CANCEL request, the gateway sends a REL
message to terminate the ISUP call.
8. The gateway sends a "487 Call Cancelled" message to the SIP node
to complete the INVITE transaction.
9. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
10. Upon receipt of the 487, the SIP node will confirm reception
Camarillo, et al. Expires December 30, 2002 [Page 18]
Internet-Draft ISUP to SIP Mapping July 2002
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 9).
+---------+
+----------------------->| 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 +------------>+
+-------------------------+
Camarillo, et al. Expires December 30, 2002 [Page 19]
Internet-Draft ISUP to SIP Mapping July 2002
6.2.1 INVITE received
When an INVITE request is received by the gateway, a "100 Trying"
response should 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
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 Initial Address Message (IAM).
A PSTN-SIP gateway is responsible for creating an IAM when it
receives an INVITE.
Five mandatory parameters appear within the IAM message: the Called
Party Number (CPN), the Nature of Connection Indicator (NCI), the
Forward Call Indicators (FCI), the Calling Party's Category (CPC),
and finally a parameter that indicates the desired bearer
characteristics of the call - in some ISUP variants the Transmission
Medium Requirement (TMR) is required, in others the User Service
Information (USI) (or both). All IAM messages must contain these
five parameters at a minimum. Thus, every gateway must have a means
of populating each of those five parameters. Many of the values that
will appear in these parameters (such as the NCI or USI) will most
likely be the same for each IAM created by the gateway. Others (such
as the CPN) will vary on a call-by-call basis; the gateway must
extract some information from the INVITE in order to properly
populate these parameters.
There are also quite a few optional parameters that can appear in an
IAM message; Q.763 [15] 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
Camarillo, et al. Expires December 30, 2002 [Page 20]
Internet-Draft ISUP to SIP Mapping July 2002
Party's Number (CIN, which is commonly present), Transit Network
Selection (TNS), Carrier Identification Parameter (CIP, present in
ANSI networks), Original Called Number (OCN), and the Generic Digits
(known in some variants as the Generic Address Parameter (GAP)).
When a SIP INVITE arrives at a PSTN gateway, the gateway should
attempt to make use of encapsulated ISUP (see [2]), if any, within
the INVITE to assist in the formulation of outbound PSTN signaling.
If possible, the gateway should reuse the values in the parameters of
the encapsulated IAM as it formulates an IAM that it will send across
its PSTN interface. In some cases, the gateway will be unable to
make use of that ISUP - for example, if the gateway cannot understand
the ISUP variant and must therefore ignore the encapsulated body.
Even when there is encapsulated ISUP, the relevant values of SIP
header fields must 'overwrite' the parameter values that would have
been set based on encapsulated ISUP through the process of
translation.
For example, if an INVITE arrives at a gateway with an encapsulated
IAM with a CPN field indicating the telephone number +12025332699,
but the Request-URI of the INVITE indicates 'tel:+15105550110', the
gateway should use the telephone number in the Request-URI, rather
than the one in the encapsulated IAM, when creating the IAM that the
gateway will send to the PSTN. Further details of how SIP header
fields are translated into ISUP parameters follow.
Gateways should use default values for mandatory ISUP parameters that
are not derived 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.
Camarillo, et al. Expires December 30, 2002 [Page 21]
Internet-Draft ISUP to SIP Mapping July 2002
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 (CIC)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
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, when ISUP feature transparency is available, `interworking
encountered' must not be specified so that ISUP behaves normally.
Therefore, when a gateway receives a message with (comprehensible)
encapsulated ISUP, it should not set the 'interworking encountered'
bit in the FCI, and it should set the 'ISUP all the way' bit. If
usable encapsulated ISUP is not present in an INVITE received by the
gateway, it may set the 'interworking encountered' bit as
Camarillo, et al. Expires December 30, 2002 [Page 22]
Internet-Draft ISUP to SIP Mapping July 2002
appropriate.
Claiming to be an ISDN node might make the callee request ISDN user
to user services. Since user to user services 1 and 2 must be
requested by the caller, they do not represent a problem (see [12]).
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.
This applies when 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.
Camarillo, et al. Expires December 30, 2002 [Page 23]
Internet-Draft ISUP to SIP Mapping July 2002
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 Status Code Mapping
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
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.
Camarillo, et al. Expires December 30, 2002 [Page 24]
Internet-Draft ISUP to SIP Mapping July 2002
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
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 may 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
Camarillo, et al. Expires December 30, 2002 [Page 25]
Internet-Draft ISUP to SIP Mapping July 2002
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 available
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
ISUP Cause value SIP response
---------------- ------------
102 recovery of timer expiry 504 Gateway 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.
Camarillo, et al. Expires December 30, 2002 [Page 26]
Internet-Draft ISUP to SIP Mapping July 2002
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 (see [10]) this is solved by connecting
the voice path backwards before sending the IAM.
The MGC sends a 183 Session Progress (see [1]) 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, in many networks timer T9 is started. T9
typically lasts between 90 seconds and 3 minutes (see [11]) . 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. Some networks do not
support timer T9.
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.
Camarillo, et al. Expires December 30, 2002 [Page 27]
Internet-Draft ISUP to SIP Mapping July 2002
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
---------------- ------------
1 Alerting 180 Ringing
2 Progress 183 Session progress
3 In-band information 183 Session progress
4 Call forward; line busy 181 Call is being forwarded
5 Call forward; no reply 181 Call is being forwarded
6 Call forward; unconditional 181 Call is being forwarded
- (no event code present) 183 Session progress
Note that, if the CPG does not indicate "Alerting," the current state
will not change.
6.3 ACK received
At this stage, the call is connected and the conversation can take
place.
Camarillo, et al. Expires December 30, 2002 [Page 28]
Internet-Draft ISUP to SIP Mapping July 2002
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|-----------18x----------->| |
| |------------CPG---------->|6
7|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|8
| |<=========Audio==========>|
9|<----------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."
Camarillo, et al. Expires December 30, 2002 [Page 29]
Internet-Draft ISUP to SIP Mapping July 2002
5. The SIP node may use further provisional messages to indicate
session progress.
6. After an ACM has been sent, all provisional responses will
translate into ISUP CPG messages as indicated in Section 7.2.3.
7. When the SIP node answers the call, it will send a 200 OK
message.
8. Upon receipt of the 200 OK message, the gateway will send an ANM
message towards the ISUP node.
9. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
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.
Camarillo, et al. Expires December 30, 2002 [Page 30]
Internet-Draft ISUP to SIP Mapping July 2002
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 *** | |
|<--------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.
Camarillo, et al. Expires December 30, 2002 [Page 31]
Internet-Draft ISUP to SIP Mapping July 2002
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 *** |
| |------------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.
Camarillo, et al. Expires December 30, 2002 [Page 32]
Internet-Draft ISUP to SIP Mapping July 2002
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. 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.
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.1.
6. The remote ISUP node confirms receipt of the REL message with an
RLC message.
Camarillo, et al. Expires December 30, 2002 [Page 33]
Internet-Draft ISUP to SIP Mapping July 2002
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
9|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|10
| |<=========Audio==========>|
11|<----------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. In this instances we assume the Contact URL
specifies a valid URL reachable by a VoIP SIP call.
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
Camarillo, et al. Expires December 30, 2002 [Page 34]
Internet-Draft ISUP to SIP Mapping July 2002
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. When the SIP node answers the call, it will send a 200 OK
message.
10. Upon receipt of the 200 OK message, the gateway will send an ANM
message towards the ISUP node.
11. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.1.7 Call Canceled by ISUP
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
9|-----------487----------->| |
10|<----------ACK------------| |
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.
Camarillo, et al. Expires December 30, 2002 [Page 35]
Internet-Draft ISUP to SIP Mapping July 2002
5. If the calling party hangs up before the SIP node answers the
call, a REL message will be generated.
6. The gateway frees the PSTN circuit and indicates that it is
available for reuse by sending an RLC.
7. Upon receipt of a REL message before an INVITE final response,
the gateway will send a CANCEL towards the SIP node.
8. Upon receipt of the CANCEL, the SIP node will send a 200
response.
9. The remote SIP node will send a "487 Call Cancelled" to complete
the INVITE transaction.
10. 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 Section 7.2.7. are taken. Not all of these
transitions are shown in this diagram.
Camarillo, et al. Expires December 30, 2002 [Page 36]
Internet-Draft ISUP to SIP Mapping July 2002
+---------+
+----------------------->| 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
Camarillo, et al. Expires December 30, 2002 [Page 37]
Internet-Draft ISUP to SIP Mapping July 2002
former will always appear in the From header (after it has been
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.
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 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 [6].
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
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, then the 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."
Camarillo, et al. Expires December 30, 2002 [Page 38]
Internet-Draft ISUP to SIP Mapping July 2002
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
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
The settings above assume that comprehensible encapsulated ISUP is
Camarillo, et al. Expires December 30, 2002 [Page 39]
Internet-Draft ISUP to SIP Mapping July 2002
present in the response. If no usable encapsulated ISUP is present,
the gateway should set the 'interworking encountered' bit of the BCI,
and should not set the ISDN user part indicator bit.
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 2xx 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.
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 6 (Forwarding) 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
Camarillo, et al. Expires December 30, 2002 [Page 40]
Internet-Draft ISUP to SIP Mapping July 2002
typically pays the first dialog 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 that 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
----------------- ----------------------
400 Bad Request 41 Temporary Failure
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option
unavailable
406 Not acceptable 79 Service/option not
implemented
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
(w/o diagnostic)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not
implemented (+)
416 Unsupported URI Scheme 127 Interworking (+)
420 Bad extension 127 Interworking (+)
421 Extension Required 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
Camarillo, et al. Expires December 30, 2002 [Page 41]
Internet-Draft ISUP to SIP Mapping July 2002
481 Call/Transaction Does not Exist 41 Temporary Failure
483 Too many hops 25 Exchange - routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
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
504 Version Not Supported 127 Interworking (+)
513 Message Too Large 127 Interworking (+)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable --- by Warning header
(*) 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
code. This document assumes that sending '31 Normal, unspecified'
will be sufficient by default for all currently assigned Warning
codes. If the Warning code speaks to an unavailable bearer
capability, cause code '64 Bearer Capability Not Implemented' could
be a superior mapping.
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.
Camarillo, et al. Expires December 30, 2002 [Page 42]
Internet-Draft ISUP to SIP Mapping July 2002
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). Note that although end-to-end delivery of the
CANCEL's payload is not guaranteed, since both sides of a PSTN
connection issue REL messages, it will not result in a failure in the
PSTN if this REL is never delivered. If, in a glare condition, a 200
OK response to the previously sent INVITE arrives after a CANCEL has
been sent, 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 [10] 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.
See Section 7.1.3 for an example callflow that includes the
expiration of T11.
Camarillo, et al. Expires December 30, 2002 [Page 43]
Internet-Draft ISUP to SIP Mapping July 2002
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. SUS is also frequently
used to signaling an on-hook state for a remote terminal before
timers leading to the transmission of a REL message are sent. While
a call is suspended, no audio media is passed end-to-end.
When a SUS is sent for a call that has a SIP leg, it may be desirable
to suspend IP media transmission until a RES is received. Putting
the media on hold insures that bandwidth is conserved when no audio
traffic needs to be transmitted.
If media suspension is appropriate, then when a SUS arrives from the
PSTN, the MGC should send an INVITE to request that the far-end's
transmission of the media stream be placed on hold. The subsequent
reception of a RES from the PSTN would then trigger a re-INVITE that
requests the resumption of the media stream. Note that the MGC may
or may not elect to stop transmitting any media itself when it
requests the cessation of far-end transmission.
If media suspension is not required by the MGC receiving the SUS from
the PSTN, the SIP INFO [5] method can be used to transmit an
encapsulated SUS rather than a re-INVITE. Subsequent RES messages
should be transmitted in the same method that was used for the
corresponding SUS (i.e. if an INFO is used for a SUS, INFO should
also be used for the subsequent RES).
Regardless of whether the INFO or re-INVITE mechanism is used to
carry a SUS message, neither has any implication that the originating
side will cease sending IP media. The recipient of an encapsulated
SUS message may therefore elect to send a re-INVITE themselves to
suspend media transmission from the MGC side if desired.
All of the following examples use the INVITE mechanism.
Camarillo, et al. Expires December 30, 2002 [Page 44]
Internet-Draft ISUP to SIP Mapping July 2002
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.
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.
Camarillo, et al. Expires December 30, 2002 [Page 45]
Internet-Draft ISUP to SIP Mapping July 2002
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
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----------->| |
Camarillo, et al. Expires December 30, 2002 [Page 46]
Internet-Draft ISUP to SIP Mapping July 2002
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----------->| |
Camarillo, et al. Expires December 30, 2002 [Page 47]
Internet-Draft ISUP to SIP Mapping July 2002
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.
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.
Camarillo, et al. Expires December 30, 2002 [Page 48]
Internet-Draft ISUP to SIP Mapping July 2002
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, et al. Expires December 30, 2002 [Page 49]
Internet-Draft ISUP to SIP Mapping July 2002
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 [7]. 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 [14]
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 may
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
administrative domains. In many if not most SIP-T networks, gateways
Camarillo, et al. Expires December 30, 2002 [Page 50]
Internet-Draft ISUP to SIP Mapping July 2002
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
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
to be in an international format, the NoA generally provides
information specific to the national dialing plan - based on this
Camarillo, et al. Expires December 30, 2002 [Page 51]
Internet-Draft ISUP to SIP Mapping July 2002
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 of 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 used 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.:
From: Anonymous <sip:restricted@gw.level3.net>
As further general-purpose privacy mechanisms are developed for the
Camarillo, et al. Expires December 30, 2002 [Page 52]
Internet-Draft ISUP to SIP Mapping July 2002
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.
Camarillo, et al. Expires December 30, 2002 [Page 53]
Internet-Draft ISUP to SIP Mapping July 2002
12. Other ISUP flavors
Other flavors of ISUP different than Q.767 [8] 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.
However, differences in the message flows are more important. In
ANSI [9] ISUP, 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 - in the event that an MGC does receive a
CRM, a CRA should be sent in return (in some implementations,
transmissions of a CRA could conceivably be based on a resource
reservation system); after a CRA is sent, the MGC should wait for a
subsequent IAM and process it normally. Any further circuit
reservation mechanism is outside the scope of this document.
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 [2]) 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
Camarillo, et al. Expires December 30, 2002 [Page 54]
Internet-Draft ISUP to SIP Mapping July 2002
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. Gateway implementors might also consider building systems that
wait for each INFO transaction to complete before initiating a new
INFO transaction.
From the callee to the caller, if an INR is received by a gateway
before the call has been answered (i.e. ANM is received) it should
be encapsulated in an INFO, provided that this will not be the first
SIP message sent in the backwards direction (in which case it must be
encapsulated in a provisional 1xx response). Similarly an INF is
received on the originating side (probably in response 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 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.
When the INVITE transaction is finished INFO requests should be used
also in this direction.
Camarillo, et al. Expires December 30, 2002 [Page 55]
Internet-Draft ISUP to SIP Mapping July 2002
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
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
VoIP Voice over IP
Camarillo, et al. Expires December 30, 2002 [Page 56]
Internet-Draft ISUP to SIP Mapping July 2002
14. Security Considerations
The transit of encapsulated ISUP within 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, et al. Expires December 30, 2002 [Page 57]
Internet-Draft ISUP to SIP Mapping July 2002
15. IANA Considerations
This document introduces no new considerations for IANA.
Camarillo, et al. Expires December 30, 2002 [Page 58]
Internet-Draft ISUP to SIP Mapping July 2002
Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[2] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
objects", RFC 3204, December 2001.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of
Number Portability and Freephone Service", draft-yu-tel-url-04
(work in progress), November 2001.
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
Camarillo, et al. Expires December 30, 2002 [Page 59]
Internet-Draft ISUP to SIP Mapping July 2002
Non-normative References
[8] International Telecommunications Union, "Application of the
ISDN user part of CCITT Signaling System No. 7 for
international ISDN interconnection", ITU-T Q.767, February
1991, <http://www.itu.int>.
[9] American National Standards Institute, "Signaling System No. 7;
ISDN User Part", ANSI T1.113, January 1995,
<http://www.itu.int>.
[10] International Telecommunications Union, "Signaling System No.
7; ISDN User Part Signaling procedures", ITU-T Q.764, December
1999, <http://www.itu.int>.
[11] International Telecommunications Union, "Abnormal conditions -
Special release", ITU-T Q.118, September 1997,
<http://www.itu.int>.
[12] International Telecommunications Union, "Specifications of
Signaling System No. 7 - ISDN supplementary services", ITU-T
Q.737, June 1997, <http://www.itu.int>.
[13] International Telecommunications Union, "Usage of cause
location in the Digital Subscriber Signaling System No. 1 and
the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May
1998, <http://www.itu.int>.
[14] International Telecommunications Union, "The international
public telecommunications numbering plan", ITU-T E.164, May
1997, <http://www.itu.int>.
[15] International Telecommunications Union, "Formats and codes of
the ISDN User Part of Signaling System No. 7", ITU-T Q.763,
December 1999, <http://www.itu.int>.
[16] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in SIP", draft-ietf-sip-100rel-06 (work in progress),
February 2002.
[17] Stewart, R., "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[18] Rosenberg, J., "The SIP UPDATE Method", draft-ietf-sip-update-
02 (work in progress), March 2002.
Camarillo, et al. Expires December 30, 2002 [Page 60]
Internet-Draft ISUP to SIP Mapping July 2002
Authors' Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Center
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
EMail: Gonzalo.Camarillo@Ericsson.com
URI: http://www.ericsson.com/
Adam Roach
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
EMail: adam@dynamicsoft.com
URI: sip:adam@dynamicsoft.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Lyndon Ong
Ciena
10480 Ridgeview Court
Cupertino, CA 95014
USA
EMail: lyOng@ciena.com
URI: http://www.ciena.com/
Camarillo, et al. Expires December 30, 2002 [Page 61]
Internet-Draft ISUP to SIP Mapping July 2002
Appendix A. 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, Jan
Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter
Du and John Elwell for their help and feedback on this document.
Camarillo, et al. Expires December 30, 2002 [Page 62]
Internet-Draft ISUP to SIP Mapping July 2002
Appendix B. 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
Changes from draft-ietf-sip-isup-03:
- Added provision for SUS/RES over INFO method
- Fixed ANSI CRM/CRA behavior
- Corrected a few status code conflicts
- Righted many nits (thanks Igor!)
Changes from draft-ietf-sipping-isup-00:
- Removed PRACK from call flows
Camarillo, et al. Expires December 30, 2002 [Page 63]
Internet-Draft ISUP to SIP Mapping July 2002
- Some updating to bring language in parity with bis
- Various nits
Changes from draft-ietf-sipping-isup-01:
- Minor editorial corrections.
- Updated references from RFC 2543 to RFC 3261.
- Split normative and non-normative references.
Changes from draft-ietf-sipping-isup-02:
- Strengthened language about overwriting parameters.
- Improved text on interworking indicators in FCI/BCI
- Various nits
Camarillo, et al. Expires December 30, 2002 [Page 64]
Internet-Draft ISUP to SIP Mapping July 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Camarillo, et al. Expires December 30, 2002 [Page 65]
