[要約] RFC 3976は、SIPとIntelligent Network（IN）アプリケーションの相互運用に関するガイドラインを提供しています。このRFCの目的は、SIPとINアプリケーションの統合に関する問題を解決し、効果的な通信を実現することです。
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
SIP とインテリジェント ネットワーク (IN) アプリケーションの相互作用
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 は、どのレベルのインターネット標準の候補でもありません。IETF は、いかなる目的に対しても、この RFC の適合性についていかなる知識も放棄し、特に、公開の決定は、セキュリティ、輻輳制御、または展開されたプロトコルとの不適切な相互作用などに関する IETF のレビューに基づいていないことに注意します。RFC 編集者は、その裁量でこの文書を公開することを選択しました。このドキュメントの読者は、実装および展開におけるその価値を評価する際に注意する必要があります。詳細については、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).
800 番号ルーティング (フリーダイヤル)、時間と曜日のルーティング、クレジット カード通話、仮想プライベート ネットワーク (プライベート ネットワーク番号を公衆番号にマッピング) などの公衆交換電話網 (PSTN) サービスは、インテリジェント ネットワークによって実現されます。ネットワーク (IN)。このドキュメントでは、IP ホストから電話への通話のためのセッション開始プロトコル (SIP) エンドポイントからの既存の IN サービスをサポートする方法について説明します。通話要求は SIP エンドポイントで発信されますが、通話に対するサービスは PSTN/IN に常駐するデータと手順によって提供されます。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]。IN は、設計上、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 は、簡略化された IN アーキテクチャを示しています。このアーキテクチャでは、サービス スイッチング ポイント (SSP) と呼ばれる電話交換機が、シグナリング システム No. 7 (SS7) と呼ばれるパケット ネットワークを介して、汎用コンピュータであるサービス コントロール ポイント (SCP) に接続されています。通話の特定の時点で、スイッチは通話を中断し、SCP に通話の続行方法に関する指示を要求することがあります。通話が中断される可能性があるポイントは、Basic Call State Model (BCSM) [1、2] 内で標準化されています。BCSM モデルには、通話の発信部分と終了部分にそれぞれ 1 つずつ、計 2 つのプロセスが含まれています。
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 は指示のリクエストを受信すると、時刻や曜日などの条件を追加した単純な数値変換などの 1 つの応答で応答したり、スイッチとの複雑なダイアログを開始したりすることができます。数字の収集、録音されたアナウンスの再生、テキストから音声への変換、または音声からテキストへの変換などを実行する他の特殊なデバイスを使用する必要があるため、状況はさらに複雑になります (これらのデバイスについてはここでは説明しません)。BCSM と同様に、ITU-T によって標準化され、Intelligent Network Application Part Protocol (INAP) として知られています [4]。標準化されているのはプロトコルのみであり、SCP API は標準化されていません。
+-----------+
| |
| SCP |
| |
+-----------+
||
||
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
Figure 1. Simplified IN Architecture
図 1. 簡略化した IN アーキテクチャ
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.
全体的な目的は、現在のネットワークで使用されている規格とソフトウェアを適応させることによって、ネットワーク内の Voice over IP (VoIP) サービスの IN 制御を容易に指定および実装できるようにすることです。このアプローチにより、ユーザーが現在または将来のネットワークに接続したときと同じように機能するサービスが実現され、現在から将来へのサービスの進化が簡素化され、より迅速な実装が可能になります。
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 では、SIP/IN インターワーキング (SIN) を実行する際に考慮すべきいくつかの問題について説明します。セクション 4 では、SIN アプローチに基づく IN サービス制御について説明します。このドキュメントで概要を説明する技術は、IN の呼び出しモデルと SIP プロトコル ステート マシンに焦点を当てています。したがって、セクション 5 では、SIP エンドポイントから IN サービスへのアクセスを可能にする 2 つのステート マシン間の完全なマッピングを確立します。セクション 6 には、SIP エンドポイントで実行される IN サービスのコール フローが含まれます。これらのサービスは、このドキュメントで説明されている技術によって簡単に有効になります。最後に、セクション 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
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 ベースのアプリケーションをサポートする手段を提供することです。SIP から (たとえば、従来のスイッチで使用されているのと同じ検出ポイント (DP) やポイントインコール (PIC) を介して) IN サービスに透過的にアクセスする 1 つの方法は、SIP プロトコル ステート マシンを IN コール モデルにマッピングすることです。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.
この文書は、どの SIP エンティティが SSP として動作するかを指定することを意図したものではありません。ただし、完全を期すために、このタスクは SIP エンドポイント自体ではなく、ネットワークのコア (またはその近く) にある SIP エンティティによって実行される必要があることに注意してください。その範囲で、プロキシ サーバーや Back-to-Back ユーザー エージェント (B2BUA) などの SIP エンティティが使用される場合があります。一般に、プロキシ サーバーは、通話のセットアップおよび切断中に発生する IN サービスに使用できます。特殊なメディア処理 (DTMF 検出など) または特殊な通話制御 (相手を保留にするなど) を必要とする IN サービスの場合、B2BUA が必要になります。
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 ドメインで既存の IN サービスを提供する最も迅速な方法は、展開された IN インフラストラクチャをできるだけ頻繁に使用することです。SIP では、既存の IN サービスにアクセスするために利用する論理ポイントは、ユーザー エージェント、またはユーザー エージェントに物理的に最も近い (おそらく同じ管理ドメイン内にある) プロキシのいずれかです。ただし、SIP エンティティは IN 通話モデルを実行しません。IN サービスに透過的にアクセスするには、SIP エンティティのステート マシンを IN レイヤーでオーバーレイし、通話の受け入れとルーティングがネイティブ ステート マシンによって実行され、サービスが IN を使用して IN レイヤーを介してアクセスされるようにすることが重要です。モデルを呼び出します。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/IN インターワーキング層
Figure 2. SIP Entity Accessing IN Services
図 2. IN サービスにアクセスする 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 エンティティを拡張し、IN と SIP のインターワーキングを含むアーキテクチャ モデルをさらに詳細に示しています。SIP層で発生したイベントはサービスアプリケーションのためにIN層に渡されます。より具体的には、IN サービスは E.164 番号を扱うため、そのような番号でサービスを提供しようとする SIN 対応の SIP エンティティは、さらなる処理のために IN 層に問い合わせて、SIP ベースのサービスとして機能すると考えるのが合理的です。SSP。IN 層は BCSM 状態を経て、通話の適切な時点で通話処理のために SCP にクエリを送信します。通話の処理が決定されると、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).
この図でモデル化されている単一の SIP エンティティは、実際にはネットワーク内の複数の異なる物理インスタンスを表すことができることに注意してください。たとえば、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
図 3. SIN 対応 SIP エンティティの機能アーキテクチャ
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.
Service Switching Function (SSF): 呼制御機能と対話する IN 機能エンティティ。
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 環境で使用される状態の間で変換を行うことです。このような翻訳では、以下に挙げる考慮事項に注意する必要があります。
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 プロキシは、UA に代わって 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 は、IN サービスを実現できるもう 1 つの 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 エンティティは、適切な通信メカニズムを使用して 1 つの論理 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 と通信します。IN コール処理層と SCP の間のこのインターフェイスは、この文書では指定されていません。実際、SCP でサポートされているインターフェイスに応じて、INAP over IP、INAP over SIGTRAN、または INAP over SS7 のいずれかになります。。
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 ネットワークには「適用されません」。また、PSTN メディア ゲートウェイ (SIP を話さない) が SCP と通信する必要がある場合には必要ありません。
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 メソッド [5] や SIP イベント通知拡張 [6] などの SIP の拡張は、通話中のシグナリングを必要とするサービスに対して考慮できます。あるいは、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 からのリクエストを受け入れ、Request-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」エンティティは、既存の IN サービスのサポートを必要とする発信通話に必要です。同様に、着信側 (または着信側) では、同様に構成されたエンティティ (「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.
このセクションでは、機能セット [8、9] とは無関係に、SIP プロトコル ステート マシンの IN 汎用基本通話状態モデル (BCSM) [2] へのマッピングを確立します。BCSM は、発信コール モデル (O_BCSM) と着信コール モデル (T_BCSM) の 2 つに分かれています。両方の半分の間には、合計 19 個の PIC と 35 個の DP があります (O_BCSM の場合は 11 個の PIC と 21 個の DP、T_BCSM の場合は 8 個の PIC と 14 個の DP) [1]。SSP、SCP、およびその他の IN 要素は、基本的な通話モデルの観点から通話の進行状況を追跡します。基本的な通話モデルは、通話に関する通信に共通のコンテキストを提供します。
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 つの写真があります:
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 つのセクションには、SIP プロトコル ステート マシンの IN BCSM へのマッピングが含まれています。IN コール モデルのすべての PIC と DP について説明することは、このドキュメントの範囲を超えています。読者は IN コール モデルの PIC と DP についてある程度の知識があることを前提としています。詳細については、[1] を参照してください。クイックリファレンスとして、付録 A には、次の 2 つのセクションで説明するように、DP から SIP 応答コードへのマッピングが含まれています。
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.
O_BCSM の 11 個の PIC は、通話要求 (SIP INVITE メッセージ) が上流の SIP クライアントから IN 通話モデルを実行している発信元の SIN 対応 SIP エンティティに到着したときに機能します。このエンティティは O_BCSM オブジェクトを作成し、O_NULL PIC で初期化します。次の 7 つの IN PIC (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 コール モデル間のコール シャトルの制御に注意してください。
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
||間の通信同じ V プロトコル内の状態
======> Communication between IN Layer and SIP Protocol
State machine to transfer call state
Figure 5. Mapping from SIP to O_BCSM
図 5. SIP から O_BCSM へのマッピング
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 (発信拒否) が処理され、制御が 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) を呼び出し、SIP ステート マシンに制御を移すことができ、SIP ステート マシンは非 2xx 最終応答 (おそらく 484) をフォーマットして送信します。ダイヤル文字列が有効な場合、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 (発信元コール スクリーニング) などの多くの IN サービスは、この PIC 中に実行されます。IN 層は、SIP INVITE リクエストの R-URI を分析に使用できます。分析が成功すると、IN レイヤーは次の PIC、SELECT_ROUTE に入るように指示されます。分析が失敗した場合、DP 6 (Invalid_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.
SELECT_ROUTE: 回線交換ネットワークでは、この時点で実際の物理ルートを選択する必要があります。SIP の類似点は、ネクスト ホップの SIP サーバーを決定することです。これはさまざまな手段で選択できます。たとえば、受信した INVITE リクエストのリクエスト URI が E.164 番号である場合、SIP エンティティは TRIP [10] のようなプロトコルを使用して、リクエストを PSTN に出力するための最適なゲートウェイを見つけることができます。成功したルートが選択された場合、IN 呼び出しモデルは DP 9 (Route_Selected) を介して PIC AUTH_CALL_SETUP に移動します。それ以外の場合、制御は DP 8 (Route_Select_Failure) を介して SIP ステート マシンに転送され、非 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 (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) が処理され、制御が SIP ステート マシンに移され、非 2xx 最終応答 (おそらく 404、488、または 502) が生成されます。それ以外の場合、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 で決定された次のダウンストリーム サーバーに通話を送信する必要があります。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.
上記の 7 つの PIC のネゴシエーションが成功すると、SIN 対応 SIP エンティティは SIP INVITE メッセージをネクスト ホップ サーバーに送信します。今後の処理は、暫定応答 (存在する場合) と、SIP プロトコル ステート マシンが受信した最終応答に依存します。コア SIP 仕様では、1xx 応答の配信は保証されていません。したがって、CALL_SENT PIC から次の PIC (O_ALERTING) に移行するには、IN 層で特別な処理が必要です。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).
SIP エンティティで受信された 2xx 応答により、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 コール モデルは、SELECT_ROUTE PIC に戻り、3xx 最終応答内の連絡先の新しいルートを選択します (簡潔にするため、図 5 には示されていません)。
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 Here) 応答により、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 はほとんどが次の PIC、DP 16 (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 - この時点で、通話はアクティブです。この状態になると、次の 3 つのイベントのいずれかが発生した場合にのみ、通話が切断されます。(1) ネットワーク接続が失敗する、(2) 着信側が通話を切断する、または (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 要求を受信すると、IN 層は DP 19 を介して最後の PIC、O_DISCONNECT に移動するように指示されます。BYE に対する最終応答は SIP エンティティによって生成および送信され、通話リソースは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.
T_BCSM オブジェクトは、SIP INVITE メッセージが終端の SIN 対応 SIP エンティティに到達するときに作成されます。このエンティティは 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 は、SIP プロトコル ステート マシンから IN コール モデルの終端半分までの視覚的なマップを示しています。
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
Figure 6. Mapping from SIP to T_BCSM
図 6. SIP から 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 の「Proceeding」状態には、以下で説明するように、最初の 5 つの PICS (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_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 エンティティは、この PIC を使用して PSTN ゲートウェイとインターフェイスし、通話をルーティングする回線/トランクを選択できます。着信側が話し中の場合、または回線/トランクを捕捉できない場合は、DP 25 (T_Called_Party_Busy) の処理が呼び出され、通話は SIP プロトコル ステート マシンに送られます。SIP プロトコル ステート マシンは、2xx 以外の最終応答 (おそらく 486 または 600) をフォーマットして送信する必要があります。回線/トランクの捕捉に成功すると、DP 26 (Termination_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) の処理が呼び出され、通話制御が SIP プロトコル ステート マシンに転送されます。SIP プロトコル ステート マシンは、非 2xx 最終応答 (おそらく 480) をフォーマットして送信する必要があります。通話が正常に行われた場合、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: この時点で、着信側は「警告」を受けています。制御は一時的に SIP プロトコル ステート マシンに渡され、「180 Ringing」応答を生成してピアに送信できるようになります。さらに、ネットワーク リソースが通話に割り当てられているため、そのようなリソースが無期限に保持されないようにタイマーが設定されています。関連するタイマーが満了すると、DP 29 (T_No_Answer) の処理が行われ、通話制御が SIP プロトコル ステート マシンに転送され、SIP プロトコル ステート マシンは非 2xx 最終応答 (おそらく 408) をフォーマットして送信する必要があります。着信側が応答すると、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) 発呼側が通話を切断する。イベント (1) の結果、DP 31 (T_Connection_Failure) の処理が発生し、呼制御が SIP プロトコル ステート マシンに転送されます。ネットワークに障害が発生したため、BYE リクエストを送信することはほとんど意味がありません。したがって、SIP プロトコル ステート マシンと IN コール層の両方は、コールに関連付けられたすべてのリソースを解放し、自身をヌル状態に初期化する必要があります。イベント (2) の結果、DP 33 (T_Disconnect) が処理され、次の PIC、T_DISCONNECT に移行します。イベント (3) は、SIP プロトコル ステート マシン (図 6 には示されていません) での BYE リクエストの受信時に発生します。通話のリソースの割り当てを解除する必要があり、SIP プロトコル ステート マシンは BYE リクエストに対して 200 OK を送信する必要があります (図 6 には示されていません)。
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.
ここでは、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
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 層は PIC を介して進み、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
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
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 番号変換のために、少なくとも To: フィールドと From: フィールドを IN 層に渡します。IN 層は PIC を介して進み、ANALYSE_INFO PIC で SCP に変換を問い合わせます。変換中に、SCP は発信側が 900 コールを行うことが許可されていないことを検出します。この情報は発信元の SIP ネットワーク サーバーに渡され、SIP 「403 Forbidden」応答ステータス コードを使用して 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
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. Kaplan、および 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] Rosenberg, J.、Schulzrinne, H.、Camarillo, G.、Johnston, A.、Peterson, J.、Sparks, R.、Handley, M.、および E. Schooler、「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] Donovan, S.、「SIP INFO メソッド」、RFC 2976、2000 年 10 月。
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Roach, 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. 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] Rosenberg, J.、Salama, H.、および M. Squire、「Telephony Routing over IP (TRIP)」、RFC 3219、2002 年 1 月。
Appendix A: Mapping of 4xx-6xx Responses in SIP to IN Detections Points
付録 A: SIP の 4xx-6xx 応答の IN 検出ポイントへのマッピング
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].
SIP でのエラー コード 4xx ～ 6xx 応答と、PIC 発信および着信呼処理で考えられる検出ポイントのマッピングを次の表に示します。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 の焦点が大きく逸れないように配慮してくれた Hui-Lan Lu に特別な感謝を表します。著者らはまた、ETSI SPAN の共同議長としてシステムおよびネットワーク アーキテクチャの側面に関して貴重な貢献をしていただいた Marconi Communications Limited の Ray C. Forbes 氏に特別な感謝を表したいと思います。IN と SIP 通話モデルの関係についての議論に貢献した、Doris Lebovits、Kamlesh Tewani、Janusz Dobrowloski、Jack Kozik、Warren Montgomery、Lev Slutsman、Henning Schulzrinne、Jonathan Rosenberg にも感謝します。
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
Vijay K. Gurbani Lucent Technologies, Inc. 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 USA 電話: 1 630 224 0216 電子メール: vkg@lucent.com
Frans Haerens Alcatel Bell Francis Welles Plein,1 Belgium Phone: +32 3 240 9034 EMail: frans.haerens@alcatel.be
Frans Haerens Alcatel Bell Francis Welles Plein,1 Belgium 電話: 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 Rastogi Wipro Technologies Plot No.72, Keonics Electronics City, Hosur Main Road, Bangalore 226 560 100 電話: 91 80 51381869 電子メール: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。