RFC3976 日本語訳
3976 Interworking SIP and Intelligent Network (IN) Applications. V. K.Gurbani, F. Haerens, V. Rastogi. January 2005. (Format: TXT=60191 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. K. Gurbani
Request for Comments: 3976 Lucent Technologies, Inc.
Category: Informational F. Haerens
Alcatel Bell
V. Rastogi
Wipro Technologies
January 2005
Network Working Group V. K. Gurbani Request for Comments: 3976 Lucent Technologies, Inc. Category: Informational F. Haerens Alcatel Bell V. Rastogi Wipro Technologies January 2005
Interworking SIP and Intelligent Network (IN) Applications
Interworking SIP and Intelligent Network (IN) Applications
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
IESG Note
IESG Note
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
Abstract
Abstract
Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP).
Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP).
Gurbani, et al. Informational [Page 1] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 1] RFC 3976 Interworking SIP & IN January 2005
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Access to IN-Services from a SIP Entity. . . . . . . . . . . . 4
3. Additional SIN Considerations . . . . . . . . . . . . . . . . 7
3.1. The Concept of State in SIP. . . . . . . . . . . . . . . 7
3.2. Relationship between SCP and a SIN-Enabled SIP entity. . 7
3.3. SIP REGISTER and IN services . . . . . . . . . . . . . . 8
3.4. Support of Announcements and Mid-Call Signaling. . . . . 8
4. The SIN Architecture . . . . . . . . . . . . . . . . . . . . . 8
4.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IN Service Control Based on the SIN Approach . . . . . . 9
5. Mapping of the SIP State Machine to the IN State Model . . . . 10
5.1. Mapping SIP Protocol State Machine to O_BCSM . . . . . . 11
5.2. Mapping SIP Protocol State Machine to T_BCSM . . . . . . 16
6. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Access to IN-Services from a SIP Entity. . . . . . . . . . . . 4 3. Additional SIN Considerations . . . . . . . . . . . . . . . . 7 3.1. The Concept of State in SIP. . . . . . . . . . . . . . . 7 3.2. Relationship between SCP and a SIN-Enabled SIP entity. . 7 3.3. SIP REGISTER and IN services . . . . . . . . . . . . . . 8 3.4. Support of Announcements and Mid-Call Signaling. . . . . 8 4. The SIN Architecture . . . . . . . . . . . . . . . . . . . . . 8 4.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 8 4.2. IN Service Control Based on the SIN Approach . . . . . . 9 5. Mapping of the SIP State Machine to the IN State Model . . . . 10 5.1. Mapping SIP Protocol State Machine to O_BCSM . . . . . . 11 5.2. Mapping SIP Protocol State Machine to T_BCSM . . . . . . 16 6. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Introduction
1. Introduction
PSTN services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network. IN is an architectural concept for the real- time execution of network services and customer applications [1]. IN is, by design, de-coupled from the call processing component of the PSTN. In this document, we describe the means to leverage this decoupling to provide IN services from SIP-based entities.
PSTN services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network. IN is an architectural concept for the real- time execution of network services and customer applications [1]. IN is, by design, de-coupled from the call processing component of the PSTN. In this document, we describe the means to leverage this decoupling to provide IN services from SIP-based entities.
First, we will explain the basics of IN. Figure 1 shows a simplified IN architecture, in which telephone switches called Service Switching Points (SSPs) are connected via a packet network called Signaling System No. 7 (SS7) to Service Control Points (SCPs), which are general purpose computers. At certain points in a call, a switch can interrupt a call and request instructions from an SCP on how to proceed with the call. The points at which a call can be interrupted are standardized within the Basic Call State Model (BCSM) [1, 2]. The BCSM models contain two processes, one each for the originating and terminating part of a call.
First, we will explain the basics of IN. Figure 1 shows a simplified IN architecture, in which telephone switches called Service Switching Points (SSPs) are connected via a packet network called Signaling System No. 7 (SS7) to Service Control Points (SCPs), which are general purpose computers. At certain points in a call, a switch can interrupt a call and request instructions from an SCP on how to proceed with the call. The points at which a call can be interrupted are standardized within the Basic Call State Model (BCSM) [1, 2]. The BCSM models contain two processes, one each for the originating and terminating part of a call.
Gurbani, et al. Informational [Page 2] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 2] RFC 3976 Interworking SIP & IN January 2005
When the SCP receives a request for instructions, it can reply with a single response, such as a simple number translation augmented by criteria like time of day or day of week, or, in turn, initiate a complex dialog with the switch. The situation is further complicated by the necessity to engage other specialized devices that collect digits, play recorded announcements, perform text-to-speech or speech-to-text conversions, etc. (These devices are not discussed here.) The related protocol, as well as the BCSM, is standardized by the ITU-T and known as the Intelligent Network Application Part protocol (INAP) [4]. Only the protocol, not an SCP API, has been standardized.
When the SCP receives a request for instructions, it can reply with a single response, such as a simple number translation augmented by criteria like time of day or day of week, or, in turn, initiate a complex dialog with the switch. The situation is further complicated by the necessity to engage other specialized devices that collect digits, play recorded announcements, perform text-to-speech or speech-to-text conversions, etc. (These devices are not discussed here.) The related protocol, as well as the BCSM, is standardized by the ITU-T and known as the Intelligent Network Application Part protocol (INAP) [4]. Only the protocol, not an SCP API, has been standardized.
+-----------+
| |
| SCP |
| |
+-----------+
||
||
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
+-----------+ | | | SCP | | | +-----------+ || || / \ / \ / INAP \ / \ / \ +--------+ ISUP +--------+ | SSP |*********| SSP | +--------+ +--------+
Figure 1. Simplified IN Architecture
Figure 1. Simplified IN Architecture
The overall objective is to ensure that IN control of Voice over IP (VoIP) services in networks can be readily specified and implemented by adapting standards and software used in the present networks. This approach leads to services that function the same when a user connects to present or future networks, simplifies service evolution from present to future, and leads to more rapid implementation.
The overall objective is to ensure that IN control of Voice over IP (VoIP) services in networks can be readily specified and implemented by adapting standards and software used in the present networks. This approach leads to services that function the same when a user connects to present or future networks, simplifies service evolution from present to future, and leads to more rapid implementation.
The rest of this document is organized as follows: Section 2 contains the architectural model of an IN aware SIP entity. Section 3 provides some issues to be taken into account when performing SIP/IN interworking (SIN). Section 4 discusses the IN service control based on the SIN approach. The technique outlined in this document focuses on the call models of IN and the SIP protocol state machine; Section 5 thus establishes a complete mapping between the two state machines that allows access to IN services from SIP endpoints. Section 6 includes call flows of IN services executing on SIP endpoints. These services are readily enabled by the technique described in this document. Finally, Section 7 covers security aspects of SIN.
The rest of this document is organized as follows: Section 2 contains the architectural model of an IN aware SIP entity. Section 3 provides some issues to be taken into account when performing SIP/IN interworking (SIN). Section 4 discusses the IN service control based on the SIN approach. The technique outlined in this document focuses on the call models of IN and the SIP protocol state machine; Section 5 thus establishes a complete mapping between the two state machines that allows access to IN services from SIP endpoints. Section 6 includes call flows of IN services executing on SIP endpoints. These services are readily enabled by the technique described in this document. Finally, Section 7 covers security aspects of SIN.
Gurbani, et al. Informational [Page 3] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 3] RFC 3976 Interworking SIP & IN January 2005
List of Acronyms
List of Acronyms
B2BUA Back-to-Back User Agent
BCSM Basic Call State Model
CCF Call Control Function
DP Detection Point
DTMF Dual Tone Multi-Frequency
IN Intelligent Network
INAP Intelligent Network Application Part
IP Internet Protocol
ITU-T International Telecommunications Union -
Telecommunications Standardization Sector
O_BCSM Originating Basic Call State Model
PIC Point in Call
PSTN Public Switched Telephone Network
RTP Real Time Protocol
R-URI Request URI
SCF Service Control Function
SCP Service Control Point
SIGTRAN Signal Transport Working Group in IETF
SIN SIP/IN Interworking
SIP Session Initiation Protocol
SS7 Signaling System No. 7
SSF Service Switching Function
SSP Service Switching Point
T_BCSM Terminating Basic Call State Model
UA User Agent
UAC User Agent Client
UAS User Agent Server
VoIP Voice over IP
VPN Virtual Private Network
B2BUA Back-to-Back User Agent BCSM Basic Call State Model CCF Call Control Function DP Detection Point DTMF Dual Tone Multi-Frequency IN Intelligent Network INAP Intelligent Network Application Part IP Internet Protocol ITU-T International Telecommunications Union - Telecommunications Standardization Sector O_BCSM Originating Basic Call State Model PIC Point in Call PSTN Public Switched Telephone Network RTP Real Time Protocol R-URI Request URI SCF Service Control Function SCP Service Control Point SIGTRAN Signal Transport Working Group in IETF SIN SIP/IN Interworking SIP Session Initiation Protocol SS7 Signaling System No. 7 SSF Service Switching Function SSP Service Switching Point T_BCSM Terminating Basic Call State Model UA User Agent UAC User Agent Client UAS User Agent Server VoIP Voice over IP VPN Virtual Private Network
2. Access to IN-Services from a SIP Entity
2. Access to IN-Services from a SIP Entity
The intent of this document is to provide the means to support existing IN-based applications in a SIP [3] environment. One way to gain access to IN services transparently from SIP (e.g., through the same detection points (DPs) and point-in-call (PIC) used by traditional switches) is to map the SIP protocol state machine to the IN call models [1].
The intent of this document is to provide the means to support existing IN-based applications in a SIP [3] environment. One way to gain access to IN services transparently from SIP (e.g., through the same detection points (DPs) and point-in-call (PIC) used by traditional switches) is to map the SIP protocol state machine to the IN call models [1].
From the viewpoint of IN elements such as the SCP, the request's origin from a SIP entity rather than a call processing function on a traditional switch is immaterial. Thus, it is important that the SIP entity be able to provide the same features as the traditional switch, including operating as an SSP for IN features. The SIP entity should also maintain call state and trigger queries to IN- based services, as do traditional switches.
From the viewpoint of IN elements such as the SCP, the request's origin from a SIP entity rather than a call processing function on a traditional switch is immaterial. Thus, it is important that the SIP entity be able to provide the same features as the traditional switch, including operating as an SSP for IN features. The SIP entity should also maintain call state and trigger queries to IN- based services, as do traditional switches.
Gurbani, et al. Informational [Page 4] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 4] RFC 3976 Interworking SIP & IN January 2005
This document does not intend to specify which SIP entity shall operate as an SSP; however, for the sake of completeness, it should be mentioned that this task should be performed by SIP entities at (or near) the core of the network rather than at the SIP end points themselves. To that extent, SIP entities such as proxy servers and Back-to-Back user agents (B2BUAs) may be employed. Generally speaking, proxy servers can be used for IN services that occur during a call setup and teardown. For IN services requiring specialized media handling (such as DTMF detection) or specialized call control (such as placing parties on hold) B2BUAs will be required.
This document does not intend to specify which SIP entity shall operate as an SSP; however, for the sake of completeness, it should be mentioned that this task should be performed by SIP entities at (or near) the core of the network rather than at the SIP end points themselves. To that extent, SIP entities such as proxy servers and Back-to-Back user agents (B2BUAs) may be employed. Generally speaking, proxy servers can be used for IN services that occur during a call setup and teardown. For IN services requiring specialized media handling (such as DTMF detection) or specialized call control (such as placing parties on hold) B2BUAs will be required.
The most expeditious manner for providing existing IN services in the IP domain is to use the deployed IN infrastructure as often as possible. In SIP, the logical point to tap into for accessing existing IN services is either the user agents or one of the proxies physically closest to the user agent (and presumably in the same administrative domain). However, SIP entities do not run an IN call model; to access IN services transparently, the trick then is to overlay the state machine of the SIP entity with an IN layer so that call acceptance and routing is performed by the native state machine and so that services are accessed through the IN layer by using an IN call model. Such an IN-enabled SIP entity, operating in synchrony with the events occurring at the SIP transaction level and interacting with the IN elements (SCP), is depicted in Figure 2:
The most expeditious manner for providing existing IN services in the IP domain is to use the deployed IN infrastructure as often as possible. In SIP, the logical point to tap into for accessing existing IN services is either the user agents or one of the proxies physically closest to the user agent (and presumably in the same administrative domain). However, SIP entities do not run an IN call model; to access IN services transparently, the trick then is to overlay the state machine of the SIP entity with an IN layer so that call acceptance and routing is performed by the native state machine and so that services are accessed through the IN layer by using an IN call model. Such an IN-enabled SIP entity, operating in synchrony with the events occurring at the SIP transaction level and interacting with the IN elements (SCP), is depicted in Figure 2:
+-------+
| SCP |
+---+---+
|
| INAP
|
+--------+
| SIN |
+........+
| SIP |
---------->| Entity |--------->
Requests | | Requests out
in +--------+ (after applying IN
services)
+-------+ | SCP | +---+---+ | | INAP | +--------+ | SIN | +........+ | SIP | ---------->| Entity |---------> Requests | | Requests out in +--------+ (after applying IN services)
SIN: SIP/IN Interworking layer
SIN: SIP/IN Interworking layer
Figure 2. SIP Entity Accessing IN Services
Figure 2. SIP Entity Accessing IN Services
Section 5 proposes this mapping between the IN layer and the SIP protocol state machine. Essentially, a SIP entity exhibiting this mapping becomes a SIN-enabled SIP entity.
Section 5 proposes this mapping between the IN layer and the SIP protocol state machine. Essentially, a SIP entity exhibiting this mapping becomes a SIN-enabled SIP entity.
Gurbani, et al. Informational [Page 5] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 5] RFC 3976 Interworking SIP & IN January 2005
This document does not propose any extensions to SIP.
This document does not propose any extensions to SIP.
Figure 3 expands the SIP entity depicted in Figure 2 and further details the architecture model involving IN and SIP interworking. Events occurring at the SIP layer will be passed to the IN layer for service application. More specifically, since IN services deal with E.164 numbers, it is reasonable to assume that a SIN-enabled SIP entity that seeks to provide services on such a number will consult the IN layer for further processing, thus acting as a SIP-based SSP. The IN layer will proceed through its BCSM states and, at appropriate points in the call, will send queries to the SCP for call disposition. Once the disposition of the call has been determined, the SIP layer is informed and processes the transaction accordingly.
Figure 3 expands the SIP entity depicted in Figure 2 and further details the architecture model involving IN and SIP interworking. Events occurring at the SIP layer will be passed to the IN layer for service application. More specifically, since IN services deal with E.164 numbers, it is reasonable to assume that a SIN-enabled SIP entity that seeks to provide services on such a number will consult the IN layer for further processing, thus acting as a SIP-based SSP. The IN layer will proceed through its BCSM states and, at appropriate points in the call, will send queries to the SCP for call disposition. Once the disposition of the call has been determined, the SIP layer is informed and processes the transaction accordingly.
Note that the single SIP entity as modeled in this figure can in fact represent several different physical instances in the network as, for example, when one SIP entity is in charge of the terminal or access network/domain, and another is in charge of the interface to the Switched Circuit Network (SCN).
Note that the single SIP entity as modeled in this figure can in fact represent several different physical instances in the network as, for example, when one SIP entity is in charge of the terminal or access network/domain, and another is in charge of the interface to the Switched Circuit Network (SCN).
+-------+
| SCP |
+---o---+
|
+-----+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF(IP) | | *
* |+-------------+ | *
* || CCF(IP) | | *
* |+------o------+ | *
* +-------|-------------------+ *
* | SIN-enabled *
* +-------o-------------------+ SIP *
* | SIP Layer | Entity *
* +---------------------------+ *
**********************************************
+-------+ | SCP | +---o---+ | +-----+ | **********|*********************************** * +-------|-------------------+ * * |+------o------+ | * * || SSF(IP) | | * * |+-------------+ | * * || CCF(IP) | | * * |+------o------+ | * * +-------|-------------------+ * * | SIN-enabled * * +-------o-------------------+ SIP * * | SIP Layer | Entity * * +---------------------------+ * **********************************************
Figure 3. Functional Architecture of a SIN-Enabled SIP Entity
Figure 3. Functional Architecture of a SIN-Enabled SIP Entity
The following architecture entities, used in Figure 3, are defined in the Intelligent Network standards:
The following architecture entities, used in Figure 3, are defined in the Intelligent Network standards:
Service Switching Function (SSF): IN functional entity that
interacts with call control functions.
Service Switching Function (SSF): IN functional entity that interacts with call control functions.
Gurbani, et al. Informational [Page 6] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 6] RFC 3976 Interworking SIP & IN January 2005
Call Control Function (CCF): IN functional entity that refers
to call and connection handling in the classical sense (i.e.,
that of an exchange).
Call Control Function (CCF): IN functional entity that refers to call and connection handling in the classical sense (i.e., that of an exchange).
3. Additional SIN Considerations
3. Additional SIN Considerations
In working between Internet Telephony and IN-PSTN networks, the main issue is to translate between the states produced by the Internet Telephony signaling and those used in traditional IN environments. Such a translation entails attention to the considerations listed below.
In working between Internet Telephony and IN-PSTN networks, the main issue is to translate between the states produced by the Internet Telephony signaling and those used in traditional IN environments. Such a translation entails attention to the considerations listed below.
3.1. The Concept of State in SIP
3.1. The Concept of State in SIP
IN services occur within the context of a call, i.e., during call setup, call teardown, or in the middle of a call. SIP entities such as proxies, with which some of these services may be realized, typically run in transaction-stateful (or stateless) mode. In this mode, a SIP proxy that proxied the initial INVITE is not guaranteed to receive a subsequent request, such as a BYE. Fortunately, SIP has primitives to force proxies to run in a call-stateful mode; namely, the Record-Route header. This header forces the user agent client (UAC) and user agent server (UAS) to create a "route set" that consists of all intervening proxies through which subsequent requests must traverse. Thus SIP proxies must run in call-stateful mode in order to provide IN services on behalf of the UAs.
IN services occur within the context of a call, i.e., during call setup, call teardown, or in the middle of a call. SIP entities such as proxies, with which some of these services may be realized, typically run in transaction-stateful (or stateless) mode. In this mode, a SIP proxy that proxied the initial INVITE is not guaranteed to receive a subsequent request, such as a BYE. Fortunately, SIP has primitives to force proxies to run in a call-stateful mode; namely, the Record-Route header. This header forces the user agent client (UAC) and user agent server (UAS) to create a "route set" that consists of all intervening proxies through which subsequent requests must traverse. Thus SIP proxies must run in call-stateful mode in order to provide IN services on behalf of the UAs.
A B2BUA is another SIP element in which IN services can be realized. As a B2BUA is a true SIP UA, it maintains complete call state and is thus capable of providing IN services.
A B2BUA is another SIP element in which IN services can be realized. As a B2BUA is a true SIP UA, it maintains complete call state and is thus capable of providing IN services.
3.2. Relationship between SCP and a SIN-Enabled SIP Entity
3.2. Relationship between SCP and a SIN-Enabled SIP Entity
In the architecture model proposed in this document, each SIN-enabled SIP entity is pre-configured to communicate with one logical SCP server, using whatever communication mechanism is appropriate. Different SIP servers (e.g., those in different administrative domains) may communicate with different SCP servers, so that there is no single SCP server responsible for all SIP servers.
In the architecture model proposed in this document, each SIN-enabled SIP entity is pre-configured to communicate with one logical SCP server, using whatever communication mechanism is appropriate. Different SIP servers (e.g., those in different administrative domains) may communicate with different SCP servers, so that there is no single SCP server responsible for all SIP servers.
As Figures 1 and 2 depict, the IN-portion of the SIN-enabled SIP entity will communicate with the SCP. This interface between the IN call handling layer and the SCP is not specified by this document and, indeed, can be any one of the following, depending on the interfaces supported by the SCP: INAP over IP, INAP over SIGTRAN, or INAP over SS7.
As Figures 1 and 2 depict, the IN-portion of the SIN-enabled SIP entity will communicate with the SCP. This interface between the IN call handling layer and the SCP is not specified by this document and, indeed, can be any one of the following, depending on the interfaces supported by the SCP: INAP over IP, INAP over SIGTRAN, or INAP over SS7.
Gurbani, et al. Informational [Page 7] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 7] RFC 3976 Interworking SIP & IN January 2005
This document is only applicable when SIP-controlled Internet telephony devices seek to operate with PSTN devices. The SIP UAs using this interface would typically appear together with a media gateway. This document is *not* applicable in an all-IP network and is not needed in cases where PSTN media gateways (not speaking SIP) need to communicate with SCPs.
This document is only applicable when SIP-controlled Internet telephony devices seek to operate with PSTN devices. The SIP UAs using this interface would typically appear together with a media gateway. This document is *not* applicable in an all-IP network and is not needed in cases where PSTN media gateways (not speaking SIP) need to communicate with SCPs.
3.3. SIP REGISTER and IN Services
3.3. SIP REGISTER and IN Services
SIP REGISTER provisions a SIP Proxy or SIP Registration server. The process is similar to the provisioning of an SCP/HLR in the switched circuit network. SCPs that provide VoIP based services can leverage this information directly. However, this document neither endorses nor prohibits such an architecture and, in fact, considers it an implementation decision.
SIP REGISTER provisions a SIP Proxy or SIP Registration server. The process is similar to the provisioning of an SCP/HLR in the switched circuit network. SCPs that provide VoIP based services can leverage this information directly. However, this document neither endorses nor prohibits such an architecture and, in fact, considers it an implementation decision.
3.4. Support of Announcements and Mid-Call Signaling
3.4. Support of Announcements and Mid-Call Signaling
Services in the IN such as credit-card calling typically play announcements and collect digits from the caller before a call is set up. Playing announcements and collecting digits require the manipulation of media streams. In SIP, proxies do not have access to the media data path. Thus, such services should be executed in a B2BUA.
Services in the IN such as credit-card calling typically play announcements and collect digits from the caller before a call is set up. Playing announcements and collecting digits require the manipulation of media streams. In SIP, proxies do not have access to the media data path. Thus, such services should be executed in a B2BUA.
Although the SIP specification [3] allows for end points to be put on hold during a call or for a change of media streams to take place, it does not have any primitives to transport other than mid-call control information. This may include transporting DTMF digits, for example. Extensions to SIP, such as the INFO method [5] or the SIP event notification extension [6], can be considered for services requiring mid-call signaling. Alternatively, DTMF can be transported in RTP itself [7].
Although the SIP specification [3] allows for end points to be put on hold during a call or for a change of media streams to take place, it does not have any primitives to transport other than mid-call control information. This may include transporting DTMF digits, for example. Extensions to SIP, such as the INFO method [5] or the SIP event notification extension [6], can be considered for services requiring mid-call signaling. Alternatively, DTMF can be transported in RTP itself [7].
4. The SIN Architecture
4. The SIN Architecture
4.1. Definitions
4.1. Definitions
The SIP architecture has the following functional elements defined in [3]:
The SIP architecture has the following functional elements defined in [3]:
- User agent client (UAC): The SIP functional entity that
initiates a request.
- User agent client (UAC): The SIP functional entity that initiates a request.
- User agent server (UAS): The SIP functional entity that
terminates a request by sending 0 or more provisional SIP
responses and one final SIP response.
- User agent server (UAS): The SIP functional entity that terminates a request by sending 0 or more provisional SIP responses and one final SIP response.
Gurbani, et al. Informational [Page 8] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 8] RFC 3976 Interworking SIP & IN January 2005
- Proxy server: An intermediary SIP entity that can act as both a
UAS and a UAC. Acting as a UAS, it accepts requests from UACs,
rewrites the Request-URI (R-URI), and, acting as a UAC, proxies
the request to a downstream UAS. Proxies may retain
significant call control state by inserting themselves in
future SIP transactions beyond the initial INVITE.
- Proxy server: An intermediary SIP entity that can act as both a UAS and a UAC. Acting as a UAS, it accepts requests from UACs, rewrites the Request-URI (R-URI), and, acting as a UAC, proxies the request to a downstream UAS. Proxies may retain significant call control state by inserting themselves in future SIP transactions beyond the initial INVITE.
- Redirect server: An intermediary SIP entity that redirects
callers to alternate locations, after possibly consulting a
location server to determine the exact location of the callee
(as specified in the R-URI).
- Redirect server: An intermediary SIP entity that redirects callers to alternate locations, after possibly consulting a location server to determine the exact location of the callee (as specified in the R-URI).
- Registrar: A SIP entity that accepts SIP REGISTER requests and
maintains a binding from a high-level URL to the exact location
for a user. This information is saved in some data-store that
is also accessible to a SIP Proxy and a SIP Redirect server. A
Registrar is usually co-located with a SIP Proxy or a SIP
Redirect server.
- Registrar: A SIP entity that accepts SIP REGISTER requests and maintains a binding from a high-level URL to the exact location for a user. This information is saved in some data-store that is also accessible to a SIP Proxy and a SIP Redirect server. A Registrar is usually co-located with a SIP Proxy or a SIP Redirect server.
- Outbound proxy: A SIP proxy located near the originator of
requests. It receives all outgoing requests from a particular
UAC, including those requests whose R-URIs identify a host
other than the outbound proxy. The outbound proxy sends these
requests, after any local processing, to the address indicated
in the R-URI.
- Outbound proxy: A SIP proxy located near the originator of requests. It receives all outgoing requests from a particular UAC, including those requests whose R-URIs identify a host other than the outbound proxy. The outbound proxy sends these requests, after any local processing, to the address indicated in the R-URI.
- Back-to-Back UA (B2BUA): A SIP entity that receives a request
and processes it as a UAS. It also acts as a UAC and generates
requests to determine how the incoming request is to be
answered. A B2BUA maintains complete dialog state and must
participate in all requests sent within the dialog.
- Back-to-Back UA (B2BUA): A SIP entity that receives a request and processes it as a UAS. It also acts as a UAC and generates requests to determine how the incoming request is to be answered. A B2BUA maintains complete dialog state and must participate in all requests sent within the dialog.
4.2. IN Service Control Based on the SIN Approach
4.2. IN Service Control Based on the SIN Approach
Figure 4 depicts the possibility of IN service control based on the
SIN approach. On both the originating and terminating ends, a SIN-
capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O
SIP" entity is required for outgoing calls that require support for
existing IN services. Likewise, on the callee's side (or terminating
side), an equally configured entity ("T SIP") will be required to
provide terminating side services. Note that the "O SIP" and "T SIP"
entities correspond, respectively, to the IN O_BCSM and T_BCSM halves
of the IN call model.
Figure 4 depicts the possibility of IN service control based on the SIN approach. On both the originating and terminating ends, a SIN- capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O SIP" entity is required for outgoing calls that require support for existing IN services. Likewise, on the callee's side (or terminating side), an equally configured entity ("T SIP") will be required to provide terminating side services. Note that the "O SIP" and "T SIP" entities correspond, respectively, to the IN O_BCSM and T_BCSM halves of the IN call model.
Gurbani, et al. Informational [Page 9] RFC 3976 Interworking SIP & IN January 2005
Gurbani, et al. Informational [Page 9] RFC 3976 Interworking SIP & IN January 2005
+---+ +---+
| S | (~~~~~~~~~~~~~) | S |
| C |<--+ ( ) +-->| C |
| P | | ( ) | | P |
+---+ | ( Switched ) | +---+
| ( Circuit ) |
V ( Network ) V
+-------+ ( ) +-------+
| SIN | +---------+ +---------+ | SIN |
+-------+----| Gateway | ... | Gateway |------+-------+
| O SIP | +---------+ +---------+ | T SIP |
+-------+ ( ) +-------+
( )
(.............)
+---+ +---+ | S | (~~~~~~~~~~~~~) | S | | C |<--+ ( ) +-->| C | | P | | ( ) | | P | +---+ | ( Switched ) | +---+ | ( Circuit ) | V ( Network ) V +-------+ ( ) +-------+ | SIN | +---------+ +---------+ | SIN | +-------+----| Gateway | ... | Gateway |------+-------+ | O SIP | +---------+ +---------+ | T SIP | +-------+ ( ) +-------+ ( ) (.............)
O SIP: Originating SIP entity
T SIP: Terminating SIP entity
O SIP: Originating SIP entity T SIP: Terminating SIP entity
Figure 4. Overall SIN Architecture
Figure 4. Overall SIN Architecture
5. Mapping of the SIP State Machine to the IN State Model
5. Mapping of the SIP State Machine to the IN State Model
This section establishes the mapping of the SIP protocol state machine to the IN generic basic call state model (BCSM) [2], independent of any capability sets [8, 9]. The BCSM is divided into two halves: an originating call model (O_BCSM) and a terminating call model (T_BCSM). There are a total of 19 PICs and 35 DPs between both the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for T_BCSM) [1]. The SSPs, SCPs, and other IN elements track a call's progress in terms of the basic call model. The basic call model provides a common context for communication about a call.
This section establishes the mapping of the SIP protocol state machine to the IN generic basic call state model (BCSM) [2], independent of any capability sets [8, 9]. The BCSM is divided into two halves: an originating call model (O_BCSM) and a terminating call model (T_BCSM). There are a total of 19 PICs and 35 DPs between both the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for T_BCSM) [1]. The SSPs, SCPs, and other IN elements track a call's progress in terms of the basic call model. The basic call model provides a common context for communication about a call.
O_BCSM has 11 PICs:
O_BCSM has 11 PICs:
O_NULL: Starting state; call does not exist yet.
AUTH_ORIG_ATTEMPT: Switch detects a call setup request.
COLLECT_INFO: Switch collects the dial string from the calling party.
ANALYZE_INFO: Complete dial string is translated into a routing
address.
SELECT_ROUTE: Physical route is selected, based on the routing
address.
AUTH_CALL_SETUP: Switch ensures the calling party is authorized to
place the call.
CALL_SENT: Control of call sent to terminating side.
O_ALERTING: Switch waits for the called party to answer.
O_ACTIVE: Connection established; communications ensue.
O_DISCONNECT: Connection torn down.
O_EXCEPTION: Switch detects an exceptional condition.
○ _ヌル: 始めの状態。 呼び出しはまだ存在していません。 AUTH_ORIG_試み: スイッチは呼び出しセットアップ要求を検出します。 _インフォメーションを集めてください: スイッチは起呼側からダイヤルストリングを集めます。 _インフォメーションを分析してください: 完全なダイヤルストリングはルーティングアドレスに翻訳されます。 _ルートを選択してください: 物理的なルートはルーティングアドレスに基づいて選択されます。 AUTH_呼び出し_セットアップ: スイッチは、起呼側が電話をするのに権限を与えられるのを確実にします。 呼び出し_は発信しました: 呼び出しのコントロールは側を終えるのに発信しました。 ○ _警告: スイッチは、被呼者が答えるのを待っています。 O_アクティブ: 接続確立する。 コミュニケーションは続きます。 ○ _連絡を断ってください: 取りこわされた接続。 O_例外: スイッチは例外的な状態を検出します。
Gurbani, et al. Informational [Page 10] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[10ページ]のRFC3976の織り込むこと
T_BCSM has 8 PICS:
T_BCSMには、8つの映画があります:
T_NULL: Starting state; call does not exist yet.
AUTH_TERM_ATT: Switch verifies whether the call can be sent to
terminating party.
SELECT_FACILITY: Switch picks a terminating resource to send the call
on.
PRESENT_CALL: Call is being presented to the called party.
T_ALERTING: Switch alerts the called party, e.g., by ringing the
line.
T_ACTIVE: Connection established; communications ensue.
T_DISCONNECT: Connection torn down.
T_EXCEPTION: Switch detects an exceptional condition.
T_ヌル: 始めの状態。 呼び出しはまだ存在していません。 AUTH_用語_ATT: スイッチは、パーティーを終えるのに呼び出しを送ることができるかどうか確かめます。 _施設を選択してください: スイッチは呼び出しを送る終わりリソースを選びます。 プレゼント_は呼びます: 呼び出しは被呼者に提示されています。 T_警告: スイッチは、例えば、線を鳴らすことによって、被呼者を警告します。 T_アクティブ: 接続確立する。 コミュニケーションは続きます。 T_は連絡を断ちます: 取りこわされた接続。 T_例外: スイッチは例外的な状態を検出します。
The state machine for O_BCSM and T_BCSM is provided in [1] on pages 98 and 103, respectively. This state machine will be used for subsequent discussion when the IN call states are mapped into SIP.
98と103ページでそれぞれ_O BCSMと_T BCSMのための州のマシンを[1]に提供します。 IN呼び出し状態がSIPに写像されるとき、この州のマシンはその後の議論に使用されるでしょう。
The next two sections contain the mapping of the SIP protocol state machine to the IN BCSMs. Explaining all PICs and DPs in an IN call model is beyond the scope of this document. It is assumed that the reader has some familiarity with the PICs and DPs of the IN call model. More information can be found in [1]. For a quick reference, Appendix A contains a mapping of the DPs to the SIP response codes as discussed in the next two sections.
次の2つのセクションがSIPプロトコル州のマシンに関するマッピングをIN BCSMsに含みます。IN呼び出しモデルですべてのPICsとDPsについて説明するのはこのドキュメントの範囲を超えています。 読者がIN呼び出しモデルのPICsとDPsに何らかの親しみを持っていると思われます。 [1]で詳しい情報を見つけることができます。 クイックリファレンスのために、Appendix Aは次の2つのセクションで議論するようにSIP応答コードにDPsに関するマッピングを含んでいます。
5.1. Mapping SIP Protocol State Machine to O_BCSM
5.1. 一口プロトコル州のマシンをO_BCSMに写像します。
The 11 PICs of O_BCSM come into play when a call request (SIP INVITE message) arrives from an upstream SIP client to an originating SIN- enabled SIP entity running the IN call model. This entity will create an O_BCSM object and initialize it in the O_NULL PIC. The next seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO, SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all be mapped to the SIP "Calling" state.
発呼要求(SIP INVITEメッセージ)が上流のSIPクライアントから由来しているSINまで到着するとき、BCSMが活動し始めるO_の11PICsがIN呼び出しモデルを車で送るSIP実体を可能にしました。 この実体は、O_BCSM物を作成して、O_NULL PICでそれを初期化するでしょう。 次の7IN PICs(_O NULL、AUTH_ORIG_ATT、COLLECT_INFO、ANALYZE_INFO、SELECT_ROUTE、AUTH_CALL_SETUP、およびCALL_SENT)をSIP「呼ぶ」状態にすべて写像できます。
Figure 5 provides a visual map from the SIP protocol state machine to the originating half of the IN call model. Note that control of the call shuttles between the SIP protocol machine and the IN O_BCSM call model while it is being serviced.
図5はSIPプロトコル州のマシンから由来しているIN呼び出しモデルの半分まで視覚地図を提供します。 それが調整されている間呼び出しのコントロールがSIPプロトコルマシンとIN O_BCSM呼び出しモデルの間を往復することに注意してください。
Gurbani, et al. Informational [Page 11] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[11ページ]のRFC3976の織り込むこと
SIP O_BCSM
一口O_BCSM
| INVITE
V
+---------+ +---------------+
| Calling +=======================>+ O_NULL +<----+
+--+---/\-+ +-/\---+--------+ |
| | || +-------------+ | | |
| | ||<===+O_Exception +---------+ +--V-+ +--+-+
| | || +--/\---------+ |DP 1| |DP21|
| | || | +----+ +-----+----+------+ +--+-+
| | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 3| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 4|<-----+ Collect_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 5| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 6|<-----+ Analyze_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 7| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 8|<-----+ Select_Route +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 9| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP10|<-----+ Auth._Call_Setup+---->+
| | || +----+ +--------+--------+
+----+ | || |
| | || +--V-+
| | || |DP11|
| 1xx | || +-----+----+------+
| | ++========================+ Call_Sent |
| | +----/\----+------+
| | On 100,180,2xx process DP14 || |
| | On 3xx, process DP12 || |
| V On 486, process DP13 || |
| +--+-------+ On 5xx, 6xx and 4xx || |
| |Proceeding| (except 486) process DP21|| |
| V+を招待してください。---------+ +---------------+ | +と呼びます。=======================_>+Oヌル+<。----+ +--+---/\-+ +-/\---+--------+ | | | || +-------------+ | | | | | ||<==+ O_例外+---------+ +--V-++--++| | || +--/\---------+ |DP1| |DP21| | | || | +----+ +-----+----+------+ +--+-+ | | || + <。---+ DP2| <、-、-、-、--+ Auth_Orig_Att+---->+| | || | +----+ +--------+--------+ | | | || | | | | | || | +--V-+| | | || | |DP3| | | | || | +----+ +-----+----+------+ | | | || + <。---+ DP4| <、-、-、-、--+ 料金先方払いの_インフォメーション+---->+| | || | +----+ +--------+--------+ | | | || | | | | | || | +--V-+| | | || | |DP5| | | | || | +----+ +-----+----+------+ | | | || + <。---+ DP6| <、-、-、-、--+は_インフォメーション+を分析します。---->+| | || | +----+ +--------+--------+ | | | || | | | | | || | +--V-+| | | || | |DP7| | | | || | +----+ +-----+----+------+ | | | || + <。---+ DP8| <、-、-、-、--+ 選んだ_ルート+---->+| | || | +----+ +--------+--------+ | | | || | | | | | || | +--V-+| | | || | |DP9| | | | || | +----+ +-----+----+------+ | | | || + <。---+ DP10| <、-、-、-、--+ Auth_呼び出し_セットアップ+---->+| | || +----+ +--------+--------+ +----+ | || | | | || +--V-+| | || |DP11| | 1xx| || +-----+----+------+ | | ++========================+ 呼び出し_は発信しました。| | | +----/\----+------+ | | 10万180、2xxの過程DP14に関して|| | | | 3xxに、DP12を処理してください。|| | | 486、過程DP13のV|| | | +--+-------+ 5xx、6xx、および4xxに関して|| | | |進行| (486を除いた) 過程DP21|| |
Gurbani, et al. Informational [Page 12] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[12ページ]のRFC3976の織り込むこと
| +-+-+------+<=========================++ |
| | | |
| | | |
| | | |
| | +--200------------------+ |
| +----4xx to 6xx--------+ | |
| | | +--V-+
| On DPs 21, 2, 4, 6, 8, 10 | | |DP14|
| send 4xx-6xx final response | | +--------+----+--+
+-------+ | | | O_Alerting |
| | | +---------+------+
+--V-------+ | | |
|Completed |<------------+ | +--V-+
+--+-------+ | |DP16|
| | +------+----+----+
+--V-------+ | +-+ O_Active |
|Terminated|<---------------+ | +-------------+--+
+----------+ | |
+-----+ +--V-+
| |DP19|
+--V-+ +--------+----+
|DP17| | O_Disconnect|
+--+-+ +-------------+
|
V
To O_EXCEPTION
Legend:
| +-+-+------+ <。=========================++ | | | | | | | | | | | | | | | +--200------------------+ | | +----6xxへの4xx--------+ | | | | | +--V-+| 毎秒壊変数21、2、4、6、8、10に関して| | |DP14| | 4xx-6xxの最終的な応答を送ってください。| | +--------+----+--+ +-------+ | | | O_警告| | | | +---------+------+ +--V-------+ | | | |完成されます。| <、-、-、-、-、-、-、-、-、-、-、--+ | +--V-++--+-------+ | |DP16| | | +------+----+----+ +--V-------+ | ++O_アクティブです。| |終わります。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | +-------------+--+ +----------+ | | +-----+ +に対する+| |DP19| +--V-++--------+----+ |DP17| | O_は連絡を断ちます。| +--+-+ +-------------+ | ○ _例外伝説へのV:
| Communication between
| states in the same
V protocol
| 間のコミュニケーション| 同じVプロトコルの州
======> Communication between IN Layer and SIP Protocol
State machine to transfer call state
======呼び出し状態を移すIN LayerとSIPプロトコル州マシンとの>コミュニケーション
Figure 5. Mapping from SIP to O_BCSM
図5。 一口からOまで_BCSMを写像します。
The SIP "Calling" protocol state has enough functionality to absorb the seven PICs as described below:
「呼SIPの」プロトコル州には、7PICsを以下で説明されるように吸収されることができるくらいの機能性があります:
O_NULL: This PIC is basically a fall through state to the next
PIC, AUTHORIZE_ORIGINATION_ATTEMPT.
○ _ヌル: _このPICは基本的に次のPICへの状態を通した低下であり、AUTHORIZE_ORIGINATIONはATTEMPTです。
AUTHORIZE_ORIGINATION_ATTEMPT: In this PIC, the IN layer has
detected that someone wishes to make a call. Under some
circumstances (e.g., if the user is not allowed to make calls
during certain hours), such a call cannot be placed. SIP can
authorize the calling party by using a set of policy directives
_創作_試みを認可してください: このPICでは、IN層はそのだれかのために、電話をかけるという願望を検出しました。 いくつかの状況(例えば、ユーザが、ある時間電話をかけることができないなら)で、そのような電話を出すことができません。 1セットの方針指示を使用することによって、SIPは起呼側に権限を与えることができます。
Gurbani, et al. Informational [Page 13] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[13ページ]のRFC3976の織り込むこと
configured by the SIP administrator. If the called party is
authorized to place the call, the IN layer is instructed to enter
the next PIC, COLLECT_INFO through DP 3
(Origination_Attempt_Authorized). If for some reason the call
cannot be authorized, DP 2 (Origination_Denied) is processed, and
control transfers to the SIP state machine. The SIP state machine
must format and send a non-2xx final response (possibly 403) to
the upstream entity.
SIP管理者によって構成されます。 被呼者が電話をするのに権限を与えられるなら、IN層が次のPIC(DP3(創作_Attempt_Authorized)を通したCOLLECT_INFO)に入るよう命令されます。 ある理由で呼び出しを認可できないなら、DP2(創作_Denied)は処理されます、そして、コントロールはSIP州のマシンに移されます。 SIP州のマシンは、非2xxの最終的な応答(ことによると403)を上流の実体にフォーマットして、送らなければなりません。
COLLECT_INFO: This PIC is responsible for collecting a dial string
from the calling party and verifying the format of the string. If
overlap dialing is being used, this PIC can invoke DP 4
(Collect_Timeout) and transfer control to the SIP state machine,
which will format and send a non-2xx final response (possibly a
484). If the dial string is valid, DP 5 (Collected_Info) is
processed, and the IN layer is instructed to enter the next PIC,
ANALYZE_INFO.
_インフォメーションを集めてください: このPICは起呼側からダイヤルストリングを集めて、ストリングの形式について確かめるのに責任があります。 オーバラップのダイヤルするのが使用していることにされるのであるなら、このPICはDP4(_Timeoutを集めます)を呼び出して、SIP州のマシンにコントロールを移すことができます。(それは、非2xxの最終的な応答(ことによると484)をフォーマットして、送るでしょう)。 ダイヤルストリングが有効であるなら、DP5(_Infoを集めます)は処理されます、そして、IN層が次のPIC(ANALYZE_INFO)に入るよう命令されます。
ANALYZE_INFO: This PIC is responsible for translating the dial
string to a routing number. Many IN services, such as freephone,
LNP (Local Number Portability), and OCS (Originating Call
Screening) occur during this PIC. The IN layer can use the R-URI
of the SIP INVITE request for analysis. If the analysis succeeds,
the IN layer is instructed to enter the next PIC, SELECT_ROUTE.
If the analysis fails, DP 6 (Invalid_Info) is processed, and the
control transfers to the SIP state machine, which will generate a
non-2xx final response (possibly 400, 401, 403, 404, 405, 406,
410, 414, 415, 416, 485, or 488) and send it to the upstream
entity.
_インフォメーションを分析してください: このPICはダイヤルストリングをルーティング番号に翻訳するのに責任があります。 フリーダイヤルや、LNP(地方のNumber Portability)や、OCSなどの多くのINサービス(由来しているCall Screening)がこのPICの間、起こります。 IN層は分析にSIP INVITE要求のR-URIを使用できます。 分析が成功するなら、IN層が次のPIC、SELECT_ROUTEに入るよう命令されます。 分析が失敗して、DP6(病人_Info)が処理されて、コントロールがSIP州のマシン(非2xxの最終的な応答(ことによると400、401、403、404、405、406、410、414、415、416、485、または488)を発生させて、上流の実体にそれを送る)に移されるなら。
SELECT_ROUTE: In the circuit-switched network, the actual physical
route has to be selected at this point. The SIP analogue would be
to determine the next hop SIP server. This could be chosen by a
variety of means. For instance, if the Request URI in the
incoming INVITE request is an E.164 number, the SIP entity can use
a protocol like TRIP [10] to find the best gateway to egress the
request onto the PSTN. If a successful route is selected, the IN
call model moves to PIC AUTH_CALL_SETUP via DP 9 (Route_Selected).
Otherwise, the control transfers to the SIP state machine via DP 8
(Route_Select_Failure), which will generate a non-2xx final
response (possibly 488) and send it to the upstream entity.
_ルートを選択してください: 回路交換ネットワークでは、実際の物理的なルートはここに選択されなければなりません。 SIPアナログは次のホップSIPサーバを決定することになっているでしょう。これはさまざまな手段によって選ばれるかもしれません。 例えば、入って来るINVITE要求におけるRequest URIがE.164番号であるなら、SIP実体は、出口への最も良いゲートウェイにPSTNへの要求を見つけるのにTRIP[10]のようなプロトコルを使用できます。 うまくいっているルートが選択されるなら、IN呼び出しモデルはDP9(ルート_Selected)を通ってPIC AUTH_CALL_SETUPに移ります。 さもなければ、コントロールはDP8(_Select_Failureを発送します)を通してSIP州のマシンに移されます。DPは非2xxの最終的な応答(ことによると488)を発生させて、上流の実体にそれを送るでしょう。
AUTH_CALL_SETUP: Certain service features restrict the type of
call that may originate on a given line or trunk. This PIC is the
point at which relevant restrictions are examined. If no such
restrictions are encountered, the IN call model moves to PIC
CALL_SENT via DP 11 (Origination_Authorized). If a restriction is
encountered that prohibits further processing of the call, DP 10
AUTH_呼び出し_セットアップ: あるサービス機能は与えられた線かトランクの上に由来するかもしれない呼び出しのタイプを制限します。 このPICは関連制限が調べられるポイントです。 何かそのような制限が遭遇しないなら、IN呼び出しモデルはDP11(創作_Authorized)を通ってPIC CALL_SENTに移ります。 さらに呼び出しの処理、DP10を禁止する制限が遭遇するなら
Gurbani, et al. Informational [Page 14] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[14ページ]のRFC3976の織り込むこと
(Authorization_Failure) is processed, and control is transferred
to the SIP state machine, which will generate a non-2xx final
response (possibly 404, 488, or 502). Otherwise, DP 11
(Origination_Authorized) is processed, and the IN layer is
instructed to enter the next PIC, CALL_SENT.
(認可_Failure)を処理します、そして、SIP州のマシンにコントロールを移します。(それは、非2xxの最終的な応答(ことによると404、488、または502)を発生させるでしょう)。 さもなければ、DP11(創作_Authorized)は処理されます、そして、IN層が次のPIC、CALL_SENTに入るよう命令されます。
CALL_SENT: At this point, the request needs to be sent to the
downstream entity. The IN layer waits for a signal confirming
either that the call has been presented to the called party or
that a called party cannot be reached for a particular reason.
The control is transferred to the SIP state machine. The SIP
state machine should now send the call to the next downstream
server determined in PIC SELECT_ROUTE. The IN call model now
blocks until unblocked by the SIP state machine.
呼び出し_は発信しました: ここに、要求は、川下の実体に送られる必要があります。 被呼者に呼び出しを提示できなかったか、特定の理由で被呼者に連絡できないと確認しながら、IN層は信号を待っています。 SIP州のマシンにコントロールを移します。 SIP州のマシンは現在、PIC SELECT_ROUTEで決定している次の川下のサーバに呼び出しを送るはずです。 IN呼び出しは現在、SIP州のマシンによって「非-妨げ」られるまでブロックをモデル化します。
If the above seven PICs have been successfully negotiated, the
SIN-enabled SIP entity now sends the SIP INVITE message to the
next hop server. Further processing now depends on the
provisional responses (if any) and the final response received by
the SIP protocol state machine. The core SIP specification does
not guarantee the delivery of 1xx responses; thus special
processing is needed at the IN layer to transition to the next PIC
(O_ALERTING) from the CALL_SENT PIC. The special processing
needed for responses while the SIP state machine is in the
"Proceeding" state and the IN layer is in the "CALL_SENT" state is
described next.
上の7PICsが首尾よく交渉されたなら、SINによって可能にされたSIP実体は現在、次のホップサーバにSIP INVITEメッセージを送ります。さらなる処理は現在、(もしあれば)の暫定的な応答とSIPプロトコル州のマシンによって受けられた最終的な応答によります。 コアSIP仕様は1xx応答の配送を保証しません。 したがって、特別な処理がIN層でCALL_SENT PICから次のPIC(O_ALERTING)への変遷に必要です。 SIP州のマシンが「進行」状態にあって、IN層が「_が送った呼び出し」状態にありますが、応答に必要である特別な処理は次に、説明されます。
A 100 response received at the SIP state machine elicits no
special behavior in the IN layer.
SIP州のマシンで受けられた100応答はIN層の中でどんな特別な振舞いも引き出しません。
A 180 response received at the SIP entity enables the
processing of DP 14 (O_Term_Seized), however, a state
transition to O_ALERTING is not undertaken yet. Instead, the
IN layer is instructed to remain in the CALL_SENT PIC until a
final response is received.
SIP実体で受けられた180応答はDP14(○ _Term_Seized)の処理を可能にして、しかしながら、O_ALERTINGへの状態遷移はまだ引き受けられていません。 代わりに、最終的な応答が受け取られているまでIN層がCALL_SENT PICに残るよう命令されます。
A 2xx response received at the SIP entity enables the
processing of DP 14 (O_Term_Seized), and the immediate
transition to the next state, O_ALERTING (processing in
O_ALERTING is described later).
SIP実体で受けられた2xx応答はDP14(○ _Term_Seized)の処理、および次の状態への即座の変遷を可能にします、O_ALERTING(O_ALERTINGでの処理は後で説明されます)。
A 3xx response received at the SIP entity enables the
processing of DP 12 (Route_Failure). The IN call model from
this point goes back to the SELECT_ROUTE PIC to select a new
route for the contacts in the 3xx final response (not shown in
Figure 5 for brevity).
SIP実体で受けられた3xx応答はDP12(ルート_Failure)の処理を可能にします。 このポイントからのIN呼び出しモデルは、3xxの最終的な応答(図5では、簡潔さのために、目立たない)における接触に新しいルートを選択するためにSELECT_ROUTE PICに戻ります。
Gurbani, et al. Informational [Page 15] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[15ページ]のRFC3976の織り込むこと
A 486 (Busy Here) response received at the SIP entity enables
the processing of DP 13 (O_Called_Party_Busy) and resources for
the call are released at the IN call model.
SIP実体で受けられた486(忙しいHere)応答はDP13(_○ _Called_パーティBusy)の処理を可能にします、そして、呼び出しのためのリソースはIN呼び出しモデルで発表されます。
If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or
6xx final response, DP 21 (O_Calling_Party_Disconnect &
O_Abandon) is processed and control passes to the SIP state
machine. Since a call was not successfully established, both
the IN layer and the SIP state machine can release resources
for the call.
SINによって可能にされたSIP実体が4xx(486を除いた)、5xx、または6xxの最終的な応答を手に入れるなら、DP21(_○ _Calling_パーティ_Disconnect&O Abandon)は処理されます、そして、コントロールはSIP州のマシンに通ります。 呼び出しが首尾よく確立されなかったので、IN層とSIP州のマシンの両方が呼び出しのためのリソースを発表できます。
O_ALERTING - This PIC will be entered as a result of receiving a
200-class response. Since a 200-class response to an INVITE
indicates acceptance, this PIC is mostly a fall through to the
next PIC, O_ACTIVE via DP 16 (O_Answer).
O_ALERTING--200クラスの応答を受けることの結果、このPICは入られるでしょう。 INVITEへの200クラスの応答が承認を示すので、このPICはほとんど次のPICに終えた低下です、DP16(O_Answer)を通したO_ACTIVE。
O_ACTIVE - At this point, the call is active. Once in this state,
the call may get disconnected only when one of the following three
events occur: (1) the network connection fails, (2) the called
party disconnects the call, or (3) the calling party disconnects
the call. If event (1) occurs, DP 17 (O_Connection_Failure) is
processed and call control is transferred to the SIP protocol
state machine. Since the network failed, there is not much sense
in attempting to send a BYE request; thus, both the SIP protocol
state machine and the IN call layer should release all resources
associated with the call and initialize themselves to the null
state. Event (2) results in the processing of DP 19
(O_DISCONNECT) and a move to the last PIC, O_DISCONNECT. Event
(3) occurs if the calling party deliberately terminated the call.
In this case, DP 21 (O_Abandon & O_Calling_Party_Disconnect) will
be processed, and control will be passed to the SIP protocol state
machine. The SIP protocol state machine must send a BYE request
and wait for a final response. The IN layer releases all of its
resources and initializes itself to the null state.
O_ACTIVE--ここに、呼び出しは活発です。 状態、これの電話がいったん得られるかもしれないと、以下の1つであるときにだけ、外されて、3回の出来事が起こります: (1) ネットワーク接続は失敗するか、(2) 被呼者が呼び出しを外すか、または(3) 起呼側が呼び出しを外します。 出来事(1)が起こるなら、DP17(○ _Connection_Failure)を処理します、そして、SIPプロトコル州のマシンに呼び出しコントロールを移します。 ネットワークが行き詰まったので、BYE要求を送るのを試みるのにおいてそれほど多くない感覚があります。 したがって、SIPプロトコル州のマシンとIN呼び出し層の両方が、呼び出しに関連しているすべてのリソースを発表して、ヌル状態に自分たちを初期化するべきです。 出来事(2)はDP19(O_DISCONNECT)の処理と最後のPIC、O_DISCONNECTへの移動をもたらします。 起呼側が故意に呼び出しを終えたなら、出来事(3)は起こります。 この場合、DP21(_O_Abandon&O_Calling_パーティDisconnect)は処理されるでしょう、そして、コントロールはSIPプロトコル州のマシンに通過されるでしょう。 SIPプロトコル州のマシンは、BYE要求を送って、最終的な応答を待たなければなりません。 IN層は、リソースのすべてをリリースして、ヌル状態にそれ自体を初期化します。
O_DISCONNECT: When the SIP entity receives a BYE request, the IN
layer is instructed to move to the last PIC, O_DISCONNECT via DP
19. A final response for the BYE is generated and transmitted by
the SIP entity, and the call resources are freed by both the SIP
protocol state machine and the IN layer.
○ _連絡を断ってください: SIP実体がBYE要求を受け取るとき、IN層が最後のPIC(DP19を通したO_DISCONNECT)に動くよう命令されます。 BYEのための最終的な応答は、SIP実体によって発生して、伝えられます、そして、呼び出しリソースはSIPプロトコル州のマシンとIN層の両方によって解放されます。
5.2. Mapping SIP Protocol State Machine to T_BCSM
5.2. 一口プロトコル州のマシンをT_BCSMに写像します。
The T_BCSM object is created when a SIP INVITE message makes its way to the terminating SIN-enabled SIP entity. This entity creates the T_BCSM object and initializes it to the T_NULL PIC.
SIP INVITEメッセージが終わっているSINによって可能にされたSIP実体への道を作ると、T_BCSM物は作成されます。 この実体は、T_BCSM物を作成して、T_NULL PICにそれを初期化します。
Gurbani, et al. Informational [Page 16] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[16ページ]のRFC3976の織り込むこと
Figure 6 provides a visual map from the SIP protocol state machine to the terminating half of the IN call model:
図6は視覚SIPプロトコル州のマシンから終わりまでの地図にIN呼び出しモデルの半分を供給します:
SIP T_BCSM
一口T_BCSM
| INVITE
V
+----------+ +------------+
|Proceeding+=========================>+ T_Null +<-------+
+-+--+--/\-+ +/\----+-----+ |
| | || +-----------+ | | |
| | ||<=======+T_Exception+--------+ +--V-+ +--+-+
| | || +-/\--------+ |DP22| |DP35|
| | || | +----+ +---+----+------+ +--+-+
| | || +<---+DP23|<------+Auth._Term._Att+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP24| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP25|<------+Select_Facility+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP26| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP27|<------+ Present_Call +---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP28| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP29|<------+ T_Alerting +---->+
| | || | +----+ +-/\--+---------+ |
| | || +<--------------+ || | |
| | || | || | |
| | ++==========================|===++ | |
| | /\ +-------+ +--V-+ |
| | || | +DP30| |
| | || +-+--+ +---+----+------+ |
| | || |DP31+<-----| T_Active +---->+
| | || +----+ +-/\-----+------+
| | || || |
| | || || |
2xx | | ++==============================++ |
sent | | |
+----+ | 3xx - 6xx response +--V-+
| | sent |DP33|
| V+を招待してください。----------+ +------------+ |進行+=========================_>+Tヌル+<。-------+ +-+--+--/\-+ +/\----+-----+ | | | || +-----------+ | | | | | ||<====+ T_例外+--------+ +--V-++--++| | || +-/\--------+ |DP22| |DP35| | | || | +----+ +---+----+------+ +--+-+ | | || + <。---+ DP23| <、-、-、-、-、--+ Auth_用語_Att+---->+| | || | +----+ +------+--------+ | | | || | | | | | || | +--V-+| | | || | |DP24| | | | || | +----+ +---+----+------+ | | | || + <。---+ DP25| <、-、-、-、-、--+ 選んだ_施設+---->+| | || | +----+ +------+--------+ | | | || | | | | | || | +--V-+| | | || | |DP26| | | | || | +----+ +---+----+------+ | | | || + <。---+ DP27| <、-、-、-、-、--+ 現在の_呼び出し+---->+| | || | +----+ +------+--------+ | | | || | | | | | || | +--V-+| | | || | |DP28| | | | || | +----+ +---+----+------+ | | | || + <。---+ DP29| <、-、-、-、-、--+ +を警告するT_---->+| | || | +----+ +-/\--+---------+ | | | || + <。--------------+ || | | | | || | || | | | | ++==========================|===++ | | | | /\ +-------+ +に対する+| | | || | + DP30| | | | || +-+--+ +---+----+------+ | | | || |DP31+<。-----| _のアクティブなT+---->+| | || +----+ +-/\-----+------+ | | || || | | | || || | 2xx| | ++==============================++ | 発信します。| | | +----+ | 3xx--6xx応答+--V-+| | 発信します。|DP33|
Gurbani, et al. Informational [Page 17] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[17ページ]のRFC3976の織り込むこと
| +----V-----+ +------+----+----+
| |Completed | | T_Disconnect |
| +----+-----+ +----------------+
| |
| | ACK received
| |
| +----V-----+
| |Confirmed |
| +----+-----+
| |
+------>|
|
+----V-----+
|Terminated|
+----------+
| +----V-----+ +------+----+----+ | |完成されます。| | T_は連絡を断ちます。| | +----+-----+ +----------------+ | | | | ACKは受信しました。| | | +----V-----+ | |確認されます。| | +----+-----+ | | +------>|、| +----V-----+ |終わります。| +----------+
Legend:
伝説:
| Communication between
| states in the same
V protocol
======> Communication between IN call model and SIP
protocol state machine to transfer call state
| 間のコミュニケーション| 同じVプロトコルの州======呼び出し状態を移すIN呼び出しモデルとSIPプロトコル州のマシンとの>コミュニケーション
Figure 6. Mapping from SIP to T_BCSM
図6。 一口からTまで_BCSMを写像します。
The SIP "Proceeding" state has enough functionality to absorb the first five PICS -- T_Null, Authorize_Termination_Attempt, Select_Facility, Present_Call, T_Alerting -- as described below:
状態を「続かせる」SIPは最初の5PICS_(_T Null、Authorize_Termination_Attempt、Select_Facility、Present_Call、T Alerting)を以下で説明されるように吸収されることができるくらいの機能性を持っています:
T_NULL: At this PIC, the terminating end creates the call at the
IN layer. The incoming call results in the processing of DP 22,
Termination_Attempt, and a transition to the next PIC,
AUTHORIZE_TERMINATION_ATTEMPT, takes place.
T_ヌル: このPICでは、終わり終わりはIN層に呼び出しを作成します。 かかってきた電話はDP22の処理をもたらします、Termination_Attempt、そして、次のPICへの変遷(AUTHORIZE_TERMINATION_ATTEMPT)は行われます。
AUTHORIZE_TERMINATION_ATTEMPT: At this PIC, it is ascertained that
the called party wishes to receive the call and that the
facilities of the called party are compatible with those of the
calling party. If any of these conditions is not met, DP 23
(Termination_Denied) is invoked, and the call control is
transferred to the SIP protocol state machine. The SIP protocol
state machine can format and send a non-2xx final response
(possibly 403, 405, 415, or 480). If the conditions of the PIC
are met, processing of DP 24 (Termination_Authorized) is invoked,
and a transition to the next PIC, SELECT_FACILITY, takes place.
終了_が試みる_を認可してください: このPICでは、被呼者が呼び出しを受けたがっていて、被呼者の施設は起呼側のものと互換性があるのが確かめられます。 これらの状態のいずれも満たさないなら、DP23(終了_Denied)を呼び出します、そして、SIPプロトコル州のマシンに呼び出しコントロールを移します。 SIPプロトコル州のマシンは、非2xxの最終的な応答(ことによると403、405、415、または480)をフォーマットして、送ることができます。 PICに関する条件が満たされるなら、DP24(終了_Authorized)の処理は呼び出されます、そして、次のPICへの変遷(SELECT_FACILITY)は行われます。
Gurbani, et al. Informational [Page 18] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[18ページ]のRFC3976の織り込むこと
SELECT_FACILITY: In circuit switched networks, this PIC is
intended to select a line or trunk to reach the called party. As
lines or trunks are not applicable in an IP network, a SIN-enabled
SIP entity can use this PIC to interface with a PSTN gateway and
select a line/trunk to route the call. If the called party is
busy, or if a line/trunk cannot be seized, the processing of DP 25
(T_Called_Party_Busy) is invoked, and the call goes to the SIP
protocol state machine. The SIP protocol state machine must
format and send a non-2xx final response (possibly 486 or 600).
If a line/trunk was successfully seized, the processing of DP 26
(Terminating_Resource_Available) is invoked, and a transition to
the next PIC, PRESENT_CALL, takes place.
_施設を選択してください: サーキット交換網では、このPICが被呼者に届くように線かトランクを選択することを意図します。 線かトランクスがIPネットワークで適切でないので、SINによって可能にされたSIP実体はPSTNゲートウェイに連結して、呼び出しを発送するために線/トランクを選択するのにこのPICを使用できます。 線/トランクを捕らえることができないなら被呼者が忙しいなら、DP25(_T_Called_パーティBusy)の処理は呼び出されます、そして、呼び出しはSIPプロトコル州のマシンに行きます。 SIPプロトコル州のマシンは、非2xxの最終的な応答(ことによると486か600)をフォーマットして、送らなければなりません。 線/トランクが首尾よく捕らえられたなら、DP26(_Resource_Availableを終えます)の処理は呼び出されます、そして、次のPICへの変遷(PRESENT_CALL)は行われます。
PRESENT_CALL: At this point, the call is being presented (via the
ISUP ACM message, or Q.931 Alerting message, or simply by ringing
a POTS phone). If there was an error presenting the call, the
processing of DP 27 (Presentation_Failure) is invoked, and the
call control is transferred to the SIP protocol state machine,
which must format and send a non-2xx final response (possibly
480). If the call was successfully presented, the processing of
DP 28 (T_Term_Seized) is invoked, and a transition to the next
PIC, T_ALERTING, takes place.
プレゼント_は呼びます: ここに、呼び出しは提示されています(ISUP ACMメッセージ、Q.931 Alertingメッセージ、または単に鳴るのによるPOTS電話を通して)。 呼び出しを提示する誤りがあって、DP27(プレゼンテーション_Failure)の処理を呼び出して、SIPプロトコル州のマシン(非2xxの最終的な応答(ことによると480)をフォーマットして、送らなければならない)に呼び出しコントロールを移すなら。 呼び出しが首尾よく提示されたなら、DP28(_T Term_Seized)の処理は呼び出されます、そして、次のPICへの変遷(T_ALERTING)は行われます。
T_ALERTING: At this point, the called party is being "alerted".
Control now passes momentarily to the SIP protocol state machine
so that it can generate and send a "180 Ringing" response to its
peer. Furthermore, since network resources have been allocated
for the call, timers are set to prevent indefinite holding of such
resources. The expiration of the relevant timers results in the
processing of DP 29 (T_No_Answer), and the call control is
transferred to the SIP protocol state machine, which must format
and send a non-2xx final response (possibly 408). If the called
party answers, then DP 30 (T_Answer) is processed, followed by a
transition to the next PIC, T_ACTIVE.
T_警告: ここに、被呼者は「警告されています」。 コントロールが今aを発生して、送ることができるようにしばらくSIPプロトコル州のマシンに通る、「180 」 同輩への応答を鳴らします。 その上、呼び出しのためにネットワーク資源を割り当てたので、タイマがそのようなリソースの無期把持を防ぐように設定されます。 関連タイマの満了はDP29(_Tいいえ_Answer)の処理をもたらします、そして、SIPプロトコル州のマシンに呼び出しコントロールを移します。(それは、非2xxの最終的な応答(ことによると408)をフォーマットして、送らなければなりません)。 被呼者が答えるなら、次のPIC、T_ACTIVEへの変遷があとに続いていて、DP30(T_Answer)は処理されます。
After the above five PICs have been negotiated, the rest are mapped as follows:
上の5PICsが交渉された後に、残りは以下の通り写像されます:
T_ACTIVE: The call is now active. Once this state is reached, the
call may become inactive under one of the following three
conditions: (1) The network fails the connection, (2) the called
party disconnects the call, or (3) the calling party disconnects
the call. Event (1) results in the processing of DP 31
(T_Connection_Failure), and call control is transferred to the SIP
protocol state machine. Since the network failed, there is little
sense in attempting to send a BYE request; thus, both the SIP
protocol state machine and the IN call layer should release all
resources associated with the call and initialize themselves to
T_アクティブ: 呼び出しは現在、活発です。 この状態にいったん達していると、呼び出しは以下の3つの条件の1つの下で不活発になるかもしれません: (1) ネットワークは接続に失敗するか、(2) 被呼者が呼び出しを外すか、または(3) 起呼側が呼び出しを外します。 出来事(1)はDP31(_T Connection_Failure)の処理をもたらします、そして、SIPプロトコル州のマシンに呼び出しコントロールを移します。 ネットワークが行き詰まったので、BYE要求を送るのを試みるのにおいて感覚がほとんどありません。 その結果、SIPプロトコル州のマシンとIN呼び出し層が呼び出しに関連しているすべてのリソースを発表して、自分たちを初期化するはずである両方
Gurbani, et al. Informational [Page 19] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[19ページ]のRFC3976の織り込むこと
the null state. Event (2) results in the processing of DP 33
(T_Disconnect) and a transition to the next PIC, T_DISCONNECT.
Event (3) occurs at the receipt of a BYE request at the SIP
protocol state machine (not shown in Figure 6). Resources for the
call should be deallocated, and the SIP protocol state machine
must send a 200 OK for the BYE request (not shown in Figure 6).
ヌル状態。 出来事(2)はDP33(T_Disconnect)の処理と次のPIC、T_DISCONNECTへの変遷をもたらします。 出来事(3)はSIPプロトコル州のマシン(図6では、目立たない)にBYE要求の領収書に起こります。 呼び出しのためのリソースは「反-割り当て」られるべきです、そして、SIPプロトコル州のマシンはBYE要求(図6では、目立たない)のための200OKを送らなければなりません。
T_DISCONNECT: In this PIC, the disconnect treatment associated
with the called party's having disconnected the call is performed
at the IN layer. The SIP protocol state machine sends out a BYE
and awaits a final response for the BYE (not shown in Figure 6).
T_は連絡を断ちます: このPICでは、呼び出しを外して、処理が被呼者のものに関連づけた分離はIN層で実行されます。 SIPプロトコル州のマシンは、BYE(図6では、目立たない)のためにBYEを出して、最終的な応答を待ちます。
6. Examples of Call Flows
6. 呼び出し流れに関する例
Two examples are provided here to show how SIP protocol state machine and the IN call model work synchronously with each other.
SIPプロトコル州のマシンとIN呼び出しモデルが互いと共にどう同時働いているかを示しているために2つの例をここに提供します。
In the first example, a SIP UAC originates a call request destined to an 800 freephone number:
最初の例では、SIP UACは800フリーダイヤル番号に運命づけられた発呼要求を溯源します:
INVITE sip:18005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
INVITE一口: 18005551212@example.com SIP/2.0From: 一口: 16305551212@example.net;tag は66ff To:として991-7と等しいです。 一口: 18005551212@example.com Via: UDP stn1.example.net Call SIP/2.0/ID: 67188121@example.net CSeq: 1 招待
The request makes its way to the originating SIP network server running an IN call model. The SIP network server hands, at the very least, the To: field and the From: field to the IN layer for freephone number translation. The IN layer proceeds through its PICs and at the ANALYSE_INFO PIC consults the SCP for freephone translation. The translated number is returned to the SIP network server, which forwards the message to the next hop SIP proxy, with the freephone number replaced by the translated number:
要求は、IN呼び出しモデルを車で送りながら、由来しているSIPネットワークサーバへの道を作ります。 SIPネットワークサーバはTo:を少なくとも手渡します。 分野とFrom: フリーダイヤル数の翻訳のためにIN層としてさばきます。 IN層は、PICsを通して続いて、フリーダイヤル翻訳のためにANALYSE_INFO PICでSCPに相談します。 翻訳された数は次期ホップSIPプロキシにメッセージを転送するSIPネットワークサーバに返されます、フリーダイヤル番号を翻訳された数に取り替えていて:
INVITE sip:18475551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66ff
To: sip:18005551212@example.com
Via: SIP/2.0/UDP ext-stn2.example.net
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 67188121@example.net
CSeq: 1 INVITE
INVITE一口: 18475551212@example.com SIP/2.0From: 一口: 16305551212@example.net;tag は66ff To:として991-7と等しいです。 一口: 18005551212@example.com Via: SIP/2.0/UDP ext-stn2.example.net Via: UDP stn1.example.net Call SIP/2.0/ID: 67188121@example.net CSeq: 1 招待
Gurbani, et al. Informational [Page 20] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[20ページ]のRFC3976の織り込むこと
In the next example, a SIP UAC originates a call request destined to a 900 number:
次の例では、SIP UACは900番号に運命づけられた発呼要求を溯源します:
INVITE sip:19005551212@example.com SIP/2.0
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
INVITE一口: 19005551212@example.com SIP/2.0From: 一口: 16305551212@example.net;tag は66dd To:として991-7と等しいです。 一口: 19005551212@example.com Via: UDP stn1.example.net Call SIP/2.0/ID: 88112@example.net CSeq: 1 招待
The request makes its way to the originating SIP network server running an IN call model. The SIP network server hands, at the very least, the To: field and the From: field to the IN layer for 900 number translation. The IN layer proceeds through its PICs and at the ANALYSE_INFO PIC consults the SCP for the translation. During the translation, the SCP detects that the originating party is not allowed to make 900 calls. It passes this information to the originating SIP network server, which informs the SIP UAC by using a SIP "403 Forbidden" response status code:
要求は、IN呼び出しモデルを車で送りながら、由来しているSIPネットワークサーバへの道を作ります。 SIPネットワークサーバはTo:を少なくとも手渡します。 分野とFrom: 900数の翻訳のためにIN層としてさばきます。 IN層は、PICsを通して続いて、翻訳のためにANALYSE_INFO PICでSCPに相談します。 翻訳の間、SCPはそれを検出します。由来しているパーティーは900を呼び出しにすることができません。 それは由来しているSIPネットワークサーバにこの情報を通過します:(サーバは、SIP「禁じられた403」応答ステータスコードを使用することによって、SIP UACに知らせます)。
SIP/2.0 403 Forbidden
From: sip:16305551212@example.net;tag=991-7as-66dd
To: sip:19005551212@example.com;tag=78K-909II
Via: SIP/2.0/UDP stn1.example.net
Call-ID: 88112@example.net
CSeq: 1 INVITE
一口/2.0 403の禁制のFrom: 一口: 16305551212@example.net;tag は66dd To:として991-7と等しいです。 一口: 19005551212@example.com;tag は以下を通って78K-909IIと等しいです。 UDP stn1.example.net Call SIP/2.0/ID: 88112@example.net CSeq: 1 招待
7. Security Considerations
7. セキュリティ問題
Security considerations for SIN services cover both networks being used, namely, the PSTN and the Internet. SIN uses the security measures in place for both the networks. With reference to Figure 2, the INAP messages between the SCP and the SIN-enabled SIP entity must be secured by the signaling transport used between the SCP and the SIN-enabled entity. Likewise, the requests coming into the SIN- enabled SIP entity must first be authenticated and, if need be, encrypted as well, using the means and procedures defined in [3] for SIP requests.
SINサービスのためのセキュリティ問題はすなわち、使用されるネットワーク、PSTNとインターネットの両方をカバーしています。 SINは両方のネットワークに適所で安全策を使用します。 図2に関して、SCPとSINによって可能にされた実体の間で使用されるシグナリング輸送でSCPとSINによって可能にされたSIP実体の間のINAPメッセージを保証しなければなりません。 同様に、最初にSINの可能にされたSIP実体に入る要求を、認証されて、必要なら、また、コード化しなければなりません、SIP要求に[3]で定義された手段と手順を用いて。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
Intelligent Network Standards: Their Application to Services,"
McGraw-Hill, 1997.
[1] I.Faynberg、L.Gabuzda、M.キャプラン、およびN.シャー、「インテリジェントネットワーク規格:」 「サービスへの彼らの適用」、マグロウヒル、1997。
Gurbani, et al. Informational [Page 21] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[21ページ]のRFC3976の織り込むこと
[2] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network
Distributed Functional Plane Architecture," International
Telecommunications Union Standardization Section, Geneva.
[2] ITU-T Q.1204 1993: 推薦Q.1204、「インテリジェントネットワークの分配された機能的な飛行機構造」、国際電気通信組合標準化部、ジュネーブ。
[3] 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.
[3] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
8.2. Informative References
8.2. 有益な参照
[4] ITU-T Q.1208: "General aspects of the Intelligent Network
Application protocol"
[4] ITU-T Q.1208: 「Intelligent Network Applicationプロトコルの一般局面」
[5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[5] ドノヴァン、S.、「一口インフォメーション方法」、RFC2976、2000年10月。
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[7] Schulzrinne、H.、およびS.Petrack(「DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量」、RFC2833)は2000がそうするかもしれません。
[8] ITU-T Q.1218: "Interface Recommendation for Intelligent Network
Capability Set 1".
[8] ITU-T Q.1218: 「インテリジェントネットワーク能力のためのインタフェース推薦は何1インチもセットしました。」
[9] ITU-T Q.1228: "Interface Recommendation for Intelligent Network
Capability Set 2".
[9] ITU-T Q.1228: 「インテリジェントネットワーク能力のためのインタフェース推薦は何2インチもセットしました。」
[10] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[10] ローゼンバーグ、J.、サラマ、H.、およびM.は2002年1月に「電話はIP(旅行)の上で掘る」RFC3219に付き添います。
Gurbani, et al. Informational [Page 22] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[22ページ]のRFC3976の織り込むこと
Appendix A: Mapping of 4xx-6xx Responses in SIP to IN Detections Points
付録A: IN発覚ポイントへの一口における4xx-6xx応答に関するマッピング
The mapping of error codes 4xx-6xx responses in SIP to the possible Detection Points in PIC Originating and Terminating Call Handling is indicated in the table below. The reason phrase in the 4xx-6xx response is reproduced from [3].
PIC OriginatingとTerminating Call Handlingの可能なDetection PointsへのSIPのエラーコード4xx-6xx応答に関するマッピングは以下のテーブルで示されます。 4xx-6xx応答における理由句は[3]から再生します。
SIP response code DP mapping to IN
----------------- ----------------------
200 OK DP 14
3xx DP 12
403 Forbidden DP 2, DP 21
484 Address Incomplete DP 4, DP 21
400 Bad Request DP 6, DP 21
401 Unauthorized DP 6, DP 21
403 Forbidden DP 6, DP 21, DP 23
404 Not Found DP 6, DP 21
405 Method Not Allowed DP 6, DP 21, DP 23
406 Not Acceptable DP 6, DP 21
408 Request Timeout DP 29
410 Gone DP 6, DP 21
414 Request-URI Too Long DP 6, DP 21
415 Unsupported Media Type DP 6, DP 21, DP 23
416 Unsupported URI Scheme DP 6, DP 21
480 Temporarily Unavailable DP 23, DP 27
485 Ambiguous DP 6, DP 21
486 Busy Here DP 13, DP 21, DP 25
488 Not Acceptable Here DP 6, DP 21
INへのSIP応答コードDPマッピング----------------- ---------------------- 200のOKのDP14 3xx DP12 403禁制のDP2、DP21 484のアドレスの不完全なDP4、DP21 400の悪い要求DP6、DP21 401の権限のないDP6、DP21 403の禁制のDP6、DP21、許容できるDP6ではなく、DP6、DP21 405の方法の許容されなかったDP6、DP21、DP21 408が要求するDP23 406がタイムアウトDP29 410ないのがDP23 404によってわからなかった、DP6; DP21 414要求URIのも長いDP6、DP21 415のサポートされないメディアがDP6、DP21、DP23 416のサポートされないURI計画DP6、DP21 480の一時入手できないDP23、DP27 485のあいまいなDP6をタイプします。DP21 486はここでDP13と忙しくします、DP21、ここで許容できないDP25 488、DP6、DP21
Gurbani, et al. Informational [Page 23] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[23ページ]のRFC3976の織り込むこと
Acknowledgments
承認
Special acknowledgment is due to Hui-Lan Lu for acting as the chair of the SIN DT and ensuring that the focus of the DT did not veer too far. The authors would also like to give special thanks to Mr. Ray C. Forbes from Marconi Communications Limited for his valuable contribution on the system and network architectural aspects as co- chair in the ETSI SPAN. Thanks also to Doris Lebovits, Kamlesh Tewani, Janusz Dobrowloski, Jack Kozik, Warren Montgomery, Lev Slutsman, Henning Schulzrinne, and Jonathan Rosenberg, who all contributed to the discussions on the relationship of IN and SIP call models.
特別な承認はSIN DTのいすとして務めて、DTの焦点があまりにはるかに向きを変えなかったのを確実にするためのホイ-ランLuのためです。 作者は、彼の有価約因のためにシステムで特別な感謝をマルコニーCommunications株式会社からレイC.フォーブズさんに与えて、また、共同いすとしてETSI SPANで建築局面をネットワークでつなぎたがっています。 ドリスLebovitsにも感謝、INとSIPの関係についての議論にすべて貢献したKamlesh Tewani、ヤヌシDobrowloski、ジャックKozik、ウォレンモンゴメリ、Lev Slutsman、ヘニングSchulzrinne、およびジョナサン・ローゼンバーグはモデルに電話をします。
Author's Addresses
作者のアドレス
Vijay K. Gurbani Lucent Technologies, Inc. 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 USA Phone: +1 630 224 0216 EMail: vkg@lucent.com
ビジェイK.GurbaniルーセントテクノロジーズInc.2000の透明なレイン、Rm 6G-440ナパービル、イリノイ60566米国は以下に電話をします。 +1 0216年の630 224メール: vkg@lucent.com
Frans Haerens Alcatel Bell Francis Welles Plein,1 Belgium Phone: +32 3 240 9034 EMail: frans.haerens@alcatel.be
フランスHaerensアルカテルベルフランシスウェルズPlein、1つのベルギー電話: +32 3 240 9034はメールされます: frans.haerens@alcatel.be
Vidhi Rastogi Wipro Technologies Plot No.72, Keonics Electronics City, Hosur Main Road, Bangalore 226 560 100 Phone: +91 80 51381869 EMail: vidhi.rastogi@wipro.com
VidhiラストーギウィプロTechnologiesはNo.72、Keonics Electronics市、バンガロール226 560 100が電話をするHosur本道を企みます: +91 80 51381869はメールされます: vidhi.rastogi@wipro.com
Gurbani, et al. Informational [Page 24] RFC 3976 Interworking SIP & IN January 2005
Gurbani、他 一口と2005年1月の情報[24ページ]のRFC3976の織り込むこと
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.orgに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Gurbani, et al. Informational [Page 25]
Gurbani、他 情報[25ページ]
一覧
スポンサーリンク
