One document matched: draft-camarillo-sip-isup-bcp-00.txt
Internet Engineering Task Force Gonzalo Camarillo/Adam Roach
Internet Draft Ericsson
Category: Informational March 2000
Expires September 2000
<draft-camarillo-sip-isup-bcp-00.txt>
Best Current Practice for ISUP to SIP mapping
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document describes a way to perform the mapping between two
signalling protocols: SIP and ISUP.
Table of Contents
1. Introduction........................................... 3
2. Scope.................................................. 3
3. Scenarios.............................................. 4
4. Extensions Required.................................... 5
4.1. "Transparent" Transit of ISUP messages................. 5
4.2. Understanding of Multipart Bodies...................... 5
4.3. Transmission of DTMF information....................... 5
4.4. Reliable Transmission of Provisional Responses......... 6
4.5. Provisional Media Streams.............................. 6
4.6. Mid-Call Transactions Which do not Change SIP State.... 6
5. Mapping................................................ 6
6. SIP to ISUP mapping.................................... 7
6.1. Call Flows............................................. 7
Camarillo/Roach [Page 1]
Internet Draft BCP for SIP to ISUP Mapping March 2000
6.1.1. En-bloc Call Setup (non auto-answer)................... 7
6.1.2. Overlap Call Setup..................................... 8
6.1.3. Overlap call setup with a routing (redirect) server.... 11
6.1.4. Auto-answer call setup................................. 12
6.1.5. ISUP T7 expires........................................ 13
6.1.6. SIP Timeout............................................ 13
6.1.7. ISUP Setup Failure..................................... 15
6.1.8. Cause present in ACM message........................... 15
6.1.9. Call cancelled by SIP node............................. 17
6.2. State Machine.......................................... 18
6.2.1. INVITE received........................................ 19
6.2.2. ISUP T7 expires........................................ 21
6.2.3. CANCEL or BYE received................................. 21
6.2.4. REL received........................................... 22
6.2.5. Early ACM received..................................... 24
6.2.6. ACM received........................................... 24
6.2.7. CON or ANM received.................................... 25
6.2.8. Timer T9 expires....................................... 25
6.2.9. CPG received........................................... 25
6.2.10. ACK received........................................... 26
7. ISUP to SIP mapping.................................... 26
7.1. Call Flows............................................. 26
7.1.1. En-bloc call setup (non auto-answer)................... 26
7.1.2. Overlap call setup..................................... 27
7.1.3. Overlap call setup with a routing (redirect) server.... 30
7.1.4. Auto-answer call setup................................. 32
7.1.5. SIP Timeout............................................ 33
7.1.6. ISUP T9 Expires........................................ 34
7.1.7. SIP Error Response..................................... 35
7.1.8. SIP Redirection........................................ 36
7.1.9. Call Cancelled by ISUP................................. 37
7.2. State Machine.......................................... 38
7.2.1. Address received....................................... 39
7.2.2. 100 received........................................... 40
7.2.3. 18x received........................................... 40
7.2.4. 200 received........................................... 41
7.2.5. 3xx received........................................... 42
7.2.6. 4xx - 6xx received..................................... 42
7.2.7. REL received........................................... 43
7.2.8. ISUP T11 Expires....................................... 44
8. Suspend/Resume......................................... 44
9. Normal Release of the Connection....................... 45
9.1. SIP initiated.......................................... 45
9.2. ISUP Initiated......................................... 45
9.2.1. Caller hangs up........................................ 46
9.2.2. Callee hangs up........................................ 46
10. ISUP maintenance messages.............................. 46
10.1. Reset messages......................................... 46
10.2. Blocking messages...................................... 47
11. Other ISUP flavours.................................... 47
Camarillo/Roach [Page 2]
Internet Draft BCP for SIP to ISUP Mapping March 2000
12. Acronyms............................................... 47
13. Acknowledgments........................................ 48
14. References............................................. 48
15. Security Considerations................................ 50
16. Authors' Addresses..................................... 50
1. Introduction
SIP [1] is an application layer protocol for establishing,
terminating and modifying multimedia sessions. It is typically
carried over IP. Telephone calls are considered a type of
multimedia sessions where just audio is exchanged.
ISUP [2] is a level 4 protocol used in SS7 networks. It typically
runs over MTP although it will run also over IP (work in
progress, IETF SIGTRAN working group). ISUP is used for
controlling telephone calls and for maintenance of the network
(blocking circuits, resetting circuits etc.).
The module performing the mapping between these two protocols is
usually referred to as Media Gateway Controller (MGC). It has
logical interfaces towards both networks, the network carrying
ISUP and the network carrying SIP, although usually they are on
the same physical interface. The MGC also has capabilities for
controlling the voice path. There is typically a Media Gateway
(MG) with E1/T1 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.
2. Scope
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.
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 flavours of ISUP. ITU-T Q.767 International
ISUP [2] is used through this document and some differences with
ANSI ISUP [3] are outlined. ISUP Q.767 [2] was chosen because is
the least complex of all the ISUP flavours. Once the mapping
between this flavour of ISUP and SIP is clear, mapping from other
flavours to SIP will be easier to resolve.
This document describes when the media path has to be
initialized, terminated, modified, etc., but it does not go into
Camarillo/Roach [Page 3]
Internet Draft BCP for SIP to ISUP Mapping March 2000
details such as how the initialization is performed or which
protocols are used for that purpose.
3. Scenarios
There are several scenarios where ISUP-SIP mapping takes place.
The way the messages are generated is different depending on the
scenario.
When there is a single MGC and the call is from a SIP phone to a
PSTN phone, or vice versa, the MGC generates the ISUP messages
based on the methods described in this document.
+-------------+ +-----+ +-------------+
| PSTN switch +-------+ MGC +-------+ SIP UAC/UAS |
+-------------+ +-----+ +-------------+
The scenario where a call originates in the PSTN, goes into a SIP
network and terminates in the PSTN again is known as "SIP
bridging". SIP bridging should provide ISUP transparency between
the PSTN switches handling the call. This is achieved by carrying
the incoming ISUP messages in the body of the SIP messages [4] .
In this case, the ISUP messages generated by the egress MGC are
the ones present in the SIP body (possibly with some
modifications; for example, if the called number in the request
URI is different from the one present in the ISUP due to SIP
redirection, the ISUP message will need to be adjusted).
+------+ +-------------+ +-----+ +------------+ +------+
| PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
+------+ +-------------+ +-----+ +------------+ +------+
SIP is used in the middle of both MGCs because the voice path has
to be established through the IP network between both MGs; this
structure also allows the call to take advantage of certain SIP
services. ISUP messages in the SIP bodies provide further
information (such as cause values and optional parameters) to the
peer MGC.
In both scenarios, the ingress MGC places the incoming ISUP
messages in the SIP body by default. Note that this has security
implications; see section 15. If the recipient of these messages
(typically a SIP 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 Signalling Gateway (SG) between the PSTN and the
MGC. It encapsulates the ISUP messages over IP. The mapping
Camarillo/Roach [Page 4]
Internet Draft BCP for SIP to ISUP Mapping March 2000
described in this document is not affected by its presence.
4. Extensions Required
For a correct mapping between ISUP and SIP, some extensions to
the basic SIP specification are needed. These extensions 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 carry ISUP payloads from gateway to
gateway. The format for carrying these messages is defined in
"MIME media types for ISUP and QSIG Objects" [4] .
SIP clients and servers which do not understand ISUP are
encouraged to recognize this MIME type and ignore it.
4.2. Understanding of Multipart Bodies
In most PSTN interworking situations, the SIP body will be
required to carry session information in addition to ISUP and/or
billing information.
PSTN interworking nodes should understand the MIME type of
"multipart/mixed" as defined in RFC2046 [5] . Clients express
support for this by including "multipart/mixed" in an "Accept"
header.
4.3. Transmission of DTMF information
Since the codec selected for voice transmission may not be
ideally suited for carrying DTMF information, a symbolic method
of transmitting this information in-band is desirable (since
out-of-band transmission alone would provide many challenges for
syncronization of the media stream for tone re-insertion). This
transmission will be performed as described in "RTP Payload for
DTMF Digits, Telephony Tones and Telephony Signals" [6] .
In addition to the need to faithfully carry telephony tones
across the audio channel, PSTN interworking situations will
require the capability on the part of SIP nodes to collect
further digits from the end user. This may be used, for example,
Camarillo/Roach [Page 5]
Internet Draft BCP for SIP to ISUP Mapping March 2000
to provide authentication information to a SIP node via DTMF
without the SIP node needing to process the media stream. This
transit is accomplished using the method described in section 2.1
of "Sample Uses of SIP INFO with Varying Reliability Needs" [7] .
4.4. Reliable Transmission of Provisional Responses
Provisional responses are used to transmission of various
progress information. PSTN interworking in particular relies on
these messages for control of the media channel and timing of
messages.
PSTN interoperation nodes should implement the extension defined
in "Reliability of Provisional Responses in SIP" [8] .
4.5. Provisional Media Streams
To allow the transmission of messages and tones before a final
connection has been established, SIP nodes which interwork with
the PSTN need to be able to establish temporary media connections
during this period.
PSTN interoperating nodes should support the establishement of
temporary provisional media streams, as specified in "SIP 183
Session Progress Message" [9] .
4.6. Mid-Call Transactions Which do not Change SIP State
When interworking with PSTN, there are situations when PSTN nodes
will need to send messages which do not correspond to any SIP
operations to each other across a SIP network.
The method for performing this transit will be in the INFO
method, defined in "The SIP INFO Method" [10] .
Nodes which do serve as PSTN interworking points should accept
"405 Method Not Allowed" and "501 Not Implemented" responses to
INFO requests as non-fatal.
5. Mapping
The mapping between ISUP and SIP is described using call flow
diagrams and state machines. One state machine handles calls from
SIP to ISUP and the second from ISUP to SIP. There are details,
such as some retransmissions and some states (waiting for RLC,
waiting for ACK etc.), that are not shown in the figures in order
to make them easier to follow.
The boxes represent the different states of the gateway, and the
arrows show changes in the state. The event that triggers the
Camarillo/Roach [Page 6]
Internet Draft BCP for SIP to ISUP Mapping March 2000
change in the state and the actions to take appear on the arrow:
event / section describing the actions to take.
For example, `INVITE / 6.1' indicates that an INVITE request has
been received by the gateway, and the procedure upon reception is
described in the section 6.1 of this document.
6. SIP to ISUP mapping
6.1. Call Flows
The following call flows illustrate the order of messages in
typical success and error cases when setting up a call initiated
from the SIP network. "100 Trying" acknowledgements to INVITE
requests are not explained, since their presence is optional.
In these diagrams, all call singnalling (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 (non auto-answer)
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
5|----------PRACK---------->| |
6|<----------200------------| |
| |<-----------CPG-----------|7
8|<----------18x------------| |
9|----------PRACK---------->| |
10|<----------200------------| |
| |<-----------ANM-----------|11
| |<=========Audio==========>|
12|<----------200------------| |
|<=========Audio==========>| |
13|-----------ACK----------->| |
(1) When a SIP user wishes to begin a session with a PSTN user,
the SIP node issues an INVITE request.
(2) Upon receipt of an INVITE request, the gateway maps it to an
IAM message and sends it to the ISUP network.
Camarillo/Roach [Page 7]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(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 (180 for "subscriber free" and
183 for "no indication") and returned to the SIP node. This
response may contain SDP to establish an early media stream
(as shown in the diagram). If no SDP is present, the audio
will be established in both directions after step 12.
(5) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) The remote ISUP node may issue a variety of CPG messages to
indicate, for example, that the call is being forwarded.
(8) Upon receipt of a CPG message, the gateway will map the event
code to a SIP provisional response (see section 6.2.6. ) and
send it to the SIP node.
(9) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(10) The PRACK is confirmed
(11) Once the PSTN user answers, an ANM message will be sent to
the gateway.
(12) Upon receipt of the ANM, the gateway will send a 200 message
to the SIP node.
(13) The SIP node, upon receiving an INVITE final response (200),
will send an ACK to acknowledge receipt.
6.1.2. Overlap Call Setup
Camarillo/Roach [Page 8]
Internet Draft BCP for SIP to ISUP Mapping March 2000
SIP MGC/MG PSTN
1|---------INVITE---------->| |
2|<----------484------------| |
3|-----------ACK----------->| |
4|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|5
| |<=========Audio===========|
6|---------INVITE---------->| |
|<----------100------------| |
| |------------SAM---------->|7
8|---------INVITE---------->| |
|<----------100------------| |
| |------------SAM---------->|9
10|---------INVITE---------->| |
|<----------100------------| |
| |------------SAM---------->|11
| |<-----------ACM-----------|12
13|<----------180------------| |
|<=========Audio===========| |
14|<----------484------------| |
15|<----------484------------| |
16|<----------484------------| |
17|----------PRACK---------->| |
18|<----------200------------| |
19|-----------ACK----------->| |
20|-----------ACK----------->| |
21|-----------ACK----------->| |
| |<-----------ANM-----------|22
| |<=========Audio==========>|
23|<----------200------------| |
|<=========Audio==========>| |
24|-----------ACK----------->| |
(1) When a SIP user wishes to begin a session with a PSTN user,
the SIP node issues an INVITE request.
(2) The gateway may be able to determine that the number in the
SIP message is not long enough to set up a call (for example;
it may not have enough of a number to know what PSTN node to
route to). Under these circumstances, it will immediately
return a "484 Address Incomplete" message.
(3) The 484 is acknowledged.
(4) After collecting more digits, the SIP node sends another
INVITE. This invite contains the same "From" and "Call-ID"
headers. The "To" field is updated to reflect the entire
called number as known so far. Since the "To" field is
Camarillo/Roach [Page 9]
Internet Draft BCP for SIP to ISUP Mapping March 2000
different, this transaction represents a different call leg
than the INVITE in step 1; consequently, there is no
relationship between the CSeq values in the two INVITE
messages. Note that the gateway may drop state knowledge
between steps 3 and 4 unless ISUP tunnelling is being
performed. (For ISUP tunneling, the IAM present in the
initial INVITE will need to be reserved for step 5).
(5) Once the gateway is not sure that the number is too short, it
will send out the digits from the INVITE message as an IAM.
(6) As more digits are collected, they will also be sent as
INVITE messages. Note that the "To" field still contains the
entire string of digits collected so far, not just the new
ones.
(7) The newly collected digits are sent to the PSTN as SAM
messages.
(8) See step 6
(9) See step 7
(10) See step 6
(11) See step 7
(12) Once the remote PSTN node receives enough digits, it will
send an ACM message to indicate that it can now route the
call.
(13) The gateway sends a 180 message for the most recent pending
transaction (or a 183 if the "called party status" field is
marked "no indication"). The transaction to which this
response belongs will be same as the INVITE which contains a
complete phone number in its "To" field (the one sent in step
10).
(14) "484 Address Incomplete" is sent to complete the INVITE
transaction started in step 4.
(15) "484 Address Incomplete" is sent to complete the INVITE
transaction started in step 6.
(16) "484 Address Incomplete" is sent to complete the INVITE
transaction started in step 8.
(17) The remote node sends a PRACK to acknowledge receipt of the
18x message sent in step 13.
Camarillo/Roach [Page 10]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(18) The 484 from step 14 is acknowledged.
(19) The 484 from step 15 is acknowledged.
(20) The 484 from step 16 is acknowledged.
(21) Once the PSTN user answers, an ANM message will be sent to
the gateway.
(22) Upon receipt of the ANM, the gateway will send a 200 message
to the SIP node.
(23) The SIP node, upon receiving an INVITE final response (200),
will send an ACK to acknowledge receipt.
6.1.3. Overlap call setup with a routing (redirect) server
SIP Routing Server PSTN
1|---------INVITE---------->| |
2|<----------484------------| |
3|-----------ACK----------->| |
4|---------INVITE---------->| |
5|<----------484------------| |
6|-----------ACK----------->| |
7|---------INVITE---------->| |
8|<----------302------------| |
9|-----------ACK----------->| |
| |
| |
| MGC/MG |
10|---------INVITE---------->| |
...
(1) When a SIP user wishes to begin a session with a PSTN user,
the SIP node issues an INVITE request. In this example, the
INVITE is sent to a server which knows how to select the
egress gateway based on a numbering prefix.
(2) Since the routing server doesn't have enough information to
select an egress gateway, it responds with a "484 Address
Incomplete".
(3) The 484 is acknowledged.
(4) After collecting more digits, the SIP node sends another
INVITE. This invite contains the same "From" and "Call-ID"
headers. The "To" field is updated to reflect the entire
called number as known so far. Since the "To" field is
different, this transaction represents a different call leg
Camarillo/Roach [Page 11]
Internet Draft BCP for SIP to ISUP Mapping March 2000
than the INVITE in step 1; consequently, there is no
relationship between the CSeq values in the two INVITE
messages. Note that the routing server will probably drop
state knowledge between steps 3 and 4.
(5) In this example, there is still not enough information to
route the call.
(6) The 484 is acknowledged.
(7) As in step 4, more digits are collected. While this INVITE
contains enough information for the routing server to select
a gateway, it is quite probable that the number is not yet
complete.
(8) A "302 Temporarily Moved" response is returned to redirect
the SIP node to the appropriate gateway. (In practice, this
may not necessarily be a gateway; it might be another
redirect server, a proxy server, or a native client).
(9) The 302 is acknowledged.
(10) The call now continues as in step 1 of section 6.1.2.
6.1.4. Auto-answer call setup
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
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.
(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 ANM, the gateway will send a 200 message
to the SIP node.
Camarillo/Roach [Page 12]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(5) The SIP node, upon receiving an INVITE final response (200),
will send an ACK to acknowledge receipt.
6.1.5. ISUP T7 expires
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
(1) When a SIP user wishes to begin a session with a PSTN user,
the SIP node issues an INVITE request.
(2) Upon receipt of an INVITE request, the gateway maps it to an
IAM message and sends it to the ISUP network. The ISUP timer
T7 is started at this point.
(3) The ISUP timer T7 expires before receipt of an ACM or CON
message, so a REL message is sent to cancel the call.
(4) A gateway timeout message is sent back to the SIP node.
(5) The SIP node, upon receiving an INVITE final response (504),
will send an ACK to acknowledge receipt.
6.1.6. SIP Timeout
Camarillo/Roach [Page 13]
Internet Draft BCP for SIP to ISUP Mapping March 2000
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.
(4) Upon receipt of the ANM, the gateway will send a 200 message
to the SIP node and set SIP timer T1.
(5) The response is retransmitted every time the SIP timer T1
expires.
(6) After seven retransmissions, the call is torn down by sending
a REL to the ISUP node, with a cause code of 102 (recover on
timer expiry).
(7) A BYE is transmitted to the SIP node in an attempt to close
the call. Further handling for this clean up is not shown,
since the SIP node's state is not easily known in this
scenario.
Camarillo/Roach [Page 14]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(8) Upon receipt of the REL message, the remote ISUP node will
reply with an RLC message.
6.1.7. 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.
6.1.8. Cause present in ACM message
Camarillo/Roach [Page 15]
Internet Draft BCP for SIP to ISUP Mapping March 2000
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
5|----------PRACK---------->| |
6|<----------200------------| |
** Interwork timer expires **
7|<----------4xx+-----------| |
| |------------REL---------->|8
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
(1) When a SIP user wishes to begin a session with a PSTN user,
the SIP node issues an INVITE request.
(2) Upon receipt of an INVITE request, the gateway maps it to an
IAM message and sends it to the ISUP network.
(3) Since the ISUP node is unable to complete the call and wants
to generate the error tone/announcement itself, it sends an
ACM with a cause code. The gateway starts an interwork timer.
(4) Upon receipt of an ACM with cause, the gateway will generate
a 183 message towards the SIP node; this contains SDP to
establish early media cut-through.
(5) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) A final INVITE response, based on the cause code received in
the earlier ACM message, is generated and sent to the SIP
node to terminate the call. See section 6.2.4. for the table
which contains the mapping from cause code to SIP response.
(8) Upon expiration of the interwork timer, a REL is sent towards
the SIP 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 signalling
progresses as in section 6.1.9.
(9) Upon receipt of the REL message, the remote ISUP node will
reply with an RLC message.
Camarillo/Roach [Page 16]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(10) The SIP node sends an ACK to acknowledge receipt of the
INVITE final response.
6.1.9. Call cancelled by SIP node
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
5|----------PRACK---------->| |
6|<----------200------------| |
| ** MG Releases IP Resources ** |
7|----------CANCEL--------->| |
8|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|9
10|<----------487------------| |
| |<-----------RLC-----------|11
12|-----------ACK----------->| |
(1) When a SIP user wishes to begin a session with a PSTN user,
the SIP node issues an INVITE request.
(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 (180 for "subscriber free" and
183 for "no indication") and returned to the SIP node. This
response may contain SDP to establish an early media stream.
(5) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) To cancel the call before it is answered, the SIP node sends
a CANCEL request.
(8) The CANCEL request is confirmed with a 200 response.
(9) Upon receipt of the CANCEL request, the gateway sends a REL
Camarillo/Roach [Page 17]
Internet Draft BCP for SIP to ISUP Mapping March 2000
message to terminate the ISUP call.
(10) The gateway sends a "487 Call Cancelled" message to the SIP
node to complete the INVITE transaction.
(11) Upon receipt of the REL message, the remote ISUP node will
reply with an RLC message.
(12) Upon receipt of the 487, the SIP node will confirm reception
with an ACK.
6.2. State Machine
Note that REL can be received in any state; the handling is the
same for each case (see section 6.2.4. ).
Camarillo/Roach [Page 18]
Internet Draft BCP for SIP to ISUP Mapping March 2000
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+
6.2.1. INVITE received
When an INVITE request is received by the gateway, a "100 Trying"
response may be sent back to the SIP network indicating that the
MGC is handling the call.
The resources for the media stream have to be reserved at this
stage, since an IAM message cannot be sent before the resource
reservation takes place. Typically the resources consist of a
time slot in an E1/T1 and an RTP/UDP port on the IP side.
Resources might also include QoS or/and security provisions.
Before sending the IAM the MG gets backward through connected.
Camarillo/Roach [Page 19]
Internet Draft BCP for SIP to ISUP Mapping March 2000
An ISUP IAM is sent. If the incoming INVITE contains a IAM in its
body this IAM is sent (possibly with certain changes; for
example, the called number may need to be updated from the "To"
field if the call was redirected inside the SIP network). If no
IAM is present the MGC generates one. The mandatory parameters of
the IAM are described below:
Message type: IAM
Nature of connection indicators
Satellite Indicator: 00 no satellite circuit
Continuity check indicator: It depends on the call
typically, 0 (no check)
Echo control device indicator: It depends on the call
Forward call indicators
National/International call indicator: It depends on the call
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
ISDN user part preference indicator: 00 ISUP preferred
ISDN access indicator: 1 ISDN access
SCCP method indicator: 0 no indication
Calling party's category: Depends on caller; usually
00001010 ordinary
Transmission medium requirement: It depends on the call
Called party's number: Based on the 'to' field
The optional parameter `Calling party number' can be added. Its
value can be derived based on the SIP `from' header. Optionally,
if this information cannot be verified, it may be sent as a
`Generic Address Parameter.' Further, the gateway may choose to
populate the `Original Called Number' (if it had to update the
`Called Number' field) and the `Charge Number' field (based on a
billing number obtained through means which are outside the scope
of this document).
When the ISUP parameters regarding interworking are set, 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.
Camarillo/Roach [Page 20]
Internet Draft BCP for SIP to ISUP Mapping March 2000
Thus, `interworking encountered' must not be specified so that
ISUP behaves normally. SIP is considered as an SS7 network and a
SIP phone is considered as ISDN access since the SIP network is
supposed to provide at least as many services as ISUP.
Claiming to be an ISDN node might make the callee request ISDN
user to user services. Since user to user sevices 1 and 2 must be
requested by the caller, they do not represent a problem [13] .
User to user service 3 can be requested by the callee also. In
non-SIP bridging situations, the MGC should be capable of
rejecting this service request.
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.
When overlap signalling is used in SIP bridging situations, more
INVITEs might arrive containing subsequent digits of the callees'
number. These INVITEs have the same Call-ID and From fields, but
the To field contains more digits.
The MGC receives these digits and sends a SAM with the new digits
and restarts T7 every time a new INVITE arrives. All the INVITEs
but the last one containing all the digits are answered with 484
Address Incomplete. The reception of an ACM from the ISUP network
confirms that the callees' address is complete.
See sections 6.1.2. and 7.1.2. for a more detailed handling of
overlapped dialing.
6.2.2. ISUP T7 expires
Since no response was received from the PSTN all the resources in
the MG are released. A `408 request timeout' is sent back to the
SIP network. A REL message with cause value 111 (protocol error)
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.
Camarillo/Roach [Page 21]
Internet Draft BCP for SIP to ISUP Mapping March 2000
In SIP bridging situations, a REL might arrive in the CANCEL or
BYE request body. This REL is sent to the PSTN.
This section ( 6.2.3. ) applies every time that a CANCEL or a BYE
is received before a final SIP response has been sent.
6.2.4. REL received
This section applies every time that a REL is received before a
final SIP response has been sent.
The resources are released in the MG and a RLC is sent to the
ISUP network to indicate that the circuit is available for reuse.
If the INVITE originating this transaction contained ISUP
messages in its body (IAM or SAMs), the MGC is handling a SIP
bridging situation. Therefore, the REL message jut received
should be included in the body of the response.
The REL contains a cause value. The SIP response is sent based on
this cause value. If a cause value other than what is listed
below is received, the default response `500 Server internal
error' would be used.
Normal event
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 410 Gone
2 no route to network 404 Not found
3 no route to destination 404 Not found
4 send special information tone ---
16 normal call clearing ---
17 user busy 486 Busy here
18 no user responding 480 Temporarily unavailable
19 no answer from the user 480 Temporarily unavailable
21 call rejected 603 Decline
22 number changed 301 Moved Permanently
27 destination out of order 404 Not found
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 404 Not found
A REL with cause 22 (number changed) might contain information
about a new number where the callee might be reachable. If the
MGC is able to parse this information it might be added to the
SIP response in a Contact header.
Camarillo/Roach [Page 22]
Internet Draft BCP for SIP to ISUP Mapping March 2000
Resource unavailable
This kind of cause value indicates a non permanent situation. A
`Retry-After' header has to be added to the response.
ISUP Cause value SIP response
---------------- ------------
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
41 temporary failure 503 Service unavailable
42 switching equipment congestion 503 Service unavailable
44 requested channel not available 503 Service unavailable
47 resource unavailable 503 Service unavailable
Service or option not available
This kind of cause value indicates a permanent situation
ISUP Cause value SIP response
---------------- ------------
55 incoming calls bared within CUG 603 Decline
57 bearer capability not authorized 503 Service unavailable
58 bearer capability not presently 503 Service unavailable
available
63 service/option not available 503 Service unavailable
Service or option not implemented
ISUP Cause value SIP response
---------------- ------------
65 bearer capability not implemented 501 Not implemented
79 service or option not implemented 501 Not implemented
Invalid message
ISUP Cause value SIP response
---------------- ------------
87 user not member of CUG 503 Service unavailable
88 incompatible destination 503 Service unavailable
95 invalid message 503 Service unavailable
Protocol error
Camarillo/Roach [Page 23]
Internet Draft BCP for SIP to ISUP Mapping March 2000
ISUP Cause value SIP response
---------------- ------------
102 recovery of timer expiry 408 Request timeout
111 protocol error 500 Server internal error
Interworking
ISUP Cause value SIP response
---------------- ------------
127 interworking unspecified 500 Server internal error
6.2.5. Early ACM received
This message is sent in certain situations for resetting the
timers. In these cases this message indicates that the call is in
progress but callee is not being alerted. This occurs for example
in mobile networks, where roaming can take a long time. The early
ACM is sent before the user is alerted to reset T7 and start T9.
An ACM is considered an `early ACM' if the Called Party's Status
Indicator is set to 00 (no indication).
After receiving an early ACM the progress of the call is
indicated by the network sending CPGs.
When there is interworking with some old systems, it is possible
to receive an ANM immediately after an early ACM (without CPG).
In this situation the SIP user will not hear any kind of ringback
tone before the callee answers. In ISDN [11] this is solved by
connecting the voice path backwards before sending the IAM.
The MGC sends a 183 Session Progress [9] to the SIP network with
a media description inside. In SIP bridging situations the early
ACM is included in the response body. Thus, the problem of
missing the ring back tone is solved and the early ACM is
transported transparently through the SIP network.
6.2.6. ACM received
Upon reception of an ACM timer T9 is started. T9 typically lasts
between 90 seconds and 3 minutes [12] . It allows the caller to
hear announcements from the network for that period of time
without being charged for the connection. If longer announcements
have to be played the network has to send an ANM. When the ANM is
sent the call begins being charged.
The nearest local exchange to the callee generates the ringback
tone and may send voice announcements.
Camarillo/Roach [Page 24]
Internet Draft BCP for SIP to ISUP Mapping March 2000
A `180 Ringing' is sent to the SIP network. It contains a media
description. The ringback tone or the proper announcements will
be generated by the PSTN exchange, and not by the callers SIP
UAC/UAS.
In SIP bridging situations, the ACM is included in the body of
the 180 response.
6.2.7. CON or ANM received
A `200 OK' response is sent to the SIP network. In SIP bridging
situations, the ISUP message is included in the body of the 200
OK response. This is also the point at which a two-way media
stream will be established.
6.2.8. Timer T9 expires
This indicates that the ANM has not arrived in time specified.
This results in the call being aborted. All the resources related
to the media path are released. A `480 temporarily unavailable'
is sent to the SIP network. A REL message with cause value 19 (no
answer from the user) is sent to the ISUP part. The PSTN responds
with RLC and the SIP network responds with an ACK indicating that
the release sequence has been completed.
6.2.9. CPG received
A CPG can indicate progress, alerting or in-band information. If
the CPG comes after an ACM, there is already a one-way voice path
open, so there is no need of taking further action in the media
path.
In SIP bridging situations, the CPG is sent in the body of a 18x
response, determined from the CPG event code.
ISUP event code SIP response
---------------- ------------
1 Alerting 180 Ringing
2 Progress 183 Call progress
3 In-band information 183 Call progress
4 Call forward; line busy 181 Call is being forwarded
5 Call forward; no reply 181 Call is being forwarded
6 Call forward; unconditional 181 Call is being forwarded
- (no event code present) 183 Call progress
Note that, if the CPG does not indicate "Alerting," the current
state will not change.
Camarillo/Roach [Page 25]
Internet Draft BCP for SIP to ISUP Mapping March 2000
6.2.10. ACK received
At this stage, the two-way voice channel may be modified based on
the SDP present in the ACK. The call is connected and the
conversation can take place.
7. ISUP to SIP mapping
7.1. Call Flows
The following call flows illustrate the order of messages in
typical success and error cases when setting up a call initiated
from the PSTN network. "100 Trying" acknowledgements to INVITE
requests are not explained, since their presence is optional.
In these diagrams, all call singnalling (SIP, ISUP) is going to
and from the MGC; media handling (e.g. audio cut-through, trunk
freeing) is being performed by the MG, under the control of the
MGC. For the purpose of simplicity, these are shown as a single
node, labeled "MGC/MG."
7.1.1. En-bloc call setup (non auto-answer)
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
5|<---------PRACK-----------| |
6|-----------200----------->| |
7|-----------18x----------->| |
| |------------CPG---------->|8
9|<---------PRACK-----------| |
10|-----------200----------->| |
11|-----------200----------->| |
|<=========Audio==========>| |
| |------------ANM---------->|12
| |<=========Audio==========>|
13|<----------ACK------------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
Camarillo/Roach [Page 26]
Internet Draft BCP for SIP to ISUP Mapping March 2000
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. If this 180 contains
a session description,
(4) Upon receipt of a provisional response of 180 or greater, the
gateway will generate an ACM message. If the response is not
180, the ACM will carry a "called party status" value of "no
indication."
(5) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) The SIP node may use further provisional messages to indicate
call progress.
(8) After an ACM has been sent, all provisional responses will
translate into ISUP CPG messages as indicated in 7.2.3.
(9) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(10) The PRACK is confirmed
(11) When the SIP node answers the call, it will send a 200 OK
message.
(12) Upon receipt of the 200 OK message, the gateway will send an
ANM message towards the ISUP node.
(13) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.1.2. Overlap call setup
Note that supporting overlap dialing in the SIP network is an
option that may be deemed undesirable due to the large number of
messages involved. In this case, the gateway may elect to collect
digits until a timer expires or a stop digit (such as #) is
entered by the user.
Camarillo/Roach [Page 27]
Internet Draft BCP for SIP to ISUP Mapping March 2000
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------484----------->| |
4|<----------ACK------------| |
| |<-----------SAM-----------|5
6|<--------INVITE-----------| |
|-----------100----------->| |
| |<-----------SAM-----------|7
8|<--------INVITE-----------| |
|-----------100----------->| |
| |<-----------SAM-----------|9
10|<--------INVITE-----------| |
|-----------100----------->| |
| |<-----------SAM-----------|11
12|<--------INVITE-----------| |
|-----------100----------->| |
13|-----------18x----------->| |
|==========Audio==========>| |
14|<---------PRACK-----------| |
| |------------ACM---------->|15
16|-----------484----------->| |
17|<----------ACK------------| |
18|-----------484----------->| |
19|<----------ACK------------| |
20|-----------484----------->| |
21|<----------ACK------------| |
22|-----------200----------->| |
23|-----------18x----------->| |
| |------------CPG---------->|24
25|<---------PRACK-----------| |
26|-----------200----------->| |
27|-----------200----------->| |
|<=========Audio==========>| |
| |------------ANM---------->|28
| |<=========Audio==========>|
29|<----------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. It is possible that the gateway
won't have enough information to send the INVITE yet; this
situation is not shown. Under these circumstances, the
gateway holds on to the IAM until it has received enough
Camarillo/Roach [Page 28]
Internet Draft BCP for SIP to ISUP Mapping March 2000
digits that it knows where to send the INVITE.
(3) The far end may immediately determine that it is unable to
terminate the call due to an insufficient number of digits.
It will return a "484 Address Incomplete" message under these
circumstances.
(4) The 484 is acknowledged.
(5) A SAM arrives from the PSTN with additional digits present.
(6) The gateway appends the new digits to the number it is
sending in the "To" field and re-sends the INVITE. This
INVITE contains the same "From" and "Call-ID" headers. Since
the "To" field of this message is different from the previous
INVITE(s), this transaction represents a different call leg
than the INVITE in step 1; consequently, there is no
relationship between the CSeq values in the two INVITE
messages.
(7) See step 5
(8) See step 6
(9) See step 5
(10) See step 6
(11) See step 5
(12) See step 6
(13) Once the far end SIP node has determined that it has enough
information to successfully route the call, it sends a 18x
message.
(14) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(15) Upon receipt of a provisional response of 180 or greater,
the gateway will generate an ACM message to indicate that
enough digits have been collected. If the response is not
180, the ACM will carry a "called party status" value of "no
indication."
(16) "484 Address Incomplete" arrives to complete the INVITE
transaction started in step 6.
(17) The 484 in step 16 is acknowledged
Camarillo/Roach [Page 29]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(18) "484 Address Incomplete" arrives to complete the INVITE
transaction started in step 8.
(19) The 484 in step 18 is acknowledged
(20) "484 Address Incomplete" arrives to complete the INVITE
transaction started in step 10.
(21) The 484 in step 20 is acknowledged
(22) The PRACK from step 14 is acknowledged
(23) The SIP node may use further provisional messages to
indicate call progress.
(24) After an ACM has been sent, all provisional responses will
translate into ISUP CPG messages as indicated in 7.2.3.
(25) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(26) The PRACK is confirmed
(27) When the SIP node answers the call, it will send a 200 OK
message.
(28) Upon receipt of the 200 OK message, the gateway will send an
ANM message towards the ISUP node.
(29) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.1.3. Overlap call setup with a routing (redirect) server
Camarillo/Roach [Page 30]
Internet Draft BCP for SIP to ISUP Mapping March 2000
Redirect Server MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------484----------->| |
4|<----------ACK------------| |
| |<-----------SAM-----------|5
6|<--------INVITE-----------| |
7|-----------484----------->| |
8|<----------ACK------------| |
| |<-----------SAM-----------|9
10|<--------INVITE-----------| |
11|-----------302----------->| |
12|<----------ACK------------| |
| |
| |
Egress MGC/MG | |
13|<--------INVITE-----------| |
|-----------100----------->| |
| |<-----------SAM-----------|
...
(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. In this example, this node is a
routing (redirection) server.
(3) Since the routing server doesn't have enough information to
select an egress gateway, it responds with a "484 Address
Incomplete".
(4) The 484 is acknowledged.
(5) After collecting more digits, the PSTN node sends a SAM with
the additional digits.
(6) The gateway appends the new digits to the number it is
sending in the "To" field and re-sends the INVITE. This
INVITE contains the same "From" and "Call-ID" headers. Since
the "To" field of this message is different from the previous
INVITE(s), this transaction represents a different call leg
than the INVITE in step 1; consequently, there is no
relationship between the CSeq values in the two INVITE
messages.
Camarillo/Roach [Page 31]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(7) In this example, there is still not enough information to
route the call.
(8) The 484 is acknowledged.
(9) See step 5.
(10) See step 6.
(11) The INVITE finally contains enough digits that the redirect
server can select a next-hop SIP node. A "302 Temporarily
Moved" response is returned to redirect the SIP node to the
appropriate gateway. (In practice, this may not necessarily
be a gateway; it might be another redirect server, a proxy
server, or a native client). Note that it is quite probable
that the called number is not completely collected at this
time; sending an ACM towards the PSTN would be extremely
destructive at this point in the call, since it would prevent
any further collection of digits.
(12) The 302 is acknowledged.
(13) The call now continues as in step 2 of section 7.1.2.
7.1.4. 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.
Camarillo/Roach [Page 32]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(5) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.1.5. 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 from being torn down by the remote node's
ISUP T7. This ACM contains a `Called Party Status' value of
`no indication.'
Camarillo/Roach [Page 33]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(5) Once the maximum number of INVITE requests has been sent, the
gateway will send a REL to the ISUP node to terminate the
call. Since this would appear to be a serious problem with
the network, the REL contains a cause code of 38: network out
of order.
(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.6. 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
Camarillo/Roach [Page 34]
Internet Draft BCP for SIP to ISUP Mapping March 2000
more and doubles each time it is retransmitted, it will be at
least a minute before SIP times out the INVITE request; since
SIP T1 is allowed to be larger than 500 ms initially, it is
possible that 7 x SIP T1 will be longer than ISUP T11 + ISUP
T9.
(4) When T11 expires, an ACM message will be sent to the ISUP
node to prevent the from being torn down by the remote node's
ISUP T7. This ACM contains a `Called Party Status' value of
`no indication.'
(5) When ISUP T9 in the remote PSTN node expires, it will send a
REL.
(6) Upon receipt of the REL, the gateway will send an RLC to
acknowledge.
(7) The REL will trigger a CANCEL request, which gets sent to the
SIP node.
7.1.7. 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.
Camarillo/Roach [Page 35]
Internet Draft BCP for SIP to ISUP Mapping March 2000
(6) The remote ISUP node confirms receipt of the REL message with
an RLC message.
7.1.8. 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|<---------PRACK-----------| |
10|-----------200----------->| |
11|-----------200----------->| |
|<=========Audio==========>| |
| |------------ANM---------->|12
| |<=========Audio==========>|
13|<----------ACK------------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
INVITE message, and sends it to an appropriate SIP node based
on called number analysis.
(3) The SIP node indicates that the resource which the user is
attempting to contact is at a different location by sending a
3xx message.
(4) The gateway sends a CPG with event indication that the call
is being forwarded upon receipt of the 3xx message. Note that
this translation should be able to be disabled by
configuration, as some ISUP nodes do not support receipt of
CPG messages before ACM messages.
(5) The gateway acknowledges receipt of the INVITE final response
by sending an ACK message to the SIP node.
(6) The gateway re-sends the INVITE message to the address
Camarillo/Roach [Page 36]
Internet Draft BCP for SIP to ISUP Mapping March 2000
indicated in the Contact: field of the 3xx message.
(7) When an event signifying that the call has sufficient
addressing information occurs, the SIP node will generate a
provisional response of 180 or greater.
(8) Upon receipt of a provisional response of 180 or greater, the
gateway will generate an ACM message with an event code as
indicated in section 7.2.3.
(9) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(10) The PRACK is confirmed
(11) When the SIP node answers the call, it will send a 200 OK
message.
(12) Upon receipt of the 200 OK message, the gateway will send an
ANM message towards the ISUP node.
(13) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.1.9. Call Cancelled by ISUP
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
5|<---------PRACK-----------| |
6|-----------200----------->| |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|7
| |------------RLC---------->|8
9|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
10|-----------200----------->| |
11|-----------487----------->| |
12|<----------ACK------------| |
(1) When a PSTN user wishes to begin a session with a SIP user,
the PSTN network generates an IAM message towards the
gateway.
(2) Upon receipt of the IAM message, the gateway generates an
Camarillo/Roach [Page 37]
Internet Draft BCP for SIP to ISUP Mapping March 2000
INVITE message, and sends it to an appropriate SIP node based
on called number analysis.
(3) When an event signifying that the call has sufficient
addressing information occurs, the SIP node will generate a
provisional response of 180 or greater.
(4) Upon receipt of a provisional response of 180 or greater, the
gateway will generate an ACM message with an event code as
indicated in section 7.2.3.
(5) The gateway sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) If the calling party hangs up before the SIP node answers the
call, a REL message will be generated.
(8) The gateway frees the PSTN circuit and indicates that it is
available for reuse by sending an RLC.
(9) Upon receipt of a REL message before an INVITE final
response, the gateway will send a CANCEL towards the SIP
node.
(10) Upon receipt of the CANCEL, the SIP node will send a 200
response.
(11) The remote SIP node will send a "487 Call Cancelled" to
complete the INVITE transaction.
(12) The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
7.2. State Machine
Note that REL may arrive in any state. Whenever this occurs, the
actions in section 7.2.7. are taken. Not all of these transitions
are shown in this diagram.
Camarillo/Roach [Page 38]
Internet Draft BCP for SIP to ISUP Mapping March 2000
+---------+
+----------------------->| 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.1 |
+<------------+ Connected +------------>+
+-----------------------------+
7.2.1. Address 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).
The called number can be received in just one IAM (`en bloc'
signalling) or in one IAM followed by one or several SAMs
(overlap signalling). In some countries there is no way for the
MGC to know whether the callees' number is already complete or
some SAMs will still arrive.
If the MGC relies on the inter-digit timeout to assume that the
number is complete, the establishment of the connection is
delayed. Alternatively, if the MGC sends the INVITE request
immediately after receiving the IAM, heavy signalling traffic may
be generated.
Camarillo/Roach [Page 39]
Internet Draft BCP for SIP to ISUP Mapping March 2000
Therefore, an individual MGC might implement a timer and/or a
stop digit (such as #). All the digits that arrive before this
timer expires will be included in the INVITE sent. The timer can
be bypassed by the user sending the stop digit. This timer should
not be larger than 5 seconds.
Thus, after receiving the IAM and possibly one or several SAMs,
the MGC issues an INVITE request. The "To" field contains the
digits received so far. If, after sending this INVITE request,
one or more SAMs are received, the MGC sends a new INVITE. This
new INVITE has the same "From" and "Call-ID" as the previous
INVITE sent. The "To" field is updated and contains all the
available digits.
`484 Address Incomplete' responses will be received for all the
INVITEs sent with the incomplete callees number. Thus, all the
call legs (same `Call-ID', different to) created while the digits
are arriving are deleted.
See sections 6.1.2. and 7.1.2. for a more detailed handling of
overlapped dialing.
7.2.2. 100 received
A 100 response does not trigger any PSTN interworking messages;
it only serves the purpose of suppressing INVITE retransmissions.
7.2.3. 18x received
If no ACM has been sent yet and no ISUP is present in the 18x
message body, and ISUP message is generated according to the
following table Note that, if an early ACM is sent, the call
enters state "Progressing" instead of state "Alerting."
Response received Message sent by the MGC
----------------- -----------------------
180 Ringing ACM
181 Call is being forwarded Early ACM and CPG, event=6
182 Queued ACM
183 Session progress message ACM
If an ACM has already been sent and no ISUP is present in the 18x
message body, an ISUP message is generated according to the
following table.
Camarillo/Roach [Page 40]
Internet Draft BCP for SIP to ISUP Mapping March 2000
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
In SIP bridging situations the MGC sends the ISUP message
contained in the response body.
7.2.4. 200 received
Response received Message sent by the MGC
----------------- -----------------------
200 OK ANM, ACK
After receiving a 200 OK response the MGC establishes a two-way
voice path in the MG and it sends an ANM to the PSTN and an ACK
Camarillo/Roach [Page 41]
Internet Draft BCP for SIP to ISUP Mapping March 2000
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. If the response body contains an ACM and an
ANM both are sent to the PSTN (first the ACM and then the ANM).
7.2.5. 3xx received
When any 3xx response is received ,the MGC should try to contact
the user using the `Contact' header or headers present in the
response. These 3xx responses are typically sent by a re-direct
server. This is a similar device to the HLR in mobile networks.
It provides another address where the callee may be reached.
A CPG message with an event code of 2 (Progress) may be sent to
indicate that the call is proceeding. Note that some ISUP nodes
may not support CPG before ACM, so this feature should be
configurable.
The 3xx MUST NOT result in the generation of an ACM message,
since there may be more digits pending in overlap dialing
situations. See sections 6.1.3. and 7.1.3. for callflows that
demonstrate the situations in which this behavior would prove
harmful.
In SIP bridging situations, the MGC sends the ISUP message
contained in the response body (if any). It is worthwhile
mentioning that a REL with cause value 22 (number changed) might
be contained in the response body of the 3xx response. This REL
might contain a new number where the callee might be reachable.
This REL can be sent to the PSTN, but most of the PSTN switches
are not able to process this information. Thus, if the MGC is
able to parse the new number, it might try the new location.
If the new location is reachable via 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 reachable using SIP, the MGC
sends an INVITE with possibly a new IAM generated by the MGC in
the message body.
All redirection situations have to be treated very carefully
because they involved special charging situations. In PSTN the
caller typically pays the first call leg and the callee pays the
second.
7.2.6. 4xx - 6xx received
Camarillo/Roach [Page 42]
Internet Draft BCP for SIP to ISUP Mapping March 2000
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.
Response received Cause value in the REL
----------------- ----------------------
400 Bad request 127 Interworking
401 Unauthorized 21 Call rejected
402 Payment required 21 Call rejected
403 Forbidden 1 Unallocated number
404 Not found 1 Unallocated number
405 Method not allowed 38 Network out of order
406 Not acceptable 58 Bearer capability not
presently available
407 Proxy authentication required 21 Call rejected
408 Request timeout 102 Recovery on timer expiry
409 Conflict 41 Temporary failure
410 Gone 1 Unallocated number
411 Length required 127 Interworking
413 Request Entity too long 127 Interworking
414 Request-URI too long 127 Interworking
415 Unsupported media type 79 Service/option not
implemented
420 Bad extension 127 Interworking
480 Temporarily unavailable 18 No user responding
481 Call leg/transaction doesn't exist 127 Interworking
482 Loop detected 127 Interworking
483 Too many hoops 127 Interworking
484 Address incomplete ---
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
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 Gateway time-out 102 Recovery on timer expiry
505 Version not supported 127 Interworking
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable 38 Network out of order
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.
Camarillo/Roach [Page 43]
Internet Draft BCP for SIP to ISUP Mapping March 2000
The MGC has to store state information for a certain period of
time, since a 200 final response for the INVITE originally sent
might arrive (even after the reception of the 200 OK for the
CANCEL). In this situation, the MGC sends an ACK and then a BYE.
In SIP bridging situations, the REL message may be included in
the CANCEL message body. CANCEL requests are answered with a
final response (such as 200 OK) by the first proxy. Therefore,
the MGC does not know if the CANCEL has arrived to the end user
(egress MGC in this scenario). Hence, if a 200 OK response for
the previously sent INVITE arrives the MGC sends an ACK and then
a BYE with the REL in the message body.
7.2.8. ISUP T11 Expires
In order to prevent the remote ISUP node's timer T7 from
expiring, the gateway may choose to keep its own supervisory
timer; ISUP defines this timer as T11. T11's duration is
carefully chosen so that it will always be shorter than the T7 of
any node to which the gateway is communicating.
To clarify timer T11's relevance with respect to SIP
interworking, Q.764 [14] explains its use as: "If in normal
operation, a delay in the receipt of an address complete signal
from the succeeding network is expected, the last common channel
signalling 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 7.1.6. for an example callflow that includes the expiration
of T11.
8. Suspend/Resume
In ISDN networks, the 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.
Camarillo/Roach [Page 44]
Internet Draft BCP for SIP to ISUP Mapping March 2000
When a SUS arrives from the PSTN, the MGC sends an INVITE to put
the media stream on hold. The reception of a RES triggers another
INVITE that resumes the media stream. For the SIP UAC/UAS the
result is an interruption in the voice path until the other party
picks up the phone again.
In SIP bridging situations, the SUS and RES messages can be
transferred in the body of the INVITE.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
The handling of a network-initiated SUS prior to call teardown is
handled in section 9.2.2.
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
Camarillo/Roach [Page 45]
Internet Draft BCP for SIP to ISUP Mapping March 2000
If the release of the connection was caused by the reception of a
REL, the REL is included in the BYE sent by the MGC.
9.2.1. Caller hangs up
For a normal release of the call (reception of REL from the
PSTN), the MGC first releases the resources in the MG and then
confirms that they are ready for re-use by sending an RLC. The
SIP connection is released by sending a BYE (which is confirmed
with a 200).
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
9.2.2. Callee hangs up
In analog PSTN, if the callee hangs up in the middle of a call,
the local exchange sends a SUS instead of a REL and starts a
timer (T6, SUS is network initiated). When the timer expires, the
REL is sent.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| | *** T6 Expires *** |
| |<-----------REL-----------|5
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|6
7|<----------BYE------------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
10. ISUP maintenance messages
ISUP contains a set of messages used for maintenance purposes.
They can be received during an ongoing call. There are basically
two kinds of maintenance messages (apart from the continuity
check): message for blocking circuits and messages for resetting
circuits.
10.1. Reset messages
Camarillo/Roach [Page 46]
Internet Draft BCP for SIP to ISUP Mapping March 2000
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."
11. Other ISUP flavours
Other flavours of ISUP different than Q.767 [2] have more
parameters and more features. Some of the parameters have more
possible values and provide more information about the status of
the call.
However, differences in the message flows are more important. In
ANSI ISUP [3] , there is no CON message. An ANM is sent instead
(with no ACM). In call forwarding situations, CPGs can be sent
before the ACM is sent. No SAMs are sent. `En bloc' signalling is
always used.
12. Acronyms
Camarillo/Roach [Page 47]
Internet Draft BCP for SIP to ISUP Mapping March 2000
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
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 Signalling Connection Control Part
SG Signalling Gateway
SIP Session Initiation Protocol
SS7 System Signalling No. 7
SUS Suspend Message
UAC User Agent Client
UAS User Agent Server
UDP User Data Protocol
VoIP Voice over IP
13. Acknowledgments
The authors would like to thank Olli Hynonen, Tomas Mecklin, Bill
Kavadas, and Miguel A. Garcia for their help and feedback on this
document.
14. References
[1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, IETF; March 1999.
Camarillo/Roach [Page 48]
Internet Draft BCP for SIP to ISUP Mapping March 2000
[2] "Application of the ISDN user part of CCITT signalling system
No. 7 for international ISDN interconnections" ITU-T Q.767
recommendation, February 1991.
[3] "Signalling System No. 7; ISDN User Part" T1.113-1995 ANSI.
January 1995.
[4] E Zimmerer/A. Vemuri/L. Ong/M. Zonoun/M. Watson, "MIME media
types for ISUP and QSIG Objects", Internet Draft
<draft-ietf-sip-isup-mime-00.txt>, IETF; January 2000. Work
in progress.
[5] N. Freed/ N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, IETF;
November 1996.
[6] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", Internet Draft
<draft-ietf-avt-tones-07.txt>, IETF; February 2000. Work in
progress.
[7] Jiri Kuthan, "Sample Uses of SIP INFO with Varying
Reliability Needs", Internet Draft
<draft-kuthan-sip-infopayload-00.txt>, IETF; October 1999.
Work in progress.
[8] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional
Responses in SIP", Internet Draft
<draft-ietf-sip-100rel-00.txt>, IETF; January 2000. Work in
progress.
[9] S. Donovan/M. Cannon/H. Schulzrinne/J. Rosenberg/A. Roach,
"SIP 183 Session Progress Message", Internet draft IETF
October 1999. Work in progress.
[10] Steven R. Donovan, "The SIP INFO Method", Internet Draft
<draft-ietf-sip-info-method-02.txt>, IETF; February 2000.
Work in progress.
[11] "Signalling System No. 7; ISDN User Part Signalling
procedures", ITU-T Q.764 recommendation, September 1997.
[12] Abnormal conditions - Special release ITU-T Q.118
recommendation, September 1997.
[13] "Specifications of Signalling System No. 7 - ISDN
supplementary services" ITU-T Q.737 recommendation, June
1997.
[14] "Specifications of Signalling System No. 7 - ISDN User Part
Camarillo/Roach [Page 49]
Internet Draft BCP for SIP to ISUP Mapping March 2000
Signalling Procedures" ITU-T Q.764 recommendation, March
1993.
15. Security Considerations
The transit of ISUP in SIP bodies may provide may opportunities
for abuse and fraud. In particular, SIP users may be able to
interpret "private" (i.e. caller-id-blocked) numbers by examining
the ISUP. Similarly, if care is not taken, SIP clients would be
able to send ISUP messages into the SS7 network with invalid
calling line identification and spoofed billing numbers.
For these reasons, it is absolutely necessary that any ISUP sent
through an IP network be strongly encrypted and authenticated.
The keys used for encryption should not be static, to prevent
replay attacks. A challenge-response model is recommended. As an
extra layer of security, it is recommended that ISUP be sent and
received only to and from nodes that are known to have an
established trust relationship with the gateway.
16. Authors' Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com
Adam Roach
Ericsson Inc.
Mailstop L-04
851 International Pkwy.
Richardson, TX 75081
USA
Phone: +1 972-583-7594
Fax: +1 972-669-0154
E-Mail: Adam.Roach@ericsson.com
Camarillo/Roach [Page 50]
| PAFTECH AB 2003-2026 | 2026-04-23 22:39:01 |