RFC3398 日本語訳
3398 Integrated Services Digital Network (ISDN) User Part (ISUP) toSession Initiation Protocol (SIP) Mapping. G. Camarillo, A. B. Roach,J. Peterson, L. Ong. December 2002. (Format: TXT=166197 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo
Request for Comments: 3398 Ericsson
Category: Standards Track A. B. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
December 2002
Network Working Group G. Camarillo Request for Comments: 3398 Ericsson Category: Standards Track A. B. Roach dynamicsoft J. Peterson NeuStar L. Ong Ciena December 2002
Integrated Services Digital Network (ISDN) User Part (ISUP)
to Session Initiation Protocol (SIP) Mapping
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Abstract
This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
Table of Contents
Table of Contents
1. Introduction............................................ 3 2. Scope................................................... 4 3. Terminology............................................. 5 4. Scenarios............................................... 5 5. SIP Mechanisms Required................................. 7 5.1 'Transparent' Transit of ISUP Messages.................. 7 5.2 Understanding MIME Multipart Bodies..................... 7 5.3 Transmission of DTMF Information........................ 8 5.4 Reliable Transmission of Provisional Responses.......... 8 5.5 Early Media............................................. 8 5.6 Mid-Call Transactions which do not change SIP state..... 9
1. Introduction............................................ 3 2. Scope................................................... 4 3. Terminology............................................. 5 4. Scenarios............................................... 5 5. SIP Mechanisms Required................................. 7 5.1 'Transparent' Transit of ISUP Messages.................. 7 5.2 Understanding MIME Multipart Bodies..................... 7 5.3 Transmission of DTMF Information........................ 8 5.4 Reliable Transmission of Provisional Responses.......... 8 5.5 Early Media............................................. 8 5.6 Mid-Call Transactions which do not change SIP state..... 9
Camarillo, et. al. Standards Track [Page 1] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 1] RFC 3398 ISUP to SIP Mapping December 2002
5.7 Privacy Protection...................................... 9 5.8 CANCEL causes........................................... 10 6. Mapping................................................. 10 7. SIP to ISUP Mapping..................................... 11 7.1 SIP to ISUP Call flows.................................. 11 7.1.1 En-bloc Call Setup (no auto-answer)..................... 11 7.1.2 Auto-answer call setup.................................. 12 7.1.3 ISUP T7 Expires......................................... 13 7.1.4 SIP Timeout............................................. 14 7.1.5 ISUP Setup Failure...................................... 15 7.1.6 Cause Present in ACM Message............................ 16 7.1.7 Call Canceled by SIP.................................... 17 7.2 State Machine........................................... 18 7.2.1 INVITE received......................................... 19 7.2.1.1 INVITE to IAM procedures................................ 19 7.2.2 ISUP T7 expires......................................... 23 7.2.3 CANCEL or BYE received.................................. 23 7.2.4 REL received............................................ 24 7.2.4.1 ISDN Cause Code to Status Code Mapping.................. 24 7.2.5 Early ACM received...................................... 27 7.2.6 ACM received............................................ 27 7.2.7 CON or ANM Received..................................... 28 7.2.8 Timer T9 Expires........................................ 29 7.2.9 CPG Received............................................ 29 7.3 ACK received............................................ 30 8. ISUP to SIP Mapping..................................... 30 8.1 ISUP to SIP Call Flows.................................. 30 8.1.1 En-bloc call setup (non auto-answer).................... 31 8.1.2 Auto-answer call setup.................................. 32 8.1.3 SIP Timeout............................................. 33 8.1.4 ISUP T9 Expires......................................... 34 8.1.5 SIP Error Response...................................... 35 8.1.6 SIP Redirection......................................... 36 8.1.7 Call Canceled by ISUP................................... 37 8.2 State Machine........................................... 39 8.2.1 Initial Address Message received........................ 39 8.2.1.1 IAM to INVITE procedures................................ 40 8.2.2 100 received............................................ 41 8.2.3 18x received............................................ 41 8.2.4 2xx received............................................ 43 8.2.5 3xx Received............................................ 44 8.2.6 4xx-6xx Received........................................ 44 8.2.6.1 SIP Status Code to ISDN Cause Code Mapping.............. 45 8.2.7 REL Received............................................ 47 8.2.8 ISUP T11 Expires........................................ 47 9. Suspend/Resume and Hold................................. 48 9.1 SUS and RES............................................. 48 9.2 Hold (re-INVITE)........................................ 50
5.7 Privacy Protection...................................... 9 5.8 CANCEL causes........................................... 10 6. Mapping................................................. 10 7. SIP to ISUP Mapping..................................... 11 7.1 SIP to ISUP Call flows.................................. 11 7.1.1 En-bloc Call Setup (no auto-answer)..................... 11 7.1.2 Auto-answer call setup.................................. 12 7.1.3 ISUP T7 Expires......................................... 13 7.1.4 SIP Timeout............................................. 14 7.1.5 ISUP Setup Failure...................................... 15 7.1.6 Cause Present in ACM Message............................ 16 7.1.7 Call Canceled by SIP.................................... 17 7.2 State Machine........................................... 18 7.2.1 INVITE received......................................... 19 7.2.1.1 INVITE to IAM procedures................................ 19 7.2.2 ISUP T7 expires......................................... 23 7.2.3 CANCEL or BYE received.................................. 23 7.2.4 REL received............................................ 24 7.2.4.1 ISDN Cause Code to Status Code Mapping.................. 24 7.2.5 Early ACM received...................................... 27 7.2.6 ACM received............................................ 27 7.2.7 CON or ANM Received..................................... 28 7.2.8 Timer T9 Expires........................................ 29 7.2.9 CPG Received............................................ 29 7.3 ACK received............................................ 30 8. ISUP to SIP Mapping..................................... 30 8.1 ISUP to SIP Call Flows.................................. 30 8.1.1 En-bloc call setup (non auto-answer).................... 31 8.1.2 Auto-answer call setup.................................. 32 8.1.3 SIP Timeout............................................. 33 8.1.4 ISUP T9 Expires......................................... 34 8.1.5 SIP Error Response...................................... 35 8.1.6 SIP Redirection......................................... 36 8.1.7 Call Canceled by ISUP................................... 37 8.2 State Machine........................................... 39 8.2.1 Initial Address Message received........................ 39 8.2.1.1 IAM to INVITE procedures................................ 40 8.2.2 100 received............................................ 41 8.2.3 18x received............................................ 41 8.2.4 2xx received............................................ 43 8.2.5 3xx Received............................................ 44 8.2.6 4xx-6xx Received........................................ 44 8.2.6.1 SIP Status Code to ISDN Cause Code Mapping.............. 45 8.2.7 REL Received............................................ 47 8.2.8 ISUP T11 Expires........................................ 47 9. Suspend/Resume and Hold................................. 48 9.1 SUS and RES............................................. 48 9.2 Hold (re-INVITE)........................................ 50
Camarillo, et. al. Standards Track [Page 2] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 2] RFC 3398 ISUP to SIP Mapping December 2002
10. Normal Release of the Connection........................ 50
10.1 SIP initiated release................................... 50
10.2 ISUP initiated release.................................. 51
10.2.1 Caller hangs up......................................... 51
10.2.2 Callee hangs up (SUS)................................... 52
11. ISUP Maintenance Messages............................... 52
11.1 Reset messages.......................................... 52
11.2 Blocking messages....................................... 53
11.3 Continuity Checks....................................... 53
12. Construction of Telephony URIs.......................... 54
12.1 ISUP format to tel URL mapping.......................... 56
12.2 tel URL to ISUP format mapping.......................... 57
13. Other ISUP flavors...................................... 58
13.1 Guidelines for sending other ISUP messages.............. 58
14. Acronyms................................................ 60
15. Security Considerations................................. 60
16. IANA Considerations..................................... 64
17. Acknowledgments......................................... 64
18. Normative References.................................... 64
19. Non-Normative References................................ 65
Authors' Addresses...................................... 67
Full Copyright Statement................................ 68
10. Normal Release of the Connection........................ 50 10.1 SIP initiated release................................... 50 10.2 ISUP initiated release.................................. 51 10.2.1 Caller hangs up......................................... 51 10.2.2 Callee hangs up (SUS)................................... 52 11. ISUP Maintenance Messages............................... 52 11.1 Reset messages.......................................... 52 11.2 Blocking messages....................................... 53 11.3 Continuity Checks....................................... 53 12. Construction of Telephony URIs.......................... 54 12.1 ISUP format to tel URL mapping.......................... 56 12.2 tel URL to ISUP format mapping.......................... 57 13. Other ISUP flavors...................................... 58 13.1 Guidelines for sending other ISUP messages.............. 58 14. Acronyms................................................ 60 15. Security Considerations................................. 60 16. IANA Considerations..................................... 64 17. Acknowledgments......................................... 64 18. Normative References.................................... 64 19. Non-Normative References................................ 65 Authors' Addresses...................................... 67 Full Copyright Statement................................ 68
1. Introduction
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.
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.
Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a level 4 protocol used in Signaling System No. 7 (SS7) networks. It typically runs over Message Transfer Part (MTP) although it can also run over IP (see SCTP [19]). ISUP is used for controlling telephone calls and for maintenance of the network (blocking circuits, resetting circuits etc.).
Integrated Services Digital Network (ISDN) User Part (ISUP) [12] is a level 4 protocol used in Signaling System No. 7 (SS7) networks. It typically runs over Message Transfer Part (MTP) although it can also run over IP (see SCTP [19]). ISUP is used for controlling telephone calls and for maintenance of the network (blocking circuits, resetting circuits etc.).
A module performing the mapping between these two protocols is usually referred to as Media Gateway Controller (MGC), although the terms 'softswitch' or 'call agent' are also sometimes used. An MGC has logical interfaces facing both networks, the network carrying ISUP and the network carrying SIP. The MGC also has some capabilities for controlling the voice path; there is typically a Media Gateway (MG) with E1/T1 trunking interfaces (voice from Public Switched Telephone Network - PSTN) and with IP interfaces (Voice over IP - VoIP). The MGC and the MG can be merged together in one physical box or kept separate.
A module performing the mapping between these two protocols is usually referred to as Media Gateway Controller (MGC), although the terms 'softswitch' or 'call agent' are also sometimes used. An MGC has logical interfaces facing both networks, the network carrying ISUP and the network carrying SIP. The MGC also has some capabilities for controlling the voice path; there is typically a Media Gateway (MG) with E1/T1 trunking interfaces (voice from Public Switched Telephone Network - PSTN) and with IP interfaces (Voice over IP - VoIP). The MGC and the MG can be merged together in one physical box or kept separate.
Camarillo, et. al. Standards Track [Page 3] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 3] RFC 3398 ISUP to SIP Mapping December 2002
These MGCs are frequently used to bridge SIP and ISUP networks so that calls originating in the PSTN can reach IP telephone endpoints and vice versa. This is useful for cases in which PSTN calls need to take advantage of services in IP world, in which IP networks are used as transit networks for PSTN-PSTN calls, architectures in which calls originate on desktop 'softphones' but terminate at PSTN terminals, and many other similar next-generation telephone architectures.
These MGCs are frequently used to bridge SIP and ISUP networks so that calls originating in the PSTN can reach IP telephone endpoints and vice versa. This is useful for cases in which PSTN calls need to take advantage of services in IP world, in which IP networks are used as transit networks for PSTN-PSTN calls, architectures in which calls originate on desktop 'softphones' but terminate at PSTN terminals, and many other similar next-generation telephone architectures.
This document describes logic and procedures which an MGC might use to implement the mapping between SIP and ISUP by illustrating the correspondences, at the message level and parameter level, between the protocols. It also describes the interplay between parallel state machines for these two protocols as a recommendation for implementers to synchronize protocol events in interworking architectures.
This document describes logic and procedures which an MGC might use to implement the mapping between SIP and ISUP by illustrating the correspondences, at the message level and parameter level, between the protocols. It also describes the interplay between parallel state machines for these two protocols as a recommendation for implementers to synchronize protocol events in interworking architectures.
2. Scope
2. Scope
This document focuses on the translation of ISUP messages into SIP messages, and the mapping of ISUP parameters into SIP headers. For ISUP calls that traverse a SIP network, the purpose of translation is to allow SIP elements such as proxy servers (which do not typically understand ISUP) to make routing decisions based on ISUP criteria such as the called party number. This document consequently provides a SIP mapping only for those ISUP parameters which might be used by intermediaries in the routing of SIP requests. As a side effect of this approach, translation also increases the overall interoperability by providing critical information about the call to SIP endpoints that cannot understand encapsulated ISUP, or perhaps which merely cannot understand the particular ISUP variant encapsulated in a message.
This document focuses on the translation of ISUP messages into SIP messages, and the mapping of ISUP parameters into SIP headers. For ISUP calls that traverse a SIP network, the purpose of translation is to allow SIP elements such as proxy servers (which do not typically understand ISUP) to make routing decisions based on ISUP criteria such as the called party number. This document consequently provides a SIP mapping only for those ISUP parameters which might be used by intermediaries in the routing of SIP requests. As a side effect of this approach, translation also increases the overall interoperability by providing critical information about the call to SIP endpoints that cannot understand encapsulated ISUP, or perhaps which merely cannot understand the particular ISUP variant encapsulated in a message.
This document also only takes into account the call functionality of ISUP. Maintenance messages dealing with PSTN trunks are treated only as far as they affect the control of an ongoing call; otherwise these messages neither have nor require any analog in SIP.
This document also only takes into account the call functionality of ISUP. Maintenance messages dealing with PSTN trunks are treated only as far as they affect the control of an ongoing call; otherwise these messages neither have nor require any analog in SIP.
Messages indicating error or congestion situations in the PSTN (MTP- 3) and the recovery mechanisms used such as User Part Available and User Part Test ISUP messages are outside the scope of this document
Messages indicating error or congestion situations in the PSTN (MTP- 3) and the recovery mechanisms used such as User Part Available and User Part Test ISUP messages are outside the scope of this document
There are several flavors of ISUP. International Telecommunication Union Telecommunication Standardization Sector (ITU-T) International ISUP [12] is used through this document; some differences with the American National Standards Institute (ANSI) [11] ISUP and the Telecommunication Technology Committee (TTC) ISUP are also outlined. ITU-T ISUP is used in this document because it is the most widely known of all the ISUP flavors. Due to the small number of fields
There are several flavors of ISUP. International Telecommunication Union Telecommunication Standardization Sector (ITU-T) International ISUP [12] is used through this document; some differences with the American National Standards Institute (ANSI) [11] ISUP and the Telecommunication Technology Committee (TTC) ISUP are also outlined. ITU-T ISUP is used in this document because it is the most widely known of all the ISUP flavors. Due to the small number of fields
Camarillo, et. al. Standards Track [Page 4] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 4] RFC 3398 ISUP to SIP Mapping December 2002
that map directly from ISUP to SIP, the signaling differences between ITU-T ISUP and specific national variants of ISUP will generally have little to no impact on the mapping. Note, however, that the ITU-T has not substantially standardized practices for Local Number Portability (LNP) since portability tends to be grounded in national numbering plan practices, and that consequently LNP must be described on a virtually per-nation basis. The number portability practices described in this document are presented as an optional mechanism.
that map directly from ISUP to SIP, the signaling differences between ITU-T ISUP and specific national variants of ISUP will generally have little to no impact on the mapping. Note, however, that the ITU-T has not substantially standardized practices for Local Number Portability (LNP) since portability tends to be grounded in national numbering plan practices, and that consequently LNP must be described on a virtually per-nation basis. The number portability practices described in this document are presented as an optional mechanism.
Mapping of SIP headers to ISUP parameters in this document focuses largely on the mapping between the parameters found in the ISUP Initial Address Message (IAM) and the headers associated with the SIP INVITE message; both of these messages are used in their respective protocols to request the establishment of a call. Once an INVITE has been sent for a particular session, such headers as the To and From field become essentially fixed, and no further translation will be required during subsequent signaling, which is routed in accordance with Via and Route headers. Hence, the problem of parameter-to- header mapping in SIP-T is confined more or less to the IAM and the INVITE. Some additional detail is given in the population of parameters in the ISUP messages Address Complete Message (ACM) and Release Message (REL) based on SIP status codes.
Mapping of SIP headers to ISUP parameters in this document focuses largely on the mapping between the parameters found in the ISUP Initial Address Message (IAM) and the headers associated with the SIP INVITE message; both of these messages are used in their respective protocols to request the establishment of a call. Once an INVITE has been sent for a particular session, such headers as the To and From field become essentially fixed, and no further translation will be required during subsequent signaling, which is routed in accordance with Via and Route headers. Hence, the problem of parameter-to- header mapping in SIP-T is confined more or less to the IAM and the INVITE. Some additional detail is given in the population of parameters in the ISUP messages Address Complete Message (ACM) and Release Message (REL) based on SIP status codes.
This document describes when the media path associated with a SIP call is to be initialized, terminated, modified, etc., but it does not go into details such as how the initialization is performed or which protocols are used for that purpose.
This document describes when the media path associated with a SIP call is to be initialized, terminated, modified, etc., but it does not go into details such as how the initialization is performed or which protocols are used for that purpose.
3. Terminology
3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and indicate requirement levels for compliant SIP implementations.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and indicate requirement levels for compliant SIP implementations.
4. Scenarios
4. Scenarios
There are several scenarios where ISUP-SIP mapping takes place. The way the messages are generated is different depending on the scenario.
There are several scenarios where ISUP-SIP mapping takes place. The way the messages are generated is different depending on the scenario.
Camarillo, et. al. Standards Track [Page 5] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 5] RFC 3398 ISUP to SIP Mapping December 2002
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.
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 | +-------------+ +-----+ +-------------+
+-------------+ +-----+ +-------------+ | PSTN switch +-------+ MGC +-------+ SIP UAC/UAS | +-------------+ +-----+ +-------------+
The scenario where a call originates in the PSTN, goes into a SIP network and terminates in the PSTN again is known as "SIP bridging". SIP bridging should provide ISUP transparency between the PSTN switches handling the call. This is achieved by encapsulating the incoming ISUP messages in the body of the SIP messages (see [3]). 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 Uniform Resource Identifier - URI - is different from the one present in the ISUP due to SIP redirection, the ISUP message will need to be adjusted).
The scenario where a call originates in the PSTN, goes into a SIP network and terminates in the PSTN again is known as "SIP bridging". SIP bridging should provide ISUP transparency between the PSTN switches handling the call. This is achieved by encapsulating the incoming ISUP messages in the body of the SIP messages (see [3]). 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 Uniform Resource Identifier - 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 | +------+ +-------------+ +-----+ +------------+ +------+
+------+ +-------------+ +-----+ +------------+ +------+ | 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.
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 User Agent Client/User Agent Server - 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.
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 User Agent Client/User Agent Server - UAC/UAS) does not understand them, a negotiation using the SIP 'Accept' and 'Require' headers will take place and they will not be included in the next SIP message exchange.
There can be a Signaling Gateway (SG) between the PSTN and the MGC. It encapsulates the ISUP messages over IP in a manner such as the one described in [19]. The mapping described in this document is not affected by the underlying transport protocol of ISUP.
There can be a Signaling Gateway (SG) between the PSTN and the MGC. It encapsulates the ISUP messages over IP in a manner such as the one described in [19]. The mapping described in this document is not affected by the underlying transport protocol of ISUP.
Note that overlap dialing mechanisms (use of the Subsequent Address Message - SAM) are outside the scope of this document. This document assumes that gateways facing ISUP networks in which overlap dialing is used will implement timers to insure that all digits have been collected before an INVITE is transmitted to a SIP network.
Note that overlap dialing mechanisms (use of the Subsequent Address Message - SAM) are outside the scope of this document. This document assumes that gateways facing ISUP networks in which overlap dialing is used will implement timers to insure that all digits have been collected before an INVITE is transmitted to a SIP network.
Camarillo, et. al. Standards Track [Page 6] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 6] RFC 3398 ISUP to SIP Mapping December 2002
In some instances, gateways may receive incomplete ISUP messages which indicate message segmentation due to excessive message length. Commonly these messages will be followed by a Segmentation Message (SGM) containing the remainder of the original ISUP message. An incomplete message may not contain sufficient parameters to allow for a proper mapping to SIP; similarly, encapsulating (see below) an incomplete ISUP message may be confusing to terminating gateways. Consequently, a gateway MUST wait until a complete ISUP message is received (which may involve waiting until one or more SGMs arrive) before sending any corresponding INVITE.
In some instances, gateways may receive incomplete ISUP messages which indicate message segmentation due to excessive message length. Commonly these messages will be followed by a Segmentation Message (SGM) containing the remainder of the original ISUP message. An incomplete message may not contain sufficient parameters to allow for a proper mapping to SIP; similarly, encapsulating (see below) an incomplete ISUP message may be confusing to terminating gateways. Consequently, a gateway MUST wait until a complete ISUP message is received (which may involve waiting until one or more SGMs arrive) before sending any corresponding INVITE.
5. SIP Mechanisms Required
5. SIP Mechanisms Required
For a correct mapping between ISUP and SIP, some SIP mechanisms above and beyond those available in the base SIP specification are needed. These mechanisms are discussed below. If the SIP UAC/UAS involved in the call does not support them, it is still possible to proceed, but the behavior in the establishment of the call may be slightly different than that expected by the user (e.g., other party answers before receiving the ringback tone, user is not informed about the call being forwarded, etc.).
For a correct mapping between ISUP and SIP, some SIP mechanisms above and beyond those available in the base SIP specification are needed. These mechanisms are discussed below. If the SIP UAC/UAS involved in the call does not support them, it is still possible to proceed, but the behavior in the establishment of the call may be slightly different than that expected by the user (e.g., other party answers before receiving the ringback tone, user is not informed about the call being forwarded, etc.).
5.1 'Transparent' Transit of ISUP Messages
5.1 'Transparent' Transit of ISUP Messages
To allow gateways 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 MUST be capable of transporting ISUP payloads from gateway to gateway. The format for encapsulating these ISUP messages is defined in [3].
To allow gateways 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 MUST be capable of transporting ISUP payloads from gateway to gateway. The format for encapsulating these ISUP messages is defined in [3].
SIP user agents which do not understand ISUP are permitted to ignore these optional MIME bodies.
SIP user agents which do not understand ISUP are permitted to ignore these optional MIME bodies.
5.2 Understanding MIME Multipart Bodies
5.2 Understanding MIME Multipart Bodies
In most PSTN interworking situations, SIP message bodies will be required to carry session information (Session Description Protocol - SDP) in addition to ISUP and/or billing information.
In most PSTN interworking situations, SIP message bodies will be required to carry session information (Session Description Protocol - SDP) in addition to ISUP and/or billing information.
PSTN interworking nodes MUST understand the MIME type of "multipart/mixed" as defined in RFC2046 [4]. Clients express support for this by including "multipart/mixed" in an "Accept" header.
PSTN interworking nodes MUST understand the MIME type of "multipart/mixed" as defined in RFC2046 [4]. Clients express support for this by including "multipart/mixed" in an "Accept" header.
Camarillo, et. al. Standards Track [Page 7] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 7] RFC 3398 ISUP to SIP Mapping December 2002
5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information
5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information
How DTMF tones played by the user are transmitted by a gateway is completely orthogonal to how SIP and ISUP are interworked; however, as DTMF carriage is a component of a complete gatewaying solution some guidance is offered here.
How DTMF tones played by the user are transmitted by a gateway is completely orthogonal to how SIP and ISUP are interworked; however, as DTMF carriage is a component of a complete gatewaying solution some guidance is offered here.
Since the codec selected for voice transmission may not be ideally suited for carrying DTMF information, a symbolic method of transmitting this information in-band is desirable (since out-of-band transmission alone would provide many challenges for synchronization of the media stream for tone re-insertion). This transmission MAY be performed as described in RFC2833 [5].
Since the codec selected for voice transmission may not be ideally suited for carrying DTMF information, a symbolic method of transmitting this information in-band is desirable (since out-of-band transmission alone would provide many challenges for synchronization of the media stream for tone re-insertion). This transmission MAY be performed as described in RFC2833 [5].
5.4 Reliable Transmission of Provisional Responses
5.4 Reliable Transmission of Provisional Responses
Provisional responses (in the 1xx class) are used in the transmission of call progress information. PSTN interworking in particular relies on these messages for control of the media channel and timing of call events.
Provisional responses (in the 1xx class) are used in the transmission of call progress information. PSTN interworking in particular relies on these messages for control of the media channel and timing of call events.
When interworking with the PSTN, SIP messages MUST be sent reliably end-to-end; reliability of requests is guaranteed by the base protocol. One application-layer provisional reliability mechanism for responses is described in [18].
When interworking with the PSTN, SIP messages MUST be sent reliably end-to-end; reliability of requests is guaranteed by the base protocol. One application-layer provisional reliability mechanism for responses is described in [18].
5.5 Early Media
5.5 Early Media
Early media denotes the capability to play media (audio for telephony) before a SIP session has been established (before a 2xx response code has been sent). For telephony, establishment of media in the backwards direction is desirable so that tones and announcements can be played, especially when interworking with a network that cannot signal call status out of band (such as a legacy MF network). In cases where interworking has not been encountered, use of early media is almost always undesirable since it consumes inter-machine trunk recourses to play media for which no revenue is collected. Note that since an INVITE almost always contains the SDP required to send media in the backwards direction, and requires that user agents prepare themselves to receive backwards media as soon as an INVITE transmitted, the baseline SIP protocol has enough support to enable rudimentary unidirectional early media systems. However, this mechanism has a number of limitations - for example, media streams offered in the SDP of the INVITE cannot be modified or declined, and bidirectional RTCP required for session maintenance cannot be established.
Early media denotes the capability to play media (audio for telephony) before a SIP session has been established (before a 2xx response code has been sent). For telephony, establishment of media in the backwards direction is desirable so that tones and announcements can be played, especially when interworking with a network that cannot signal call status out of band (such as a legacy MF network). In cases where interworking has not been encountered, use of early media is almost always undesirable since it consumes inter-machine trunk recourses to play media for which no revenue is collected. Note that since an INVITE almost always contains the SDP required to send media in the backwards direction, and requires that user agents prepare themselves to receive backwards media as soon as an INVITE transmitted, the baseline SIP protocol has enough support to enable rudimentary unidirectional early media systems. However, this mechanism has a number of limitations - for example, media streams offered in the SDP of the INVITE cannot be modified or declined, and bidirectional RTCP required for session maintenance cannot be established.
Camarillo, et. al. Standards Track [Page 8] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 8] RFC 3398 ISUP to SIP Mapping December 2002
Therefore gateways MAY support more sophisticated early media systems as they come to be better understood. One mechanism that provides a way of initiating a fully-featured early media system is described in [20].
Therefore gateways MAY support more sophisticated early media systems as they come to be better understood. One mechanism that provides a way of initiating a fully-featured early media system is described in [20].
Note that in SIP networks not just switches but also user agents can generate the 18x response codes and initiate early backwards media, and that therefore some gateways may wish to enforce policies that restrict the use of backwards media from arbitrary user agents (see Section 15).
Note that in SIP networks not just switches but also user agents can generate the 18x response codes and initiate early backwards media, and that therefore some gateways may wish to enforce policies that restrict the use of backwards media from arbitrary user agents (see Section 15).
5.6 Mid-Call Transactions which do not change SIP state
5.6 Mid-Call Transactions which do not change SIP state
When interworking with the PSTN, there are situations when gateways will need to send messages to each other over SIP that do not correspond to any SIP operations.
When interworking with the PSTN, there are situations when gateways will need to send messages to each other over SIP that do not correspond to any SIP operations.
In support of mid-call transactions and other ISUP events that do not correspond to existing SIP methods, SIP gateways MUST support the INFO method, defined in RFC2976 [6]. Note that this document does not prescribe or endorse the use of INFO to carry DTMF digits.
In support of mid-call transactions and other ISUP events that do not correspond to existing SIP methods, SIP gateways MUST support the INFO method, defined in RFC2976 [6]. Note that this document does not prescribe or endorse the use of INFO to carry DTMF digits.
Gateways MUST accept "405 Method Not Allowed" and "501 Not Implemented" as non-fatal responses to INFO requests - that is, any call in progress MUST NOT be torn down if a destination so rejects an INFO request sent by a gateway.
Gateways MUST accept "405 Method Not Allowed" and "501 Not Implemented" as non-fatal responses to INFO requests - that is, any call in progress MUST NOT be torn down if a destination so rejects an INFO request sent by a gateway.
5.7 Privacy Protection
5.7 Privacy Protection
ISUP has a concept of presentation restriction - a mechanism by which a user can specify that they would not like their telephone number to be displayed to the person they are calling (presumably someone with Caller ID). When a gateway receives an ISUP request that requires presentation restriction, it must therefore shield the identity of the caller in some fashion.
ISUP has a concept of presentation restriction - a mechanism by which a user can specify that they would not like their telephone number to be displayed to the person they are calling (presumably someone with Caller ID). When a gateway receives an ISUP request that requires presentation restriction, it must therefore shield the identity of the caller in some fashion.
The base SIP protocol supports a method of specifying that a user is anonymous. However, this system has a number of limitations - for example, it reveals the identity of the gateway itself, which could be a privacy-impacting disclosure. Therefore gateways MAY support more sophisticated privacy systems. One mechanism that provides a way of supporting fully-featured privacy negotiation (which interacts well with identity management systems) is described in [9B].
The base SIP protocol supports a method of specifying that a user is anonymous. However, this system has a number of limitations - for example, it reveals the identity of the gateway itself, which could be a privacy-impacting disclosure. Therefore gateways MAY support more sophisticated privacy systems. One mechanism that provides a way of supporting fully-featured privacy negotiation (which interacts well with identity management systems) is described in [9B].
Camarillo, et. al. Standards Track [Page 9] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 9] RFC 3398 ISUP to SIP Mapping December 2002
5.8 CANCEL causes
5.8 CANCEL causes
There is a way in ISUP to signal that you would like to discontinue an attempt to set up a call - the general-purpose REL is sent in the forwards direction. There is a similar concept in SIP - that of a CANCEL request that is sent in order to discontinue the establishment of a SIP dialog. For various reasons, however, CANCEL requests cannot contain message bodies, and therefore in order to carry the important information in the REL (the cause code) end-to-end in sip bridging cases, ISUP encapsulation cannot be used.
あなたは呼び出しをセットアップする試みを中止したがっています--汎用のRELがフォワードで送られると合図する入口ISUP指示があります。 同様の概念がSIP(それがSIP対話の確立を中止するために送られるようキャンセルを要求する)にあります。 しかしながら、様々な理由で、キャンセル要求はメッセージ本体を含むことができません、そして、したがって、ケースに橋を架けながら一口へのREL(原因コード)の終わりからエンドで重要情報を運ぶために、ISUPカプセル化は使用できません。
Ordinarily, this is not a big problem, because for practical purposes the only reason that a REL is ever issued to cancel a call setup attempt is that a user hangs up the phone while it is still ringing (which results in a "Normal clearing" cause code). However, under exceptional conditions, like catastrophic network failure, a REL may be sent with a different cause code, and it would be handy if a SIP network could carry the cause code end-to-end. Therefore gateways MAY support a mechanism for end-to-end delivery of such failure reasons. One mechanism that provides this capability is described in [9].
通常、これは重要な問題ではありません、RELが今までに呼び出しセットアップ試みを中止するために発行される唯一の理由が実用的な目的のためのまだ(「通常の開拓地」原因コードのどの結果)を鳴らしているか間ユーザが受話器をかけるということであるので。 しかしながら、壊滅的なネットワーク失敗のように、例外的な条件のもとで、異なった原因コードと共にRELを送るかもしれません、そして、SIPネットワークが原因のコードの終わりから終わりを運ぶことができるなら、便利でしょうに。 したがって、ゲートウェイはそのような失敗理由の終わりから終わりへの配送のためにメカニズムをサポートするかもしれません。 この能力を提供する1つのメカニズムが[9]で説明されます。
6. Mapping
6. マッピング
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 the Release Complete Message - RLC, waiting for SIP ACK etc.), that are not shown in the figures in order to make them easier to follow.
ISUPとSIPの間のマッピングは、呼び出しフローチャートと州のマシンを使用することで説明されます。 1台の州のマシンがSIPからISUPまでの呼び出しとISUPからSIPまでの2番目を扱います。 彼らに続くのをより簡単にするように数字に示されないいくつかの「再-トランスミッション」やいくつかの州などの細部(Release Complete Messageの待ち--SIP ACKなどを待つRLC)があります。
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 / 7.2.1' indicates that an INVITE request has been received by the gateway, and the procedure upon reception is described in the section 7.2.1 of this document.
例えば、'INVITE / 7.2.1'はゲートウェイでINVITE要求を受け取って、この.1通のセクション7.2ドキュメントでレセプションの手順について説明するのを示します。
It is RECOMMENDED that gateways implement functional equivalence with the call flows detailed in Section 7.1 and Section 8.1. Deviations from these flows are permissible in support of national ISUP variants, or any of the conservative policies recommended in Section 15.
ゲートウェイがセクション7.1とセクション8.1で詳細な呼び出し流れに伴う機能的な等価性を実行するのは、RECOMMENDEDです。 これらの流れからの逸脱は国家のISUP異形、またはセクション15のお勧めの保守政策のどれかを支持して許されています。
Camarillo, et. al. Standards Track [Page 10] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[10ページ]。
7. SIP to ISUP Mapping
7. ISUPマッピングへの一口
7.1 SIP to ISUP Call flows
7.1 ISUP CallへのSIPは流れます。
The following call flows illustrate the order of messages in typical success and error cases when setting up a call initiated from the SIP network. "100 Trying" acknowledgements to INVITE requests are not displayed below although they are required in many architectures.
SIPネットワークから開始された呼び出しをセットアップするとき、以下の呼び出し流れは典型的な成功と誤り事件における、メッセージの注文を例証します。 「100 」 承認をINVITEに試みて、それらが多くの構造で必要ですが、要求は以下に表示されません。
In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC; media handling (e.g., audio cut-through, trunk freeing) is being performed by the MG, under the control of the MGC. For the purpose of simplicity, these are shown as a single node, labeled "MGC/MG."
これらのダイヤグラムで、すべての呼び出しシグナリング(SIP、ISUP)がMGCとMGCから行くでしょう。 メディア取り扱い(例えば、深く切られたオーディオ、トランク解放)はMGCのコントロールの下でMGによって実行されています。 簡単さの目的のために、これらは「MGC/mg」に分類されたただ一つのノードとして示されます。
7.1.1 En-bloc Call Setup (no auto-answer)
7.1.1 アン団体呼び出しセットアップ(自動応答がありません)
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
一口MGC/mg PSTN1|---------招待---------->|、| | <、-、-、-、-、-、-、-、-、--100------------| | | |------------IAM---------->|2 | |<=====オーディオ===========| | | <、-、-、-、-、-、-、-、-、-、--ACM-----------|3 4| <、-、-、-、-、-、-、-、-、--18x------------| | |<=====オーディオ===========| | | | <、-、-、-、-、-、-、-、-、-、--CPG-----------|5 6| <、-、-、-、-、-、-、-、-、--18x------------| | | | <、-、-、-、-、-、-、-、-、-、--ANM-----------|7 | |<=====オーディオ==========>| 8| <、-、-、-、-、-、-、-、-、--200------------| | |<=====オーディオ==========>|、| 9|-----------ACK----------->|、|
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
1. SIPユーザがPSTNユーザと共に開会したがっているとき、SIPノードはINVITE要求を出します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. INVITE要求を受け取り次第、ゲートウェイは、IAMメッセージにそれを写像して、ISUPネットワークにそれを送ります。
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
3. リモートISUPノードは、アドレスがACMメッセージを返送することによって呼び出しをセットアップするために十分であることを示します。
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node. This response may
contain SDP to establish an early media stream (as shown in the
diagram). If no SDP is present, the audio will be established in
both directions after step 8.
4. ACMメッセージの「被呼者状態」コードは、SIPの暫定的な応答(セクション7.2.5とセクション7.2.6で説明されるように)に写像されて、SIPノードに返されます。 この応答は早めのメディアの流れを確立するSDPを含むかもしれません(ダイヤグラムで示されるように)。 どんなSDPも存在していないと、オーディオはステップ8後の両方の方向に確立されるでしょう。
Camarillo, et. al. Standards Track [Page 11] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[11ページ]。
5. If the ISUP variant permits, the remote ISUP node may issue a
variety of Call Progress (CPG) messages to indicate, for example,
that the call is being forwarded.
5. ISUP異形が可能にするなら、リモートISUPノードはさまざまなCall Progress(CPG)に例えば呼び出しが進められているのを示すメッセージを発行するかもしれません。
6. Upon receipt of a CPG message, the gateway will map the event
code to a SIP provisional response (see Section 7.2.9) and send
it to the SIP node.
6. CPGメッセージを受け取り次第、ゲートウェイは、SIPの暫定的な応答(セクション7.2.9を見る)にイベントコードを写像して、SIPノードにそれを送るでしょう。
7. Once the PSTN user answers, an Answer (ANM) message will be sent
to the gateway.
7. PSTNユーザがいったん答えると、Answer(ANM)メッセージをゲートウェイに送るでしょう。
8. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node.
8. ANMを受け取り次第、ゲートウェイは200メッセージをSIPノードに送るでしょう。
9. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
9. INVITEの最終的な応答(200)を受けるとき、SIPノードは、領収書を受け取ったことを知らせるためにACKを送るでしょう。
7.1.2 Auto-answer call setup
7.1.2 自動応答呼び出しセットアップ
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |
一口MGC/mg PSTN1|---------招待---------->|、| | <、-、-、-、-、-、-、-、-、--100------------| | | |------------IAM---------->|2 | |<=====オーディオ===========| | | <、-、-、-、-、-、-、-、-、-、--まやかし-----------|3 | |<=====オーディオ==========>| 4| <、-、-、-、-、-、-、-、-、--200------------| | |<=====オーディオ==========>|、| 5|-----------ACK----------->|、|
Note that this flow is not supported in ANSI networks.
この流れがANSIネットワークで支持されないことに注意してください。
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
1. SIPユーザがPSTNユーザと共に開会したがっているとき、SIPノードはINVITE要求を出します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. INVITE要求を受け取り次第、ゲートウェイは、IAMメッセージにそれを写像して、ISUPネットワークにそれを送ります。
3. Since the remote node is configured for automatic answering, it
will send a Connect Message (CON) upon receipt of the IAM. (For
ANSI, this message will be an ANM).
3. 遠隔ノードが自動応答のために構成されるので、それはIAMを受け取り次第Connect Message(CON)を送るでしょう。 (このメッセージはANSIに関する、ANMになるでしょう。)
4. Upon receipt of the CON, the gateway will send a 200 message to
the SIP node.
4. CONを受け取り次第、ゲートウェイは200メッセージをSIPノードに送るでしょう。
5. The SIP node, upon receiving an INVITE final response (200), will
send an ACK to acknowledge receipt.
5. INVITEの最終的な応答(200)を受けるとき、SIPノードは、領収書を受け取ったことを知らせるためにACKを送るでしょう。
Camarillo, et. al. Standards Track [Page 12] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[12ページ]。
7.1.3 ISUP T7 Expires
7.1.3 ISUP T7は期限が切れます。
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
一口MGC/mg PSTN1|---------招待---------->|、| | <、-、-、-、-、-、-、-、-、--100------------| | | |------------IAM---------->|2 | |<=====オーディオ===========| | | *** T7は***を吐き出します。| | ** mgはPSTNトランク**をリリースします。| 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.
1. SIPユーザがPSTNユーザと共に開会したがっているとき、SIPノードはINVITE要求を出します。
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.
2. INVITE要求を受け取り次第、ゲートウェイは、IAMメッセージにそれを写像して、ISUPネットワークにそれを送ります。 ISUPタイマT7はここに始動されます。
3. The ISUP timer T7 expires before receipt of an ACM or CON
message, so a REL message is sent to cancel the call.
3. ISUPタイマT7がACMかCONメッセージの領収書の前で期限が切れるので、呼び出しを中止するためにRELメッセージを送ります。
4. A gateway timeout message is sent back to the SIP node.
4. SIPノードはゲートウェイタイムアウトメッセージに送り返されます。
5. The SIP node, upon receiving an INVITE final response (504), will
send an ACK to acknowledge receipt.
5. INVITEの最終的な応答(504)を受けるとき、SIPノードは、領収書を受け取ったことを知らせるためにACKを送るでしょう。
Camarillo, et. al. Standards Track [Page 13] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[13ページ]。
7.1.4 SIP Timeout
7.1.4 一口タイムアウト
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
一口MGC/mg PSTN1|---------招待---------->|、| | <、-、-、-、-、-、-、-、-、--100------------| | | |------------IAM---------->|2 | |<=====オーディオ===========| | | <、-、-、-、-、-、-、-、-、-、--まやかし-----------|3 | |<=====オーディオ==========>| 4| <、-、-、-、-、-、-、-、-、--200------------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、-、-、--200------------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、-、-、--200------------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、-、-、--200------------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、-、-、--200------------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、-、-、--200------------| | | *** T1は***を吐き出します。| | 5| <、-、-、-、-、-、-、-、-、--200------------| | | *** T1は***を吐き出します。| | | ** mgはPSTNトランク**をリリースします。| 7| <、-、-、-、-、-、-、-、-、--さようなら------------|------------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.
1. SIPユーザがPSTNユーザと共に開会したがっているとき、SIPノードはINVITE要求を出します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. INVITE要求を受け取り次第、ゲートウェイは、IAMメッセージにそれを写像して、ISUPネットワークにそれを送ります。
3. Since the remote node is configured for automatic answering, it
will send a CON message upon receipt of the IAM. In ANSI flows,
rather than a CON, an ANM (without ACM) would be sent.
3. 遠隔ノードが自動応答のために構成されるので、それはIAMを受け取り次第CONメッセージを送るでしょう。 CONよりむしろANSI流れでは、ANM(ACMのない)を送るでしょう。
4. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node and set SIP timer T1.
4. ANMを受け取り次第、ゲートウェイは、200メッセージをSIPノードに送って、SIPタイマT1を設定するでしょう。
5. The response is retransmitted every time the SIP timer T1
expires.
5. SIPタイマT1が期限が切れるときはいつも、応答は再送されます。
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).
6. 7「再-トランスミッション」の後に、ISUPノードにRELを送ることによって、呼び出しを取りこわします、102の原因コードで(タイマ満期に、回復してください)。
Camarillo, et. al. Standards Track [Page 14] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[14ページ]。
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.
7. BYEは呼び出しを終える試みでSIPノードに伝えられます。 これが掃除するので、さらなる取り扱いは示されません、SIPノードの状態がこのシナリオで容易に知られていないので。
8. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
8. RELメッセージを受け取り次第、リモートISUPノードはRLCメッセージで返答するでしょう。
7.1.5 ISUP Setup Failure
7.1.5 ISUPセットアップの故障
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |
一口MGC/mg PSTN1|---------招待---------->|、| | <、-、-、-、-、-、-、-、-、--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.
1. SIPユーザがPSTNユーザと共に開会したがっているとき、SIPノードはINVITE要求を出します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. INVITE要求を受け取り次第、ゲートウェイは、IAMメッセージにそれを写像して、ISUPネットワークにそれを送ります。
3. Since the remote ISUP node is unable to complete the call, it
will send a REL.
3. リモートISUPノードが呼び出しを終了できないので、それはRELを送るでしょう。
4. The gateway releases the circuit and confirms that it is
available for reuse by sending an RLC.
4. ゲートウェイは、サーキットをリリースして、それがRLCを送ることによって再利用に利用可能であると確認します。
5. The gateway translates the cause code in the REL to a SIP error
response (see Section 7.2.4) and sends it to the SIP node.
5. ゲートウェイは、SIP誤り応答(セクション7.2.4を見る)にRELの原因コードを翻訳して、SIPノードにそれを送ります。
6. The SIP node sends an ACK to acknowledge receipt of the INVITE
final response.
6. SIPノードは、INVITEの最終的な応答の領収書を受け取ったことを知らせるためにACKを送ります。
Camarillo, et. al. Standards Track [Page 15] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[15ページ]。
7.1.6 Cause Present in ACM Message
7.1.6 ACMメッセージの現在の原因
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
一口MGC/mg PSTN1|---------招待---------->|、| | <、-、-、-、-、-、-、-、-、--100------------| | | |------------IAM---------->|2 | |<=====オーディオ===========| | | <、-、--原因コードがあるACM---|3 4| <、-、-、-、-、--183 SDPと共に-------| | |<=====オーディオ===========| | ** 織り込む、タイマは**5を吐き出します。| <、-、-、-、-、-、-、-、-、--4xx+-----------| | | |------------REL---------->|6 | | <、-、-、-、-、-、-、-、-、-、--RLC-----------|7 8|-----------ACK----------->|、|
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
1. SIPユーザがPSTNユーザと共に開会したがっているとき、SIPノードはINVITE要求を出します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. INVITE要求を受け取り次第、ゲートウェイは、IAMメッセージにそれを写像して、ISUPネットワークにそれを送ります。
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.
3. ISUPノードが誤りトーン/発表自体を発生させるように呼び出しと必需品を終了できないので、それは原因コードがあるACMを送ります。 ゲートウェイが始動する、タイマを織り込んでください。
4. Upon receipt of an ACM with cause (presence of the CAI
parameter), the gateway will generate a 183 message towards the
SIP node; this contains SDP to establish early media cut-through.
4. 原因(CAIパラメタの存在)があるACMを受け取り次第、ゲートウェイはSIPノードに向かって183メッセージを発生させるでしょう。 これは深く切られた早めのメディアを確立するSDPを含んでいます。
5. A final INVITE response, based on the cause code received in the
earlier ACM message, is generated and sent to the SIP node to
terminate the call. See Section 7.2.4.1 for the table which
contains the mapping from cause code to SIP response.
5. 呼び出しを終えるために以前のACMメッセージに受け取られた原因コードに基づく最終的なINVITE応答を、SIPノードに発生して、送ります。 セクション7.2を見てください。.4 .1 原因コードからSIP応答までのマッピングを含むテーブルのために。
6. Upon expiration of the interwork timer, a REL is sent towards the
PSTN node to terminate the call. Note that the SIP node can also
terminate the call by sending a CANCEL before the interwork timer
expires. In this case, the signaling progresses as in Section
7.1.7.
6. 満了、タイマを織り込んでください、そして、呼び出しを終えるためにPSTNノードに向かってRELを送ります。 タイマを織り込んでください。また、SIPノードが以前キャンセルを送ることによって呼び出しを終えることができることに注意してください、期限が切れます。 この場合、シグナリングはセクション7.1.7のように進歩をします。
7. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
7. RELメッセージを受け取り次第、リモートISUPノードはRLCメッセージで返答するでしょう。
8. The SIP node sends an ACK to acknowledge receipt of the INVITE
final response.
8. SIPノードは、INVITEの最終的な応答の領収書を受け取ったことを知らせるためにACKを送ります。
Camarillo, et. al. Standards Track [Page 16] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[16ページ]。
7.1.7 Call Canceled by SIP
7.1.7 一口によって中止された呼び出し
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
一口MGC/mg PSTN1|---------招待---------->|、| | <、-、-、-、-、-、-、-、-、--100------------| | | |------------IAM---------->|2 | |<=====オーディオ===========| | | <、-、-、-、-、-、-、-、-、-、--ACM-----------|3 4| <、-、-、-、-、-、-、-、-、--18x------------| | |<=====オーディオ===========| | | ** mgはIPリソース**をリリースします。| 5|----------キャンセル--------->|、| 6| <、-、-、-、-、-、-、-、-、--200------------| | | ** mgはPSTNトランク**をリリースします。| | |------------REL---------->|7 8| <、-、-、-、-、-、-、-、-、--487------------| | | | <、-、-、-、-、-、-、-、-、-、--RLC-----------|9 10|-----------ACK----------->|、|
1. When a SIP user wishes to begin a session with a PSTN user, the
SIP node issues an INVITE request.
1. SIPユーザがPSTNユーザと共に開会したがっているとき、SIPノードはINVITE要求を出します。
2. Upon receipt of an INVITE request, the gateway maps it to an IAM
message and sends it to the ISUP network.
2. INVITE要求を受け取り次第、ゲートウェイは、IAMメッセージにそれを写像して、ISUPネットワークにそれを送ります。
3. The remote ISUP node indicates that the address is sufficient to
set up a call by sending back an ACM message.
3. リモートISUPノードは、アドレスがACMメッセージを返送することによって呼び出しをセットアップするために十分であることを示します。
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node. This response may
contain SDP to establish an early media stream.
4. ACMメッセージの「被呼者状態」コードは、SIPの暫定的な応答(セクション7.2.5とセクション7.2.6で説明されるように)に写像されて、SIPノードに返されます。 この応答は早めのメディアの流れを確立するSDPを含むかもしれません。
5. To cancel the call before it is answered, the SIP node sends a
CANCEL request.
5. それが答えられる前に呼び出しを中止するために、SIPノードはキャンセル要求を送ります。
6. The CANCEL request is confirmed with a 200 response.
6. キャンセル要求は200応答で確認されます。
7. Upon receipt of the CANCEL request, the gateway sends a REL
message to terminate the ISUP call.
7. キャンセル要求を受け取り次第、ゲートウェイはISUP呼び出しを終えるRELメッセージを送ります。
8. The gateway sends a "487 Call Cancelled" message to the SIP node
to complete the INVITE transaction.
8. ゲートウェイは、INVITE取引を完了するために「487呼び出しは中止した」というメッセージをSIPノードに送ります。
9. Upon receipt of the REL message, the remote ISUP node will reply
with an RLC message.
9. RELメッセージを受け取り次第、リモートISUPノードはRLCメッセージで返答するでしょう。
Camarillo, et. al. Standards Track [Page 17] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[17ページ]。
10. Upon receipt of the 487, the SIP node will confirm reception
with an ACK.
10. 487を受け取り次第、SIPノードはACKとのレセプションを確認するでしょう。
7.2 State Machine
7.2 州のマシン
Note that REL can be received in any state; the handling is the same for each case (see Section 10).
どんな状態にもRELを受け取ることができることに注意してください。 各ケースに、取り扱いは同じです(セクション10を見てください)。
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 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を招待してください。| | V| | T7/6.2.2+-------------------------+ REL/6.2.4| + <。----------------+ +を試みること。------------>+| +-+--------+------+-------+ | | キャンセル/6.2.3| | | | | + <。----------------+ | E.ACM/| ACM/| まやかし/ANM| | | 6.2.5 |6.2.6 | 6.2.7 | | V| | | | T9/6.2.8+--------------+ | | | + <。----------+ 警告しない| | | | | +-------+------+ | | | | キャンセル/6.2.3| | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--+ | CPG/| | | | | 6.2.9 | | | | V V| | | T9/6.2.8+---------------+ | REL/6.2.4| + <。----------------+ 警告|、-、|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+--+-----+------+ | | | キャンセル/6.2.3| ^ | | | | CPG/| | | ANM/| | | 6.2.9 +--+ | 6.2.7 | | | V V| | +-------------------------+ REL/9.2| | | ACKを待つこと。|、-、-、-、-、-、-、-、-、-、-、--、>|、| +-------------+-----------+ | | | | | | ACK/6.2.10| | V| | さようなら/9.1+-------------------------+ REL/9.2| + <。----------------+ 接続+------------>++-------------------------+
Camarillo, et. al. Standards Track [Page 18] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[18ページ]。
7.2.1 INVITE received
7.2.1 INVITEは受信しました。
When an INVITE request is received by the gateway, a "100 Trying" response MAY be sent back to the SIP network indicating that the gateway is handling the call.
INVITE要求がいつゲートウェイ、aによって受信されているか、「100 」 応答を試みるのはゲートウェイが呼び出しを扱っているのを示すSIPネットワークに送り返されるかもしれません。
The necessary hardware resources for the media stream MUST be reserved in the gateway when the INVITE is received, since an IAM message cannot be sent before the resource reservation (especially TCIC selection) 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 any quality-of-service provisions (although no such practices are recommended in this document).
INVITEが受け取られているとき、ゲートウェイでメディアの流れのための必要なハードウェアリソースを予約しなければなりません、資源予約(特にTCIC選択)が行われる前にIAMメッセージを送ることができないので。 通常、リソースはE1/T1とIP側の上のRTP/UDPポートで時間帯から成ります。 また、リソースはどんなサービスの質条項も含むかもしれません(そのようなどんな習慣も本書ではお勧めがではありませんが)。
After sending the IAM the timer T7 is started. The default value of T7 is between 20 and 30 seconds. The gateway goes to the 'Trying' state.
タイマをIAMに送った後に、T7は始動されます。 T7のデフォルト値は20〜30秒です。 ゲートウェイは'試みている'状態まで続いています。
7.2.1.1 INVITE to IAM procedures
7.2.1.1 IAM手順へのINVITE
This section details the mapping of the SIP headers in an INVITE message to the ISUP parameters in an Initial Address Message (IAM). A PSTN-SIP gateway is responsible for creating an IAM when it receives an INVITE.
このセクションはINVITEメッセージでInitial Address Message(IAM)のISUPパラメタにSIPヘッダーに関するマッピングを詳しく述べます。 PSTN-SIPゲートウェイはINVITEを受けるときIAMを作成するのに原因となります。
Five mandatory parameters appear within the IAM message: the Called Party Number (CPN), the Nature of Connection Indicator (NCI), the Forward Call Indicators (FCI), the Calling Party's Category (CPC), and finally a parameter that indicates the desired bearer characteristics of the call - in some ISUP variants the Transmission Medium Requirement (TMR) is required, in others the User Service Information (USI) (or both). All IAM messages MUST contain these five parameters at a minimum. Thus, every gateway must have a means of populating each of those five parameters when an INVITE is received. Many of the values that will appear in these parameters (such as the NCI or USI) will most likely be the same for each IAM created by the gateway. Others (such as the CPN) will vary on a call-by-call basis; the gateway extracts information from the INVITE in order to properly populate these parameters.
5つの義務的なパラメタがIAMメッセージの中に現れます: CalledパーティNumber(CPN)、Connection Indicatorのネイチャー(NCI)、Forward Call Indicators(FCI)、CallingパーティのCategory(CPC)、および最終的に呼び出しの必要な運搬人の特性を示すパラメタ--いくつかのISUP異形では、Transmission Medium Requirement(TMR)が必要です、他のもののUser Service情報(USI)(ともに)。 すべてのIAMメッセージが最小限にこれらの5つのパラメタを含まなければなりません。 したがって、あらゆるゲートウェイには、INVITEが受け取られているときそれぞれのそれらの5つのパラメタに居住する手段がなければなりません。 これらのパラメタ(NCIかUSIなどの)に現れる値の多くがたぶんゲートウェイによって作成された各IAMに同じになるでしょう。 他のもの(CPNなどの)は呼び出しごとのベースにおいて異なるでしょう。 ゲートウェイは、適切にこれらのパラメタに居住するためにINVITEから情報を抜粋します。
There are also quite a few optional parameters that can appear in an IAM message; Q.763 [17] lists 29 in all. However, each of these parameters need not to be translated in order to achieve the goals of SIP-ISUP mapping. As is stated above, translation allows SIP network elements to understand the basic PSTN context of the session (who it is for, and so on) if they are not capable of deciphering any encapsulated ISUP. Parameters that are only meaningful to the PSTN will be carried through PSTN-SIP- PSTN networks via encapsulation -
また、IAMメッセージに現れることができるかなり多くの任意のパラメタがあります。 Q.763[17]は全部で29を記載します。 しかしながら、それぞれのこれらのパラメタは、SIP-ISUPマッピングの目標を達成するために翻訳されない必要があります。 そのままで、上に述べられていて、それらが少しの要約のISUPも解読できないなら、SIPネットワーク要素は翻訳でセッション(それはだれにとってありますか、そして、など)の基本のPSTN関係を理解できます。 PSTNだけに重要なパラメタがPSTN-SIP- PSTNネットワークを通してカプセル化で運ばれる、-
Camarillo, et. al. Standards Track [Page 19] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[19ページ]。
translation is not necessary for these parameters. Of the aforementioned 29 optional parameters, only the following are immediately useful for translation: the Calling Party's Number (CIN, which is commonly present), Transit Network Selection (TNS), Carrier Identification Parameter (CIP, present in ANSI networks), Original Called Number (OCN), and the Generic Digits (known in some variants as the Generic Address Parameter (GAP)).
翻訳はこれらのパラメタに必要ではありません。 29の前述の任意のパラメタでは、以下だけがすぐに、翻訳の役に立ちます: CallingパーティのNumber(一般的に存在しているCIN)、Transit Network Selection(TNS)、Carrier Identification Parameter(ANSIネットワークにおける現在のCIP)、Original Called Number(OCN)、およびGeneric Digits(いくつかの異形では、Generic Address Parameter(GAP)として知られています)。
When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD attempt to make use of encapsulated ISUP (see [3]), if any, within the INVITE to assist in the formulation of outbound PSTN signaling, but SHOULD also heed the security considerations in Section 15. If possible, the gateway SHOULD reuse the values of each of the ISUP parameters of the encapsulated IAM as it formulates an IAM that it will send across its PSTN interface. In some cases, the gateway will be unable to make use of that ISUP - for example, if the gateway cannot understand the ISUP variant and must therefore ignore the encapsulated body. Even when there is comprehensible encapsulated ISUP, the relevant values of SIP header fields MUST 'overwrite' through the process of translation the parameter values that would have been set based on encapsulated ISUP. In other words, the updates to the critical session context parameters that are created in the SIP network take precedence, in ISUP-SIP-ISUP bridging cases, over the encapsulated ISUP. This allows many basic services, including various sorts of call forwarding and redirection, to be implemented in the SIP network.
SIP INVITEがPSTNゲートウェイに到着すると、ゲートウェイSHOULDは、要約のISUPを利用するのを試みます。(INVITEの中でもしあれば[3])を見て、外国行きのPSTNの定式化が合図するのを助けなさい、ただし、また、SHOULDはセクション15のセキュリティ問題を意に介します。 できれば、PSTNインタフェースの向こう側に送るIAMを定式化するとき、ゲートウェイSHOULDはそれぞれの要約のIAMのISUPパラメタの値を再利用します。 いくつかの場合、ゲートウェイが例えばISUP異形を理解できないで、したがって、要約のボディーを無視しなければならないと、ゲートウェイはそのISUPを利用できないでしょう。 分かりやすい要約のISUPさえありさえするときさえ、SIPヘッダーフィールドの関連値は翻訳の過程で要約のISUPに基づいて設定されたパラメタ値を'上書きしなければなりません'。 言い換えれば、SIPネットワークで作成されるきわどいセッション文脈パラメタへのアップデートは優先します、ISUP-SIP-ISUP橋を架ける場合で、要約のISUPの上で。 これは、様々な種類の自動転送とリダイレクションを含む多くの基本サービスがSIPネットワークで実行されるのを許容します。
For example, if an INVITE arrives at a gateway with an encapsulated IAM with a CPN field indicating the telephone number +12025332699, but the Request-URI of the INVITE indicates 'tel:+15105550110', the gateway MUST use the telephone number in the Request-URI, rather than the one in the encapsulated IAM, when creating the IAM that the gateway will send to the PSTN. Further details of how SIP header fields are translated into ISUP parameters follow.
ゲートウェイがPSTNに送るIAMを作成するとき、例えば、CPN分野が電話番号+12025332699を示していてINVITEが要約のIAMと共にゲートウェイに到着しますが、INVITEのRequest-URIが'tel:+15105550110'を示すなら、ゲートウェイは要約のIAMのものよりむしろRequest-URIに電話番号を使用しなければなりません。 SIPヘッダーフィールドがどうISUPパラメタに翻訳されるかに関する詳細は従います。
Gateways MUST be provisioned with default values for mandatory ISUP parameters that cannot be derived from translation(such as the NCI or TMR parameters) for those cases in which no encapsulated ISUP is present. The FCI parameter MUST also have a default, as only the 'M' bit of the default may be overwritten during the process of translation if the optional number portability translation mechanisms described below are used.
要約のISUPがないのが現在であるそれらの場合のための翻訳(NCIかTMRパラメタなどの)から得ることができない義務的なISUPパラメタのためにデフォルト値でゲートウェイに食糧を供給しなければなりません。 また、FCIパラメタには、デフォルトがなければなりません、以下で説明された任意のナンバーポータビリティ変換メカニズムが使用されているなら翻訳の過程の間デフォルトの'M'ビットだけを上書きしてもよいとき。
The first step in the translation of the fields of an INVITE message to the parameters of an IAM is the inspection of the Request-URI.
IAMのパラメタへのINVITEメッセージの分野に関する翻訳における第一歩はRequest-URIの点検です。
Camarillo, et. al. Standards Track [Page 20] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[20ページ]。
If the optional number portability practices are supported by the gateway, then the following steps related to handling of the 'npdi' and 'rn' parameters of the Request-URI should be followed.
任意のナンバーポータビリティ習慣がゲートウェイによって支持されるなら、'npdi'の取り扱いとRequest-URIの'Rn'パラメタに関連する以下の方法は従われるべきです。
If there is no 'npdi=yes' field within the Request-URI, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
Request-URIの中に'npdi=はい'分野が全くなければ、tel URL(すぐに'tel:'に続くケタ)の第一の電話番号をISUP形式に変換しなければなりません、セクション12で説明されて、CPNパラメタに居住するのに用いられた手順に従って。
If the 'npdi=yes' field exists in the Request-URI, then the FCI parameter bit for 'number translated' within the IAM MUST reflect that a number portability dip has been performed.
'npdi=はい'分野がRequest-URIで存在しているなら、IAM MUSTの中で'数は翻訳した'FCIパラメタビットが、ナンバーポータビリティディップが実行されたのを反映します。
If in addition to the 'npdi=yes' field there is no 'rn=' field present, then the main telephone number in the tel URL MUST be converted to ISUP format (see Section 12) and used to populate the CPN parameter. This indicates that a portability dip took place, but that the called party's number was not ported.
どんな存在している'Rn='分野も'npdi=はい'分野に加えていなければ、tel URLの主な電話番号をISUP形式(セクション12を見る)に変換されて、CPNパラメタに居住するのに使用しなければなりません。 これは、携帯性ディップが行われましたが、被呼者の番号が移植されなかったのを示します。
If in addition to the 'npdi=yes' field an 'rn=' field is present, then in ANSI ISUP the 'rn=' field MUST be converted to ISUP format and used to populate the CPN. The main telephone number in the tel URL MUST be converted to ISUP format and used to populate the Generic Digits Parameter (or GAP in ANSI). In some other ISUP variants, the number given in the 'rn=' field would instead be prepended to the main telephone number (with or without a prefix or separator) and the combined result MUST be used to populate the CPN. Once the 'rn=' and 'npdi=' parameters have been translation, the number portability translation practices are complete.
'Rn='分野が'npdi=はい'分野に加えて存在しているなら、ANSI ISUPでは、'Rn='分野をISUP形式に変換されて、CPNに居住するのに使用しなければなりません。 Generic Digits Parameter(または、ANSIのGAP)に居住するのにtel URLの主な電話番号をISUP形式に変換されて、使用しなければなりません。 ある他のISUP異形では、'Rn='分野で与えられた数は代わりに主な電話番号(接頭語か分離符のあるなしにかかわらず)にprependedされるでしょう、そして、CPNに居住するのに結合した結果を使用しなければなりません。 'Rn='と'npdi='パラメタがいったん翻訳になると、ナンバーポータビリティ翻訳練習は完全です。
The following mandatory translation practices are performed after number portability translations, if any.
もしあれば翻訳練習がナンバーポータビリティ翻訳の後に実行されるのが義務的な以下
If number portability practices are not supported by the gateway, then the primary telephone number in the tel URL (the digits immediately following 'tel:') MUST be converted to ISUP format, following the procedures described in Section 12, and used to populate the CPN parameter.
ナンバーポータビリティ習慣がゲートウェイによって支持されないなら、tel URL(すぐに'tel:'に続くケタ)の第一の電話番号をISUP形式に変換しなければなりません、セクション12で説明されて、CPNパラメタに居住するのに用いられた手順に従って。
If the primary telephone number in the Request-URI and that of the To header are at variance, then the To header SHOULD be used to populate an OCN parameter. Otherwise the To header SHOULD be ignored.
ヘッダーSHOULDが第一の電話番号であるなら次に、変化、ToにToヘッダーのRequest-URIとものに、あります。OCNパラメタに居住するのが使用されます。 そうでなければ、ToヘッダーSHOULD、無視されてください。
Some optional translation procedures are provided for carrier-based routing. If the 'cic=' parameter is present in the Request-URI, the gateway SHOULD consult local policy to make sure that it is appropriate to transmit this Carrier Identification Code (CIC, not to
いくつかの任意の翻訳手順をキャリヤーベースのルーティングに提供します。 'cic='パラメタがRequest-URIで存在しているなら、ゲートウェイSHOULDがこのCarrier Identification Codeを伝えるのが確実に適切になるようにするためにローカルの方針に相談する、(CIC
Camarillo, et. al. Standards Track [Page 21] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[21ページ]。
be confused with the MTP3 'circuit identification code') in the IAM; if the gateway supports many independent trunks, it may need to choose a particular trunk that points to the carrier identified by the CIC, or a tandem through which that carrier is reachable. Policies for such trunks (based on the preferences of the carriers with which the trunks are associated and the ISUP variant in use) SHOULD dictate whether the CIP or TNS parameter is used to carry the CIC. In the absence of any pre-arranged policies, the TNS should be used when the CPN parameter is in an international format (i.e., the tel URL portion of the Request-URI is preceded by a '+', which will generate a CPN in international format), and (where supported) the CIP should be used in other cases.
混乱してください、MTP3'サーキット識別コード') コネによるIAM。 ゲートウェイが多くの独立しているトランクスを支えるなら、それは、CICによって特定された運送業者を示す特定のトランク、またはそのキャリヤーが届いている2人乗り自転車を選ぶ必要があるかもしれません。 そのようなトランクス(トランクスが関連しているキャリヤーと使用中のISUP異形の好みに基づいている)のための方針 SHOULDは、CIPかTNSパラメタがCICを運ぶのに使用されるかどうかと決めます。 どんな根回しされた方針がないとき、国際的な形式にCPNパラメタがあるとき(国際的な形式でCPNを発生させる'+'はすなわち、Request-URIのtel URL部分に先行します)、TNSは使用されるべきであり、(支持されるところで)CIPは他の場合に使用されるべきです。
When a SIP call has been routed to a gateway, then the Request-URI will most likely contain a tel URL (or a SIP URI with a tel URL user portion) - SIP-ISUP gateways that receive Request-URIs that do not contain valid telephone numbers SHOULD reject such requests with an appropriate response code. Gateways SHOULD however continue to process requests with a From header field that does not contain a telephone number, as will sometimes be the case if a call originated at a SIP phone that employs a SIP URI user@host convention. The CIN parameter SHOULD be omitted from the outbound IAM if the From field is unusable. Note that as an alternative, gateway implementers MAY consider some non-standard way of mapping particular SIP URIs to telephone numbers.
SIP呼び出しがゲートウェイに発送されたなら、Request-URIはたぶん、tel URL(または、tel URLユーザ部分があるSIP URI)を含むでしょう--有効な電話番号SHOULDを含まないRequest-URIを受けるSIP-ISUPゲートウェイが適切な応答コードでそのような要求を拒絶します。 しかしながら、ゲートウェイSHOULDは、電話番号を含まないFromヘッダーフィールドで要求を処理し続けています、呼び出しがSIP URI user@host コンベンションを使うSIP電話で由来したなら時々そうであるように。 CINパラメタSHOULD、外国行きのIAMから、From分野が使用不可能であるなら、省略されてください。 代替手段として、ゲートウェイimplementersが何らかの標準的でない道に特定のSIP URIを電話番号に写像するのを考えるかもしれないことに注意してください。
When a gateway receives a message with (comprehensible) encapsulated ISUP, it MUST set the FCI indicator in the generated IAM so that all interworking-related bits have the same values as their counterparts in the encapsulated ISUP. In most cases, these indicators will state that no interworking was encountered, unless interworking has been encountered somewhere else in the call path. If usable encapsulated ISUP is not present in an INVITE received by the gateway, it is STRONGLY RECOMMENDED that the gateway set the Interworking Indicator bit of the FCI to 'no interworking' and the ISDN User Part Indicator to 'ISUP used all the way'; the gateway MAY also set the Originating Access indicator to 'Originating access non-ISDN' (generally, it is not safe to assume that SIP phones will support ISDN endpoint services, and the procedures in this document do not detail mappings to translate all such services).
ゲートウェイが受信されるとき、(分かりやすい)があるメッセージはISUPを要約して、それは、すべての織り込み関連のビットが要約のISUPに彼らの対応者と同じ値を持つように、発生しているIAMにFCIインディケータをはめ込まなければなりません。 多くの場合、これらのインディケータは、織り込まないことが遭遇したと述べるでしょう、織り込むことが呼び出し経路の他のどこかで遭遇していない場合。 使用可能な要約のISUPがゲートウェイによって受け取られたINVITEに存在していないなら、ゲートウェイが'織り込まないこと'へのFCIと'いっぱいに使用されるISUP'へのISDN User Part IndicatorのInterworking Indicatorビットを設定するのは、STRONGLY RECOMMENDEDです。 また、ゲートウェイは'由来しているアクセス非ISDN'にOriginating Accessインディケータを設定するかもしれません(一般に、SIP電話がISDN終点サービスを支持すると仮定するのが安全でなく、また手順はそのようなすべてのサービスを翻訳するために本書ではマッピングを詳しく述べません)。
Note that when 'interworking encountered' is set in the FCI parameter of the IAM, this indicates that ISUP is interworking with a network which is not capable of providing as many services as ISUP does. ISUP networks will therefore not employ certain features they otherwise normally would, including potentially the use of ISDN cause codes in failure conditions (as opposed to sending ACMs followed by audible announcements). If desired, gateway vendors MAY provide a
'遭遇する織り込むこと'がIAMのFCIパラメタにおいてセットであるときに、これが、ISUPがネットワークで織り込むことであることをISUPと同じくらい多くのサービスを提供できない示すことに注意してください。 したがって、ISUPネットワークはある特徴を使わないでしょう。通常、そうでなければ、それらはそうするでしょう、潜在的に失敗条件(聞きとれる発表があとに続いたACMsを送ることと対照的に)におけるISDN原因コードの使用を含んでいて。 望まれているなら、ゲートウェイ業者はaを提供するかもしれません。
Camarillo, et. al. Standards Track [Page 22] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[22ページ]。
configurable option, usable at the discretion of service providers, that will signal in the FCI that interworking has been encountered (and that ISUP is not used all the way) when encapsulated ISUP is not present; however, doing so may significantly limit the efficiency and transparency of SIP-ISUP translation.
要約のISUPが存在していないとき、FCIにその織り込むことを示す構成可能なサービスプロバイダーの裁量で使用可能なオプションが遭遇しました(そのISUPはいっぱいに使用されません)。 しかしながら、そうするのはSIP-ISUP翻訳の効率と透明をかなり制限するかもしれません。
Claiming to be an ISDN node might make the callee request ISDN user to user services. Since user to user services 1 and 2 must be requested by the caller, they do not represent a problem (see [14]). 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.
ISDNノードであると主張するのは訪問される人要求ISDNユーザをユーザサービスにするかもしれません。 訪問者がユーザサービス1へのユーザと2を要求しなければならないので、彼らは問題を表しません。([14])を見てください。 訪問される人はユーザサービス3へのユーザを要求できます。 非SIPの橋を架ける状況で、MGCはこのサービスのリクエストを拒絶できるべきです。
7.2.2 ISUP T7 expires
7.2.2 ISUP T7は期限が切れます。
Since no response was received from the PSTN all the resources in the MG are released. A '504 Server Timeout' SHOULD be sent back to the SIP network. A REL message with cause value 102 (protocol error, recovery on timer expiry) SHOULD be sent to the PSTN. Gateways can expect the PSTN to respond with RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
PSTNから応答を全く受けなかったので、MGのすべてのリソースが発表されます。 '504Server Timeout'SHOULD、SIPネットワークに送り返されてください。 原因価値102(プロトコル誤り、タイマ満期の回復)のSHOULDをPSTNに送るRELメッセージ。 ゲートウェイは、PSTNがRLCとACKが、リリース系列が完了したのを示していて反応させるSIPネットワークと共に応じると予想できます。
7.2.3 CANCEL or BYE received
7.2.3 キャンセルかBYEが受信しました。
If a CANCEL or BYE request is received before a final SIP response has been sent, a '200 OK' MUST be sent to the SIP network to confirm the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE transaction. All the resources are released and a REL message SHOULD be sent to the PSTN with cause value 16 (normal clearing). Gateways can expect an RLC from the PSTN to be received indicating that the release sequence is complete.
最終的なSIP応答を送る前にキャンセルかBYE要求が受信されているなら、キャンセルを確認するSIPネットワークかBYEに'200OK'を送らなければなりません。 また、INVITE取引を終えるために487を送らなければなりません。 すべてのリソースが、リリースされていてRELメッセージSHOULDです。原因値16(通常の開拓地)があるPSTNに送ってください。 リリース系列が完全であることを示しながら、ゲートウェイは、PSTNからのRLCが受け取られると予想できます。
In SIP bridging situations, a REL might be encapsulated in the body of a BYE request. Although BYE is usually mapped to cause code 16 (normal clearing), under exceptional circumstances the cause code in the REL message might be different. Therefore the Cause Indicator parameter of the encapsulated REL should be re-used in the REL sent to the PSTN.
SIP橋を架ける状況で、RELはBYE要求のボディーで要約されるかもしれません。 BYEは通常写像されますが、例外的な状況によるコード16(通常の開拓地)にRELメッセージの原因コードを引き起こすのは異なっているかもしれません。 したがって、要約のRELのCause IndicatorパラメタはPSTNに送られたRELで再使用されるべきです。
Note that a BYE or CANCEL request may contain a Reason header that SHOULD be mapped to the Cause Indicator parameter (see Section 5.8). If a BYE contains both a Reason header and encapsulated ISUP, the value in the Reason header MUST be preferred.
BYEかキャンセル要求がCause Indicatorパラメタに写像されていた状態でSHOULDがあるReasonヘッダーを含むかもしれないことに注意してください(セクション5.8を見てください)。 BYEがReasonヘッダーと要約のISUPの両方を含んでいるなら、Reasonヘッダーの値を好まなければなりません。
All the resources in the gateway SHOULD be released before the gateway sends any REL message.
すべてのリソース、ゲートウェイがどんなRELメッセージも送る前にゲートウェイSHOULDでリリースされてください。
Camarillo, et. al. Standards Track [Page 23] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[23ページ]。
7.2.4 REL received
7.2.4 RELは受信しました。
This section applies when a REL is received before a final SIP response has been sent. Typically, this condition arises when a call has been rejected by the PSTN.
最終的なSIP応答を送る前にRELが受け取られているとき、このセクションは適用されます。 呼び出しがPSTNによって拒絶されたとき、通常、この状態は起こります。
Any gateway resources SHOULD be released immediately and an RLC MUST be sent to the ISUP network to indicate that the circuit is available for reuse.
すぐに、リリースされていてRLC MUSTになってください。どんなゲートウェイリソースSHOULD、もサーキットが再利用に利用可能であることを示すためにISUPネットワークに送ります。
If the INVITE that originated this transaction contained a legitimate and comprehensible encapsulated ISUP message (i.e., an IAM using a variant supported by the gateway, preferably with a digital signature), then encapsulated ISUP SHOULD be sent in the response to the INVITE when possible (since this suggests an ISUP-SIP-ISUP bridging case) - therefore, the REL message just received SHOULD be included in the body of the SIP response. The gateway SHOULD NOT return a response with encapsulated ISUP if the originator of the INVITE did not enclose ISUP itself.
この取引を溯源したINVITEが正統の、そして、分かりやすい要約のISUPメッセージ(すなわち、望ましくは、デジタル署名と共にゲートウェイによって支持された異形を使用するIAM)を含んで、次に、ISUP SHOULDを要約したなら、INVITEへの応答では、可能である(これがISUP-SIP-ISUP橋を架けるケースを示すので)ときには、送ってください--したがって、含まれていて、RELメッセージはSIP応答のボディーでただSHOULDを受けました。 INVITEの創始者がISUP自身を同封しなかったなら、ゲートウェイSHOULD NOTは要約のISUPとの応答を返します。
Note that the receipt of certain maintenance messages in response to IAM such as Blocking Message (BLO) or Reset Message (RSC) (or their circuit group message equivalents) may also result in the teardown of calls in this phase of the state machine. Behavior for maintenance messages is given below in Section 11.
また、Blocking Message(BLO)かReset Message(RSC)(または、それらのサーキットグループメッセージ同等物)などのIAMに対応したある維持メッセージの領収書が州のマシンのこのフェーズの、呼び出しの分解をもたらすかもしれないことに注意してください。 セクション11で維持メッセージのための振舞いを以下に与えます。
7.2.4.1 ISDN Cause Code to Status Code Mapping
7.2.4.1 ステータスコードマッピングへのISDN原因コード
The use of the REL message in the SS7 network is very general, whereas SIP has a number of specific tools that, collectively, play the same role as REL - namely BYE, CANCEL, and the various status/response codes. An REL can be sent to tear down a call that is already in progress (BYE), to cancel a previously sent call setup request that has not yet been completed (CANCEL), or to reject a call setup request (IAM) that has just been received (corresponding to a SIP status code).
SIPには、RELと同じ役割をまとめて果たす多くの特定のツールがあります--すなわち、BYE、キャンセル、および様々な状態/応答コードにもかかわらず、SS7ネットワークにおけるRELメッセージの使用は非常に一般的です。 まだ終了していない以前に送られた呼び出しセットアップ要求(キャンセル)を中止するという既に進行している要求(BYE)を取りこわすか、またはちょうど受け取られた(SIPステータスコードに対応する)呼び出しセットアップ要求(IAM)を拒絶するためにRELを送ることができます。
Note that it is not necessarily appropriate to map some ISDN cause codes to SIP messages because these cause codes are only meaningful to the ISUP interface of a gateway. A good example of this is cause code 44 "Request circuit or channel not available." 44 signifies that the CIC for which an IAM had been sent was believed by the receiving equipment to be in a state incompatible with a new call request - however, the appropriate behavior in this case is for the originating switch to re-send the IAM for a different CIC, not for the call to be torn down. Clearly, there is not (nor should there be) an SIP status code indicating that a new CIC should be selected - this matter is internal to the originating gateway. Hence receipt of cause code 44
これらの原因コードが単にゲートウェイのISUPインタフェースに重要であるので、いくつかのISDN原因コードをSIPメッセージに写像するのが必ず適切であるというわけではないことに注意してください。 この好例は「サーキットを要求するか、または利用可能でなく精神を集中してください」をコード44に引き起こすことです。 44 IAMが送られたCICが新しい発呼要求と両立しない状態にあると受信設備によって信じられていました--しかしながら、この場合、適切な行動が由来しているスイッチが取りこわされるという要求のために再送するのではなく、異なったCICのためにIAMを再送することであることを意味します。 明確に、新しいCICが選択されるべきであるのを示すSIPステータスコードがありません(または、あるべきです)--この件は由来しているゲートウェイに内部です。 したがって、原因コード44の領収書
Camarillo, et. al. Standards Track [Page 24] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[24ページ]。
should not result in any SIP status code being sent; effectively, the cause code is untranslatable.
送られる少しのSIPステータスコードももたらすべきではありません。 事実上、原因コードは「非-翻訳でき」です。
If a cause value other than those listed below is received, the default response '500 Server internal error' SHOULD be used.
以下に記載されたもの以外の原因値が受け取られていて、デフォルト応答が'500Server内部エラー'であるというSHOULDであるなら、使用されてください。
Finally, in addition to the ISDN Cause Code, the CAI parameter also contains a cause 'location' that gives some sense of which entity in the network was responsible for terminating the call (the most important distinction being between the user and the network). In most cases, the cause location does not affect the mapping to a SIP status code; some exceptions are noted below. A diagnostic field may also be present for some ISDN causes; this diagnostic will contain additional data pertaining to the termination of the call.
また、最終的に、ISDN Cause Codeに加えて、CAIパラメタはネットワークにおけるどの実体が要求(ユーザとネットワークの間にある最も重要な区別)を終えるのに原因となったかに関する何らかの感覚を与える原因'位置'を含んでいます。 多くの場合、原因位置はSIPステータスコードにマッピングに影響しません。 いくつかの例外が以下に述べられます。 また、診断分野もいくつかのISDN原因のために存在しているかもしれません。 この病気の特徴は呼び出しの終了に関係する追加データを含むでしょう。
The following mapping values are RECOMMENDED:
値を写像する↓これはRECOMMENDEDです:
Normal event
正常な出来事
ISUP Cause value SIP response ---------------- ------------ 1 unallocated number 404 Not Found 2 no route to network 404 Not found 3 no route to destination 404 Not found 16 normal call clearing --- (*) 17 user busy 486 Busy here 18 no user responding 408 Request Timeout 19 no answer from the user 480 Temporarily unavailable 20 subscriber absent 480 Temporarily unavailable 21 call rejected 403 Forbidden (+) 22 number changed (w/o diagnostic) 410 Gone 22 number changed (w/ diagnostic) 301 Moved Permanently 23 redirection to new destination 410 Gone 26 non-selected user clearing 404 Not Found (=) 27 destination out of order 502 Bad Gateway 28 address incomplete 484 Address incomplete 29 facility rejected 501 Not implemented 31 normal unspecified 480 Temporarily unavailable
ISUP Cause値のSIP応答---------------- ------------ 「非-割り当て」られたNo.404Not Found2ノー、がNotが404Notを目的地に発送するのが3ノー、がわかった404をネットワークでつなぐために発送する1によって、16の通常の呼び出しがクリアされているのがわかりました。--- (*) 17 ここのユーザの忙しい486Busyは、480のTemporarilyの入手できない21のないユーザ480のTemporarilyの入手できない20加入者から301に変えられた(病気の特徴のない)410Gone22番号が変えた(病気の特徴で)拒絶された403Forbidden(+)22番号に電話をします18ノーユーザ応じる408Request Timeout19ノー、が、答える; 故障していた状態で404Not Found(=)27の目的地をクリアしている新しい目的地410Gone26非選択されたユーザー502Badゲートウェイ28アドレス不完全な484Address不完全な29施設への動くPermanently23リダイレクションは入手できない501Not実行された31標準不特定の480Temporarilyを拒絶しました。
(*) ISDN Cause 16 will usually result in a BYE or CANCEL
(*) 通常、ISDN Cause16はBYEかキャンセルをもたらすでしょう。
(+) If the cause location is 'user' than the 6xx code could be given rather than the 4xx code (i.e., 403 becomes 603)
原因位置が6xxコードより'ユーザ'であるなら4xxコードよりむしろ(+)を与えるかもしれません。(すなわち、403は603になります)
(=) ANSI procedure - in ANSI networks, 26 is overloaded to signify 'misrouted ported number'. Presumably, a number portability dip should have been performed by a prior network. Otherwise cause 26 is usually not used in ISUP procedures.
(=)ANSI手順--ANSIネットワークでは、26は、'misrouted移植された数'を意味するように積みすぎられます。 おそらく、ナンバーポータビリティディップは先のネットワークによって実行されるべきでした。 さもなければ、通常、原因26はISUP手順で使用されません。
Camarillo, et. al. Standards Track [Page 25] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[25ページ]。
A REL with ISDN cause 22 (number changed) might contain information about a new number where the callee might be reachable in the diagnostic field. If the MGC is able to process this information it SHOULD be added to the SIP response (301) in a Contact header.
ISDN原因22(数は変化しました)があるRELは訪問される人が診断分野で届くかもしれない新しい数の情報を含むかもしれません。 MGCがこの情報を処理できる、それ、SHOULD、ContactヘッダーでSIP応答(301)に加えられてください。
Resource unavailable
入手できないリソース
This kind of cause value indicates a temporary failure. A 'Retry- After' header MAY be added to the response if appropriate.
この種類の原因価値は一時障害を示します。 '適切であるならヘッダーが応答に加えられたかもしれない後に'再試行。
ISUP Cause value SIP response ---------------- ------------ 34 no circuit available 503 Service unavailable 38 network out of order 503 Service unavailable 41 temporary failure 503 Service unavailable 42 switching equipment congestion 503 Service unavailable 47 resource unavailable 503 Service unavailable
ISUP Cause値のSIP応答---------------- ------------ 34 入手できない設備の503のServiceの入手できない47混雑リソース入手できない503Serviceを切り換える利用可能なサーキットの503Service入手できない38ネットワークがありません不適切な503Service入手できない41一時障害503のServiceの入手できない42。
Service or option not available
利用可能でないサービスかオプション
This kind of cause value indicates that there is a problem with the request, rather than something that will resolve itself over time.
この種類の原因価値は、時間がたつにつれて自然に解決する何かよりむしろ要求に関する問題があるのを示します。
ISUP Cause value SIP response
---------------- ------------
55 incoming calls barred within CUG 403 Forbidden
57 bearer capability not authorized 403 Forbidden
58 bearer capability not presently 503 Service unavailable
available
ISUP Cause値のSIP応答---------------- ------------ 55 CUG403Forbidden57運搬人能力の中で禁じられた入って来る呼び出しは現在の入手できない503Serviceではなく、利用可能な403Forbidden58運搬人能力を認可しませんでした。
Service or option not available
利用可能でないサービスかオプション
ISUP Cause value SIP response ---------------- ------------ 65 bearer capability not implemented 488 Not Acceptable Here 70 only restricted digital avail 488 Not Acceptable Here 79 service or option not implemented 501 Not implemented
ISUP Cause値のSIP応答---------------- ------------ 65 運搬人能力が488Not Acceptable Here70唯一の制限されたデジタル利益488Not Acceptable Here79サービスを実行しなかったか、またはオプションはNotが実行した501を実行しませんでした。
Invalid message
無効のメッセージ
ISUP Cause value SIP response ---------------- ------------ 87 user not member of CUG 403 Forbidden 88 incompatible destination 503 Service unavailable
ISUP Cause値のSIP応答---------------- ------------ メンバーではなく、入手できないCUG403Forbidden88の非互換な目的地503Serviceの87ユーザ
Camarillo, et. al. Standards Track [Page 26] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[26ページ]。
Protocol error
プロトコル誤り
ISUP Cause value SIP response ---------------- ------------ 102 recovery of timer expiry 504 Gateway timeout 111 protocol error 500 Server internal error
ISUP Cause値のSIP応答---------------- ------------ 102 タイマ満期504ゲートウェイタイムアウト111プロトコル誤り500Server内部エラーの回復
Interworking
織り込むこと
ISUP Cause value SIP response ---------------- ------------ 127 interworking unspecified 500 Server internal error
ISUP Cause値のSIP応答---------------- ------------ 127 不特定の500Serverが内部エラーであると織り込むこと。
7.2.5 Early ACM received
7.2.5 早く、ACMは受信しました。
An ACM message is sent in certain situations to indicate that the call is in progress in order to satisfy ISUP timers, rather than to signify that the callee is being alerted. This occurs for example in mobile networks, where roaming can delay call setup significantly. 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).
むしろISUPタイマを満たして、訪問される人が警告されているのを意味するより呼び出しが進行しているのを示すためにある状況でACMメッセージを送ります。 これは例えば、モバイルネットワークで起こります。そこでは、ローミングが呼び出しセットアップをかなり遅らせることができます。 T7をリセットして、T9を始動するようユーザに注意を促す前に前のACMを送ります。 CalledパーティのStatus Indicatorが00(指示がない)に用意ができているなら、ACMは'前のACM'であると考えられます。
After sending an early ACM, the ISUP network can be expected to indicate the further progress of the call by sending CPGs.
前のACMを送った後に、ISUPネットワークがCPGsを送ることによって呼び出しのさらなる進歩を示すと予想できます。
When an early ACM is received the gateway SHOULD send a 183 Session Progress response (see [1]) to the SIP network. In SIP bridging situations (where encapsulated ISUP was contained in the INVITE that initiated this call) the early ACM SHOULD also be included in the response body.
前のACMがそうときに、受け取って、ゲートウェイSHOULDは183Session Progress応答を送ります。(SIPネットワークにおいて[1])を見てください。 SIP橋を架ける状況、(要約のISUPがこの呼び出し) 前のACM SHOULDも開始したINVITEに含まれたところでは、応答本体で含められてください。
Note that sending 183 before a gateway has confirmation that the address is complete (ACM) creates known problems in SIP bridging cases, and it SHOULD NOT therefore be sent.
ゲートウェイにアドレスがそうである確認がある前に183を送って、完全な(ACM)がケース、およびそれに橋を架けるSIPで既知の問題を作成することに注意してください、SHOULD NOT、したがって、送ってください。
7.2.6 ACM received
7.2.6 ACMは受信しました。
Most commonly, on receipt of an ACM a provisional response (in the 18x class) SHOULD be sent to the SIP network. If the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP, then the ACM received by the gateway SHOULD be encapsulated in the provisional response.
最も一般的に、ACMのa暫定的な応答(18xのクラスにおける)SHOULDを受け取り次第SIPネットワークに送ってください。 このセッションを開始したINVITEが正統の、そして、分かりやすい要約のISUPを含んだなら、ACMは要約のコネが暫定的な応答であったならゲートウェイSHOULDのそばで受信しました。
If the ACM contains a Backward Call Indicators parameter with a value of 'subscriber free', the gateway SHOULD send a '180 Ringing' response. When a 180 is sent, it is assumed, in the absence of any early media extension, that any necessary ringback tones will be
ACMが'自由な加入者'の値があるBackward Call Indicatorsパラメタを含んでいるなら、ゲートウェイSHOULDは'180Ringing'応答を送ります。 180が送ります、どんな早めのメディア拡大がないときどんな必要なringbackトーンもそうになると思われるということであるときに
Camarillo, et. al. Standards Track [Page 27] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[27ページ]。
generated locally by the SIP user agent to which the gateway is responding (which may in turn be a gateway).
ゲートウェイが応じているSIPユーザエージェント(順番にゲートウェイであるかもしれない)によって局所的に発生します。
If the Backward Call Indicators (BCI) parameter of the ACM indicates that interworking has been encountered (generally designating that the ISUP network sending the ACM is interworking with a less sophisticated network which cannot report its status via out-of-band signaling), then there may be in-band announcements of call status such as an audible busy tone or caller intercept message, and if possible a backwards media transmission SHOULD be initiated. Backwards media SHOULD also be transmitted if the Optional Backward Call Indicators parameter field for in-band media is set. For more information on early media (before 200 OK/ANM) see Section 5.5. After early media transmission has been initiated, the gateway SHOULD send a 183 Session Progress response code.
ACMのBackward Call Indicators(BCI)パラメタが、織り込むことが遭遇したのを(一般に、バンドで出ているシグナリングでACMを送ると状態を報告できないそれほど精巧でないネットワークと共に織り込まれているISUPネットワークにそれを指定します)示すなら、バンドにおける、聞きとれる話中音か訪問者インタセプトメッセージなどの呼び出し状態の発表があるかもしれません、そして、可能なa遅れているメディアトランスミッションSHOULDであるなら、開始されてください。 遅れているメディアSHOULD、また、バンドにおけるメディアのためのOptional Backward Call Indicatorsパラメタ分野が設定されるなら、伝えられてください。 早めのメディア(200OK/ANMの前の)の詳しい情報に関しては、セクション5.5を見てください。 早めのメディアトランスミッションが開始された後に、ゲートウェイSHOULDは応答コードを183Session Progressに送ります。
Gateways MAY have some means of ascertaining the disposition of in- band audio media; for example, a way of determining by inspecting signaling in some ISUP variants, or by listening to the audio, that ringing, or a busy tone, is being played over the circuit. Such gateways MAY elect to discard the media and send the corresponding response code (such as 180 or 486) in its stead. However, the implementation of such a gateway would entail overcoming a number of known challenges that are outside the scope of this document.
ゲートウェイには、コネバンドオーディオメディアの気質を確かめるいくつかの手段があるかもしれません。 例えば、いくつかのISUP異形、またはオーディオを聞くことによってシグナリングを点検しながら自決する方法(その鳴ること、または話中音)は、サーキットの上にプレーされています。 そのようなゲートウェイは、メディアを捨てて、代わりにおける対応する応答コード(180か486などの)を送るのを選ぶかもしれません。 しかしながら、そのようなゲートウェイの実現は、このドキュメントの範囲の外にある多くの知られている挑戦に打ち勝つのを伴うでしょう。
When they receive an ACM, switches in many ISUP networks start a timer known as "T9" which usually lasts between 90 seconds and 3 minutes (see [13]). When early media is being played, this timer permits the caller to hear backwards audio media (in the form ringback, tones or announcements) from a remote switch in the ISUP network for that period of time without incurring any charge for the connection. The nearest possible local ISUP exchange to the callee generates the ringback tone or voice announcements. If longer announcements have to be played, the network has to send an ANM, which initiates bidirectional media of indefinite duration. In common ISUP network practice, billing commences when the ANM is received. Some networks do not support timer T9.
いつとして彼らがACMを受けて、多くのISUPネットワークにおけるスイッチが知られているタイマを始動するか、「通常、90秒と3分の間持続するT9"、([13])を見てください、」 早めのメディアが対戦されているとき、このタイマは、訪問者が接続のためにどんな料金も被らないでオーディオメディア(フォームringback、トーンまたは発表における)をリモート・スイッチからその期間にISUPネットワークで後方に、聞くのを可能にします。 訪問される人への可能な限り近い地方のISUP交換はringbackトーンか声の発表を発生させます。 より長い発表がプレーされなければならないなら、ネットワークはANMを送らなければなりません。(ANMは無期限の双方向のメディアに着手します)。 一般的なISUPネットワーク習慣では、ANMが受け取られているとき、支払いは始まります。 タイマT9を支持しないネットワークもあります。
7.2.7 CON or ANM Received
7.2.7 まやかしかANMが受信しました。
When an ANM or CON message is received, the call has been answered and thus '200 OK' response SHOULD be sent to the SIP network. This 200 OK SHOULD contain an answer to the media offered in the INVITE. In SIP bridging situations (when the INVITE that initiated this call contained legitimate and comprehensible encapsulated ISUP), the ISUP message is included in the body of the 200 OK response. If it has not done so already, the gateway MUST establish a bidirectional media stream at this time.
'ANMかCONメッセージが受信されているとき、呼び出しは答えられました、そして、その結果、200は'応答SHOULDを承認します。SIPネットワークに送ります。 この200OK SHOULDはINVITEで提供されたメディアの答えを含んでいます。 SIP橋を架ける状況(この呼び出しを開始したINVITEが正統の、そして、分かりやすい要約のISUPを含んだとき)で、ISUPメッセージは200OK応答のボディーに含まれています。 そう既にしていないなら、ゲートウェイはこのとき、双方向のメディアの流れを確立しなければなりません。
Camarillo, et. al. Standards Track [Page 28] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[28ページ]。
When there is interworking with some legacy networks, it is possible for an ISUP switch to receive an ANM immediately after an early ACM (without CPG or any other backwards messaging), or without receiving any ACM at all (when an automaton answers the call). In this situation the SIP user will never have received a 18x provisional response, and consequently they will not hear any kind of ringtone before the callee answers. This may result in some clipping of the initial forward media from the caller (since forward media transmission cannot commence until SDP has been acquired from the destination). In ISDN (see [12]) this is solved by connecting the voice path backwards before sending the IAM.
いくつかの遺産ネットワークによる織り込むことがあるとき、ISUPスイッチが前のACM(CPGも遅れているメッセージングのないいかなる他のも)直後、全くどんなACMも受けないでANMを受け取るのは、可能です(オートマトンが電話口に出るとき)。 この状況で、SIPユーザは18xの暫定的な応答を一度も受けたことがないでしょう、そして、その結果、訪問される人に答える前に彼らはどんな種類の着信音も聞かないでしょう。 これは訪問者からの初期の前進のメディアのある切り取りをもたらすかもしれません(前進のメディアトランスミッションが目的地からSDPを獲得するまで始まることができないので)。 ISDN、([12]) これがIAMを送る前に後方に声の経路をつなげることによって解決されているのを確実にしてください。
7.2.8 Timer T9 Expires
7.2.8 タイマT9は期限が切れます。
The expiry of this timer (which is not used in all networks) signifies that an ANM has not arrived a significant period of time after alerting began (with the transmission of an ACM) for this call. Usually, this means that the callee's terminal has been alerted for many rings but has not been answered. It may also occur in interworking cases when the network is playing a status announcement (such as one indicating that a number is not in service) that has cycled several times. Whatever the cause of the protracted incomplete call, when this timer expires the call MUST be released. All of the gateway resources related to the media path SHOULD be released. A '480 Temporarily Unavailable' response code SHOULD be sent to the SIP network, and an REL message with cause value 19 (no answer from the user) SHOULD be sent to the ISUP network. The PSTN can be expected to respond with an RLC and the SIP network to respond with an ACK indicating that the release sequence has been completed.
このタイマ(すべてのネットワークに使用されない)の満期は、警告が始まった(ACMのトランスミッションで)後にANMがこの呼び出しに到着したa重要な期間を過さないのを意味します。 通常、これは、訪問される人の端末が多くのリングのために警告されましたが、答えられていないことを意味します。 また、それはネットワークが何度か循環した状態発表(数が使用中でないことを示すものなどの)をプレーしているときケースを織り込む際に起こるかもしれません。 このタイマが期限が切れるとき、延長された不完全な呼び出しの原因が何であっても、呼び出しをリリースしなければなりません。 ゲートウェイリソースのすべてがメディア経路SHOULDに関連しました。リリースされます。 '480Temporarily Unavailable'応答はSHOULDをコード化します。SIPネットワーク、およびRELメッセージに原因価値19(ユーザからの答えがありません)のSHOULDをISUPネットワークに送って送ってください。 PSTNがACKが、リリース系列が完了したのを示していて反応させるRLCとSIPネットワークと共に応じると予想できます。
7.2.9 CPG Received
7.2.9 CPGは受信しました。
A CPG is a provisional message that can indicate progress, alerting or in-band information. If a CPG suggests that in-band information is available, the gateway SHOULD begin to transmit early media and cut through the unidirectional backwards media path.
CPGは進歩、警告またはバンドにおける情報を示すことができる暫定的なメッセージです。 CPGが、バンドにおける情報が利用可能であると示唆するなら、ゲートウェイSHOULDは早めのメディアを伝えて、後方に単方向までメディア経路を切り始めます。
Camarillo, et. al. Standards Track [Page 29] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[29ページ]。
In SIP bridging situations (when the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP), the CPG SHOULD be sent in the body of a particular 18x response, determined from the CPG Event Code as follows:
以下のCPG Event Codeから状況(このセッションを開始したINVITEが正統の、そして、分かりやすい要約のISUPを含んだとき)、特定の18x応答のボディーで送られて、決定するCPG SHOULDに橋を架けるSIPで:
ISUP event code SIP response ---------------- ------------ 1 Alerting 180 Ringing 2 Progress 183 Session progress 3 In-band information 183 Session progress 4 Call forward; line busy 181 Call is being forwarded 5 Call forward; no reply 181 Call is being forwarded 6 Call forward; unconditional 181 Call is being forwarded - (no event code present) 183 Session progress
ISUPイベントコードSIP応答---------------- ------------ 1 警告180Ringing2Progress183Session進歩3In-バンド情報183Sessionは前方に4Callを進行します。 前方に線忙しい181Callに5Callを送っています。 いいえは返答します。181 前方に6CallをCallに送っています。 無条件の181Callを進めています--(イベントコードプレゼントがありません)183Sessionは進歩をします。
Note that if the CPG does not indicate "Alerting," the current state will not change.
CPGが「警告」を示さないと、現状が変化しないことに注意してください。
7.3 ACK received
7.3 ACKは受信しました。
At this stage, the call is fully connected and the conversation can take place. No ISUP message should be sent by the gateway when an ACK is received.
現在のところ、呼び出しは完全に接続されます、そして、会話は行われることができます。 ACKが受け取られているとき、ゲートウェイはISUPメッセージを全く送るべきではありません。
8. ISUP to SIP Mapping
8. マッピングをちびちび飲むISUP
8.1 ISUP to SIP Call Flows
8.1 ちびちび飲むISUPは、流れと呼びます。
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 depicted, since their presence is optional.
PSTNネットワークから開始された呼び出しをセットアップするとき、以下の呼び出し流れは典型的な成功と誤り事件における、メッセージの注文を例証します。 「100 」 承認をINVITEに試みて、それらの存在が任意であるので、要求は表現されません。
In these diagrams, all call signaling (SIP, ISUP) is going to and from the MGC; media handling (e.g., audio cut-through, trunk freeing) is being performed by the MG, under the control of the MGC. For the purpose of simplicity, these are shown as a single node, labeled "MGC/MG".
これらのダイヤグラムで、すべての呼び出しシグナリング(SIP、ISUP)がMGCとMGCから行くでしょう。 メディア取り扱い(例えば、深く切られたオーディオ、トランク解放)はMGCのコントロールの下でMGによって実行されています。 簡単さの目的のために、これらは「MGC/mg」に分類されたただ一つのノードとして示されます。
Camarillo, et. al. Standards Track [Page 30] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[30ページ]。
8.1.1 En-bloc call setup (non auto-answer)
8.1.1 アン団体呼び出しセットアップ(非自動応答)です。
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |=========================>|
| |------------ACM---------->|4
5|-----------18x----------->| |
| |------------CPG---------->|6
7|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|8
| |<=========Audio==========>|
9|<----------ACK------------| |
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--IAM-----------|1 | |==========オーディオ==========>| 2| <、-、-、-、-、-、-、--招待-----------| | |-----------100----------->|、| 3|-----------18x----------->|、| |==========オーディオ==========>|、|、| |=========================>|、| |------------ACM---------->|4 5|-----------18x----------->|、|、| |------------CPG---------->|6 7|-----------200-(I)------->|、| |<=====オーディオ==========>|、|、| |------------ANM---------->|8 | |<=====オーディオ==========>| 9| <、-、-、-、-、-、-、-、-、--ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM message towards the gateway.
1. PSTNユーザがSIPユーザと共に開会したがっているとき、PSTNネットワークはIAMメッセージをゲートウェイに向かって発生させます。
2. Upon receipt of the IAM message, the gateway generates an INVITE
message, and sends it to an appropriate SIP node.
2. IAMメッセージを受け取り次第、ゲートウェイは、INVITEメッセージを発生させて、適切なSIPノードにそれを送ります。
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.
3. 呼び出しには十分なアドレス指定情報があるのを意味する出来事が起こると、SIPノードは180以上の暫定的な応答を発生させるでしょう。
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."
4. 180以上の暫定的な応答を受け取り次第、ゲートウェイはACMメッセージを発生させるでしょう。 応答が180でないなら、ACMは「指示がありません」の「被呼者状態」値を運ぶでしょう。
5. The SIP node may use further provisional messages to indicate
session progress.
5. SIPノードはセッション進歩を示すさらなる暫定的なメッセージを使用するかもしれません。
6. After an ACM has been sent, all provisional responses will
translate into ISUP CPG messages as indicated in Section 8.2.3.
6. ACMを送った後に、すべての暫定的な応答がセクション8.2.3にみられるようにISUP CPGメッセージに翻訳されるでしょう。
7. When the SIP node answers the call, it will send a 200 OK
message.
7. SIPノードが電話口に出るとき、それは200OKメッセージを送るでしょう。
8. Upon receipt of the 200 OK message, the gateway will send an ANM
message towards the ISUP node.
8. 200OKメッセージを受け取り次第、ゲートウェイはISUPノードに向かってANMメッセージを送るでしょう。
9. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
9. ゲートウェイは、INVITEの最終的な応答の領収書を受け取ったことを知らせるためにSIPノードにACKを送るでしょう。
Camarillo, et. al. Standards Track [Page 31] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[31ページ]。
8.1.2 Auto-answer call setup
8.1.2 自動応答呼び出しセットアップ
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--IAM-----------|1 | |==========オーディオ==========>| 2| <、-、-、-、-、-、-、--招待-----------| | 3|-----------200----------->|、| |<=====オーディオ==========>|、|、| |------------まやかし---------->|4 | |<=====オーディオ==========>| 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.
1. PSTNユーザがSIPユーザと共に開会したがっているとき、PSTNネットワークはIAMメッセージをゲートウェイに向かって発生させます。
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.
2. IAMメッセージを受け取り次第、ゲートウェイは、呼ばれた数の分析に基づく適切なSIPノードに、INVITEメッセージを発生させて、それを送ります。
3. Since the SIP node is set up to automatically answer the call, it
will send a 200 OK message.
3. SIPノードが自動的に電話口に出るためにセットアップされるので、それは200OKメッセージを送るでしょう。
4. Upon receipt of the 200 OK message, the gateway will send a CON
message towards the ISUP node.
4. 200OKメッセージを受け取り次第、ゲートウェイはISUPノードに向かってCONメッセージを送るでしょう。
5. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
5. ゲートウェイは、INVITEの最終的な応答の領収書を受け取ったことを知らせるためにSIPノードにACKを送るでしょう。
Camarillo, et. al. Standards Track [Page 32] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[32ページ]。
8.1.3 SIP Timeout
8.1.3 一口タイムアウト
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
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--IAM-----------|1 | |==========オーディオ==========>| 2| <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | 3| <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | | *** T11は***を吐き出します。| | |------------ACM---------->|4 | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | ** mgはPSTNトランク**をリリースします。| | |------------REL---------->|5 6| <、-、-、-、-、-、-、--キャンセル-----------| | | | <、-、-、-、-、-、-、-、-、-、--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.
1. PSTNユーザがSIPユーザと共に開会したがっているとき、PSTNネットワークはIAMメッセージをゲートウェイに向かって発生させます。
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.
2. IAMメッセージを受け取り次第、ゲートウェイは、呼ばれた数の分析に基づく適切なSIPノードに、INVITEメッセージを発生させて、それを送ります。 ISUPタイマT11とSIPタイマT1はこのとき、用意ができています。
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.
3. INVITEメッセージは、タイマT1が期限が切れるたびにSIPノードに送られ続けるでしょう。 SIP規格は、どんな応答も受け取られていないとINVITEトランスミッションが7回実行されると指定します。
Camarillo, et. al. Standards Track [Page 33] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[33ページ]。
4. When T11 expires, an ACM message will be sent to the ISUP node to
prevent the call from being torn down by the remote node's ISUP
T7. This ACM contains a 'Called Party Status' value of 'no
indication.'
4. T11が期限が切れるとき、呼び出しが遠隔ノードのISUP T7によって取りこわされるのを防ぐためにACMメッセージをISUPノードに送るでしょう。 このACMは'指示がありません'の'呼ばれたパーティStatus'値を含んでいます。
5. Once the maximum number of INVITE requests has been sent, the
gateway will send a REL (cause code 18) to the ISUP node to
terminate the call.
5. いったんINVITE要求の最大数を送ると、ゲートウェイは、呼び出しを終えるために、REL(原因コード18)をISUPノードに送るでしょう。
6. The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.
6. また、ゲートウェイは、どんな開始試みも終えるためにキャンセルメッセージをSIPノードに送ります。
7. Upon receipt of the REL, the remote ISUP node will send an RLC to
acknowledge.
7. REL、ノードが承認するためにRLCを送るリモートISUPを受け取り次第。
8.1.4 ISUP T9 Expires
8.1.4 ISUP T9は期限が切れます。
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-----------| |
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--IAM-----------|1 | |==========オーディオ==========>| 2| <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | 3| <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | | *** T11は***を吐き出します。| | |------------ACM---------->|4 | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | *** T1は***を吐き出します。| | | <、-、-、-、-、-、-、--招待-----------| | | | *** T9は***を吐き出します。| | ** mgはPSTNトランク**をリリースします。| | | <、-、-、-、-、-、-、-、-、-、--REL-----------|5 | |------------RLC---------->|6 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.
1. PSTNユーザがSIPユーザと共に開会したがっているとき、PSTNネットワークはIAMメッセージをゲートウェイに向かって発生させます。
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.
2. IAMメッセージを受け取り次第、ゲートウェイは、呼ばれた数の分析に基づく適切なSIPノードに、INVITEメッセージを発生させて、それを送ります。 ISUPタイマT11とSIPタイマT1はこのとき、用意ができています。
Camarillo, et. al. Standards Track [Page 34] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[34ページ]。
3. The INVITE message will continue to be sent to the SIP node each
time the timer T1 expires. The SIP standard specifies that
INVITE transmission will be performed 7 times if no response is
received. Since SIP T1 starts at 1/2 second or more and doubles
each time it is retransmitted, it will be at least a minute
before SIP times out the INVITE request; since SIP T1 is allowed
to be larger than 500 ms initially, it is possible that 7 x SIP
T1 will be longer than ISUP T11 + ISUP T9.
3. INVITEメッセージは、タイマT1が期限が切れるたびにSIPノードに送られ続けるでしょう。 SIP規格は、どんな応答も受け取られていないとINVITEトランスミッションが7回実行されると指定します。 SIP T1が1/2秒以上に始まって、それが再送されるたびに倍増するので、INVITE要求からのSIP回少なくとも1分前になるでしょう。 SIP T1が初めは500msより大きいのが許容されているので、7x SIP T1がISUP T11+ISUP T9よりさらに長くなるのは、可能です。
4. When T11 expires, an ACM message will be sent to the ISUP node to
prevent the call from being torn down by the remote node's ISUP
T7. This ACM contains a 'Called Party Status' value of 'no
indication.'
4. T11が期限が切れるとき、呼び出しが遠隔ノードのISUP T7によって取りこわされるのを防ぐためにACMメッセージをISUPノードに送るでしょう。 このACMは'指示がありません'の'呼ばれたパーティStatus'値を含んでいます。
5. When ISUP T9 in the remote PSTN node expires, it will send a REL.
5. リモートPSTNノードのISUP T9が期限が切れると、それはRELを送るでしょう。
6. Upon receipt of the REL, the gateway will send an RLC to
acknowledge.
6. REL、意志が承認するためにRLCを送るゲートウェイを受け取り次第。
7. The REL will trigger a CANCEL request, which gets sent to the SIP
node.
7. RELはキャンセル要求の引き金となるでしょう。(それは、SIPノードに送られます)。
8.1.5 SIP Error Response
8.1.5 一口誤り応答
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--IAM-----------|1 | |==========オーディオ==========>| 2| <、-、-、-、-、-、-、--招待-----------| | 3|-----------4xx+---------->|、| 4| <、-、-、-、-、-、-、-、-、--ACK------------| | | ** mgはPSTNトランク**をリリースします。| | |------------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.
1. PSTNユーザがSIPユーザと共に開会したがっているとき、PSTNネットワークはIAMメッセージをゲートウェイに向かって発生させます。
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.
2. IAMメッセージを受け取り次第、ゲートウェイは、呼ばれた数の分析に基づく適切なSIPノードに、INVITEメッセージを発生させて、それを送ります。
3. The SIP node indicates an error condition by replying with a
response with a code of 400 or greater.
3. SIPノードは、400以上のコードで応答で返答することによって、エラー条件を示します。
4. The gateway sends an ACK message to acknowledge receipt of the
INVITE final response.
4. ゲートウェイはINVITEの最終的な応答の領収書を受け取ったことを知らせるACKメッセージを送ります。
Camarillo, et. al. Standards Track [Page 35] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[35ページ]。
5. An ISUP REL message is generated from the SIP code, as specified
in Section 8.2.6.1.
5. ISUP RELメッセージはセクション8.2.6で.1に指定されるようにSIPコードから発生します。
6. The remote ISUP node confirms receipt of the REL message with an
RLC message.
6. リモートISUPノードはRLCメッセージがあるRELメッセージの領収書を確認します。
8.1.6 SIP Redirection
8.1.6 一口リダイレクション
SIP node 1 MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------3xx+---------->| |
| |------------CPG---------->|4
5|<----------ACK------------| |
| |
| |
SIP node 2 | |
6|<--------INVITE-----------| |
7|-----------18x----------->| |
|<=========Audio===========| |
| |------------ACM---------->|8
9|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|10
| |<=========Audio==========>|
11|<----------ACK------------| |
SIPノード1MGC/MG PSTN| | <、-、-、-、-、-、-、-、-、-、--IAM-----------|1 | |==========オーディオ==========>| 2| <、-、-、-、-、-、-、--招待-----------| | 3|-----------3xx+---------->|、|、| |------------CPG---------->|4 5| <、-、-、-、-、-、-、-、-、--ACK------------| | | | | | SIPノード2| | 6| <、-、-、-、-、-、-、--招待-----------| | 7|-----------18x----------->|、| |<=====オーディオ===========| | | |------------ACM---------->|8 9|-----------200-(I)------->|、| |<=====オーディオ==========>|、|、| |------------ANM---------->|10 | |<=====オーディオ==========>| 11| <、-、-、-、-、-、-、-、-、--ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM message towards the gateway.
1. PSTNユーザがSIPユーザと共に開会したがっているとき、PSTNネットワークはIAMメッセージをゲートウェイに向かって発生させます。
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.
2. IAMメッセージを受け取り次第、ゲートウェイは、呼ばれた数の分析に基づく適切なSIPノードに、INVITEメッセージを発生させて、それを送ります。
3. The SIP node indicates that the resource which the user is
attempting to contact is at a different location by sending a 3xx
message. In this instance we assume the Contact URL specifies a
valid URL reachable by a VoIP SIP call.
3. SIPノードは、ユーザが連絡するのを試みているリソースが別の場所に3xxメッセージを送ることによってあるのを示します。 この場合私たちは、Contact URLがVoIP SIP呼び出しで届いている有効なURLを指定すると思います。
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.
4. ゲートウェイは3xxメッセージを受け取り次第呼び出しを進めているというイベント指示と共にCPGを送ります。 構成がこの翻訳が無能にすることができるべきであることに注意してください、いくつかのISUPノードがACMメッセージの前にCPGメッセージの領収書を支えないとき。
5. The gateway acknowledges receipt of the INVITE final response by
sending an ACK message to the SIP node.
5. ゲートウェイは、ACKメッセージをSIPノードに送ることによって、INVITEの最終的な応答の領収書を受け取ったことを知らせます。
Camarillo, et. al. Standards Track [Page 36] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[36ページ]。
6. The gateway re-sends the INVITE message to the address indicated
in the Contact: field of the 3xx message.
6. ゲートウェイはContactで示されたアドレスにINVITEメッセージを再送します: 3xxメッセージの分野。
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.
7. 呼び出しには十分なアドレス指定情報があるのを意味する出来事が起こると、SIPノードは180以上の暫定的な応答を発生させるでしょう。
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 8.2.3.
8. 180以上の暫定的な応答を受け取り次第、ゲートウェイはセクション8.2.3にみられるようにイベントコードでACMメッセージを発生させるでしょう。
9. When the SIP node answers the call, it will send a 200 OK
message.
9. SIPノードが電話口に出るとき、それは200OKメッセージを送るでしょう。
10. Upon receipt of the 200 OK message, the gateway will send an ANM
message towards the ISUP node.
10. 200OKメッセージを受け取り次第、ゲートウェイはISUPノードに向かってANMメッセージを送るでしょう。
11. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
11. ゲートウェイは、INVITEの最終的な応答の領収書を受け取ったことを知らせるためにSIPノードにACKを送るでしょう。
8.1.7 Call Canceled by ISUP
8.1.7 ISUPによって中止された呼び出し
SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
9|-----------487----------->| |
10|<----------ACK------------| |
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--IAM-----------|1 | |==========オーディオ==========>| 2| <、-、-、-、-、-、-、--招待-----------| | 3|-----------18x----------->|、| |==========オーディオ==========>|、|、| |------------ACM---------->|4 | ** mgはPSTNトランク**をリリースします。| | | <、-、-、-、-、-、-、-、-、-、--REL-----------|5 | |------------RLC---------->|6 7| <、-、-、-、-、-、-、-、--キャンセル----------| | | ** mgはIPリソース**をリリースします。| 8|-----------200----------->|、| 9|-----------487----------->|、| 10| <、-、-、-、-、-、-、-、-、--ACK------------| |
1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM message towards the gateway.
1. PSTNユーザがSIPユーザと共に開会したがっているとき、PSTNネットワークはIAMメッセージをゲートウェイに向かって発生させます。
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.
2. IAMメッセージを受け取り次第、ゲートウェイは、呼ばれた数の分析に基づく適切なSIPノードに、INVITEメッセージを発生させて、それを送ります。
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.
3. 呼び出しには十分なアドレス指定情報があるのを意味する出来事が起こると、SIPノードは180以上の暫定的な応答を発生させるでしょう。
Camarillo, et. al. Standards Track [Page 37] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[37ページ]。
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 8.2.3.
4. 180以上の暫定的な応答を受け取り次第、ゲートウェイはセクション8.2.3にみられるようにイベントコードでACMメッセージを発生させるでしょう。
5. If the calling party hangs up before the SIP node answers the
call, a REL message will be generated.
5. SIPノードが電話口に出る前に起呼側がハングアップすると、RELメッセージは発生するでしょう。
6. The gateway frees the PSTN circuit and indicates that it is
available for reuse by sending an RLC.
6. ゲートウェイは、PSTNサーキットを解放して、それがRLCを送ることによって再利用に利用可能であることを示します。
7. Upon receipt of a REL message before an INVITE final response,
the gateway will send a CANCEL towards the SIP node.
7. INVITEの最終的な応答の前のRELメッセージを受け取り次第、ゲートウェイはSIPノードに向かってキャンセルを送るでしょう。
8. Upon receipt of the CANCEL, the SIP node will send a 200
response.
8. キャンセルを受け取り次第、SIPノードは200応答を送るでしょう。
9. The remote SIP node will send a "487 Call Cancelled" to complete
the INVITE transaction.
9. リモートSIPノードは、INVITE取引を完了するために「中止された487呼び出し」を送るでしょう。
10. The gateway will send an ACK to the SIP node to acknowledge
receipt of the INVITE final response.
10. ゲートウェイは、INVITEの最終的な応答の領収書を受け取ったことを知らせるためにSIPノードにACKを送るでしょう。
Camarillo, et. al. Standards Track [Page 38] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[38ページ]。
8.2 State Machine
8.2 州のマシン
Note that REL may arrive in any state. Whenever this occurs, the actions in section Section 8.2.7. are taken. Not all of these transitions are shown in this diagram.
RELがどんな状態にも到着するかもしれないことに注意してください。 これが起こるときはいつも、セクションセクション8.2.7における行動を取ります。 これらの変遷のすべてがこのダイヤグラムで示されるというわけではありません。
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | IAM/7.2.1 |
| V |
| REL/7.2.7 +-------------------------+ 400+/7.2.6 |
+<----------------+ Trying |------------>|
| +-+--------+------+-------+ |
| | | | |
| | T11/ | 18x/ | 200/ |
| | 7.2.8 |7.2.3 | 7.2.4 |
| V | | |
| REL/7.2.7 +--------------+ | | 400+/7.2.6 |
|<----------| Progressing |-|------|-------------------->|
| +--+----+------+ | | |
| | | | | |
| 200/ | | 18x/ | | |
| 7.2.4 | | 7.2.3 | | |
| | V V | |
| REL/7.2.7 | +---------------+ | 400+/7.2.6 |
|<-------------|--| Alerting |-|-------------------->|
| | +--------+------+ | |
| | | | |
| | | 200/ | |
| | | 7.2.4 | |
| V V V |
| BYE/9.1 +-----------------------------+ REL/9.2 |
+<------------+ Connected +------------>+
+-----------------------------+
+---------+ +----------------------->| 怠けてください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | +----+----+ | | | | | | IAM/7.2.1| | V| | REL/7.2.7+-------------------------+ 400+/7.2.6 | + <。----------------+ トライ|、-、-、-、-、-、-、-、-、-、-、--、>|、| +-+--------+------+-------+ | | | | | | | | T11/| 18x/| 200/ | | | 7.2.8 |7.2.3 | 7.2.4 | | V| | | | REL/7.2.7+--------------+ | | 400+/7.2.6 | | <、-、-、-、-、-、-、-、-、--、| 進歩をします。|、-、|、-、-、-、-、--、|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| +--+----+------+ | | | | | | | | | | 200/ | | 18x/| | | | 7.2.4 | | 7.2.3 | | | | | V V| | | REL/7.2.7| +---------------+ | 400+/7.2.6 | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、--、| 警告|、-、|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| +--------+------+ | | | | | | | | | | 200/ | | | | | 7.2.4 | | | V V V| | さようなら/9.1+-----------------------------+ REL/9.2| + <。------------+ 接続+------------>++-----------------------------+
8.2.1 Initial Address Message received
8.2.1 初期のAddress Messageは受信しました。
Upon receipt of an IAM, the gateway SHOULD reserve appropriate internal resources (Digital Signal Processors - DSPs - and the like) necessary for handling the IP side of the call. It MAY make any necessary preparations to connect audio in the backwards direction (towards the caller).
IAMを受け取り次第、ゲートウェイSHOULDは呼び出しのIP側を扱うのに必要な適切な社内資源(デジタルシグナルプロセッサ(DSPs)と同様のもの)を予約します。 それは、遅れている方向(訪問者に向かった)にオーディオを接続するためにどんな必要な準備もするかもしれません。
Camarillo, et. al. Standards Track [Page 39] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[39ページ]。
8.2.1.1 IAM to INVITE procedures
8.2.1.1 INVITE手順へのIAM
When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message MUST be created for transmission to the SIP network. This section details the process by which a gateway populates the fields of the INVITE based on parameters found within the IAM.
IAMがPSTN-SIPゲートウェイに到着するとき、SIPネットワークへの伝送のためSIP INVITEメッセージを作成しなければなりません。 このセクションはゲートウェイがIAMの中で見つけられたパラメタに基づくINVITEの分野に居住する過程を詳しく述べます。
The context of the call setup request read by the gateway in the IAM will be mapped primarily to two URIs in the INVITE, one representing the originator of the session and the other its destination. The former will always appear in the From header (after it has been converted from ISUP format by the procedure described in Section 12), and the latter is almost always used for both the To header and the Request-URI.
IAMでゲートウェイによって読まれた呼び出しセットアップ要求の文脈はセッションの創始者の代理をしながら、主としてINVITE、1の2つのURIに写像されるでしょう、そして、目的地はもう片方が写像されます。 前者はFromヘッダーにいつも現れるでしょう、そして、(それがISUP形式からセクション12で説明された手順で変換された後に)後者はToヘッダーとRequest-URIの両方にほとんどいつも使用されます。
Once the address of the called party number has been read from the IAM, it SHOULD be translated into a destination tel URL that will serve as the Request-URI of the INVITE. Alternatively, a gateway MAY first attempt a Telephone Number Mapping (ENUM) [8] query to resolve the called party number to a URI. Some additional ISUP fields MAY be added to the tel URL after translation has been completed, namely:
かつて、IAMから被呼者番号のアドレスを読んであって、それはSHOULDです。INVITEのRequest-URIとして機能する目的地tel URLに翻訳されてください。 あるいはまた、ゲートウェイは、最初に、被呼者番号をURIに決議するためにTelephone Number Mapping(ENUM)[8]質問を試みるかもしれません。 翻訳が終了した後にいくつかの追加ISUP分野がtel URLに追加されるかもしれない、すなわち:
o If the gateway supports carrier-based routing (which is optional
in this specification), it SHOULD ascertain if either the CIP (in
ANSI networks) or TNS parameter is present in the IAM. If a value
is present, the CIC SHOULD be extracted from the given parameter
and analyzed by the gateway. A 'cic=' field with the value of the
CIC SHOULD be appended to the destination tel URL, if doing so is
in keeping with local policy (i.e., provided that the CIC does not
indicate the network which owns the gateway or some similar
condition). Note that if it is created, the 'cic=' parameter MUST
be prefixed with the country code used or implied in the called
party number, so that CIC '5062' becomes, in the United States,
'+1-5062'. For further information on the 'cic=' tel URL field
see [21].
o If the gateway supports carrier-based routing (which is optional in this specification), it SHOULD ascertain if either the CIP (in ANSI networks) or TNS parameter is present in the IAM. If a value is present, the CIC SHOULD be extracted from the given parameter and analyzed by the gateway. A 'cic=' field with the value of the CIC SHOULD be appended to the destination tel URL, if doing so is in keeping with local policy (i.e., provided that the CIC does not indicate the network which owns the gateway or some similar condition). Note that if it is created, the 'cic=' parameter MUST be prefixed with the country code used or implied in the called party number, so that CIC '5062' becomes, in the United States, '+1-5062'. For further information on the 'cic=' tel URL field see [21].
o If the gateway supports number portability-based routing (which is
optional in this specification), then the gateway will need to
look at a few other fields. To correctly map the FCI 'number
translated' bit indicating that an LNP dip had been performed in
the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL.
If a GAP is present in the IAM, then the contents of the CPN (the
Location Routing Number - LRN) SHOULD be translated from ISUP
format (as described in Section 12) and copied into an 'rn=' field
which must be appended to the tel URL, whereas the GAP itself
should be translated to ISUP format and used to populate the
primary telephone number field of the tel URL. Note that in some
national numbering plans, both the LRN and the dialed number may
o If the gateway supports number portability-based routing (which is optional in this specification), then the gateway will need to look at a few other fields. To correctly map the FCI 'number translated' bit indicating that an LNP dip had been performed in the PSTN, an 'npdi=yes' field SHOULD be appended to the tel URL. If a GAP is present in the IAM, then the contents of the CPN (the Location Routing Number - LRN) SHOULD be translated from ISUP format (as described in Section 12) and copied into an 'rn=' field which must be appended to the tel URL, whereas the GAP itself should be translated to ISUP format and used to populate the primary telephone number field of the tel URL. Note that in some national numbering plans, both the LRN and the dialed number may
Camarillo, et. al. Standards Track [Page 40] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 40] RFC 3398 ISUP to SIP Mapping December 2002
be stored in the CPN parameter, in which case they must be
separated out into different fields to be stored in the tel URL.
Note that LRNs are necessarily national in scope, and consequently
they MUST NOT be preceded by a '+' in the 'rn=' field. For
further information on these tel URL fields see [21].
be stored in the CPN parameter, in which case they must be separated out into different fields to be stored in the tel URL. Note that LRNs are necessarily national in scope, and consequently they MUST NOT be preceded by a '+' in the 'rn=' field. For further information on these tel URL fields see [21].
In most cases, the resulting destination tel URL SHOULD be used in both the To field and Request-URI sent by the gateway. However, if the OCN parameter is present in the IAM, the To field SHOULD be constructed from the translation (from ISUP format following Section 12 of the OCN parameter, and hence the Request-URI and To field MAY be different.
In most cases, the resulting destination tel URL SHOULD be used in both the To field and Request-URI sent by the gateway. However, if the OCN parameter is present in the IAM, the To field SHOULD be constructed from the translation (from ISUP format following Section 12 of the OCN parameter, and hence the Request-URI and To field MAY be different.
The construction of the From header field is dependent on the presence of a CIN parameter. If the CIN is not present, then the gateway SHOULD create a dummy From header field containing a SIP URI without a user portion which communicates only the hostname of the gateway (e.g., 'sip:gw.sipcarrier.com). If the CIN is available, then it SHOULD be translated (in accordance with the procedure described above) into a tel URL which should populate the From header field. In either case, local policy or requests for presentation restriction (see Section 12.1) MAY result in a different value for the From header field.
The construction of the From header field is dependent on the presence of a CIN parameter. If the CIN is not present, then the gateway SHOULD create a dummy From header field containing a SIP URI without a user portion which communicates only the hostname of the gateway (e.g., 'sip:gw.sipcarrier.com). If the CIN is available, then it SHOULD be translated (in accordance with the procedure described above) into a tel URL which should populate the From header field. In either case, local policy or requests for presentation restriction (see Section 12.1) MAY result in a different value for the From header field.
8.2.2 100 received
8.2.2 100 received
A 100 response SHOULD NOT trigger any PSTN interworking messages; it only serves the purpose of suppressing INVITE retransmissions.
A 100 response SHOULD NOT trigger any PSTN interworking messages; it only serves the purpose of suppressing INVITE retransmissions.
8.2.3 18x received
8.2.3 18x received
Upon receipt of a 18x provisional response, if no ACM has been sent and no legitimate and comprehensible ISUP is present in the 18x message body, then the ISUP message SHOULD be generated according to the following table. Note that if an early ACM is sent, the call MUST enter state "Progressing" instead of state "Alerting."
Upon receipt of a 18x provisional response, if no ACM has been sent and no legitimate and comprehensible ISUP is present in the 18x message body, then the ISUP message SHOULD be generated according to the following table. Note that if an early ACM is sent, the call MUST enter state "Progressing" instead of state "Alerting."
Response received Message sent by the MGC ----------------- ----------------------- 180 Ringing ACM (BCI = subscriber free) 181 Call is being forwarded Early ACM and CPG, event=6 182 Queued ACM (BCI = no indication) 183 Session progress message ACM (BCI = no indication)
Response received Message sent by the MGC ----------------- ----------------------- 180 Ringing ACM (BCI = subscriber free) 181 Call is being forwarded Early ACM and CPG, event=6 182 Queued ACM (BCI = no indication) 183 Session progress message ACM (BCI = no indication)
Camarillo, et. al. Standards Track [Page 41] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 41] RFC 3398 ISUP to SIP Mapping December 2002
If an ACM has already been sent and no ISUP is present in the 18x message body, an ISUP message SHOULD be generated according to the following table.
If an ACM has already been sent and no ISUP is present in the 18x message body, an ISUP message SHOULD be generated according to the following table.
Response received Message sent by the MGC ----------------- ----------------------- 180 Ringing CPG, event = 1 (Alerting) 181 Call is being forwarded CPG, event = 6 (Forwarding) 182 Queued CPG, event = 2 (Progress) 183 Session progress message CPG, event = 2 (Progress)
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)
Upon receipt of a 180 response, the gateway SHOULD generate the ringback tone to be heard by the caller on the PSTN side (unless the gateway knows that ringback will be provided by the network on the PSTN side).
Upon receipt of a 180 response, the gateway SHOULD generate the ringback tone to be heard by the caller on the PSTN side (unless the gateway knows that ringback will be provided by the network on the PSTN side).
Note however that a gateway might receive media at any time after it has transmitted an SDP offer that it has sent in an INVITE, even before a 18x provisional response is received. Therefore the gateway MUST be prepared to play this media to the caller on the PSTN side (if necessary, ceasing any ringback tone that it may have begun to generate and then playing media). Note that the gateway may also receive SDP offers in responses for an early media session using some SIP extension, see Section 5.5. If a gateway receives a 183 response while it is playing backwards media, then when it generates a mapping for this response, if no encapsulated ISUP is present, the gateway SHOULD indicate that in-band information is available (for example, with the Event Information parameter of the CPG message or the Optional Backward Call Indicators parameter of the ACM).
Note however that a gateway might receive media at any time after it has transmitted an SDP offer that it has sent in an INVITE, even before a 18x provisional response is received. Therefore the gateway MUST be prepared to play this media to the caller on the PSTN side (if necessary, ceasing any ringback tone that it may have begun to generate and then playing media). Note that the gateway may also receive SDP offers in responses for an early media session using some SIP extension, see Section 5.5. If a gateway receives a 183 response while it is playing backwards media, then when it generates a mapping for this response, if no encapsulated ISUP is present, the gateway SHOULD indicate that in-band information is available (for example, with the Event Information parameter of the CPG message or the Optional Backward Call Indicators parameter of the ACM).
When an ACM is sent, the mandatory Backward Call Indicators parameter must be set, as well as any optional parameters as gateway policy dictates. If legitimate and comprehensible ISUP is present in the 18x response, the gateway SHOULD re-use the appropriate parameters of the ISUP message contained in the response body, including the value of the Backward Call Indicator parameter, as it formulates a message that it will send across its PSTN interface. In the absence of a usable encapsulated ACM, the BCI parameter SHOULD be set as follows:
When an ACM is sent, the mandatory Backward Call Indicators parameter must be set, as well as any optional parameters as gateway policy dictates. If legitimate and comprehensible ISUP is present in the 18x response, the gateway SHOULD re-use the appropriate parameters of the ISUP message contained in the response body, including the value of the Backward Call Indicator parameter, as it formulates a message that it will send across its PSTN interface. In the absence of a usable encapsulated ACM, the BCI parameter SHOULD be set as follows:
Camarillo, et. al. Standards Track [Page 42] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 42] RFC 3398 ISUP to SIP Mapping December 2002
Message type: ACM
Message type: ACM
Backward Call Indicators
Charge indicator: 10 charge
Called party's status indicator: 01 subscriber free or
00 no indication
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 used all the way
Holding indicator: 0 no holding
ISDN access indicator: 0 No ISDN access
Echo control device indicator: It depends on the call
SCCP method indicator: 00 no indication
Backward Call Indicators Charge indicator: 10 charge Called party's status indicator: 01 subscriber free or 00 no indication 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 used all the way Holding indicator: 0 no holding ISDN access indicator: 0 No ISDN access Echo control device indicator: It depends on the call SCCP method indicator: 00 no indication
Note that when the ISUP Backward Call Indicator parameter Interworking indicator field is set to 'interworking encountered', this indicates that ISDN is interworking with a network which is not capable of providing as many services as ISDN does. ISUP therefore may not employ certain features it otherwise normally uses. Gateway vendors MAY however provide a configurable option, usable at the discretion of service providers when they require additional ISUP services, that in the absence of encapsulated ISUP will signal in the BCI that interworking has been encountered, and that ISUP is not used all the way, for those operators that as a matter of policy would rather operate in this mode. For more information on the effects of interworking see Section 7.2.1.1.
Note that when the ISUP Backward Call Indicator parameter Interworking indicator field is set to 'interworking encountered', this indicates that ISDN is interworking with a network which is not capable of providing as many services as ISDN does. ISUP therefore may not employ certain features it otherwise normally uses. Gateway vendors MAY however provide a configurable option, usable at the discretion of service providers when they require additional ISUP services, that in the absence of encapsulated ISUP will signal in the BCI that interworking has been encountered, and that ISUP is not used all the way, for those operators that as a matter of policy would rather operate in this mode. For more information on the effects of interworking see Section 7.2.1.1.
8.2.4 2xx received
8.2.4 2xx received
Response received Message sent by the MGC ----------------- ----------------------- 200 OK ANM, ACK
Response received Message sent by the MGC ----------------- ----------------------- 200 OK ANM, ACK
After receiving a 200 OK response the gateway MUST establish a directional media path in the gateway and send an ANM to the PSTN as well as an ACK to the SIP network.
After receiving a 200 OK response the gateway MUST establish a directional media path in the gateway and send an ANM to the PSTN as well as an ACK to the SIP network.
If the 200 OK response arrives before the gateway has sent an ACM, a CON is sent instead of the ANM, in those ISUP variants that support the CON message.
If the 200 OK response arrives before the gateway has sent an ACM, a CON is sent instead of the ANM, in those ISUP variants that support the CON message.
When a legitimate and comprehensible ANM is encapsulated in the 200 OK response, the gateway SHOULD re-use any relevant ISUP parameters in the ANM it sends to the PSTN.
When a legitimate and comprehensible ANM is encapsulated in the 200 OK response, the gateway SHOULD re-use any relevant ISUP parameters in the ANM it sends to the PSTN.
Camarillo, et. al. Standards Track [Page 43] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 43] RFC 3398 ISUP to SIP Mapping December 2002
Note that gateways may sometimes receive 200 OK responses for requests other than INVITE (for example, those used in managing provisional responses, or the INFO method). The procedures described in this section apply only to 200 OK responses received as a result of sending an INVITE. The gateway SHOULD NOT send any PSTN messages if it receives a 200 OK in response to non-INVITE requests it has sent.
Note that gateways may sometimes receive 200 OK responses for requests other than INVITE (for example, those used in managing provisional responses, or the INFO method). The procedures described in this section apply only to 200 OK responses received as a result of sending an INVITE. The gateway SHOULD NOT send any PSTN messages if it receives a 200 OK in response to non-INVITE requests it has sent.
8.2.5 3xx Received
8.2.5 3xx Received
When any 3xx response (a redirection) is received, the gateway SHOULD try to reach the destination by sending one or more new call setup requests using URIs found in any Contact header field(s) present in the response, as is mandated in the base SIP specification. Such 3xx responses are typically sent by a redirect server, and can be thought of as similar to a location register in mobile PSTN networks.
When any 3xx response (a redirection) is received, the gateway SHOULD try to reach the destination by sending one or more new call setup requests using URIs found in any Contact header field(s) present in the response, as is mandated in the base SIP specification. Such 3xx responses are typically sent by a redirect server, and can be thought of as similar to a location register in mobile PSTN networks.
If a particular URI presented in the Contact header of a 3xx is best reachable (according to the gateway's routing policies) via the PSTN, the gateway SHOULD send a new IAM and from that moment on act as a normal PSTN switch (no SIP involved) - usually this will be the case when the URI in the Contact header is a tel URL, one that the gateway cannot reach locally and one for which there is no ENUM mapping.
If a particular URI presented in the Contact header of a 3xx is best reachable (according to the gateway's routing policies) via the PSTN, the gateway SHOULD send a new IAM and from that moment on act as a normal PSTN switch (no SIP involved) - usually this will be the case when the URI in the Contact header is a tel URL, one that the gateway cannot reach locally and one for which there is no ENUM mapping.
Alternatively, the gateway MAY send a REL message to the PSTN with a redirection indicator (23) and a diagnostic field corresponding to the telephone number in the URI. If, however, the new location is best reachable using SIP (if the URI in the Contact header contains no telephone number at all), the MGC SHOULD send a new INVITE with a Request-URI possibly a new IAM generated by the MGC in the message body.
Alternatively, the gateway MAY send a REL message to the PSTN with a redirection indicator (23) and a diagnostic field corresponding to the telephone number in the URI. If, however, the new location is best reachable using SIP (if the URI in the Contact header contains no telephone number at all), the MGC SHOULD send a new INVITE with a Request-URI possibly a new IAM generated by the MGC in the message body.
While it is exploring a long list of Contact header fields with SIP requests, a gateway MAY send a CPG message with an event code of 6 (Forwarding) to the PSTN in order to indicate that the call is proceeding (where permitted by the ISUP variant in question).
While it is exploring a long list of Contact header fields with SIP requests, a gateway MAY send a CPG message with an event code of 6 (Forwarding) to the PSTN in order to indicate that the call is proceeding (where permitted by the ISUP variant in question).
All redirection situations have to be treated very carefully because they involved special charging situations. In PSTN the caller typically pays for the first leg (to the gateway) and the callee pays the second (from the forwarding switch to the destination).
All redirection situations have to be treated very carefully because they involved special charging situations. In PSTN the caller typically pays for the first leg (to the gateway) and the callee pays the second (from the forwarding switch to the destination).
8.2.6 4xx-6xx Received
8.2.6 4xx-6xx Received
When a response code of 400 or greater is received by the gateway, then the INVITE previously sent by the gateway has been rejected. Under most circumstances the gateway SHOULD release the resources in the gateway, send a REL to the PSTN with a cause value and send an
When a response code of 400 or greater is received by the gateway, then the INVITE previously sent by the gateway has been rejected. Under most circumstances the gateway SHOULD release the resources in the gateway, send a REL to the PSTN with a cause value and send an
Camarillo, et. al. Standards Track [Page 44] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 44] RFC 3398 ISUP to SIP Mapping December 2002
ACK to the SIP network. Some specific circumstances are identified below in which a gateway MAY attempt to rectify a SIP-specific problem communicated by a status code without releasing the call by retrying the request. When a REL is sent to the PSTN, the gateway expects the arrival of an RLC indicating that the release sequence is complete.
ACK to the SIP network. Some specific circumstances are identified below in which a gateway MAY attempt to rectify a SIP-specific problem communicated by a status code without releasing the call by retrying the request. When a REL is sent to the PSTN, the gateway expects the arrival of an RLC indicating that the release sequence is complete.
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping
8.2.6.1 SIP Status Code to ISDN Cause Code Mapping
When a REL message is generated due to a SIP rejection response that contains an encapsulated REL message, the Cause Indicator (CAI) parameter in the generated REL SHOULD be set to the value of the CAI parameter received in the encapsulated REL. If no encapsulated ISUP is present, the mapping below between status code and cause codes are RECOMMENDED.
When a REL message is generated due to a SIP rejection response that contains an encapsulated REL message, the Cause Indicator (CAI) parameter in the generated REL SHOULD be set to the value of the CAI parameter received in the encapsulated REL. If no encapsulated ISUP is present, the mapping below between status code and cause codes are RECOMMENDED.
Any SIP status codes not listed below (associated with SIP extensions, versions of SIP subsequent to the issue of this document, or simply omitted) should be mapping to cause code 31 "Normal, unspecified". These mappings cover only responses; note that the BYE and CANCEL requests, which are also used to tear down a dialog, SHOULD be mapped to 16 "Normal clearing" under most circumstances (although see Section 5.8).
Any SIP status codes not listed below (associated with SIP extensions, versions of SIP subsequent to the issue of this document, or simply omitted) should be mapping to cause code 31 "Normal, unspecified". These mappings cover only responses; note that the BYE and CANCEL requests, which are also used to tear down a dialog, SHOULD be mapped to 16 "Normal clearing" under most circumstances (although see Section 5.8).
By default, the cause location associated with the CAI parameter should be encoded such that 6xx codes are given the location 'user', whereas 4xx and 5xx codes are given a 'network' location. Exceptions are marked below.
By default, the cause location associated with the CAI parameter should be encoded such that 6xx codes are given the location 'user', whereas 4xx and 5xx codes are given a 'network' location. Exceptions are marked below.
Camarillo, et. al. Standards Track [Page 45] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 45] RFC 3398 ISUP to SIP Mapping December 2002
Just as there are certain ISDN cause codes that are ISUP-specific and have no corollary SIP action, so there are SIP status codes that should not simply be translated to ISUP - some SIP-specific action should be attempted first. See the note on the (+) tag below.
Just as there are certain ISDN cause codes that are ISUP-specific and have no corollary SIP action, so there are SIP status codes that should not simply be translated to ISUP - some SIP-specific action should be attempted first. See the note on the (+) tag below.
Response received Cause value in the REL
----------------- ----------------------
400 Bad Request 41 Temporary Failure
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option
unavailable
406 Not acceptable 79 Service/option not
implemented (+)
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed
(w/o diagnostic)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not
implemented (+)
416 Unsupported URI Scheme 127 Interworking (+)
420 Bad extension 127 Interworking (+)
421 Extension Required 127 Interworking (+)
423 Interval Too Brief 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
481 Call/Transaction Does not Exist 41 Temporary Failure
482 Loop Detected 25 Exchange - routing error
483 Too many hops 25 Exchange - routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
487 Request Terminated --- (no mapping)
488 Not Acceptable here --- by Warning header
500 Server internal error 41 Temporary failure
501 Not implemented 79 Not implemented, unspecified
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Server time-out 102 Recovery on timer expiry
504 Version Not Supported 127 Interworking (+)
513 Message Too Large 127 Interworking (+)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable --- by Warning header
Response received Cause value in the REL ----------------- ---------------------- 400 Bad Request 41 Temporary Failure 401 Unauthorized 21 Call rejected (*) 402 Payment required 21 Call rejected 403 Forbidden 21 Call rejected 404 Not found 1 Unallocated number 405 Method not allowed 63 Service or option unavailable 406 Not acceptable 79 Service/option not implemented (+) 407 Proxy authentication required 21 Call rejected (*) 408 Request timeout 102 Recovery on timer expiry 410 Gone 22 Number changed (w/o diagnostic) 413 Request Entity too long 127 Interworking (+) 414 Request-URI too long 127 Interworking (+) 415 Unsupported media type 79 Service/option not implemented (+) 416 Unsupported URI Scheme 127 Interworking (+) 420 Bad extension 127 Interworking (+) 421 Extension Required 127 Interworking (+) 423 Interval Too Brief 127 Interworking (+) 480 Temporarily unavailable 18 No user responding 481 Call/Transaction Does not Exist 41 Temporary Failure 482 Loop Detected 25 Exchange - routing error 483 Too many hops 25 Exchange - routing error 484 Address incomplete 28 Invalid Number Format (+) 485 Ambiguous 1 Unallocated number 486 Busy here 17 User busy 487 Request Terminated --- (no mapping) 488 Not Acceptable here --- by Warning header 500 Server internal error 41 Temporary failure 501 Not implemented 79 Not implemented, unspecified 502 Bad gateway 38 Network out of order 503 Service unavailable 41 Temporary failure 504 Server time-out 102 Recovery on timer expiry 504 Version Not Supported 127 Interworking (+) 513 Message Too Large 127 Interworking (+) 600 Busy everywhere 17 User busy 603 Decline 21 Call rejected 604 Does not exist anywhere 1 Unallocated number 606 Not acceptable --- by Warning header
Camarillo, et. al. Standards Track [Page 46] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 46] RFC 3398 ISUP to SIP Mapping December 2002
(*) In some cases, it may be possible for a SIP gateway to provide credentials to the SIP UAS that is rejecting an INVITE due to authorization failure. If the gateway can authenticate itself, then obviously it SHOULD do so and proceed with the call; only if the gateway cannot authenticate itself should cause code 21 be sent.
(*) In some cases, it may be possible for a SIP gateway to provide credentials to the SIP UAS that is rejecting an INVITE due to authorization failure. If the gateway can authenticate itself, then obviously it SHOULD do so and proceed with the call; only if the gateway cannot authenticate itself should cause code 21 be sent.
(+) If at all possible, a SIP gateway SHOULD respond to these protocol errors by remedying unacceptable behavior and attempting to re-originate the session. Only if this proves impossible should the SIP gateway fail the ISUP half of the call.
(+) If at all possible, a SIP gateway SHOULD respond to these protocol errors by remedying unacceptable behavior and attempting to re-originate the session. Only if this proves impossible should the SIP gateway fail the ISUP half of the call.
When the Warning header is present in a SIP 606 or 488 message, there may be specific ISDN cause code mappings appropriate to the Warning code. This document recommends that '31 Normal, unspecified' SHOULD by default be used for most currently assigned Warning codes. If the Warning code speaks to an unavailable bearer capability, cause code '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping.
When the Warning header is present in a SIP 606 or 488 message, there may be specific ISDN cause code mappings appropriate to the Warning code. This document recommends that '31 Normal, unspecified' SHOULD by default be used for most currently assigned Warning codes. If the Warning code speaks to an unavailable bearer capability, cause code '65 Bearer Capability Not Implemented' is a RECOMMENDED mapping.
8.2.7 REL Received
8.2.7 REL Received
This circumstance generally arises when the user on the PSTN side hangs up before the call has been answered; the gateway therefore aborts the establishment of the session. A CANCEL request MUST be issued (a BYE is not used, since no final response has arrived from the SIP side). A 200 OK for the CANCEL can be expected by the gateway, and finally a 487 for the INVITE arrives (which the gateway ACKs in turn).
This circumstance generally arises when the user on the PSTN side hangs up before the call has been answered; the gateway therefore aborts the establishment of the session. A CANCEL request MUST be issued (a BYE is not used, since no final response has arrived from the SIP side). A 200 OK for the CANCEL can be expected by the gateway, and finally a 487 for the INVITE arrives (which the gateway ACKs in turn).
The gateway SHOULD store state information related to this dialog 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 gateway MUST send an ACK followed by an appropriate BYE request.
The gateway SHOULD store state information related to this dialog 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 gateway MUST send an ACK followed by an appropriate BYE request.
In SIP bridging situations, the REL message cannot be encapsulated in a CANCEL message (since CANCEL cannot have a message body). Usually, the REL message will contain a CAI value of 16 "Normal clearing". If the value is other than a 16, the gateway MAY wish to use some other means of communicating the cause value (see Section 5.8).
In SIP bridging situations, the REL message cannot be encapsulated in a CANCEL message (since CANCEL cannot have a message body). Usually, the REL message will contain a CAI value of 16 "Normal clearing". If the value is other than a 16, the gateway MAY wish to use some other means of communicating the cause value (see Section 5.8).
8.2.8 ISUP T11 Expires
8.2.8 ISUP T11 Expires
In order to prevent the remote ISUP node's timer T7 from expiring, the gateway MAY 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.
In order to prevent the remote ISUP node's timer T7 from expiring, the gateway MAY 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.
Camarillo, et. al. Standards Track [Page 47] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 47] RFC 3398 ISUP to SIP Mapping December 2002
To clarify timer T11's relevance with respect to SIP interworking, Q.764 [12] explains its use as: "If in normal operation, a delay in the receipt of an address complete signal from the succeeding network is expected, the last common channel signaling exchange will originate and send an address complete message 15 to 20 seconds [timer (T11)] after receiving the latest address message." Since SIP nodes have no obligation to respond to an INVITE request within 20 seconds, SIP interworking inarguably qualifies as such a situation.
To clarify timer T11's relevance with respect to SIP interworking, Q.764 [12] explains its use as: "If in normal operation, a delay in the receipt of an address complete signal from the succeeding network is expected, the last common channel signaling exchange will originate and send an address complete message 15 to 20 seconds [timer (T11)] after receiving the latest address message." Since SIP nodes have no obligation to respond to an INVITE request within 20 seconds, SIP interworking inarguably qualifies as such a situation.
If the gateway supports this optional mechanism, then if its T11 expires, it SHOULD send an early ACM (i.e., called party status set to "no indication") to prevent the expiration of the remote node's T7 (where permitted by the ISUP variant). See Section 8.2.3 for the value of the ACM parameters.
If the gateway supports this optional mechanism, then if its T11 expires, it SHOULD send an early ACM (i.e., called party status set to "no indication") to prevent the expiration of the remote node's T7 (where permitted by the ISUP variant). See Section 8.2.3 for the value of the ACM parameters.
If a "180 Ringing" message arrives subsequently, it SHOULD be sent in a CPG, as shown in Section 8.2.3.
If a "180 Ringing" message arrives subsequently, it SHOULD be sent in a CPG, as shown in Section 8.2.3.
See Section 8.1.3 for an example callflow that includes the expiration of T11.
See Section 8.1.3 for an example callflow that includes the expiration of T11.
9. Suspend/Resume and Hold
9. Suspend/Resume and Hold
9.1 Suspend (SUS) and Resume (RES) Messages
9.1 Suspend (SUS) and Resume (RES) Messages
In ISDN networks, a user can generate a SUS (timer T2, user initiated) in order to unplug the terminal from the socket and plug it in another one. A RES is sent once the terminal has been reconnected and the T2 timer has not expired. SUS is also frequently used to signaling an on-hook state for a remote terminal before timers leading to the transmission of a REL message are sent (this is the more common case by far). While a call is suspended, no audio media is passed end-to-end.
In ISDN networks, a user can generate a SUS (timer T2, user initiated) in order to unplug the terminal from the socket and plug it in another one. A RES is sent once the terminal has been reconnected and the T2 timer has not expired. SUS is also frequently used to signaling an on-hook state for a remote terminal before timers leading to the transmission of a REL message are sent (this is the more common case by far). While a call is suspended, no audio media is passed end-to-end.
When a SUS is sent for a call that has a SIP leg, a gateway MAY suspend IP media transmission until a RES is received. Putting the media on hold insures that bandwidth is conserved when no audio traffic needs to be transmitted.
When a SUS is sent for a call that has a SIP leg, a gateway MAY suspend IP media transmission until a RES is received. Putting the media on hold insures that bandwidth is conserved when no audio traffic needs to be transmitted.
If media suspension is appropriate, then when a SUS arrives from the PSTN, the MGC MAY send an INVITE to request that the far-end's transmission of the media stream be placed on hold. The subsequent reception of a RES from the PSTN SHOULD then trigger a re-INVITE that requests the resumption of the media stream. Note that the MGC may or may not elect to stop transmitting any media itself when it requests the cessation of far-end transmission.
If media suspension is appropriate, then when a SUS arrives from the PSTN, the MGC MAY send an INVITE to request that the far-end's transmission of the media stream be placed on hold. The subsequent reception of a RES from the PSTN SHOULD then trigger a re-INVITE that requests the resumption of the media stream. Note that the MGC may or may not elect to stop transmitting any media itself when it requests the cessation of far-end transmission.
Camarillo, et. al. Standards Track [Page 48] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 48] RFC 3398 ISUP to SIP Mapping December 2002
If media suspension is not required by the MGC receiving the SUS from the PSTN, the SIP INFO [6] method MAY be used to transmit an encapsulated SUS rather than a re-INVITE. Note that the recipient of such an INFO request may be a simple SIP phone that does not understand ISUP (and would therefore take no action on receipt of this message); if a prospective destination for an INFO-encapsulated SUS has not used encapsulated ISUP in any messages it has previously sent, the gateway SHOULD NOT relay the INFO method, but rather should handle the SUS and the corresponding RES without signaling their arrival to the SIP network.
If media suspension is not required by the MGC receiving the SUS from the PSTN, the SIP INFO [6] method MAY be used to transmit an encapsulated SUS rather than a re-INVITE. Note that the recipient of such an INFO request may be a simple SIP phone that does not understand ISUP (and would therefore take no action on receipt of this message); if a prospective destination for an INFO-encapsulated SUS has not used encapsulated ISUP in any messages it has previously sent, the gateway SHOULD NOT relay the INFO method, but rather should handle the SUS and the corresponding RES without signaling their arrival to the SIP network.
In any case, subsequent RES messages MUST be transmitted in the same method that was used for the corresponding SUS (i.e., if an INFO is used for a SUS, INFO should also be used for the subsequent RES).
In any case, subsequent RES messages MUST be transmitted in the same method that was used for the corresponding SUS (i.e., if an INFO is used for a SUS, INFO should also be used for the subsequent RES).
Regardless of whether the INFO or re-INVITE mechanism is used to carry a SUS message, neither has any implication that the originating side will cease sending IP media. The recipient of an encapsulated SUS message MAY therefore elect to send a re-INVITE themselves to suspend media transmission from the MGC side if desired.
Regardless of whether the INFO or re-INVITE mechanism is used to carry a SUS message, neither has any implication that the originating side will cease sending IP media. The recipient of an encapsulated SUS message MAY therefore elect to send a re-INVITE themselves to suspend media transmission from the MGC side if desired.
The following example uses the INVITE mechanism. Note that this flow is informative, not proscriptive; compliant gateways are free to implement functionally equivalent flows, as described in the preceding paragraphs.
The following example uses the INVITE mechanism. Note that this flow is informative, not proscriptive; compliant gateways are free to implement functionally equivalent flows, as described in the preceding paragraphs.
SIP MGC/MG PSTN
| |<-----------SUS-----------|1
2|<--------INVITE-----------| |
3|-----------200----------->| |
4|<----------ACK------------| |
| |<-----------RES-----------|5
6|<--------INVITE-----------| |
7|-----------200----------->| |
8|<----------ACK------------| |
SIP MGC/MG PSTN | |<-----------SUS-----------|1 2|<--------INVITE-----------| | 3|-----------200----------->| | 4|<----------ACK------------| | | |<-----------RES-----------|5 6|<--------INVITE-----------| | 7|-----------200----------->| | 8|<----------ACK------------| |
The handling of a network-initiated SUS immediately prior to call teardown is handled in Section 10.2.2.
The handling of a network-initiated SUS immediately prior to call teardown is handled in Section 10.2.2.
Camarillo, et. al. Standards Track [Page 49] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 49] RFC 3398 ISUP to SIP Mapping December 2002
9.2 Hold (re-INVITE)
9.2 Hold (re-INVITE)
After a call has been connected, a re-INVITE could be sent to a gateway from the SIP side in order to place the call on hold. This re-INVITE will have an SDP offer indicating that the originator of the re-INVITE no longer wishes to receive media.
After a call has been connected, a re-INVITE could be sent to a gateway from the SIP side in order to place the call on hold. This re-INVITE will have an SDP offer indicating that the originator of the re-INVITE no longer wishes to receive media.
SIP MGC/MG PSTN
1|---------INVITE---------->| |
| |------------CPG---------->|2
3|<----------200------------| |
4|-----------ACK----------->| |
SIP MGC/MG PSTN 1|---------INVITE---------->| | | |------------CPG---------->|2 3|<----------200------------| | 4|-----------ACK----------->| |
When such a re-INVITE is received, the gateway SHOULD send a CPG in order to express that the call has been placed on hold. The CPG SHOULD contain a Generic Notification Indicator (or, in ANSI networks, a Notification Indicator) with a value of 'remote hold'.
そのような再INVITEが受け取られているとき、ゲートウェイSHOULDは、電話が保持に出されたと言い表すためにCPGを送ります。 CPG SHOULDは'リモート保持'の値でGeneric Notification Indicatorを含んでいます(またはANSIネットワーク、Notification Indicatorで)。
If, subsequent to the sending of the re-INVITE, the SIP side wishes to take the remote end off hold and begin receiving media again, it SHOULD repeat the flow above with an INVITE that contains an SDP offer with an appropriate media destination. The Generic Notification Indicator would in this instance have a value of 'remote retrieval' (or in some variants 'remote hold released').
再INVITEの発信にその後です、リモートエンドを取り去るというSIPサイド願望は成立して、再びメディアを受け取り始めます、それ。SHOULDは適切なメディアの目的地があるSDP申し出を含むINVITEと共に上で流れを繰り返します。 Generic Notification Indicatorには、'リモート検索'(または'リモート保持はリリースした'いくつかの異形で)の値がこの場合あるでしょう。
Finally, note that a CPG with hold indicators may be received by a gateway from the PSTN. In the interests of conserving bandwidth, the gateway SHOULD stop sending media until the call is resumed and SHOULD send a re-INVITE to the SIP leg of the call requesting that the remote side stop sending media.
最終的に、保持インディケータがあるCPGがゲートウェイによってPSTNから受け取られるかもしれないことに注意してください。 帯域幅を保存することのために、ゲートウェイSHOULDは、呼び出しが再開されて、SHOULDが遠隔地側が、メディアを送るのを止めるよう要求する呼び出しのSIP行程に再INVITEを送るまでメディアを送るのを止めます。
10. Normal Release of the Connection
10. 接続の通常の解放
From the perspective of a gateway, either the SIP side or the ISUP side can release a call, regardless of which side initiated the call. Note that cancellation of a call setup request (either from the ISUP or SIP side) is discussed elsewhere in this document (in Section 8.2.7 and Section 7.2.3, respectively).
ゲートウェイの見解から、SIP側かISUP側のどちらかが呼び出しをリリースできます、どの側が呼び出しを開始したかにかかわらず。 ほかの場所で本書では(セクション8.2.7とセクション7.2.3でそれぞれ)呼び出しセットアップ要求(ISUPかSIP側からの)のキャンセルについて議論することに注意してください。
Gateways SHOULD implement functional equivalence with the flows in this section.
流れがこのセクションにある状態で、ゲートウェイSHOULDは機能的な等価性を実行します。
10.1 SIP initiated release
10.1 SIPはリリースを開始しました。
For a normal termination of the dialog (receipt of a BYE request), the gateway MUST immediately send a 200 response. The gateway then MUST release any media resources in the gateway (DSPs, TCIC locks, and so on) and send an REL with a cause code of 16 (normal call
対話(BYE要求の領収書)の正常終了のために、ゲートウェイはすぐに、200応答を送らなければなりません。 次に、ゲートウェイがゲートウェイ(DSPs、TCIC錠など)でどんなメディアリソースも発表して、16の原因コードと共にRELを送らなければならない、(通常の呼び出し
Camarillo, et. al. Standards Track [Page 50] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[50ページ]。
clearing) to the PSTN. Release of resources is confirmed by the PSTN side with an RLC message.
開拓地) PSTNに。 リソースのリリースはRLCメッセージがあるPSTN側によって確認されます。
In SIP bridging situations, the cause code of any REL encapsulated in the BYE request SHOULD be re-used in any REL that the gateway sends to the PSTN.
SIP橋を架ける状況、どんなRELのコードも要約した原因では、ゲートウェイがPSTNに送るあらゆるRELでBYE要求SHOULDで再使用されてください。
SIP MGC/MG PSTN
1|-----------BYE----------->| |
| ** MG Releases IP Resources ** |
2|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|3
| |<-----------RLC-----------|4
一口MGC/mg PSTN1|-----------さようなら----------->|、|、| ** mgはIPリソース**をリリースします。| 2| <、-、-、-、-、-、-、-、-、--200------------| | | ** mgはPSTNトランク**をリリースします。| | |------------REL---------->|3 | | <、-、-、-、-、-、-、-、-、-、--RLC-----------|4
10.2 ISUP initiated release
10.2 ISUPはリリースを開始しました。
If the release of the connection was caused by the reception of a REL, the REL SHOULD be encapsulated in the BYE sent by the gateway. Whether the caller or callee hangs up first, the gateway SHOULD release any internal resources used in support of the call and then MUST confirm that the circuit is ready for re-use by sending an RLC.
接続の解放は要約のコネがゲートウェイによって送られたBYEであったならREL、REL SHOULDのレセプションによって引き起こされました。 訪問者か訪問される人が、1番目、何か社内資源が呼び出しを支持して使用したゲートウェイSHOULDリリースを掛けて、次に、サーキットが再使用のRLCを送ることによって準備ができていると確認でなければならないかどうか
10.2.1 Caller hangs up
10.2.1 訪問者はハングアップします。
When the caller hangs up, the SIP dialog MUST be terminated by sending a BYE request (which is confirmed with a 200).
訪問者がハングアップするとき、BYE要求(200で確認される)を送ることによって、SIP対話を終えなければなりません。
SIP MGC/MG PSTN
| |<-----------REL-----------|1
| ** MG Releases PSTN Trunk ** |
| |------------RLC---------->|2
3|<----------BYE------------| |
| ** MG Releases IP Resources ** |
4|-----------200----------->| |
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--REL-----------|1 | ** mgはPSTNトランク**をリリースします。| | |------------RLC---------->|2 3| <、-、-、-、-、-、-、-、-、--さようなら------------| | | ** mgはIPリソース**をリリースします。| 4|-----------200----------->|、|
Camarillo, et. al. Standards Track [Page 51] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[51ページ]。
10.2.2 Callee hangs up (SUS)
10.2.2 訪問される人はハングアップします。(SUS)
In some PSTN scenarios, 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. This necessitates a slightly different SIP flow; see Section 9 for more information on handling suspension. It is RECOMMENDED that gateways implement functional equivalence with the following flow for this case:
いくつかのPSTNシナリオでは、訪問される人が呼び出しの途中でハングアップするなら、市内交換は、RELの代わりにSUSを送って、タイマを始動します(T6、SUSは開始されたネットワークです)。 タイマが期限が切れるとき、RELを送ります。 これはわずかに異なったSIP流動を必要とします。 取り扱いサスペンションの詳しい情報に関してセクション9を見てください。 ゲートウェイがこのような場合以下の流れに伴う機能的な等価性を実行するのは、RECOMMENDEDです:
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----------->| |
一口MGC/mg PSTN| | <、-、-、-、-、-、-、-、-、-、--SUS-----------|1 2| <、-、-、-、-、-、-、--招待-----------| | 3|-----------200----------->|、| 4| <、-、-、-、-、-、-、-、-、--ACK------------| | | | *** T6は***を吐き出します。| | | <、-、-、-、-、-、-、-、-、-、--REL-----------|5 | ** mgはPSTNトランク**をリリースします。| | |------------RLC---------->|6 7| <、-、-、-、-、-、-、-、-、--さようなら------------| | | ** mgはIPリソース**をリリースします。| 8|-----------200----------->|、|
11. ISUP Maintenance Messages
11. ISUP維持メッセージ
ISUP contains a set of messages used for maintenance purposes. They can be received during any ongoing call. There are basically two kinds of maintenance messages (apart from the continuity check): messages for blocking circuits and messages for resetting circuits.
ISUPは維持目的に使用される1セットのメッセージを含んでいます。 どんな進行中の呼び出しの間も、それらを受け取ることができます。 基本的に、2種類の維持メッセージ(連続チェックは別として)があります: サーキットを妨げることへのメッセージとリセットサーキットへのメッセージ。
11.1 Reset messages
11.1 リセットメッセージ
Upon reception of an RSC message for a circuit currently being used by the gateway for a call, the call MUST be released immediately (this typically results from a serious maintenance condition). RSC MUST be answered with an RLC after resetting the circuit in the gateway. Group reset (GRS) messages which target a range of circuits are answered with a Circuit Group Reset ACK Message (GRA) after resetting all the circuits affected by the message.
サーキットへの現在呼び出しにゲートウェイによって使用されるRSCメッセージのレセプションでは、すぐに、呼び出しをリリースしなければなりません(これは重大な維持状態から通常生じます)。 RSC MUST、ゲートウェイのサーキットをリセットした後に、RLCと共に答えられてください。 メッセージで影響を受けるすべてのサーキットをリセットした後に、さまざまなサーキットを狙うグループリセット(GRS)メッセージがCircuit Group Reset ACK Message(GRA)と共に答えられます。
The gateways SHOULD behave as if a REL had been received in order to release the dialog on the SIP side. A BYE or a CANCEL are sent depending of the status of the call. See the procedures in Section 10.
SHOULDが反応させるゲートウェイにまるでSIPで対話をリリースするためにRELを受け取ったかのように面があります。 BYEかキャンセルに呼び出しの状態を依存させます。 セクション10で手順を見てください。
Camarillo, et. al. Standards Track [Page 52] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[52ページ]。
11.2 Blocking messages
11.2 メッセージを妨げること。
There are two kinds of blocking messages: maintenance messages or hardware-failure messages. Maintenance blocking messages indicate that the circuit is to be blocked for any subsequent calls, but these messages do not affect any ongoing call. This allows circuits to be gradually quiesced and taken out of service for maintenance.
メッセージを2種類の妨げるのがあります: 維持メッセージかハードウェア故障メッセージ。 維持ブロッキングメッセージは、サーキットがどんなその後の呼び出しのためにも妨げられることであることを示しますが、これらのメッセージはどんな進行中の呼び出しにも影響しません。 これは、サーキットが徐々にquiescedされて、メンテナンスのために使われなくなっていた状態で取られるのを許容します。
Hardware-oriented blocking messages have to be treated as reset messages. They generally are sent only when a hardware failure has occurred. Media transmission for all calls in progress on these circuits would be affected by this hardware condition, and therefore all calls must be released immediately.
ハードウェア指向のブロッキングメッセージはリセットメッセージとして扱われなければなりません。 ハードウェアの故障が起こったときだけ、一般に、それらを送ります。 これらのサーキットの進行中のすべての呼び出しのためのメディア送信はこのハードウェア状態で影響を受けるでしょう、そして、したがって、すぐに、すべての呼び出しをリリースしなければなりません。
BLO is always maintenance oriented and it is answered by the gateway with a Blocking ACK Message (BLA) when the circuit is blocked - this requires no corresponding SIP actions. Circuit Group Blocking (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. If the CGB results from a hardware failure, then each call in progress in the affected range of circuits MUST be terminated immediately as if a REL had been received, following the procedures in Section 10. CGBs MUST be answered with CGBAs.
サーキットが妨げられるとき、それはBlocking ACK Message(BLA)と共にゲートウェイによって答えられます--いつもBLOは適応する維持です、そして、これはどんな対応するSIP動作も必要としません。 サーキットGroup Blocking(CGB)メッセージはCircuit Group Supervision Message Type Indicatorの中に「タイプインディケータ」を持っています。 それは、CGBが失敗が適応させた維持かそれともハードウェアであるかを示します。 CGBがハードウェアの故障から生じるなら、まるですぐRELを受け取ったかのように影響を受ける範囲のサーキットの進行中のそれぞれの呼び出しを終えなければなりません、セクション10で手順に従って。 CGBAsと共にCGBsに答えなければなりません。
11.3 Continuity Checks
11.3 連続はチェックします。
A continuity check is a test performed on a circuit that involves the reflection of a tone generated at the originating switch by a loopback at the destination switch. Two variants of the continuity check appear in ISUP: the implicit continuity check request within an IAM (in which case the continuity check takes place as a precondition before call setup begins), and the explicit continuity check signaled by a Continuity Check Request (CCR) message. PSTN gateways in regions that support continuity checking generally SHOULD have some way of accommodating these tests (if they hope to be fielded by providers that interconnect with any major carrier).
連続チェックは由来しているスイッチで目的地スイッチのループバックで発生するトーンの反映にかかわるサーキットに実行されたテストです。 連続チェックの2つの異形がISUPに現れます: IAM(その場合、呼び出しセットアップが始まる前に連続チェックは前提条件として行われる)の中の暗黙の連続チェック要求、およびContinuity Check Request(CCR)メッセージによって合図された明白な連続チェック。 一般にSHOULDをチェックする連続を支持する領域のPSTNゲートウェイには、これらのテストに対応する何らかの方法があります(どんな主要なキャリヤーでも内部連絡されるプロバイダーによってさばかれることを望んでいるなら)。
When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT send any corresponding SIP messages; the scope of the continuity check applies only to the PSTN trunks, not to any IP media paths beyond the gateway. CCR messages also do not designate any called party number, or any other way to determine what SIP user agent server should be reached.
PSTN-SIPゲートウェイでCCRを受け取るとき、ゲートウェイSHOULD NOTはどんな対応するSIPメッセージも送ります。 連続チェックの範囲はゲートウェイを超えたどんなIPメディア経路ではなく、PSTNトランクスだけにも適用されます。 CCRメッセージもどんな被呼者番号、またはどんなSIPユーザエージェントサーバに達するべきであるかを決定するいかなる他の方法も指定しません。
When an IAM with the Continuity Check Indicator flag set within the NCI parameter is received, the gateway MUST process the continuity check before sending an INVITE message (and proceeding normally with
そして、NCIパラメタの中に設定されたContinuity Check Indicator旗があるIAMが受け取られているとき、INVITEメッセージを送る前にゲートウェイが連続チェックを処理しなければならない、(通常、続きます。
Camarillo, et. al. Standards Track [Page 53] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[53ページ]。
call setup); if the continuity check fails (a COT with Continuity Indicator of 'failed' is received), then an INVITE MUST NOT be sent.
呼び出しセットアップ)、。 チェックは連続であるなら失敗して('失敗されること'のContinuity IndicatorとCOTは受け取られています)、その時はINVITE MUST NOTです。送ります。
12. Construction of Telephony URIs
12. 電話URIの工事
SIP proxy servers MAY route SIP messages on any signaling criteria desired by network administrators, but generally the Request-URI is the foremost routing criterion. The To and From headers are also frequently of interest in making routing decisions. SIP-ISUP mapping assumes that proxy servers are interested in at least these three fields of SIP messages, all of which contain URIs.
SIPプロキシサーバはネットワーク管理者によって望まれていたどんなシグナリング評価基準に関するSIPメッセージも発送するかもしれませんが、一般にRequest-URIは最前のルーティング評価基準です。 また、ToとFromヘッダーも頻繁にルーティングを決定にするのにおもしろいです。 SIP-ISUPマッピングは、プロキシサーバが少なくとも3がさばくそれのすべてがURIを含むSIPメッセージのこれらに興味を持っていると仮定します。
SIP-ISUP mapping frequently requires the representation of telephone numbers in these URIs. In some instances these numbers will be presented first in ISUP messages, and SS7-SIP gateways will need to translate the ISUP formats of these numbers into SIP URIs. In other cases the reverse transformation will be required.
SIP-ISUPマッピングは頻繁にこれらのURIにおける、電話番号の表現を必要とします。 ある場合にこれらの数は最初に、ISUPメッセージに示されるでしょう、そして、SS7-SIPゲートウェイはこれらの数のISUP書式をSIP URIに翻訳する必要があるでしょう。 他の場合では、逆の変化が必要でしょう。
The most common format used in SIP for the representation of telephone numbers is the tel URL [7]. When converting between formats, the tel URL MAY constitute the entirety of a URI field in a SIP message, or it MAY appear as the user portion of a SIP URI. For example, a To field might appear as:
電話番号の表現にSIPで使用される中で最も一般的な形式はtel URL[7]です。 形式の間で変換するとき、tel URLがSIPメッセージにおける、URI分野の全体を構成するかもしれませんか、またはそれはSIP URIのユーザ部分として現れるかもしれません。 例えば、To野原は以下として現れるかもしれません。
To: tel:+17208881000
To: tel: +17208881000
Or
または
To: sip:+17208881000@level3.com
To: 一口: + 17208881000@level3.com
Whether or not a particular gateway or endpoint should formulate URIs in the tel or SIP format is a matter of local administrative policy - if the presence of a host portion would aid the surrounding network in routing calls, the SIP format should be used. A gateway MUST accept either tel or SIP URIs from its peers.
特定のゲートウェイか終点がtelでURIを定式化するべきであるか、ホスト部分の存在がルーティング呼び出しで周囲のネットワークを支援するならSIP形式がローカルの施政方針の問題であることにかかわらず、SIP形式は使用されるべきです。 ゲートウェイは同輩からtelかSIP URIのどちらかを受け入れなければなりません。
The '+' sign preceding the number in tel URLs indicates that the digits which follow constitute a fully-qualified E.164 [16] number; essentially, this means that a country code is provided before any national-specific area codes, exchange/city codes, or address codes. The absence of a '+' sign MAY signify that the number is merely nationally significant, or perhaps that a private dialing plan is in use. When the '+' sign is not present, but a telephone number is represented by the user portion of the URI, the SIP URI SHOULD contain the optional ';user=phone' parameter; e.g.,
tel URLの数に先行する'+'サインは、続くケタが完全に適切なE.164[16]数を構成するのを示します。 本質的には国名略号がどんな国家に特定の市外局番、交換/都市名コードの前にも提供されるこの手段かアドレスコード。 '+'サインの欠如は、数が全国的に単に重要であるか、または恐らく、個人的なダイヤルするプランが使用中であることを意味するかもしれません。 ''+'サインが存在していませんが、電話番号がURIのユーザ部分によって表されるとき、SIP URI SHOULDは任意を含んでいる'; ユーザ=電話'パラメタ 例えば
To: sip:83000@sip.example.net;user=phone
To: 一口: 83000@sip.example.net;user は電話と等しいです。
Camarillo, et. al. Standards Track [Page 54] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[54ページ]。
However, it is strongly RECOMMENDED that only internationally significant E.164 numbers be passed between SIP-T gateways, especially when such gateways are in different regions or different administrative domains. In many if not most SIP-T networks, gateways are not responsible for end-to-end routing of SIP calls; practically speaking, gateways have no way of knowing if the call will terminate in a local or remote administrative domain and/or region, and hence gateways SHOULD always assume that calls require an international numbering plan. There is no guarantee that recipients of SIP signaling will be capable of understanding national dialing plans used by the originators of calls - if the originating gateway does not internationalize the signaling, the context in which the digits were dialed cannot be extrapolated by far-end network elements.
しかしながら、それが強くそうである、RECOMMENDED、特にそのようなゲートウェイが異なった領域か異なった管理ドメインにあるとき、国際的に重要なE.164番号だけがSIP-Tゲートウェイの間で通過されます。 多くかほとんどのSIP-Tネットワークでは、ゲートウェイは終わりから終わりへのSIP呼び出しのルーティングに原因となりません。 実際に話すなら、ゲートウェイには、呼び出しが地方の、または、遠く離れた管理ドメイン、そして/または、領域で終わるかどうかを知る方法が全くありません、そして、したがって、ゲートウェイSHOULDはいつも呼び出しが国際的な付番プランを必要とすると仮定します。 SIPシグナリングの受取人がプランが使用した国家のダイヤルすることを呼び出しの創始者に解釈できるという保証が全くありません--由来しているゲートウェイがシグナリングを国際的にしないなら、ケタがダイヤルされた文脈は推定された断然終わりのネットワーク要素であるはずがありません。
In ISUP signaling, a telephone number appears in a common format that is used in several parameters, including the CPN and CIN; when it represents a calling party number it sports some additional information (detailed below). For the purposes of this document, we will refer to this format as 'ISUP format' - if the additional calling party information is present, the format shall be referred to as 'ISUP- calling format'. The format consists of a byte called the Nature of Address (NoA) indicator, followed by another byte which contains the Numbering Plan Indicator (NPI), both of which are prefixed to a variable-length series of bytes that contains the digits of the telephone number in Binary Coded Decimal (BCD) format. In the calling party number case, the NPI's byte also contains bit fields which represent the caller's presentation preferences and the status of any call screening checks performed up until this point in the call.
ISUPシグナリングでは、電話番号はいくつかのパラメタで使用される一般的な形式に現れます、CPNとCINを含んでいて。 起呼側番号を表すとき、それは何らかの追加情報(以下で詳細な)を見せびらかします。 このドキュメントの目的について、私たちは'ISUP形式'とこの書式を呼ぶつもりです--追加起呼側情報が存在しているなら、書式は'形式と呼ぶISUP'と呼ばれるものとします。 形式は2進化10進法(BCD)形式における、電話番号のケタを含むNumbering Plan Indicator(NPI)を含むもう1バイトがあとに続いたそれの両方が前に置かれているAddress(NoA)インディケータのネイチャーと呼ばれる1バイトから可変長のシリーズのバイトから成ります。 また、起呼側数の事件では、NPIのバイトは訪問者のプレゼンテーション好みを表す噛み付いている分野と呼び出しでこのポイントまで実行されたどんな呼び出し選別チェックの状態も含んでいます。
H G F E D C B A H G F E D C B A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NoA | | | NoA |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | NPI | spare | | | NPI |PrI|ScI|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| dig...| dig 1 | | dig...| dig 1 |
| ... | | ... |
| dig n | dig...| | dig n | dig...|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
++++++++++++++++++あたりH G F E D C Bは1H G F E D C Bです。| | NoA| | | NoA| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | NPI| 予備| | | NPI|PrI|ScI| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 掘ってください…| 1を掘ってください。| | 掘ってください…| 1を掘ってください。| | ... | | ... | | nを掘ってください。| 掘ってください…| | nを掘ってください。| 掘ってください…| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ISUP format ISUP calling format
形式と呼ぶISUP形式ISUP
ISUP numbering formats
ISUP付番形式
The NPI field is generally set to the value 'ISDN (Telephony) numbering plan (Recommendation E.164)', but this does not mean that the digits which follow necessarily contain a country code; the NoA
一般に、NPI分野は値の'ISDN(電話)への'これだけが、続くケタが必ず国名略号を含むことを意味しないというプラン(推薦E.164)に付番するセットです。 NoA
Camarillo, et. al. Standards Track [Page 55] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[55ページ]。
field dictates whether the telephone number is in a national or international format. When the represented number is not designated to be in an international format, the NoA generally provides information specific to the national dialing plan - based on this information one can usually determine how to convert the number in question into an international format. Note that if the NPI contains a value other than 'ISDN numbering plan', then the tel URL may not be suitable for carrying the address digits, and the handling for such calls is outside the scope of this document.
国家的、または、国際的な形式に電話番号があるか否かに関係なく、命令をさばいてください。 表された数が国際的な形式にはあるように指定されないとき、一般に、NoAは国家のダイヤルするプランに特定の情報を提供します--この情報に基づいて、通常、人は問題の数を国際的な形式に変換する方法を決定できます。 NPIが'ISDN付番プラン'を除いた値を含んでいるならtel URLがアドレスケタを運ぶのに適当でないかもしれなく、このドキュメントの範囲の外にそのような呼び出しのための取り扱いがあることに注意してください。
12.1 ISUP format to tel URL mapping
12.1 tel URLマッピングへのISUP形式
Based on the above, conversion from ISUP format to a tel URL is as follows. First, provided that the NPI field indicates that the telephone number format uses E.164, the NoA is consulted. If the NoA indicates that the number is an international number, then the telephone number digits SHOULD be appended unmodified to a 'tel:+' string. If the NoA has the value 'national (significant) number', then a country code MUST be prefixed to the telephone number digits before they are committed to a tel URL; if the gateway performing this conversion interconnects with switches homed to several different country codes, presumably the appropriate country code SHOULD be chosen based on the originating switch or trunk group. If the NoA has the value 'subscriber number', both a country code and any other numbering components necessary for the numbering plan in question (such as area codes or city codes) MAY need to be added in order for the number to be internationally significant - however, such procedures vary greatly from country to country, and hence they cannot be specified in detail here. Only if a country or network- specific value is used for the NoA SHOULD a tel URL not include a '+' sign; in these cases, gateways SHOULD simply copy the provided digits into the tel URL and append a 'user=phone' parameter if a SIP URI format is used. Any non-standard or proprietary mechanisms used to communicate further context for the call in ISUP are outside the scope of this document.
上記に基づいて、ISUP形式からtel URLまでの変換は以下の通りです。 まず最初に、NPI分野が、電話番号形式がE.164を使用するのを示せば、NoAは相談されます。 NoAがそれを示すなら、数は国際的な数であり、次に、電話番号はケタSHOULDです。'tel:+'ストリングに変更されていなく、追加してください。 NoAに値の'国家(重要な)の数'があるなら、彼らがtel URLに心がける前に電話番号ケタへ国名略号を前に置かなければなりません。 この変換を実行するゲートウェイが内部連絡されるなら、スイッチがいくつかの異なった国名略号、おそらく適切な国名略号SHOULDと家へ帰って、由来しているスイッチかトランクグループに基づいて選ばれてください。 NoAに値の'加入者番号'があるなら、国名略号といかなる他の付番コンポーネントの問題の付番プラン(市外局番か都市名コードなどの)に必要な両方も、数が国際的に重要であるように加えられる必要があるかもしれません--しかしながら、そのような手順は大いに国によって違います、そして、したがって、ここで詳細にそれらは指定できません。 国かネットワークの特定の値がNoA SHOULDに使用される場合にだけ、tel URLは'+'サインを含んでいません。 これらの場合では、ゲートウェイSHOULDは単にtel URLに提供されたケタをコピーして、SIP URI形式が使用されているなら、'ユーザ=電話'パラメタを追加します。 このドキュメントの範囲の外にISUPでの呼び出しのためにさらなる文脈を伝えるのにおいて中古のどんな標準的でないか独占であるメカニズムもあります。
If a nationally-specific parameter is present that allows for the transmission of the calling party's name (such as the Generic Name Parameter in ANSI), then generally, if presentation is not restricted, this information SHOULD be used to populate the display- name portion of the From field.
起呼側の名前(ANSIのGeneric Name Parameterなどの)、次に、一般にこの情報プレゼンテーションが制限されないならSHOULDに、全国的に特定のパラメタがそれがトランスミッションのために許すプレゼントであるなら使用されて、部分というFrom分野の表示名に居住してください。
Camarillo, et. al. Standards Track [Page 56] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[56ページ]。
If ISUP calling format is being converted rather than ISUP format, then two additional pieces of information must be taken into account: presentation indicators and screening indicators. If the presentation indicators are set to 'presentation restricted', then a special URI is created by the gateway which communicates to the far end that the caller's identity has been omitted. This URI SHOULD be a SIP URI with a display-name and username of 'Anonymous', e.g.:
形式と呼ぶISUPがISUP形式よりむしろ変換されているなら、2つの追加情報を考慮に入れなければなりません: プレゼンテーションインディケータと選別インディケータ。 プレゼンテーションインディケータが'制限されたプレゼンテーション'に設定されるなら、特別なURIは訪問者のアイデンティティが省略された遠い終わりまで交信するゲートウェイによって作成されます。 このURI SHOULD、例えば'匿名'に関する表示名とユーザ名があるSIP URIになってください:
From: Anonymous <sip:anonymous@anonymous.invalid>
From: 匿名の<一口: anonymous@anonymous.invalid 、gt。
For further information about privacy in SIP, see Section 5.7.
SIPのプライバシーに関する詳細に関しては、セクション5.7を見てください。
If presentation is set to 'address unavailable', then gateways should treat the IAM as if the CIN parameter was omitted. Screening indicators should not be translated, as they are only meaningful end-to-end.
プレゼンテーションが'入手できないアドレス'に設定されるなら、まるでCINパラメタが省略されるかのようにゲートウェイはIAMを扱うはずです。 それらが重要な終わりから終わりにすぎないので、選別インディケータを翻訳するべきではありません。
12.2 tel URL to ISUP format mapping
12.2 ISUP形式マッピングへのtel URL
Conversion from tel URLs to ISUP format is simpler. If the URI is in international format, then the gateway SHOULD consult the leading country code of the URI. If the country code is local to the gateway (the gateway has one or more trunks that point to switches which are homed to the country code in question), the gateway SHOULD set the NoA to reflect 'national (significant) number' and strip the country code from the URI before populating the digits field. If the country code is not local to the gateway, the gateway SHOULD set the NoA to 'international number' and retain the country code. In either case the NPI MUST be set to 'ISDN numbering plan'.
tel URLからISUP形式までの変換は、より簡単です。 国際的な形式にURIがあるなら、ゲートウェイSHOULDはURIの先進国コードに相談します。 国名略号がゲートウェイに地方であるなら(ゲートウェイには、1つがあるか、またはそうするスイッチを示すより多くのトランクスが問題の国名略号と家へ帰りました)、ゲートウェイSHOULDはNoAに'国家(重要な)の数'を反映して、ケタ分野に居住する前にURIから国名略号を剥取るように設定します。 国名略号がゲートウェイに地方でないなら、ゲートウェイSHOULDは'国際的な数'にNoAを設定して、国名略号を保有します。 どちらかでは、NPI MUSTをケースに入れてください。'ISDN付番プラン'に設定されてください。
If the URI is not in international format, the gateway MAY attempt to treat the telephone number within the URI as if it were appropriate to its national or network-specific dialing plan; if doing so gives rise to internal gateway errors or the gateway does not support such procedures, then the gateway SHOULD respond with appropriate SIP status codes to express that the URI could not be understood (if the URI in question is the Request-URI, a 484).
国際的な形式にURIがないなら、ゲートウェイは、まるでそれが国家の、または、ネットワーク特有のダイヤルするプランに適切であるかのようにURIの中で電話番号を扱うのを試みるかもしれません。 そうするのが内部のゲートウェイ誤りをもたらすか、またはゲートウェイがそのような手順を支持しないなら、ゲートウェイSHOULDは、URIを理解できなかったと言い表すために適切なSIPステータスコードで応じます(問題のURIがRequest-URI、484であるなら)。
When converting from a tel URL to ISUP calling format, the procedure is identical to that described in the preceding paragraphs, but additionally, the presentation indicator SHOULD be set to 'presentation allowed' and the screening indicator to 'network provided', unless some service provider policy or user profile specifically disallows presentation.
形式と呼びながらtel URLからISUPまで変換するとき、手順はさらに、先行のパラグラフにもかかわらず、説明されたそれと同じです、プレゼンテーションインディケータSHOULD。'許容されたプレゼンテーション'と'ネットワークは提供したこと'への選別インディケータに設定されてください、いくらかのサービスプロバイダー方針かユーザ・プロファイルが明確にプレゼンテーションを禁じない場合。
Camarillo, et. al. Standards Track [Page 57] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[57ページ]。
13. Other ISUP flavors
13. 他のISUP風味
Other flavors of ISUP different than ITU-T ISUP have different parameters and more features. Some of the parameters have more possible values and provide more information about the status of the call.
ITU-T ISUPと異なったISUPの他の風味には、異なったパラメタと、より多くの特徴があります。 パラメタのいくつかが、呼び出しの状態に関して、より可能な値を持って、詳しい情報を提供します。
The Circuit Query Message (CQM) and Circuit Query Response (CQR) are used in many ISUP variants. These messages have no analog in SIP, although receipt of a CQR may cause state reconciliation if the originating and destination switches have become desynchronized; as states are reconciled some calls may be terminated, which may cause SIP or ISUP messages to be sent (as described in Section 10).
Circuit Query Message(CQM)とCircuit Query Response(CQR)は多くのISUP異形で使用されます。 これらのメッセージはSIPにアナログを全く持っていません、由来と目的地スイッチが反連動するようになったなら、CQRの領収書は州の和解を引き起こすかもしれませんが。 州が和解しているとき、いくつかの呼び出し(送られるべきメッセージをSIPかISUPに引き起こすかもしれない)が終えられるかもしれません(セクション10で説明されるように)。
However, differences in the message flows are more important. In ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent instead (when no ACM has been sent before the call is answered). In call forwarding situations, CPGs MAY be sent before the ACM is sent. SAMs MUST NOT be sent; 'en-bloc' signaling is always used. The ANSI Exit Message (EXM) SHOULD NOT result in any SIP signaling in gateways. ANSI also uses the Circuit Reservation Message (CRM) and Circuit Reservation Acknowledgment (CRA) as part of its interworking procedures - in the event that an MGC does receive a CRM, a CRA SHOULD be sent in return (in some implementations, transmissions of a CRA could conceivably be based on a resource reservation system); after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and process it normally. Any further circuit reservation mechanism is outside the scope of this document.
しかしながら、メッセージ流れの違いは、より重要です。 ANSI[11]ISUPでは、CONメッセージを送ってはいけません。 代わりにANMを送ります(呼び出しに答える前にACMを全く送らないとき)。 自動転送状況で、ACMを送る前にCPGsを送るかもしれません。 SAMsを送ってはいけません。 'アン団体'シグナリングはいつも使用されます。 ANSI Exit Message(EXM)SHOULD NOTはゲートウェイで合図するどんなSIPももたらします。 また、MGCが送られたコネがリターンであったならCRM、CRA SHOULDを受ける場合(いくつかの実現では、CRAのトランスミッションは多分リソース保留制に基づくことができました)、ANSIは織り込む手順の一部としてCircuit予約Message(CRM)とCircuit予約Acknowledgment(CRA)を使用します。 CRAを送った後に、通常、MGC SHOULDはその後のIAMを待っていて、それを処理します。 このドキュメントの範囲の外にどんなさらなるサーキット予約メカニズムもあります。
Although receipt of a Confusion (CFN) message is an indication of a protocol error, corresponding SIP messages SHOULD NOT be sent on receipt of a CFN - the CFN should be handled with ISUP-specific procedures by the gateway (usually by retransmission of the packet to which the CFN responded). Only if ISUP procedures fails repeatedly should this cause a SIP error condition (and call failure) to arise.
Confusion(CFN)メッセージの領収書はCFNを受け取り次第、送ってください--ゲートウェイ(通常CFNが応じたパケットの「再-トランスミッション」による)によってCFNがISUP特有の手順で扱われるべきであるというプロトコル誤り、対応するSIPメッセージSHOULD NOTのしるしですが。 ISUP手順が繰り返し失敗する場合にだけ、これで、SIPエラー条件(失敗に電話をする)は起こるべきですか?
In TTC ISUP CPGs MAY be sent before the ACM is sent. Messages such as a Charging Information Message (CHG) MAY be sent between ACM and ANM. 'En-bloc' signaling is always used and there is no T9 timer.
TTC ISUP CPGs5月に、ACMを送る前に送ってください。 Charging情報Message(CHG)などのメッセージをACMとANMの間に送るかもしれません。 'アン団体'シグナリングはいつも使用されます、そして、T9タイマが全くありません。
13.1 Guidelines for sending other ISUP messages
13.1 他のISUPメッセージを送るためのガイドライン
Some ISUP variants send more messages than the ones described in this document. Therefore, some guidelines are provided here with regard to transport and mapping of these ISUP message.
いくつかのISUP異形が本書では説明されたものより多くのメッセージを送ります。 したがって、これらのISUPメッセージの輸送とマッピングに関していくつかのガイドラインをここに提供します。
Camarillo, et. al. Standards Track [Page 58] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[58ページ]。
From the caller to the callee, other ISUP messages SHOULD be encapsulated (see [3]) inside INFO messages, even if the INVITE transaction is still not finished. Note that SIP does not ensure that INFO requests are delivered in order, and therefore in adverse network conditions an egress gateway might process INFOs out of order. This issue, however, does not represent an important problem since it is not likely to happen and its effects are negligible in most of the situations. The Information (INF) message and Information Response (INR) are examples of messages that should be encapsulated within an INFO. Gateway implementers might also consider building systems that wait for each INFO transaction to complete before initiating a new INFO transaction.
要約されてください。訪問者から訪問される人、他のISUPメッセージSHOULD、(INFOメッセージで[3])を見てください、INVITE取引がまだ終わらないでも。 SIPが、INFO要求が整然とした状態で提供されるのを確実にしないことに注意してください。そうすれば、したがって、不利なネットワーク状態では、出口ゲートウェイは故障していた状態でINFOsを処理するかもしれません。 それが起こりそうになくて、効果が状況の大部分で取るにたらないので、しかしながら、この問題は重大な問題を表しません。 情報(INF)メッセージと情報Response(INR)はINFOの中で要約されるべきであるメッセージに関する例です。 また、ゲートウェイimplementersは新しいINFO取引を開始する前に完了するそれぞれのINFO取引を待つシステム構築を考えるかもしれません。
From the callee to the caller, if a message is received by a gateway before the call has been answered (i.e., ANM is received) it SHOULD be encapsulated in an INFO, provided that this will not be the first SIP message sent in the backwards direction (in which case it SHOULD be encapsulated in a provisional 1xx response). Similarly a message which is received on the originating side (probably in response to an INR) before a 200 OK has been received by the gateway should be carried within an INFO. In order for this mechanism to function properly in the forward direction, any necessary Contact or To-tag must have appeared in a previous provisional response or the message might not be correctly routed to its destination. As such all SIP-T gateways MUST send all provisional responses with a Contact header and any necessary tags in order to enable proper routing of new requests issued before a final response has been received. When the INVITE transaction is finished INFO requests SHOULD also be used in this direction.
SHOULDがINFOで要約されて、送られて、呼び出しにそれに答える(すなわち、ANMは受け取られています)前にゲートウェイでメッセージを受け取って、これがそうしなければ訪問される人から訪問者まで、最初のSIPメッセージになってください、遅れている指示、(どれがそれをケースに入れるか、SHOULD、暫定的な1xx応答で要約されてください、) 同様に、ゲートウェイで200OKを受け取る前に由来側(たぶんINRに対応した)に受け取るメッセージはINFOの中で伝えられるべきです。 このメカニズムが適切に順方向に機能するように、どんな必要なContactやTo-タグも前の暫定的な応答に現れなかったかもしれないに違いありませんか、メッセージは正しく目的地に発送されないかもしれません。 そういうものとしてすべてのSIP-Tゲートウェイが、最終的な応答を受ける前に出す新しい要求の適切なルーティングを可能にするためにContactヘッダーとどんな必要なタグでもすべての暫定的な応答を送らなければなりません。 また、INVITE取引が完成INFO要求SHOULDであるときには、この方向に使用されてください。
Camarillo, et. al. Standards Track [Page 59] RFC 3398 ISUP to SIP Mapping December 2002
etキャマリロ、アル。 規格は、2002年12月を写像して、ちびちび飲むためにRFC3398ISUPを追跡します[59ページ]。
14. Acronyms
14. 頭文字語
ACK Acknowledgment
ACM Address Complete Message
ANM Answer Message
ANSI American National Standards Institute
BLA Blocking ACK message
BLO Blocking Message
CGB Circuit Group Blocking Message
CGBA Circuit Group Blocking ACK Message
CHG Charging Information Message
CON Connect Message
CPG Call Progress Message
CUG Closed User Group
GRA Circuit Group Reset ACK Message
GRS Circuit Group Reset Message
HLR Home Location Register
IAM Initial Address Message
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
ITU-T International Telecommunication Union
Telecommunication Standardization Sector
MG Media Gateway
MGC Media Gateway Controller
MTP Message Transfer Part
REL Release Message
RES Resume Message
RLC Release Complete Message
RTP Real-time Transport Protocol
SCCP Signaling Connection Control Part
SG Signaling Gateway
SIP Session Initiation Protocol
SS7 Signaling System No. 7
SUS Suspend Message
TTC Telecommunication Technology Committee
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
VoIP Voice over IP
ACK Acknowledgment ACM Address Complete Message ANM Answer Message ANSI American National Standards Institute BLA Blocking ACK message BLO Blocking Message CGB Circuit Group Blocking Message CGBA Circuit Group Blocking ACK Message CHG Charging Information Message CON Connect Message CPG Call Progress Message CUG Closed User Group GRA Circuit Group Reset ACK Message GRS Circuit Group Reset Message HLR Home Location Register IAM Initial Address Message IETF Internet Engineering Task Force IP Internet Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part ITU-T International Telecommunication Union Telecommunication Standardization Sector MG Media Gateway MGC Media Gateway Controller MTP Message Transfer Part REL Release Message RES Resume Message RLC Release Complete Message RTP Real-time Transport Protocol SCCP Signaling Connection Control Part SG Signaling Gateway SIP Session Initiation Protocol SS7 Signaling System No. 7 SUS Suspend Message TTC Telecommunication Technology Committee UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol VoIP Voice over IP
15. Security Considerations
15. Security Considerations
The translation of ISUP parameters into SIP headers may introduce some privacy and security concerns above and beyond those that have been identified for other functions of SIP-T [9A]. Merely securing encapsulated ISUP, for example, would not provide adequate privacy
The translation of ISUP parameters into SIP headers may introduce some privacy and security concerns above and beyond those that have been identified for other functions of SIP-T [9A]. Merely securing encapsulated ISUP, for example, would not provide adequate privacy
Camarillo, et. al. Standards Track [Page 60] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 60] RFC 3398 ISUP to SIP Mapping December 2002
for a user requesting presentation restriction if the Calling Party Number parameter is openly mapped to the From header. Section 12.2 shows how SIP Privacy [9B] should be used for this function. Since the scope of SIP-ISUP mapping has been restricted to only those parameters that will be translated into the headers and fields used to route SIP requests, gateways consequently reveal through translation the minimum possible amount of information.
for a user requesting presentation restriction if the Calling Party Number parameter is openly mapped to the From header. Section 12.2 shows how SIP Privacy [9B] should be used for this function. Since the scope of SIP-ISUP mapping has been restricted to only those parameters that will be translated into the headers and fields used to route SIP requests, gateways consequently reveal through translation the minimum possible amount of information.
A security analysis of ISUP is beyond the scope of this document. ISUP bridging across SIP is discussed more fully in [9A], but Section 7.2.1.1 discusses processing the translated ISUP values in relation to any embedded ISUP in a request arriving at PSTN gateway. Lack of ISUP security analysis may pose some risks if embedded ISUP is blindly interpreted. Accordingly, gateways SHOULD NOT blindly trust embedded ISUP unless the request was strongly authenticated [9A], and the sender is trusted, e.g., is another MGC that is authorized to use ISUP over SIP in bridge mode. When requests are received from arbitrary end points, gateways SHOULD filter any received ISUP. In particular, only known-safe commands and parameters should be accepted or passed through. Filtering by deleting believed-to-be dangerous entries does not work well.
A security analysis of ISUP is beyond the scope of this document. ISUP bridging across SIP is discussed more fully in [9A], but Section 7.2.1.1 discusses processing the translated ISUP values in relation to any embedded ISUP in a request arriving at PSTN gateway. Lack of ISUP security analysis may pose some risks if embedded ISUP is blindly interpreted. Accordingly, gateways SHOULD NOT blindly trust embedded ISUP unless the request was strongly authenticated [9A], and the sender is trusted, e.g., is another MGC that is authorized to use ISUP over SIP in bridge mode. When requests are received from arbitrary end points, gateways SHOULD filter any received ISUP. In particular, only known-safe commands and parameters should be accepted or passed through. Filtering by deleting believed-to-be dangerous entries does not work well.
In most respects, the information that is translated from ISUP to SIP has no special security requirements. In order for translated parameters to be used to route requests, they should be legible to intermediaries; end-to-end confidentiality of this data would be unnecessary and most likely detrimental. There are also numerous circumstances under which intermediaries can legitimately overwrite the values that have been provided by translation, and hence integrity over these headers is similarly not desirable.
In most respects, the information that is translated from ISUP to SIP has no special security requirements. In order for translated parameters to be used to route requests, they should be legible to intermediaries; end-to-end confidentiality of this data would be unnecessary and most likely detrimental. There are also numerous circumstances under which intermediaries can legitimately overwrite the values that have been provided by translation, and hence integrity over these headers is similarly not desirable.
There are some concerns however that arise from the other direction of mapping, the mapping of SIP headers to ISUP parameters, which are enumerated in the following paragraphs. When end users dial numbers in the PSTN today, their selections populate the telephone number portion of the Called Party Number parameter, as well as the digit portions of the Carrier Identification Code and Transit Network Selection parameters of an ISUP IAM. Similarly, the tel URL and its optional parameters in the Request-URI of a SIP, which can be created directly by end users of a SIP device, map to those parameters at a gateway. However, in the PSTN, policy can prevent the user from dialing certain (invalid or restricted) numbers, or selecting certain carrier identification codes. Thus, gateway operators MAY wish to use corresponding policies to restrict the use of certain tel URLs, or tel URL parameters, when authorizing a call.
There are some concerns however that arise from the other direction of mapping, the mapping of SIP headers to ISUP parameters, which are enumerated in the following paragraphs. When end users dial numbers in the PSTN today, their selections populate the telephone number portion of the Called Party Number parameter, as well as the digit portions of the Carrier Identification Code and Transit Network Selection parameters of an ISUP IAM. Similarly, the tel URL and its optional parameters in the Request-URI of a SIP, which can be created directly by end users of a SIP device, map to those parameters at a gateway. However, in the PSTN, policy can prevent the user from dialing certain (invalid or restricted) numbers, or selecting certain carrier identification codes. Thus, gateway operators MAY wish to use corresponding policies to restrict the use of certain tel URLs, or tel URL parameters, when authorizing a call.
Camarillo, et. al. Standards Track [Page 61] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 61] RFC 3398 ISUP to SIP Mapping December 2002
The fields relevant to number portability, which include in ANSI ISUP the LRN portion of the Generic Address Parameter and the 'M' bit of the Forward Call Indicators, are used to route calls in the PSTN. Since these fields are rendered as tel URL parameters in the SIP-ISUP mapping, users can set the value of these fields arbitrarily. Consequently, an end-user could change the end office to which a call would be routed (though if LRN value were chosen at random, it is more likely that it would prevent the call from being delivered altogether). The PSTN is relatively resilient to calls that have been misrouted on account of local number portability, however. In some networks, a REL message with some sort of "misrouted ported number" cause code is sent in the backwards direction when such a condition arises. Alternatively, the PSTN switch to which a call was misrouted can forward the call along to the proper switch after making its own number portability query - this is an interim number portability practice that is still common in most segments of the PSTN that support portability. It is not anticipated that end users will typically set these SIP fields, and the risks associated with allowing an adventurous or malicious user to set the LRN do not seem to be grave, but they should be noted by network operators. The limited degree to which SIP signaling contributes to the interworking indicators of the Forward Call Indicators and Backward Call Indicator parameters incurs no foreseeable risks.
The fields relevant to number portability, which include in ANSI ISUP the LRN portion of the Generic Address Parameter and the 'M' bit of the Forward Call Indicators, are used to route calls in the PSTN. Since these fields are rendered as tel URL parameters in the SIP-ISUP mapping, users can set the value of these fields arbitrarily. Consequently, an end-user could change the end office to which a call would be routed (though if LRN value were chosen at random, it is more likely that it would prevent the call from being delivered altogether). The PSTN is relatively resilient to calls that have been misrouted on account of local number portability, however. In some networks, a REL message with some sort of "misrouted ported number" cause code is sent in the backwards direction when such a condition arises. Alternatively, the PSTN switch to which a call was misrouted can forward the call along to the proper switch after making its own number portability query - this is an interim number portability practice that is still common in most segments of the PSTN that support portability. It is not anticipated that end users will typically set these SIP fields, and the risks associated with allowing an adventurous or malicious user to set the LRN do not seem to be grave, but they should be noted by network operators. The limited degree to which SIP signaling contributes to the interworking indicators of the Forward Call Indicators and Backward Call Indicator parameters incurs no foreseeable risks.
Some additional risks may result from the SIP response code to ISUP Cause Code parameter mapping. SIP user agents could conceivably respond to an INVITE from a gateway with any arbitrary SIP response code, and thus they can dictate (within the boundaries of the mappings supported by the gateway) the Q.850 cause code that will be sent by the gateway in the resulting REL message. Generally speaking, the manner in which a call is rejected is unlikely to provide any avenue for fraud or denial of service - to the best knowledge of the authors there is no cause code identified in this document that would signal that some call should not be billed, or that the network should take critical resources off-line. However, operators may want to scrutinize the set of cause codes that could be mapped from SIP response codes (listed in 7.2.6.1) to make sure that no undesirable network-specific behavior could result from operating a gateway supporting the recommended mappings. In some cases, operators MAY wish to implement gateway policies that use alternative mappings, perhaps selectively based on authorization data.
Some additional risks may result from the SIP response code to ISUP Cause Code parameter mapping. SIP user agents could conceivably respond to an INVITE from a gateway with any arbitrary SIP response code, and thus they can dictate (within the boundaries of the mappings supported by the gateway) the Q.850 cause code that will be sent by the gateway in the resulting REL message. Generally speaking, the manner in which a call is rejected is unlikely to provide any avenue for fraud or denial of service - to the best knowledge of the authors there is no cause code identified in this document that would signal that some call should not be billed, or that the network should take critical resources off-line. However, operators may want to scrutinize the set of cause codes that could be mapped from SIP response codes (listed in 7.2.6.1) to make sure that no undesirable network-specific behavior could result from operating a gateway supporting the recommended mappings. In some cases, operators MAY wish to implement gateway policies that use alternative mappings, perhaps selectively based on authorization data.
If the Request-URI and the To header field of a request received at a gateway differ, Section 7.2.1.1 recommends that the To header (if it is a telephone number) should map to the Original Called Number parameter, and the Request-URI to the Called Party Number parameter. However, the user can, at the outset of a request, select a To header field value that differs from the Request-URI; these two field values
If the Request-URI and the To header field of a request received at a gateway differ, Section 7.2.1.1 recommends that the To header (if it is a telephone number) should map to the Original Called Number parameter, and the Request-URI to the Called Party Number parameter. However, the user can, at the outset of a request, select a To header field value that differs from the Request-URI; these two field values
Camarillo, et. al. Standards Track [Page 62] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 62] RFC 3398 ISUP to SIP Mapping December 2002
are not required to be the same. This essentially allows a user to set the ISUP Original Called Number parameter arbitrarily. Any applications that rely on the Original Called Number for settlement purposes could be affected by this mapping recommendation. It is anticipated that future SIP work in this space will arrive at a better general account of the re-targeting of SIP requests that may be applicable to the OCN mapping.
are not required to be the same. This essentially allows a user to set the ISUP Original Called Number parameter arbitrarily. Any applications that rely on the Original Called Number for settlement purposes could be affected by this mapping recommendation. It is anticipated that future SIP work in this space will arrive at a better general account of the re-targeting of SIP requests that may be applicable to the OCN mapping.
The arbitrary population of the From header of requests by SIP user agents has some well-understood security implications for devices that rely on the From header as an accurate representation of the identity of the originator. Any gateway that intends to use the From header to populate the called party's number parameter of an ISUP IAM message should authenticate the originator of the request and make sure that they are authorized to assert that calling number (or make use of some more secure method to ascertain the identity of the caller). Note that gateways, like all other SIP user agents, MUST support Digest authentication as described in [1].
The arbitrary population of the From header of requests by SIP user agents has some well-understood security implications for devices that rely on the From header as an accurate representation of the identity of the originator. Any gateway that intends to use the From header to populate the called party's number parameter of an ISUP IAM message should authenticate the originator of the request and make sure that they are authorized to assert that calling number (or make use of some more secure method to ascertain the identity of the caller). Note that gateways, like all other SIP user agents, MUST support Digest authentication as described in [1].
There is another class of potential risk that is related to the cut- through of the backwards media path before the call is answered. Several practices described in this document recommend that a gateway signal an ACM when a called user agent returns a 18x provisional response code. At that time, backwards media will be cut through end-to-end in the ISUP network, and it is possible for the called user agent then to play arbitrary audio to the caller for an indefinite period of time before transmitting a final response (in the form of a 2xx or higher response code). There are conceivable respects in which this capability could be used illegitimately by the called user agent. It is also however a useful feature to allow progress tones and announcements to be played in the backwards direction in the 'ACM sent' state (so that the caller won't be billed for calls that don't actually complete but for which failure conditions must be rendered to the user as in-band audio). In fact, ISUP commonly uses this backwards cut-through capability in order to pass tones and announcements relating to the status of a call when an ISUP network interworks with legacy networks that are not capable of expressing Q.850 cause codes.
There is another class of potential risk that is related to the cut- through of the backwards media path before the call is answered. Several practices described in this document recommend that a gateway signal an ACM when a called user agent returns a 18x provisional response code. At that time, backwards media will be cut through end-to-end in the ISUP network, and it is possible for the called user agent then to play arbitrary audio to the caller for an indefinite period of time before transmitting a final response (in the form of a 2xx or higher response code). There are conceivable respects in which this capability could be used illegitimately by the called user agent. It is also however a useful feature to allow progress tones and announcements to be played in the backwards direction in the 'ACM sent' state (so that the caller won't be billed for calls that don't actually complete but for which failure conditions must be rendered to the user as in-band audio). In fact, ISUP commonly uses this backwards cut-through capability in order to pass tones and announcements relating to the status of a call when an ISUP network interworks with legacy networks that are not capable of expressing Q.850 cause codes.
It is the contention of the authors that SIP introduces no risks with regard to backwards media that do not exist in Q.931-ISUP mapping, but gateways implementers MAY develop an optional mechanism (possibly something that could be configured by an operator) that would cut off such 'early media' on a brief timer - it is unlikely that more than 20 or 30 seconds of early media is necessary to convey status information about the call (see Section 7.2.6). A more conservative approach would be to never cut through backwards media in the gateway until a 2xx final response has been received, provided that the
It is the contention of the authors that SIP introduces no risks with regard to backwards media that do not exist in Q.931-ISUP mapping, but gateways implementers MAY develop an optional mechanism (possibly something that could be configured by an operator) that would cut off such 'early media' on a brief timer - it is unlikely that more than 20 or 30 seconds of early media is necessary to convey status information about the call (see Section 7.2.6). A more conservative approach would be to never cut through backwards media in the gateway until a 2xx final response has been received, provided that the
Camarillo, et. al. Standards Track [Page 63] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 63] RFC 3398 ISUP to SIP Mapping December 2002
gateway implements some way of prevent clipping of the initial media associated with the call.
gateway implements some way of prevent clipping of the initial media associated with the call.
Unlike a traditional PSTN phone, a SIP user agent can launch multiple simultaneous requests in order to reach a particular resource. It would be trivial for a SIP user agent to launch 100 SIP requests at a 100 port gateway, thereby tying up all of its ports. A malicious user could choose to launch requests to telephone numbers that are known never to answer, which would saturate these resources indefinitely and potentially without incurring any charges. Gateways therefore MAY support policies that restrict the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack.
Unlike a traditional PSTN phone, a SIP user agent can launch multiple simultaneous requests in order to reach a particular resource. It would be trivial for a SIP user agent to launch 100 SIP requests at a 100 port gateway, thereby tying up all of its ports. A malicious user could choose to launch requests to telephone numbers that are known never to answer, which would saturate these resources indefinitely and potentially without incurring any charges. Gateways therefore MAY support policies that restrict the number of simultaneous requests originating from the same authenticated source, or similar mechanisms to address this possible denial-of-service attack.
16. IANA Considerations
16. IANA Considerations
This document introduces no new considerations for IANA.
This document introduces no new considerations for IANA.
17. Acknowledgments
17. Acknowledgments
This document existed as an Internet-Draft for four years, and it received innumerable contributions from members of the various Transport Area IETF working groups that it called home (which included the MMUSIC, SIP and SIPPING WGs). In particular, the authors would like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars Tovander, Al Varney and William T. Marshall for their help and feedback on this document. The authors would also like to thank ITU-T SG11 for their advice on ISUP procedures.
This document existed as an Internet-Draft for four years, and it received innumerable contributions from members of the various Transport Area IETF working groups that it called home (which included the MMUSIC, SIP and SIPPING WGs). In particular, the authors would like to thank Olli Hynonen, Tomas Mecklin, Bill Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada, Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir, Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars Tovander, Al Varney and William T. Marshall for their help and feedback on this document. The authors would also like to thank ITU-T SG11 for their advice on ISUP procedures.
18. Normative References
18. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
objects", RFC 3204, December 2001.
[3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
Camarillo, et. al. Standards Track [Page 64] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 64] RFC 3398 ISUP to SIP Mapping December 2002
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[5] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[8] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header
Field for the Session Initiation Protocol", RFC 3326, December
2002.
[9] Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header Field for the Session Initiation Protocol", RFC 3326, December 2002.
[9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63, RFC
3372, September 2002.
[9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[9B] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[9B] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
19. Non-Normative References
19. Non-Normative References
[10] International Telecommunications Union, "Application of the ISDN
user part of CCITT Signaling System No. 7 for international ISDN
interconnection", ITU-T Q.767, February 1991,
<http://www.itu.int>.
[10] International Telecommunications Union, "Application of the ISDN user part of CCITT Signaling System No. 7 for international ISDN interconnection", ITU-T Q.767, February 1991, <http://www.itu.int>.
[11] American National Standards Institute, "Signaling System No. 7;
ISDN User Part", ANSI T1.113, January 1995,
<http://www.itu.int>.
[11] American National Standards Institute, "Signaling System No. 7; ISDN User Part", ANSI T1.113, January 1995, <http://www.itu.int>.
[12] International Telecommunications Union, "Signaling System No. 7;
ISDN User Part Signaling procedures", ITU-T Q.764, December
1999, <http://www.itu.int>.
[12] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, December 1999, <http://www.itu.int>.
[13] International Telecommunications Union, "Abnormal conditions -
Special release", ITU-T Q.118, September 1997,
<http://www.itu.int>.
[13] International Telecommunications Union, "Abnormal conditions - Special release", ITU-T Q.118, September 1997, <http://www.itu.int>.
[14] International Telecommunications Union, "Specifications of
Signaling System No. 7 - ISDN supplementary services", ITU-T
Q.737, June 1997, <http://www.itu.int>.
[14] International Telecommunications Union, "Specifications of Signaling System No. 7 - ISDN supplementary services", ITU-T Q.737, June 1997, <http://www.itu.int>.
Camarillo, et. al. Standards Track [Page 65] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 65] RFC 3398 ISUP to SIP Mapping December 2002
[15] International Telecommunications Union, "Usage of cause location
in the Digital Subscriber Signaling System No. 1 and the
Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998,
<http://www.itu.int>.
[15] International Telecommunications Union, "Usage of cause location in the Digital Subscriber Signaling System No. 1 and the Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998, <http://www.itu.int>.
[16] International Telecommunications Union, "The international
public telecommunications numbering plan", ITU-T E.164, May
1997, <http://www.itu.int>.
[16] International Telecommunications Union, "The international public telecommunications numbering plan", ITU-T E.164, May 1997, <http://www.itu.int>.
[17] International Telecommunications Union, "Formats and codes of
the ISDN User Part of Signaling System No. 7", ITU-T Q.763,
December 1999, <http://www.itu.int>.
[17] International Telecommunications Union, "Formats and codes of the ISDN User Part of Signaling System No. 7", ITU-T Q.763, December 1999, <http://www.itu.int>.
[18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in SIP", RFC 3262, June 2002.
[18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in SIP", RFC 3262, June 2002.
[19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960, October 2000.
[20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of
Number Portability and Freephone Service", Work in Progress.
[21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of Number Portability and Freephone Service", Work in Progress.
Camarillo, et. al. Standards Track [Page 66] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 66] RFC 3398 ISUP to SIP Mapping December 2002
Authors' Addresses
Authors' Addresses
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Phone: +358 9 299 3371 URI: http://www.ericsson.com/ EMail: Gonzalo.Camarillo@Ericsson.com
Phone: +358 9 299 3371 URI: http://www.ericsson.com/ EMail: Gonzalo.Camarillo@Ericsson.com
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
URI: sip:adam@dynamicsoft.com EMail: adam@dynamicsoft.com
URI: sip:adam@dynamicsoft.com EMail: adam@dynamicsoft.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA
Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA
URI: http://www.ciena.com/ EMail: lyOng@ciena.com
URI: http://www.ciena.com/ EMail: lyOng@ciena.com
Camarillo, et. al. Standards Track [Page 67] RFC 3398 ISUP to SIP Mapping December 2002
Camarillo, et. al. Standards Track [Page 67] RFC 3398 ISUP to SIP Mapping December 2002
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Camarillo, et. al. Standards Track [Page 68]
Camarillo, et. al. Standards Track [Page 68]
一覧
スポンサーリンク
