Internet Engineering Task Force Gonzalo Camarillo/Adam Roach Internet Draft Ericsson Category: Informational March 2000 Expires September 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 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 , 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 , IETF; February 2000. Work in progress. [7] Jiri Kuthan, "Sample Uses of SIP INFO with Varying Reliability Needs", Internet Draft , IETF; October 1999. Work in progress. [8] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional Responses in SIP", Internet Draft , 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 , 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]