Internet Engineering Task Force Gonzalo Camarillo
Internet draft Ericsson
Category: Informational August 1999
Expires March 2000
Best Current Practice for ISUP to SIP mapping
<draft-camarillo-mmusic-sip-isup-bcp-00.txt>
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.
Abstract
This document describes a way to perform the mapping between two
signalling protocols: SIP and ISUP.
General comment
This is a very preliminary version of this draft. It intends to get
feedback and opinions about 'SIP to ISUP mapping' related issues.
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 control
functionality of ISUP. Maintenance 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 details such as
how the initialization is performed or which protocol 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],[8]. In
this case, the ISUP messages generated by the egress MGC are the
ones present in the SIP body.
+------+ +-------------+ +-----+ +------------+ +------+
| PSTN +---+ Ingress MGC +---+ SIP +---+ Egress MGC +---+ PSTN |
+------+ +-------------+ +-----+ +------------+ +------+
In both scenarios, the ingress MGC places the incoming ISUP messages
in the SIP body by default. 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.
Eventually there can be a Signalling Gateway (SG) between the PSTN
and the MGC. It encapsulates the ISUP messages over IP. The mapping
described in this document is not affected by its presence.
4. Require extensions
For a correct mapping between ISUP and SIP, some extensions to the
basic SIP specification are needed. They are defined in [5]. If the
SIP UAC/UAS involved in the call does not support them it is still
possible to proceed, but the behaviour in the establishment of the
call may be slightly different to the one expected by the user
(other party answers before receiving the ringback tone, user is not
informed about the call being forwarded, etc.).
5. Mapping
The mapping between ISUP and SIP is described using two state
machines. One handles calls from SIP to ISUP and the second from
ISUP to SIP. There are details, such as some retransmissions and
some states when the call is being disconnected (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.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 state machine
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.1 |
| V |
| T7/6.2 +-------------------------+ REL/6.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ |
| | 6.5 | 6.6 | 6.7 |
| V | | |
| T9/6.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| | | | |
| | CPG/ | | |
| | 6.9 | | |
| V V | |
| T9/6.10 +---------------+ | |
+<----------------+ Alerting | | |
| ++-------+------+ | |
| | ^ | | |
| CPG/ | | | ANM/ | |
| 6.11 +--+ | 6.12 | |
| V V |
| +-------------------------+ |
| | Waiting for ACK | |
| +-------------+-----------+ |
| | |
| | ACK/6.13 |
| V |
| BYE/8 +-------------------------+ REL/8 |
+<----------------+ Connected +------------>+
+-------------------------+
6.1 INVITE request received
When an INVITE request is received by the gateway, a "100 Trying"
response is sent back to the SIP network indicating that the MGC is
handling of 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. Before sending
the IAM the MG gets backward through connected.
An ISUP IAM is sent. 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
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 ISDN all the way
ISDN user part preference indicator: 00 ISDN preferred
ISDN access indicator: 1 ISDN access
SCCP method indicator: 0 no indication
Calling party's category: 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.
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.
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.
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 Timer 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. An ACK arrives acknowledging the reception of the response.
6.3 CANCEL request is received
If a CANCEL request is received, a '200 OK' is sent to the SIP
network. 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.
If instead of receiving a CANCEL, a BYE request arrives, after
answering properly to the BYE (200 OK) all the resources in the MGC
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.
This section (6.3) applies every time that a CANCEL or a BYE is
received before a final SIP response has been sent.
6.4 REL is received
The REL contains a cause value. The SIP response is sent based on
this cause value.
ISUP Cause value SIP response
Normal event
1 unallocated number 410 Gone
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
Resource unavailable
This kind of cause value indicates a non permanent situation. A
'Retry-After' header has to be added to the 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
55 incoming calls bared within CUG 603 Decline
57 bearer capability not authorized 501 Not implemented
58 bearer capability not presently 501 Not implemented
available
63 service/option not available 501 Not implemented
Service or option not implemented
65 bearer capability not implemented 501 Not implemented
79 service or option not implemented 501 Not implemented
Invalid message
87 user not member of CUG 603 decline
88 incompatible destination 400 Bad request
95 invalid message 400 Bad request
Protocol error
102 recovery of timer expiry 480 Request timeout
111 protocol error 400 Bad request
Interworking
127 interworking unspecified 500 Server internal error
If a different cause value was received the default response '500
Server internal error' would be used.
This section applies every time that a REL is received before a
final SIP response has been sent.
6.5 Early ACM is 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 [6] this is solved by connecting
the voice path backwards before sending the IAM.
6.6 ACM is received
The nearest local exchange to the caller generates the ringback tone
and may send voice announcements.
A '183 session progress message' [7] is sent to the SIP network.
Even if there are not in-band notifications or announcements it is
not correct to send a '180 Ringing' response, since the ringback
tone has to be generated by the PSTN exchange, and not by the SIP
UAC/UAS.
6.7 CON is received
A '200 OK' response is sent to the SIP network.
6.8 Timer T9 expires
Since an ANM has not arrived in time the call is aborted. All the
resources in the MG are released. A '408 request timeout' is sent to
the SIP network. A REL message with cause value 102 (recovery of
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.9 CPG with status 'alerting' is received
If a CPG message with Event Indicator 'Alerting' or 'in-band
information or an appropriate pattern is now available' is received
the same procedure as described in section 6.5 is followed.
6.10 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 102 (recovery of
timer expiry) 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.11 CPG is received
A CPG can indicate progress, alerting or in-band information. Since
there is already a one-way voice path open, there is no need of
taking further action.
6.12 ANM is received
The callee has picked up the phone. A '200 OK' response is sent to
the SIP network.
6.13 ACK is received
At this stage a two-way voice channel is established between the
caller and the callee. The call is connected and the conversation
can take place.
7. ISUP to SIP state machine
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | Address info complete/7.1 |
| V |
| +-------------------------+ |
+<----------------+ Trying | |
| +-+--------+------+-------+ |
| | | | |
| | 3xx/ | 1xx/ | 200/ |
| | 7.4 | 7.2 | 7.3 |
| V | | |
| +--------------+ | | |
| | Progressing | | | |
| +--+----+------+ | | |
| | | | | |
| | | 1xx/ | | |
| | | 7.2 | | |
| | V V | |
| | +---------------+ | |
| 200/ | | Alerting | | |
| 7.3 | +--------+------+ | |
| | | | |
| | | 200/ | |
| | | 7.3 | |
| V V V |
| BYE/8 +-----------------------------+ REL/8 |
+<------------+ Connected +------------>+
+-----------------------------+
7.1 Address received
Upon the reception of an IAM resources are reserved in the MG and it
gets backward through connected.
The B-party 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 B-party 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.
Therefore every individual MGC must be configured with a specific
timer. If an MGC never receives a SAM the value of the timer should
be zero. If the reception of a SAM is likely the value of the timer
should be sufficient for receiving them before the INVITE is sent
(after receiving the minimum amount of digits that can represent a
number, around 5 seconds).
Thus, after receiving the B-party number, the MGC issues an INVITE
request. If after sending this request a SAM is received the MGC
will CANCEL the INVITE and send a new INVITE to the complete
address. If a '484 Address Incomplete' is received the MGC should
wait for subsequent SAMs and send a new INVITE.
7.2 1xx received
Response received Message sent by the MGC
100 Trying Nothing
180 Ringing ACM
181 Call is being forwarded Early ACM
182 Queued ACM
183 Session progress message ACM
After the MGC receives of a '180 Ringing' response the MG generates
the ringback tone.
After the MGC receives a '183 Session progress message' response
the SIP network generates the ringback tone (or any announcement).
The ACM sent by the MGC after the reception of a '180' response or a
'183' response is the same. 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
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 ISDN 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
7.3 200 received
Response received Message sent by the MGC
200 OK ANM, ACK
After receiving a 200 OK response the MGC establishes a two-way
voice path in the MG and it sends an ANM to the PSTN and an ACK to
the SIP network.
If the '200 OK' response arrives before the MGC has sent the ACM, a
CON is sent instead of the ANM.
7.3 3xx received
3xx responses Message sent by the MGC
300 Multiple choices Early ACM
301 Moved permanently Early ACM
302 Moved temporarily Early ACM
305 Use proxy Early ACM
380 Alternative services Early ACM or REL
with cause 58
(if the service proposed is
not supported by the PSTN)
When any of these responses is received the MGC should try to
contact the user using the 'Contact' 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.
If a SIP provisional response is received after sending the Early
ACM, a CPG is sent (instead of an ACM).
7.4 4xx 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.
Response received Cause value in the REL
400 Bad request 127 interworking
401 Unauthorized 57 bearer capability not
authorized
402 Payment required 21 Call rejected
403 Forbidden 57 bearer capability not
authorized
404 Not found 1 Unallocated number
405 Method not allowed 127 Interworking
406 Not acceptable 127 Interworking
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 28 Address incomplete
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
7.5 5xx received
The MGC releases the resources in the MG, sends a REL to the PSTN
with a cause value and sends an ACK to the SIP network. An RLC
arrives indicating that the release sequence is complete.
Response received Cause value in the REL
500 Server internal error 41 Temporary failure
501 Not implemented 79 Service/option not
implemented
502 Bad gateway 38 Network out of order
503 Service unavailable 63 Service/option not
available
504 Gateway time-out 102 recovery on timer expiry
505 Version not supported 127 Interworking
7.6 6xx received
The MGC releases the resources in the MG, sends a REL to the PSTN
with a cause value and sends an ACK to the SIP network. An RLC
arrives indicating that the release sequence is complete.
Response received Cause value in the REL
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable 58 Bearer capability not
presently available
8. Release of the connection
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.
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.
When SUS and RES messages arrive from the PSTN the gateway will not
modify the status of the resources involved in the control of the
media stream. This way the signalling traffic in the network is
reduced (no messages are exchanged between MGC and MG). For the SIP
UAC/UAS the result is an interruption in the voice path until the
other party picks up the phone again.
For a normal release of the call (reception of REL from the PSTN or
BYE from the SIP network), the MGC first releases the resources in
the MG and then answers the message received (RLC to the PSTN or
'200 OK' to the SIP network). The connection on the other side is
then released by sending a REL for the PSTN or a BYE to the SIP
network. The REL sent by the MGC has a cause value of 16 (normal
call clearing).
9. 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, 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.
10. Acronyms
ACK Acknowledgment
ACM Address Complete Message
ANM Answer Message
ANSI American National Standards Institute
CON Connect Message
CPG Call Progress Message
CUG Closed User Group
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
11. References
[1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, IETF; Mach 1999.
[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, "The SIP ISUP/MIME type", Internet draft
IETF July 1999. Work in progress.
[5] A. Roach, "SIP PSTN Interworking Umbrella 'Require:' Header",
Internet draft IETF June 1999. Work in progress.
[6] "Signalling System No. 7; ISDN User Part Signalling
procedures", ITU-T Q.764 recommendation, September 1997.
[7] S. Donovan/M. Cannon/H. Schulzrinne/J. Rosenberg, "SIP 183
Session Progress Message", Internet draft IETF June 1999. Work in
progress.
[8] A. Roach, "ISUP parameters expected in SIP messages", Internet
draft IETF June 1999. Work in progress.
12. Acknowledgments
I would like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas and
Miguel A. Garcia for their help and feedback on this document.
13. Author's Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3118
Email: Gonzalo.Camarillo@ericsson.com