Internet Engineering Task Force Gonzalo Camarillo Internet draft Ericsson Category: Informational August 1999 Expires March 2000 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 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