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
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
IESG Note
IESG注意
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.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、そして公開する決定が展開プロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
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).
公衆交換電話網（PSTN）など800個のルーティング（フリーダイヤル）、時間と日のルーティング、クレジットカード通話、および仮想プライベートネットワーク（パブリック数にプライベートネットワーク番号をマッピングする）などのサービスインテリジェントによって実現されているスイッチドネットワーク（IN）。この文書アドレスは、IPホストから電話への通話のためのセッション開始プロトコル（SIP）エンドポイントからサービス内の既存のサポートすることを意味します。コール要求は、SIPエンドポイントから発信されていますが、コールへのサービスは、IN / PSTNのデータと手続き居住者によって提供されています。 SIPエンドポイントに透過的にINサービスを提供するには、この文書では、SIPおよびインテリジェントネットワークアプリケーション部（INAP）をインターワーキングするためのメカニズムを説明しています。
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
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.
こうした800番号（フリーダイヤル）ルーティング、時間と日のルーティング、クレジットカード通話、および仮想プライベートネットワーク（パブリック数にプライベートネットワーク番号をマッピングする）としてPSTNサービスはインテリジェントネットワークによって実現されます。 INは、ネットワークサービスと顧客アプリケーションのリアルタイム実行のためのアーキテクチャの概念[1]です。であり、設計により、PSTNの呼処理コンポーネントから脱結合されます。この文書では、我々は、SIPベースのエンティティからINサービスを提供するために、このデカップリングを活用するための手段を説明します。
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.
まず、我々は、INの基本を説明します。図1は、汎用コンピュータであるサービス制御ポイント（SCPの）へシグナリングシステム第7号（SS7）と呼ばれるパケットネットワークを介して接続されている電話交換機がサービス交換ポイント（SSPの）と呼ばれる、アーキテクチャを簡略化示します。通話中に特定の時点で、スイッチは呼び出しを続行する方法についてはSCPからの呼び出しと要求命令を中断することができます。呼が中断可能な点は、基本呼状態モデル（BCSM）[1,2]内に標準化されています。 BCSMモデルは、2つのプロセス、発信するための1つのそれぞれの呼び出しの終端部分を含みます。
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は、命令の要求を受信すると、そのような曜日や時間帯などの基準によって増大シンプルな数の訳語として、単一の応答を返信することができ、または、順番に、スイッチとの複雑な対話を開始します。状況はさらに、（これらのデバイスは、ここで議論されていません。）関連のプロトコルは、数字を収集する他の専用デバイスに係合記録アナウンスを再生し、テキストを音声に変換するなど、または音声テキスト変換を実行するために必要によって複雑になります同様にBCSMとして、ITU-Tで標準化され、インテリジェントネットワークアプリケーションパートプロトコル（INAP）として知られている[4]。プロトコルだけではなく、SCPのAPIは、標準化されています。
+-----------+
| |
| SCP |
| |
+-----------+
||
||
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
Figure 1. Simplified IN Architecture
図1.アーキテクチャを簡素化
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.
全体的な目的は、ボイスオーバーIPの制御にネットワークで（VoIP）のサービスが容易に現在のネットワークで使用される基準やソフトウェアを適応させることによって指定して実施することができるようにすることです。このアプローチは、ユーザが現在または将来のネットワークに接続したときに同じように機能し、サービスにつながる、未来に存在からサービスの進化を簡素化し、より迅速な実施につながります。
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.
このドキュメントの残りは以下の通り構成されています。第2節では、IN意識SIPエンティティのアーキテクチャモデルが含まれています。第3節では（SIN）のインターワーキングIN / SIPを実行するときに考慮されるいくつかの問題を提供します。第4節では、SINのアプローチに基づいてINサービス制御について説明します。この文書で概説技術は、INとSIPプロトコルステートマシンの呼び出しモデルに焦点を当てて。第5節では、このようにSIPエンドポイントからのINサービスへのアクセスを可能にする2台の状態マシン間の完全なマッピングを確立します。第6節は、SIPエンドポイント上で実行する際のサービスのコールフローを含んでいます。これらのサービスは、容易に、この文書に記載された技術で有効になっています。最後に、7節はSINのセキュリティの側面をカバーしています。
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
インテリジェントネットワークINAP、IN B2BUAバックツーバックユーザエージェントBCSM基本呼状態モデルCCFコール制御機能DP検出ポイントDTMFデュアルトーン多重周波数インテリジェントネットワークアプリケーション部IPインターネットプロトコルITU-T国際電気通信連合 - 電気通信標準化部門O_BCSM発信基本公共号インターワーキングSIPセッション開始プロトコルSS7シグナリングシステムIN / IETF SIN SIPで電話網RTPリアルタイムプロトコルR-URIリクエストURI SCFサービス制御機能SCPサービス制御ポイントSIGTRAN信号交通ワーキンググループを交換呼PSTNに状態モデルPICポイントを呼び出しIP VPN仮想プライベートネットワーク上のポイントT_BCSM終端基本呼状態モデルUAユーザーエージェントUACユーザエージェントクライアントUASユーザエージェントサーバのVoIPの音声を切り替え7 SSFサービス切替機能SSPサービス
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].
このドキュメントの意図は、SIP [3]環境内の既存のIN-ベースのアプリケーションをサポートするための手段を提供することです。 （同一の検出点（DPS）と伝統的なスイッチによって使用されるポイント・イン・コール（PIC）を介して、例えば、）透過SIPからINサービスへのアクセスを得るための一つの方法は、IN呼モデルにSIPプロトコルステートマシンをマッピングすることです[ 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.
例えばSCPとしてIN要素の観点から、伝統的なスイッチのSIPエンティティではなく、呼処理機能からの要求の起源は重要ではありません。したがって、SIPエンティティがIN機能のSSPとして動作を含め、従来のスイッチと同じ機能を提供できることが重要です。伝統的なスイッチがそうであるようにSIPエンティティはまた、IN-ベースのサービスへの通話状態とトリガのクエリを維持する必要があります。
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.
この文書では、SSPとして動作しなければならないどのSIPエンティティを指定するつもりはありません。しかしながら、完全を期すためには、ネットワークのコアではなく、SIPの端部には、自身を指し、このタスクは、AT（または近く）SIPエンティティによって実行されるべきであることに言及すべきです。その程度まで、このようなプロキシサーバとバックツーバックユーザエージェント（型B2BUA）としてSIPエンティティを使用することができます。一般的に言って、プロキシサーバは、コールセットアップとティアダウン中に発生したINサービスに使用することができます。型B2BUAを（たとえば、保留にパーティーを置くなど）の特殊なメディア（例えばDTMF検出など）の取り扱いや専門の呼制御を必要としたINサービスのために必要となります。
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:
IPドメインでサービス内の既存の提供するための最も迅速な方法は、できるだけ頻繁にインフラに配備を使用することです。 SIPでは、サービス内の既存のアクセスのために活用するために論理的な点は、ユーザエージェントまたは（およびおそらく同じ管理ドメイン内の）ユーザエージェントに物理的に最も近いプロキシの1つのどちらかです。しかし、SIPエンティティは、INコールモデルを実行しないでください。透過的にサービスでのアクセスのために、トリックは、その呼受付及びルーティングはネイティブ状態マシンによって実行され、サービスがINを使用してIN層を介してアクセスされるようにIn層とSIPエンティティの状態マシンをオーバーレイすることですコールモデル。イベントは、SIPトランザクション・レベルで発生するとIN素子（SCP）との相互作用に同期して動作するようIN対応SIPエンティティは、図2に示されています。
+-------+
| SCP |
+---+---+
|
| INAP
|
+--------+
| SIN |
+........+
| SIP |
---------->| Entity |--------->
Requests | | Requests out
in +--------+ (after applying IN
services)
SIN: SIP/IN Interworking layer
SIN：SIP /インターワーキング層に
Figure 2. SIP Entity Accessing IN Services
図2. SIPエンティティへのアクセスでのサービス
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.
第5節では、In層とSIPプロトコルステートマシン間のこのマッピングを提案しています。基本的に、このマッピングを示すSIPエンティティは、SIN対応SIPエンティティとなります。
This document does not propose any extensions to SIP.
このドキュメントは、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.
図3は、図2及びさらに詳細にかつSIPインターワーキングを含むアーキテクチャモデルに示されているSIPエンティティを拡張します。 SIP層で発生するイベントは、サービスアプリケーションのためのIn層に渡されます。具体的には、E.164番号でのINサービスの契約以来、そのような数にサービスを提供しようとSIN対応のSIPエンティティは、このようにSIPベースとして機能し、さらなる処理のためIn層に相談すると仮定するのが妥当ですSSP。 In層は、コールの処分のためにSCPにクエリを送信し、通話中に適切なポイントで、そのBCSMの状態を経て進行します。コールの処分が決定されると、SIP層が通知され、それに応じてトランザクションを処理しています。
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).
例えば、1つのSIPエンティティは、端末またはアクセスネットワーク/ドメインの担当であり、別の担当であり、この図にモデル化されたように、単一のSIPエンティティは、実際にネットワーク内にはいくつかの異なる物理的インスタンスを表すことができることに注意してください回線交換ネットワーク（SCN）へのインタフェース。
+-------+
| 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
SIN対応SIPエンティティの図3.機能アーキテクチャ
The following architecture entities, used in Figure 3, are defined in the Intelligent Network standards:
図3で使用される以下のアーキテクチャエンティティは、インテリジェントネットワーク規格で定義されています。
Service Switching Function (SSF): IN functional entity that
interacts with call control functions.
Call Control Function (CCF): IN functional entity that refers to call and connection handling in the classical sense (i.e., that of an exchange).
制御機能（CCF）を呼び出す：機能エンティティIN呼び出し、古典的な意味での接続処理を意味する（すなわち、交換のもの）。
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-PSTNネットワーク間での作業では、主な問題は、インターネットテレフォニーシグナリングおよび環境での伝統的に使用されているものによって生成状態の間で変換することです。このような翻訳は、下記の注意事項に注意を要します。
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サービスコールセットアップ、コールのティアダウン、またはコールの途中で中に、すなわち、コールのコンテキスト内で発生します。これらのサービスのいくつかは、実現することができるとともに、そのようなプロキシとしてSIPエンティティは、典型的には、トランザクションステートフル（またはステートレス）モードで実行します。このモードでは、初期INVITEをプロキシSIPプロキシは、BYEなどの後続の要求を受信することが保証されません。幸いなことに、SIPは、コールステートフルモードで動作するようにプロキシを強制的にプリミティブを持っています。即ち、Record-Routeヘッダ。このヘッダは、後続の要求が経由しなければならない、それを通して介在するすべてのプロキシで構成され、「ルートセット」を作成するために、ユーザエージェントクライアント（UAC）とユーザエージェントサーバ（UAS）を強制します。したがって、SIPプロキシは、UASの代わりにINサービスを提供するために、コールステートフルモードで実行する必要があります。
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.
B2BUAは、サービスで実現することができる別のSIP要素です。 B2BUAは、真のSIP UAであるとして、それは完全な通話状態を維持し、サービスを提供する、INので、可能です。
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.
この文書で提案されたアーキテクチャモデルでは、各SIN-有効SIPエンティティは、機構が適切であるどのような通信用いて、一つの論理SCPサーバと通信するように事前に構成されています。すべてのSIPサーバを担当する単一のSCPサーバが存在しないように、異なるSIPサーバは、（例えば、異なる管理ドメイン内のもの）は、異なるSCPサーバと通信することができます。
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.
1および図2を図のように、SIN-有効SIPエンティティのIN-部分は、SCPと通信します。 SS7オーバーSIGTRANオーバーIPオーバーINAP、INAP、またはINAP：のIN呼処理層とSCPとの間のこのインターフェースは、実際に、SCPによってサポートされているインターフェイスに応じて、次のいずれかにすることができ、この文書で指定されたとされていません。
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.
SIP制御インターネットテレフォニーデバイスは、PSTNデバイスで動作するように求める場合は、この文書にのみ適用されます。このインタフェースを使用して、SIP UAは、典型的には、メディアゲートウェイと一緒に見えます。この文書では、オールIPネットワークに適用* *ではないとのSCPと通信する必要がPSTNメディアゲートウェイ（SIPを話していない）場合には必要ありません。
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規定SIPプロキシやSIP登録サーバー。プロセスは、回線交換網におけるSCP / HLRのプロビジョニングと同様です。 VoIPのベースのサービスを提供するのSCPは、直接この情報を活用することができます。しかし、この文書はどちらも実際には、それ実装決定と見なし、是認することも、そのようなアーキテクチャを禁止します。
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.
一般的にアナウンスを再生し、呼が設定される前に、発信者からの数字を収集呼び出し、クレジットカードとしてのInサービス。アナウンスを再生すると、収集の数字は、メディアストリームの操作を必要としています。 SIPでは、プロキシは、メディアデータパスにアクセスすることはできません。したがって、このようなサービスは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].
SIPの仕様は[3]通話中にまたは場所を取るためにメディアストリームの変更を保留にするエンドポイントを可能にしますが、それは、通話制御情報以外の輸送する任意のプリミティブを持っていません。これは、例えば、DTMFディジットを輸送挙げられます。このようなINFO方法としてSIPの拡張、[5]またはSIPイベント通知拡張[6]、ミッドコールシグナリングを必要とするサービスのために考慮することができます。あるいは、DTMFはRTP自体で輸送することができる[7]。
The SIP architecture has the following functional elements defined in [3]:
SIPアーキテクチャは、[3]で定義された以下の機能要素を有します。
- User agent client (UAC): The SIP functional entity that initiates a request.
- ユーザエージェントクライアント（UAC）：要求を開始し、SIP機能エンティティ。
- 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.
- ユーザエージェントサーバ（UAS）：0またはそれ以上の暫定SIP応答と1つの最終SIP応答を送信することによって要求を終了するSIP機能エンティティ。
- 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.
- プロキシサーバー：UASとUACの両方として作用することができる中間のSIPエンティティ。 UASとして動作する、それが求めるUACからの要求を受け付け、リクエストURI（R-URI）を書き換え、及び、UACとして動作する、下流UASへの要求をプロキシ。プロキシは、最初のINVITEを超えて将来のSIPトランザクションで自分自身を挿入することにより、大幅な呼制御状態を保持することができます。
- 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).
おそらく（R-URIで指定されるように）呼び出し先の正確な位置を決定するためにロケーションサーバに相談した後、別の場所への発信者をリダイレクト中間SIPエンティティ： - サーバーをリダイレクトします。
- 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.
- レジストラ：SIP REGISTERリクエストを受け付け、ユーザのための正確な位置への高レベルのURLからの結合を維持するSIPエンティティ。この情報は、SIPプロキシおよびSIPリダイレクトサーバにアクセス可能であるいくつかのデータ・ストアに保存されます。レジストラは、通常、SIPプロキシまたはSIPリダイレクトサーバと同じ場所に配置されます。
- 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.
- アウトバウンドプロキシ：要求の発信元の近くにあるSIPプロキシ。それはR-URIをアウトバウンドプロキシ以外のホストを識別し、それらの要求を含む特定のUACからのすべての発信要求を受信します。アウトバウンドプロキシは、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.
- バックツーバックUA（B2BUA）：要求を受信し、UASとしてそれを処理するSIPエンティティ。また、UACとして動作し、着信要求が回答する方法を決定するための要求を生成します。 B2BUAは、完全な対話状態を維持し、ダイアログ内で送信されたすべての要求に参加しなければなりません。
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.
図4は、SINのアプローチに基づいて、INサービス制御の可能性を示しています。発信および終端両端に、SIN-可能なSIPエンティティは（それがプロキシまたはB2BUAであることができる）と仮定されます。 「O SIP」の実体は、サービス内の既存のサポートを必要と発信コールのために必要とされます。同様に、被呼者側（または終端側）には、均等構成エンティティ（「T SIP」）は終端側サービスを提供するために必要とされるであろう。 「O SIP」と「T SIP」エンティティがIN呼モデルのIN O_BCSMとT_BCSM半部に、それぞれ対応しています。
+---+ +---+
| 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：発信SIPエンティティT SIP：SIPエンティティを終了
Figure 4. Overall SIN Architecture
図4.全体のSINのアーキテクチャ
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.
このセクションでは、ジェネリック基本呼状態モデル（BCSM）にSIPプロトコル状態機械のマッピングを確立する[2]、任意のケーパビリティセットの独立した[8,9]。発信コールモデル（O_BCSM）及び着信呼モデル（T_BCSM）：BCSMは、二つの半部に分割されています。 [1]; 19枚の写真と両半分（T_BCSM 8枚の写真と14枚のDP 11枚の写真とO_BCSM 21 DPS）の間の35枚のDPの合計があります。 SSP、SCPの、および他の要素には、基本的なコール・モデルの観点から、コールの進行状況を追跡します。基本呼モデルは、呼び出しに関する通信のための共通のコンテキストを提供します。
O_BCSM has 11 PICs:
O_BCSMは11個のPICがあります。
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.
O_NULL：開始状態。呼び出しがまだ存在していません。 AUTH_ORIG_ATTEMPT：スイッチは呼設定要求を検出します。 COLLECT_INFO：スイッチは、発呼者からのダイヤル文字列を収集します。 ANALYZE_INFO：完全なダイヤル文字列は、ルーティングアドレスに変換されます。 SELECT_ROUTE：物理ルートをルーティング・アドレスに基づいて、選択されます。 AUTH_CALL_SETUP：スイッチは、発呼者が電話をかけることを許可されている保証します。 CALL_SENT：側の終端に送信されたコールのコントロール。 O_ALERTING：着呼側が応答するためにスイッチが待機します。 O_ACTIVE：接続が確立。通信が続いて起こります。 O_DISCONNECT：接続取り壊さ。 O_EXCEPTION：スイッチは例外条件を検出します。
T_BCSM has 8 PICS:
T_BCSMは8 PICSがあります。
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_NULL：開始状態。呼び出しがまだ存在していません。 AUTH_TERM_ATT：スイッチは、通話が終了する相手に送信することが可能かどうかを検証します。 SELECT_FACILITY：スイッチがコールを送信するために、終端リソースを選びます。 PRESENT_CALL：コールは、着信側に提示されています。 T_ALERTING：スイッチのアラートラインを鳴らすことで、着信側、例えば、。 T_ACTIVE：接続が確立。通信が続いて起こります。 T_DISCONNECT：接続取り壊さ。 T_EXCEPTION：スイッチは例外条件を検出します。
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.
O_BCSMとT_BCSMためのステートマシンは、それぞれ、ページ98と103の[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つのセクションでは、IN BCSMsにSIPプロトコル状態機械のマッピングを含みます。 INコールモデル内のすべてのPICとのDPを説明することは、この文書の範囲外です。読者がINコールモデルの写真とのDPとのある程度の知識を持っていることを想定しています。詳しくは、[1]に見出すことができます。クイックリファレンスについては、付録Aは、次の2つのセクションで説明したようにSIP応答コードへのDPのマッピングを含みます。
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メッセージが）のINコールモデルを実行している元のSIN-有効なSIPエンティティに上流のSIPクライアントから到着したときO_BCSMの11個のPICは遊びに来ます。このエンティティはO_BCSMオブジェクトを作成し、O_NULL PICでそれを初期化します。 O_NULL、AUTH_ORIG_ATT、COLLECT_INFO、ANALYZE_INFO、SELECT_ROUTE、AUTH_CALL_SETUP、およびCALL_SENT - - PICの中の次の7は、すべての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は、IN呼モデルの発信半分にSIPプロトコル状態機械からの視覚マップを提供します。それがサービスしている間にSIPプロトコルマシンとIN O_BCSMコールモデルとの間の呼シャトルの制御に注意してください。
SIP O_BCSM
SIP 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|| |
| +-+-+------+<=========================++ |
| | | |
| | | |
| | | |
| | +--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:
| Communication between
| states in the same
V protocol
======> Communication between IN Layer and SIP Protocol State machine to transfer call state
======> In層と通話状態を転送するSIPプロトコルのステートマシン間の通信
Figure 5. Mapping from SIP to O_BCSM
SIPからO_BCSMに図5のマッピング
The SIP "Calling" protocol state has enough functionality to absorb the seven PICs as described below:
プロトコル状態を「呼び出し」SIPは、後述のように7つのPICを吸収するのに十分な機能を持っています：
O_NULL: This PIC is basically a fall through state to the next PIC, AUTHORIZE_ORIGINATION_ATTEMPT.
O_NULL：この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 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.
AUTHORIZE_ORIGINATION_ATTEMPT：このPICでは、In層は、誰かが電話をかけることを望んでいることを検出しました。いくつかの状況（例えば、ユーザが特定の時間中に電話をかけることを許可されていない場合）の下で、そのような呼び出しを配置することができません。 SIPは、SIP管理者によって設定されたポリシーディレクティブのセットを使用することにより、発呼者を認可することができます。着呼側が電話をかけることを許可されている場合は、In層は、DP 3（Origination_Attempt_Authorized）を介して次のPIC、COLLECT_INFOを入力するように指示されました。何らかの理由でコールが許可できない場合は、DP 2（Origination_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.
COLLECT_INFO：このPICは、発呼者からのダイヤル文字列を収集し、文字列の形式を検証する責任があります。オーバーラップダイヤリングが使用されている場合、このPICは、DP 4（Collect_Timeout）を起動し、フォーマットし、非2xxの最終応答（おそらく484）を送信しますSIP状態機械に制御を転送することができます。ダイヤル文字列が有効な場合、DP 5（Collected_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.
ANALYZE_INFO：このPICは、ルーティング番号にダイヤル文字列を翻訳する責任があります。こうしたフリーダイヤル、LNP（ローカル番号ポータビリティ）、およびOCS（発信スクリーニング）などのサービス、の多くのは、このPICの間に発生します。 IN層は、分析のためのINVITE要求をSIPのR-URIを使用することができます。分析が成功した場合、In層は、SELECT_ROUTEを次のPICを入力するように指示されました。解析が失敗した場合、DP 6（Invalid_Info）が処理され、非2xxの最終的な応答を生成するSIP状態機械、（にコントロール転送おそらく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.
SELECT_ROUTEは：回線交換網では、実際の物理的な経路は、この時点で選択しなければなりません。 SIP類似体は、次ホップSIPサーバを決定するであろう。これは、種々の手段により選択することができます。 INVITE着信要求内の要求URIがE.164番号である場合、例えば、SIPエンティティは、出口に最もよいゲートウェイをPSTNへの要求を見つけるためにTRIP等プロトコル[10]を使用することができます。成功したルートを選択した場合、のINコールモデルは、DP 9（Route_Selected）を介してPIC AUTH_CALL_SETUPに移動します。そうでなければ、非2xxの最終応答（おそらく488）を生成し、上流のエンティティに送信しますDP 8（Route_Select_Failure）を介してSIP状態機械の制御転送、。
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 (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.
AUTH_CALL_SETUP：一部のサービス機能は、特定の行またはトランクに生じ得るコールの種類を制限します。このPICは、関連する制限が検討されている点です。そのような制限が発生していない場合は、のINコールモデルは、DP 11（Origination_Authorized）を介してPIC CALL_SENTに移動します。制限は、呼の更なる処理を禁止し、その発生した場合、DP 10（Authorization_Failure）が処理され、そして制御は、非2xxの最終応答（おそらく404、488、または502）を生成するSIP状態機械に転送されます。それ以外の場合は、DP 11（Origination_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.
CALL_SENT：この時点で、要求は下流のエンティティに送信する必要があります。 In層は、いずれかのコールは、着信側に提示または被呼者が特定の理由のために達することができないということであったことを確認する信号を待ちます。制御は、SIP状態機械に転送されます。 SIPのステートマシンは現在、PIC SELECT_ROUTEに決定された次のダウンストリームサーバーへのコールを送信する必要があります。 SIPのステートマシンによってブロック解除されるまでのINコールモデルは現在のブロック。
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.
上記7つのPICが正常にネゴシエートされている場合は、SIN-有効なSIPエンティティは現在SIPは、次ホップサーバーにINVITEメッセージを送信します。さらなる処理は、現在暫定応答（もしあれば）とSIPプロトコル状態マシンによって受信された最終的な応答に依存します。コアSIP仕様はの1xx応答の配信を保証するものではありません。従って、特別な処理がCALL_SENT PICから次PIC（O_ALERTING）に移行するには層に必要とされます。 SIP状態機械が「Proceeding」ステート及びIn層の「CALL_SENT」状態にあるながら応答するために必要な特別な処理を説明します。
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応答は、DP 14（O_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).
2xx応答がSIPエンティティで受信DP 14（O_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応答は、DP 12（Route_Failure）の処理を可能にします。この時点からのINコールモデルは、（簡潔にするため、図5に示されていない）3xxの最終応答で連絡先のための新たなルートを選択するために戻ってSELECT_ROUTE PICになります。
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（ここでBUSY）応答は、DP 13（O_Called_Party_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の最終的な応答、DP 21（O_Calling_Party_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 - このPICは、200クラス応答を受信した結果として入力されます。 INVITEに対する200クラス応答が受諾を示すので、このPICは、DP 16を介して次のPIC、O_ACTIVE（O_Answer）に至るまでほとんど秋です。
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）ネットワーク接続が失敗し、（2）被呼者が通話を切断し、または（3）発呼者が通話を切断し、次の3つのイベントのいずれかが発生した場合にのみ、一度この状態で、通話が切断される場合があります。イベントは、（1）発生した場合、DP 17（O_Connection_Failure）が処理され、呼制御はSIPプロトコルステートマシンに転送されます。ネットワークに障害が発生しているので、BYE要求を送信しようではあまり意味がありません。このように、SIPプロトコルステートマシンとのINコール層の両方は、コールに関連付けられたすべてのリソースを解放し、ヌル状態に自分自身を初期化する必要があります。イベント（2）DP 19（O_DISCONNECT）の処理における結果と最後のPIC、O_DISCONNECTへ移動します。発呼者が故意に通話を終了した場合、イベント（3）が発生します。この場合、DP 21（O_Abandon＆O_Calling_Party_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.
O_DISCONNECTは：SIPエンティティは、BYE要求を受信すると、層がBYEに対する最終応答が生成され、SIPエンティティによって送信されるDP 19を介して最後のPIC、O_DISCONNECTに移動するように指示され、呼リソースがによって解放されますSIPプロトコル状態機械とIN層の両方。
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にそれを初期化します。
Figure 6 provides a visual map from the SIP protocol state machine to the terminating half of the IN call model:
図6は、IN呼モデルの終端半分にSIPプロトコル状態機械からの視覚地図を提供します。
SIP T_BCSM
SIP 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-----+ +------+----+----+
| |Completed | | T_Disconnect |
| +----+-----+ +----------------+
| |
| | ACK received
| |
| +----V-----+
| |Confirmed |
| +----+-----+
| |
+------>|
|
+----V-----+
|Terminated|
+----------+
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
SIPからT_BCSMに図6のマッピング
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:
T_Null、Authorize_Termination_Attempt、Select_Facility、Present_Call、T_Alerting - - SIP "Proceeding" ステートは、最初の5つのPICSを吸収するのに十分な機能を持っている以下のように：
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_NULL：このPICで、終端は、IN層でコールを作成します。 DP 22、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.
AUTHORIZE_TERMINATION_ATTEMPT：このPICで、着信側がコールを受信したいと着信側の施設は、発呼者のものと互換性があることが確認されています。これらの条件のいずれかが満たされない場合、DP 23（Termination_Denied）が呼び出され、呼制御はSIPプロトコルステートマシンに転送されます。 SIPプロトコルステートマシンは、非2xxの最終応答（おそらく403、405、415、または480）をフォーマットし、送信することができます。 PICの条件が満たされた場合、DP 24（Termination_Authorized）の処理が呼び出され、次のPICへの移行は、SELECT_FACILITYが行われます。
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.
SELECT_FACILITY：回路交換ネットワークでは、このPICは、着信側に到達するために行またはトランクを選択することを意図しています。回線またはトランクがIPネットワークに適用されないように、SIN-有効SIPエンティティは、コールをPSTNゲートウェイとインターフェースするために、このPICを使用してルートに回線/トランクを選択することができます。着信側がビジー状態の場合はライン/トランクを押収することができない場合、または、DP 25（T_Called_Party_Busy）の処理が呼び出され、コールはSIPプロトコルステートマシンに行きます。 SIPプロトコルステートマシンは、非2xxの最終応答（おそらく486または600）をフォーマットして送信しなければなりません。ライン/トランクが正常に押収された場合、DP 26（Terminating_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.
PRESENT_CALL：この時点で、コールは（ISUP ACMメッセージ、またはQ.931アラートメッセージを経由して、あるいは単にPOTS電話を鳴らすことで）提示されています。コールを提示するエラーが発生した場合、DP 27（Presentation_Failure）の処理が呼び出され、呼制御フォーマットと非2xxの最終応答（おそらく480）を送信しなければならないSIPプロトコルステートマシンに転送されます。コールが正常に提示された場合は、DP 28（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_ALERTING：この時点では、着信側が「警告」されています。それが生成し、そのピアに「180リンギング」応答を送信することができるように制御についてSIPプロトコルステートマシンを一時的に通過します。ネットワークリソースが呼に対して割り当てられているので、タイマーは、そのようなリソースの不定保持を防止するために設定されています。 DP 29（T_No_Answer）の処理に関連するタイマーの結果の有効期限、および呼制御をフォーマットし、非2xxの最終応答（おそらく408）を送信しなければならないSIPプロトコルステートマシンに転送されます。その後、着信側の回答、DP 30（T_Answer）が処理されている場合は、次のPIC、T_ACTIVEへの移行が続きます。
After the above five PICs have been negotiated, the rest are mapped as follows:
上記5つのPICがネゴシエートされた後、次のように、残りはマップされます。
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 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).
T_ACTIVE：通話がアクティブになりました。この状態に達すると、コールは、次の3つのいずれかの条件の下で不活性になることがあります。（1）ネットワークは、（2）被呼者が通話を切断し、または（3）発呼者が通話を切断し、接続に失敗しました。イベントDP 31の処理（1）の結果（T_Connection_Failure）、及び呼制御はSIPプロトコルステートマシンに転送されます。ネットワークに障害が発生しているので、BYE要求を送信しようではあまり意味があります。このように、SIPプロトコルステートマシンとのINコール層の両方は、コールに関連付けられたすべてのリソースを解放し、ヌル状態に自分自身を初期化する必要があります。イベントDP 33（T_DISCONNECT）の処理と次PIC、T_DISCONNECTへの移行（2）の結果。 （3）イベントは、（図6には示されていない）SIPプロトコル状態機械でBYE要求の受信時に起こります。呼び出しのためのリソースが割り当て解除されるべきであり、SIPプロトコルステートマシンはBYE要求（図6には示されていない）のために200 OKを送信しなければなりません。
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_DISCONNECT：このPICでは、切断処理は、着信側の切断したコールは、In層で実行されるに関連付けられています。 SIPプロトコルステートマシンは、BYEを送信し、BYE（図6には示されていない）のための最終的な応答を待ちます。
Two examples are provided here to show how SIP protocol state machine and the IN call model work synchronously with each other.
2つの例は、相互に同期する方法SIPプロトコルステートマシンとのコールモデルの仕事を表示するには、ここに提供されています。
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 SIP：18005551212@example.comからSIP / 2.0：SIP：16305551212@example.net;にタグ= 991-7as-66ff：SIP：18005551212@example.com経由：SIP / 2.0 / UDP stn1.example.netコール-ID：67188121@example.netのCSeq：1 INVITE
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ネットワークサーバ手、非常に少なくとも、宛先：フィールドとから：フィールドフリーダイヤル番号変換のためのIn層へ。そのPICを通って、ANALYSE_INFO PICでIn層進み、フリーダイヤル翻訳のための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
16305551212@example.net;にタグ= 991-7as-66ff：18475551212@example.comからSIP / 2.0：一口一口を、SIP INVITE：18005551212@example.com経由：SIP / 2.0 / UDP EXT-stn2.example。ネット経由：SIP / 2.0 / UDP stn1.example.netコールID：67188121@example.netのCSeq：1 INVITE
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 SIP：19005551212@example.comからSIP / 2.0：SIP：16305551212@example.net;にタグ= 991-7as-66dd：SIP：19005551212@example.com経由：SIP / 2.0 / UDP stn1.example.netコール-ID：88112@example.netのCSeq：1 INVITE
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ネットワークサーバ手、非常に少なくとも、宛先：フィールドとから：フィールド900番号変換のためのIn層へ。そのPICを通って、ANALYSE_INFO PICでIn層進み、翻訳のためのSCPを調べます。変換時に、SCPは、発信側が900本の電話をかけることが許可されていないことを検出します。それは、SIP「403禁止」応答ステータスコードを使用して、SIP UACに通知する発信SIPネットワークサーバにこの情報を渡します。
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
SIP：SIP / 2.0 403を禁止16305551212@example.net;タグ= 991-7as-66ddへ：SIP：19005551212@example.com;タグ= 78K-909II経由：SIP / 2.0 / UDP stn1.example.netコール-ID：88112@example.netのCSeq：1 INVITE
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-有効SIPエンティティとの間のINAPメッセージはSCPとSIN-有効エンティティ間で使用されるシグナリング輸送によって確保されなければなりません。必要であれば、同様に、SIN-有効SIPエンティティに入ってくる要求が最初に認証されなければならない、SIP要求の[3]で定義された手段および手順を用いて、同様に暗号化されました。
[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.Shah、 "インテリジェントネットワーク規格：サービスへの応用、" マグロウヒル、1997。
[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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] ITU-T Q.1208: "General aspects of the Intelligent Network Application protocol"
[4] ITU-T Q.1208：「インテリジェントネットワークアプリケーションプロトコルの一般的な態様」
[5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[5]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、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. 2000 Petrackとを、 "DTMFケタ、電話トーン、および電話信号のためのRTPペイロード"、RFC 2833、2000年5月。
[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.スクワイア、 "オーバーIPテレフォニールーティング（TRIP）"、RFC 3219、2002年1月。
Appendix A: Mapping of 4xx-6xx Responses in SIP to IN Detections Points
付録A IN：検出数ポイントにSIPでの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発信及び処理着呼に可能な検出点に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
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の焦点が遠すぎる向きを変えるなかったことを確実にするためのホイ - ラン呂によるものです。著者らはまた、システム上の彼の貴重な貢献のためにマルコーニコミュニケーションズ株式会社から氏レイC.フォーブスに特別な感謝を与え、ETSI SPANでの共同議長としての建築の側面をネットワークしたいと思います。おかげで、すべてがINとSIPコールモデルの関係に関する議論に貢献しドリスLebovits、Kamlesh Tewani、ヤヌシュDobrowloski、ジャック・コジック、ウォーレン・モンゴメリー、レフ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ルーセント・テクノロジーズ株式会社2000ルーセントレーン、Rmの6G-440ネーパーヴィル、イリノイ州60566 USA電話：+1 630 224 0216 Eメール：vkg@lucent.com
Frans Haerens Alcatel Bell Francis Welles Plein,1 Belgium Phone: +32 3 240 9034 EMail: frans.haerens@alcatel.be
フランツHaerensアルカテル・ベルフランシスまあプレイン、1ベルギー電話：+32 3 240 9034 Eメール：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 Rastogiウィプロ・テクノロジーズプロットNo.72、Keonicsエレクトロニクスシティ、ホスールメインロード、バンガロール226 560 100電話：+91 80 51381869 Eメール：vidhi.rastogi@wipro.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に及び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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 ISOC文書の権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。