[要約] 要約：RFC 3372は、SIP-T（Telephonesのためのセッション開始プロトコル）のコンテキストとアーキテクチャについて説明しています。 目的：このRFCの目的は、SIP-Tの背景や使用方法、アーキテクチャの詳細を提供し、電話システムにおけるセッション開始プロトコルの実装と運用を支援することです。
Network Working Group A. Vemuri
Request for Comments: 3372 Qwest Communications
BCP: 63 J. Peterson
Category: Best Current Practice NeuStar
September 2002
Session Initiation Protocol for Telephones (SIP-T): Context and Architectures
電話のセッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
The popularity of gateways that interwork between the PSTN (Public Switched Telephone Network) and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. This document taxonomizes the uses of PSTN-SIP gateways, provides uses cases, and identifies mechanisms necessary for interworking. The mechanisms detail how SIP provides for both 'encapsulation' (bridging the PSTN signaling across a SIP network) and 'translation' (gatewaying).
PSTN（パブリックスイッチ付き電話ネットワーク）とSIPネットワークとの間のインターワークの人気は、実装全体で一貫した動作を保証できる一連の一般的なプラクティスの公開を動機付けました。このドキュメントは、PSTN-SIPゲートウェイの使用を分類し、使用するケースを提供し、インターワーキングに必要なメカニズムを識別します。メカニズムは、SIPが「カプセル化」（SIPネットワーク全体でPSTNシグナル伝達を埋める）と「翻訳」（ゲートウェイ）の両方をどのように提供するかを詳述しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SIP-T for ISUP-SIP Interconnections . . . . . . . . . . . . . 4
3. SIP-T Flows . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 SIP Bridging (PSTN - IP - PSTN) . . . . . . . . . . . . . . . 8
3.2 PSTN origination - IP termination . . . . . . . . . . . . . . 9
3.3 IP origination - PSTN termination . . . . . . . . . . . . . . 11
4. SIP-T Roles and Behavior . . . . . . . . . . . . . . . . . . . 12
4.1 Originator . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Terminator . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Intermediary . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Behavioral Requirements Summary . . . . . . . . . . . . . . . 15
5. Components of the SIP-T Protocol . . . . . . . . . . . . . . . 16
5.1 Core SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Translation . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Support for mid-call signaling . . . . . . . . . . . . . . . . 17
6. SIP Content Negotiation . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
The Session Initiation Protocol (SIP [1]) is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. These multimedia sessions include multimedia conferences, Internet telephony and similar applications. SIP is one of the key protocols used to implement Voice over IP (VoIP). Although performing telephony call signaling and transporting the associated audio media over IP yields significant advantages over traditional telephony, a VoIP network cannot exist in isolation from traditional telephone networks. It is vital for a SIP telephony network to interwork with the PSTN.
セッション開始プロトコル（SIP [1]）は、マルチメディアセッションまたはコールを確立、変更、終了できるアプリケーションレイヤー制御プロトコルです。これらのマルチメディアセッションには、マルチメディア会議、インターネットテレフォニー、同様のアプリケーションが含まれます。SIPは、Voice over IP（VOIP）を実装するために使用される重要なプロトコルの1つです。テレフォニーコールシグナリングを実行し、関連するオーディオメディアをIPよりも輸送すると、従来のテレフォニーよりも大きな利点が得られますが、従来の電話ネットワークから隔離してVoIPネットワークは存在することはできません。SIPテレフォニーネットワークがPSTNと対戦することが重要です。
The popularity of gateways that interwork between the PSTN and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. The scarcity of SIP expertise outside the IETF suggests that the IETF is the best place to stage this work, especially since SIP is in a relative state of flux compared to the core protocols of the PSTN. Moreover, the IETF working groups that focus on SIP (SIP and SIPPING) are best positioned to ascertain whether or not any new extensions to SIP are justified for PSTN interworking. This framework addresses the overall context in which PSTN-SIP interworking gateways might be deployed, provides use cases and identifies the mechanisms necessary for interworking.
PSTNとSIPネットワークの間のインターワークが、実装全体で一貫した動作を保証できる一連の一般的なプラクティスの公開を動機付けているというゲートウェイの人気があります。IETF外のSIPの専門知識の希少性は、特にSIPがPSTNのコアプロトコルと比較してフラックスの相対的な状態にあるため、IETFがこの作業を舞台にするのに最適な場所であることを示唆しています。さらに、SIP（SIPとすすりの）に焦点を当てたIETFワーキンググループは、SIPの新しい拡張機能がPSTNインターワーキングのために正当化されるかどうかを確認するために最適に位置するのが最適です。このフレームワークは、PSTN-SIPインターワーキングゲートウェイが展開され、ユースケースを提供し、インターワーキングに必要なメカニズムを識別する全体的なコンテキストに対処します。
An important characteristic of any SIP telephony network is feature transparency with respect to the PSTN. Traditional telecom services such as call waiting, freephone numbers, etc., implemented in PSTN protocols such as Signaling System No. 7 (SS7 [6]) should be offered by a SIP network in a manner that precludes any debilitating difference in user experience while not limiting the flexibility of SIP. On the one hand, it is necessary that SIP support the primitives for the delivery of such services where the terminating point is a regular SIP phone (see definition in Section 2 below) rather than a device that is fluent in SS7. However, it is also essential that SS7 information be available at gateways, the points of SS7-SIP interconnection, to ensure transparency of features not otherwise supported in SIP. If possible, SS7 information should be available in its entirety and without any loss to trusted parties in the SIP network across the PSTN-IP interface; one compelling need to do so also arises from the fact that certain networks utilize proprietary SS7 parameters to transmit certain information through their networks.
SIPテレフォニーネットワークの重要な特徴は、PSTNに対する機能の透明度です。シグナリングシステムNo. 7（SS7 [6]）などのPSTNプロトコルに実装された、コール待機、フリーフォン番号などの従来の通信サービスは、ユーザーエクスペリエンスの衰弱性の違いを排除する方法でSIPネットワークによって提供されるべきです。SIPの柔軟性を制限していません。一方では、SS7に堪能なデバイスではなく、終端ポイントが通常のSIP電話（以下のセクション2の定義を参照）であるようなサービスの配信のためのSIPをサポートする必要があります。ただし、SS7情報がSS7-SIP相互接続のポイントであるGatewaysで、SIPでサポートされていない機能の透明性を確保することも不可欠です。可能であれば、SS7情報は、PSTN-IPインターフェイス全体のSIPネットワーク内の信頼できる当事者に損失を伴わずに利用できるようにする必要があります。それを行う必要のある必要性の1つは、特定のネットワークが独自のSS7パラメーターを利用して、特定の情報をネットワークから送信するという事実からも生じます。
Another important characteristic of a SIP telephony network is routability of SIP requests - a SIP request that sets up a telephone call should contain sufficient information in its headers to enable it to be appropriately routed to its destination by proxy servers in the SIP network. Most commonly this entails that parameters of a call like the dialed number should be carried over from SS7 signaling to SIP requests. Routing in a SIP network may in turn be influenced by mechanisms such as TRIP [8] or ENUM [7].
SIPテレフォニーネットワークのもう1つの重要な特性は、SIPリクエストのルーティング可能性です - 電話をセットアップするSIPリクエストは、SIPネットワークのプロキシサーバーによって適切に宛先にルーティングできるようにヘッダーに十分な情報を含める必要があります。最も一般的には、これには、ダイヤル番号のような呼び出しのパラメーターがSS7シグナリングからSIPリクエストに引き継がれることを伴います。SIPネットワークのルーティングは、トリップ[8]や列挙[7]などのメカニズムの影響を受ける可能性があります。
The SIP-T (SIP for Telephones) effort provides a framework for the integration of legacy telephony signaling into SIP messages. SIP-T provides the above two characteristics through techniques known as 'encapsulation' and 'translation' respectively. At a SIP-ISUP gateway, SS7 ISUP messages are encapsulated within SIP in order that information necessary for services is not discarded in the SIP request. However, intermediaries like proxy servers that make routing decisions for SIP requests cannot be expected to understand ISUP, so simultaneously, some critical information is translated from an ISUP message into the corresponding SIP headers in order to determine how the SIP request will be routed.
SIP-T（SIP For Shonewones）の取り組みは、SIPメッセージにレガシーテレフォニーシグナリングを統合するためのフレームワークを提供します。SIP-Tは、それぞれ「カプセル化」と「翻訳」として知られる手法を通じて上記の2つの特性を提供します。SIP-ISUPゲートウェイでは、SS7 ISUPメッセージは、SIPリクエストでサービスに必要な情報が廃棄されないように、SIP内でカプセル化されます。ただし、SIPリクエストのルーティング決定を行うプロキシサーバーなどの仲介業者は、ISUPを理解することは期待できないため、同時に、SIPリクエストのルーティング方法を決定するために、ISUPメッセージから対応するSIPヘッダーにいくつかの重要な情報が翻訳されます。
While pure SIP has all the requisite instruments for the establishment and termination of calls, it does not have any baseline mechanism to carry any mid-call information (such as the ISUP INF/INR query) along the SIP signaling path during the session. This mid-call information does not result in any change in the state of SIP calls or the parameters of the sessions that SIP initiates. A provision to transmit such optional application-layer information is also needed.
純粋なSIPには、コールの確立と終了に必要なすべての必要な機器がありますが、セッション中のSIP信号パスに沿って中間情報（ISUP INF/INRクエリなど）を運ぶためのベースラインメカニズムはありません。このミッドコール情報は、SIPコールの状態やSIPが開始するセッションのパラメーターに変更をもたらすことはありません。このようなオプションのアプリケーション層情報を送信するための規定も必要です。
Problem definition: To provide ISUP transparency across SS7-SIP interworking
問題の定義：SS7-SIPインターワーキング全体でISUPの透明性を提供する
SS7-SIP Interworking Requirements SIP-T Functions
==================================================================
Transparency of ISUP Encapsulation of ISUP in the
Signaling SIP body
Routability of SIP messages with Translation of ISUP information dependencies on ISUP into the SIP header
SIPメッセージの翻訳を使用したSIPメッセージのルーチャ性SIPヘッダーへのISUPの依存性
Transfer of mid-call ISUP signaling Use of the INFO Method for mid-messages call signaling
ミッドコールISUPシグナリングの転送ミッドメッセージのための情報方法の使用コールシグナリング
Table 1: SIP-T features that fulfill PSTN-IP inter-connection Requirements
表1：PSTN-IP間接続要件を満たすSIP-T機能
While this document specifies the requirements above, it provide mechanisms to satisfy them - however, this document does serve as an framework for the documents that do provide these mechanisms, all of which are referenced in Section 5.
このドキュメントは上記の要件を指定しますが、それらを満たすためのメカニズムを提供しますが、このドキュメントは、これらのメカニズムを提供するドキュメントのフレームワークとして機能します。これらはすべてセクション5で参照されます。
Note that many modes of signaling are used in telephony (SS7 ISUP, BTNUP, Q.931, MF etc.). This document focuses on SS7 ISUP and aims to specify the behavior across ISUP-SIP interfaces only. The scope of the SIP-T enterprise may, over time, come to encompass other signaling systems as well.
多くのシグナリングモードはテレフォニーで使用されていることに注意してください（SS7 ISUP、BTNUP、Q.931、MFなど）。このドキュメントは、SS7 ISUPに焦点を当てており、ISUP-SIPインターフェイスのみで動作を指定することを目的としています。SIP-Tエンタープライズの範囲は、時間の経過とともに、他のシグナリングシステムを包含するようになる場合があります。
SIP-T is not a new protocol - it is a set of mechanisms for interfacing traditional telephone signaling with SIP. The purpose of SIP-T is to provide protocol translation and feature transparency across points of PSTN-SIP interconnection. It intended for use where a VoIP network (a SIP network, for the purposes of this document) interfaces with the PSTN.
SIP -Tは新しいプロトコルではありません。これは、従来の電話信号とSIPをインターフェースするためのメカニズムのセットです。SIP-Tの目的は、PSTN-SIP相互接続のポイント全体でプロトコル変換と特徴の透明度を提供することです。これは、VoIPネットワーク（このドキュメントの目的のためにSIPネットワーク）がPSTNとインターフェイスする場所で使用することを目的としていました。
Using SIP-T, there are three basic models for how calls interact with gateways. Calls that originate in the PSTN can traverse a gateway to terminate at a SIP endpoint, such as an IP phone. Conversely, an IP phone can make a call that traverses a gateway to terminate in the PSTN. Finally, an IP network using SIP may serve as a transit network between gateways - a call may originate and terminate in the PSTN, but cross a SIP-based network somewhere in the middle.
SIP-Tを使用して、呼び出しがゲートウェイとの相互作用方法については3つの基本モデルがあります。PSTNに由来する呼び出しは、IP電話などのSIPエンドポイントで終了するゲートウェイを通過する可能性があります。逆に、IP電話は、PSTNで終了するゲートウェイを横断する通話を行うことができます。最後に、SIPを使用するIPネットワークは、ゲートウェイ間のトランジットネットワークとして機能する場合があります。PSTNでコールが発生および終了する場合がありますが、中央のどこかでSIPベースのネットワークを横断できます。
The SS7 interfaces of a particular gateway determine the ISUP variants that that gateway supports. Whether or nor a gateway supports a particular version of ISUP determines whether it can provide feature transparency while terminating a call.
特定のゲートウェイのSS7インターフェイスは、そのゲートウェイがサポートするISUPバリアントを決定します。GatewayがISUPの特定のバージョンをサポートするかどうかは、呼び出しを終了しながら機能の透明度を提供できるかどうかを決定します。
The following are the primary agents in a SIP-T-enabled network.
以下は、SIP-T対応ネットワークの主要なエージェントです。
o PSTN (Public Switched Telephone Network): This refers to the entire interconnected collection of local, long-distance and international phone companies. In the examples below, the term Local Exchange Carrier (LEC) is used to denote a portion (usually, a regional division) of the PSTN.
o PSTN（公開された電話ネットワーク）：これは、地元、長距離、国際的な電話会社の相互接続されたコレクション全体を指します。以下の例では、Local Exchange Carrier（LEC）という用語を使用して、PSTNの一部（通常は地域部門）を示します。
o IP endpoints: Any SIP user agent that can act as an originator or recipient of calls. Thus, the following devices are classified as IP endpoints:
o IPエンドポイント：呼び出しの発信者または受信者として機能するSIPユーザーエージェント。したがって、次のデバイスはIPエンドポイントとして分類されます。
* Gateways: A telephony gateway provides a point of conversion between signaling protocols (such as ISUP and SIP) as well as circuit-switch and packet-switched audio media. The term Media Gateway Controller (MGC) is also used in the examples and diagrams in this document to denote large-scale clusters of decomposed gateways and control logic that are frequently deployed today. So for example, a SIP-ISUP gateway speaks ISUP to the PSTN and SIP to the Internet and is responsible for converting between the types of signaling, as well as interchanging any associated bearer audio media.
* ゲートウェイ：テレフォニーゲートウェイは、シグナリングプロトコル（ISUPやSIPなど）とサーキットスイッチとパケットスイッチのオーディオメディア間の変換ポイントを提供します。このドキュメントの例と図では、メディアゲートウェイコントローラー（MGC）という用語も使用されており、現在頻繁に展開されている分解されたゲートウェイと制御ロジックの大規模なクラスターを示しています。したがって、たとえば、SIP-ISUPゲートウェイは、PSTNにISUPを話し、インターネットにSIPを話し、シグナリングの種類間を変換するだけでなく、関連するBearerオーディオメディアと交換する責任があります。
* SIP phones: The term used to represent all end-user devices that originate or terminate SIP VoIP calls.
* SIP電話：SIP VoIP呼び出しを発信または終了するすべてのエンドユーザーデバイスを表すために使用される用語。
* Interface points between networks where administrative policies are enforced (potentially middleboxes, proxy servers, or gateways).
* 管理ポリシーが実施されるネットワーク間のインターフェイスポイント（潜在的にミドルボックス、プロキシサーバー、またはゲートウェイ）。
o Proxy Servers: A proxy server is a SIP intermediary that routes SIP requests to their destinations. For example, a proxy server might direct a SIP request to another proxy, a gateway or a SIP phone.
o プロキシサーバー：プロキシサーバーは、SIPリクエストを宛先にルーティングするSIP仲介者です。たとえば、プロキシサーバーは、SIPリクエストを別のプロキシ、ゲートウェイ、またはSIP電話に向ける場合があります。
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------
Figure 1: Motivation for SIP-T in ISUP-SIP interconnection
図1：ISUP-SIP相互接続におけるSIP-Tの動機
In Figure 2 a VoIP cloud serves as a transit network for telephone calls originating in a pair of LECs, where SIP is employed as the VoIP protocol used to set up and tear down these VoIP calls. At the edge of the depicted network, an MGC converts the ISUP signals to SIP requests, and sends them to a proxy server which in turn routes calls on other MGCs. Although this figure depicts only two MGCs, VoIP deployments would commonly have many such points of interconnection with the PSTN (usually to diversify among PSTN rate centers). For a call originating from LEC1 and be terminating in LEC2, the originator in SIP-T is the gateway that generates the SIP request for a VoIP call, and the terminator is the gateway that is the consumer of the SIP request; MGC1 would thus be the originator and MGC2, the terminator. Note that one or more proxies may be used to route the call from the originator to the terminator.
図2では、VOIPクラウドは、LECのペアから発信される電話の交通機関ネットワークとして機能します。SIPは、これらのVOIPコールのセットアップと解体に使用されるVOIPプロトコルとして使用されます。描かれたネットワークの端で、MGCはISUP信号をSIPリクエストに変換し、それらをプロキシサーバーに送信し、他のMGCを呼び出します。この図は2つのMGCのみを示していますが、VoIPの展開は一般に、PSTNとの相互接続の多くのポイントを持っています（通常、PSTNレートセンター間で多様化するため）。LEC1から発信され、LEC2で終了するコールの場合、SIP-TのオリジネーターはVoIPコールのSIPリクエストを生成するゲートウェイであり、ターミネーターはSIPリクエストの消費者であるゲートウェイです。したがって、MGC1はオリジネーターとターミネーターであるMGC2になります。1つまたは複数のプロキシを使用して、オリジネーターからターミネーターへの呼び出しをルーティングできることに注意してください。
In this flow, in order to seamlessly integrate the IP network with the PSTN, it is important to preserve the received SS7 information within SIP requests at the originating gateway and reuse this SS7 information when signaling to the PSTN at the terminating gateway. By encapsulating ISUP information in the SIP signaling, a SIP network can ensure that no SS7 information that is critical to the instantiation of features is lost when SIP bridges calls between two segments of the PSTN.
このフローでは、IPネットワークをPSTNとシームレスに統合するために、発信元のゲートウェイでSIP要求内に受信したSS7情報を保存し、終端ゲートウェイでPSTNに信号を送信するときにこのSS7情報を再利用することが重要です。SIPシグナリングのISUP情報をカプセル化することにより、SIPネットワークは、SIPブリッジがPSTNの2つのセグメント間で呼び出すと、機能のインスタンスに重要なSS7情報が失われないようにします。
That much said, if only the exchange of ISUP between gateways were relevant here, any protocol for the transport of signaling information may be used to achieve this, obviating the need for SIP and consequently that of SIP-T. SIP-T is employed in order to leverage the intrinsic benefits of utilizing SIP: request routing and call control leveraging proxy servers (including the use of forking), ease of SIP service creation, SIP's capability negotiation systems, and so on. Translation of information from the received ISUP message parameters to SIP header fields enables SIP intermediaries to consider this information as they handle requests. SIP-T thus facilitates call establishment and the enabling of new telephony services over the IP network while simultaneously providing a method of feature-rich interconnection with the PSTN.
多くのことは、ここでゲートウェイ間のISUPの交換のみが関連している場合、シグナリング情報の輸送のためのプロトコルを使用してこれを達成することができ、SIPの必要性、その結果、SIP-Tの必要性を排除することができます。SIP-Tは、SIPを使用することの本質的な利点を活用するために採用されています。リクエストルーティングとコールコントロールプロキシサーバー（フォーキングの使用を含む）、SIPサービス作成の容易さ、SIPの機能交渉システムなど。受信したISUPメッセージパラメーターからSIPヘッダーフィールドへの情報の翻訳により、SIP仲介者はリクエストを処理するときにこの情報を検討できます。したがって、SIP-Tは、IPネットワーク上のコール設定と新しいテレフォニーサービスの有効化を促進し、同時にPSTNとの機能が豊富な相互接続の方法を提供します。
Finally, the scenario in Figure 2 is just one of several flows in which SIP-T can be used - voice calls do not always both originate and terminate in the PSTN (via gateways); SIP phones can also be endpoints in a SIP-T session. In subsequent sections, the following possible flows will be further detailed:
最後に、図2のシナリオは、SIP -Tを使用できるいくつかのフローの1つにすぎません。音声コールは、常にPSTNで発生および終了するとは限りません（ゲートウェイ経由）。SIP電話は、SIP-Tセッションのエンドポイントにすることもできます。後続のセクションでは、次の可能なフローをさらに詳しく説明します。
1. PSTN origination - PSTN termination: The originating gateway receives ISUP from the PSTN and it preserves this information (via encapsulation and translation) in the SIP messages that it transmits towards the terminating gateway. The terminator extracts the ISUP content from the SIP message that it receives and it reuses this information in signaling sent to the PSTN.
1. PSTNオリジネーション-PSTN終了：発信元のゲートウェイはPSTNからISUPを受信し、SIPメッセージでこの情報を（カプセル化と翻訳を介して）終端ゲートウェイに送信することを保存します。ターミネーターは、受信したSIPメッセージからISUPコンテンツを抽出し、PSTNに送信された信号でこの情報を再利用します。
2. PSTN origination - IP termination: The originating gateway receives ISUP from the PSTN and it preserves this ISUP information in the SIP messages (via encapsulation and translation) that it directs towards the terminating SIP user agent. The terminator has no use for the encapsulated ISUP and ignores it.
2. PSTNオリジネーション - IP終了：発信元のゲートウェイは、PSTNからISUPを受信し、このISUP情報をSIPメッセージ（カプセル化と翻訳を介して）で、終了SIPユーザーエージェントに向けて保存します。ターミネーターは、カプセル化されたISUPを使用しておらず、それを無視します。
3. IP origination - PSTN termination: A SIP phone originates a VoIP call that is routed by one or more proxy servers to the appropriate terminating gateway. The terminating gateway converts to ISUP signaling and directs the call to an appropriate PSTN interface, based on information that is present in the received SIP header.
3. IP Origination -PSTN終了：SIP電話は、1つ以上のプロキシサーバーによって適切な終端ゲートウェイにルーティングされるVoIPコールを発信します。終了ゲートウェイは、ISUPシグナリングに変換され、受信したSIPヘッダーに存在する情報に基づいて、適切なPSTNインターフェイスに呼び出しを指示します。
4. IP origination - IP termination: This is a case for pure SIP. SIP-T (either encapsulation or translation of ISUP) does not come into play as there is no PSTN interworking.
4. IP Origination -IP終了：これは純粋なSIPの場合です。SIP-T（ISUPのカプセル化または翻訳のいずれか）は、PSTNインターワーキングがないため、機能しません。
The follow sections explore the essential SIP-T flows in detail. Note that because proxy servers are usually responsible for routing SIP requests (based on the Request-URI) the eventual endpoints at which a SIP request will terminate is generally not known to the originator. So the originator does not select from the flows described in this section, as a matter of static configuration or on a per-call basis - rather, each call is routed by the SIP network independently, and it may instantiate any of the flows below as the routing logic of the network dictates.
次のセクションでは、必須のSIP-Tフローを詳細に調べます。プロキシサーバーは通常、SIPリクエストをルーティングする責任があるため（リクエスト-URIに基づく）、SIP要求が終了する最終的なエンドポイントは、一般的に発信者には知られていないことに注意してください。したがって、このセクションで説明されているフローから、静的な構成の問題として、または一人当たりのフローから選択されていません。むしろ、各呼び出しはSIPネットワークによって独立してルーティングされ、以下のフローを以下のフローをインスタンス化する場合があります。ネットワークのルーティングロジックが指示します。
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|---| |---|
/|MGC| VoIP Network |MGC|\
/ --- --- \
/ * * \
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| PSTN | *** *** | PSTN |
-------- ********************* ---------
Figure 2: PSTN origination - PSTN termination (SIP Bridging)
図2：PSTNオリジネーション-PSTN終了（SIPブリッジング）
A scenario in which a SIP network connects two segments of the PSTN is referred to as 'SIP bridging'. When a call destined for the SIP network originates in the PSTN, an SS7 ISUP message will eventually be received by the gateway that is the point of interconnection with the PSTN network. This gateway is from the perspective of the SIP protocol the user agent client for this call setup request. Traditional SIP routing is used in the IP network to determine the appropriate point of termination (in this instance a gateway) and to establish a SIP dialog and begin negotiation of a media session between the origination and termination endpoints. The egress gateway then signals ISUP to the PSTN, reusing any encapsulated ISUP present in the SIP request it receives as appropriate.
SIPネットワークがPSTNの2つのセグメントを接続するシナリオは、「SIPブリッジング」と呼ばれます。SIPネットワーク向けのコールがPSTNに由来する場合、PSTNネットワークとの相互接続のポイントであるGatewayによって最終的にSS7 ISUPメッセージが受信されます。このゲートウェイは、このコールセットアップリクエストのSIPプロトコルのユーザーエージェントクライアントの観点からのものです。従来のSIPルーティングは、IPネットワークで使用され、適切な終了ポイント（この場合はゲートウェイ）を決定し、SIPダイアログを確立し、オリジネーションエンドポイントと終端エンドポイント間のメディアセッションのネゴシエーションを開始します。Engress Gatewayは、PSTNにISUPを指示し、必要に応じて受信するSIPリクエストに存在するカプセル化されたISUPを再利用します。
A very elementary call-flow for SIP bridging is shown below.
SIPブリッジング用の非常に基本的なコールフローを以下に示します。
PSTN MGC#1 Proxy MGC#2 PSTN
|-------IAM------>| | | |
| |-----INVITE---->| |
| | | |-----IAM----->|
| |<--100 TRYING---| |
| | | |<----ACM------|
| |<-----18x-------| |
|<------ACM-------| | | |
| | | |<----ANM------|
| |<----200 OK-----| |
|<------ANM-------| | | |
| |------ACK------>| |
|====================Conversation=================|
|-------REL------>| | | |
|<------RLC-------|------BYE------>| |
| | | |-----REL----->|
| |<----200 OK-----| |
| | | |<----RLC------|
| | | | |
********************
*** ***
* *
* *
* *
* *
|----| |-----|
/|MGC | VoIP Network |proxy|\
/ ---- ----- \
/ * * \
/ * * \
/ * * \
-------- * * -------------
| PSTN | ** ** | SIP phone |
-------- ********************* -------------
Figure 3: PSTN origination - IP termination A call originates from the PSTN and terminates at a SIP phone. Note that in Figure 5, the proxy server acts as the registrar for the SIP phone in question.
図3：PSTNオリジネーション - IP終了呼び出しはPSTNから発生し、SIP電話で終了します。図5では、プロキシサーバーが問題のSIP電話のレジストラとして機能することに注意してください。
A simple call-flow depicting the ISUP and SIP signaling for a PSTN-originated call terminating at a SIP endpoint follows:
SIPエンドポイントで終了するPSTNオリジネートコールのISUPとSIPシグナリングを描いた簡単なコールフローが次のとおりです。
PSTN MGC Proxy SIP phone
|----IAM----->| | |
| |--------INVITE------>| |
| | |-------INVITE------->|
| |<------100 TRYING----| |
| | |<-------18x----------|
| |<---------18x--------| |
|<----ACM-----| | |
| | |<-------200 OK-------|
| |<-------200 OK-------| |
|<----ANM-----| | |
| |---------ACK-------->| |
| | |---------ACK-------->|
|=====================Conversation========================|
|-----REL---->| | |
| |----------BYE------->| |
|<----RLC-----| |---------BYE-------->|
| | |<-------200 OK-------|
| |<-------200 OK-------| |
| | | |
********************
*** ***
* *
* *
* *
* *
|-----| |----|
/|proxy| VoIP Network |MGC |\
/ ----- ---- \
/ * * \
/ * * \
/ * * \
------------ * * ---------
|SIP phone | ** ** | PSTN |
------------ ********************* ---------
Figure 4: IP origination - PSTN termination
図4：IPオリジネーション-PSTN終了
A call originates from a SIP phone and terminates in the PSTN. Unlike the previous two flows, there is therefore no ISUP encapsulation in the request - the terminating gateway therefore only performs translation on the SIP headers to derive values for ISUP parameters.
通話はSIP電話から発生し、PSTNで終了します。したがって、以前の2つのフローとは異なり、リクエストにはISUPカプセル化はありません。したがって、終了ゲートウェイは、ISUPパラメーターの値を導出するためにSIPヘッダーの翻訳のみを実行します。
A simple call-flow illustrating the different legs in the call is as shown below.
以下に示すように、コール内のさまざまな脚を示す簡単なコールフロー。
SIP phone Proxy MGC PSTN
|-----INVITE----->| | |
| |--------INVITE-------->| |
|<---100 TRYING---| |-----IAM---->|
| |<------100 TRYING------| |
| | |<----ACM-----|
| |<---------18x----------| |
|<------18x-------| | |
| | |<----ANM-----|
| |<--------200 OK--------| |
|<-----200 OK-----| | |
|-------ACK------>| | |
| |----------ACK--------->| |
|========================Conversation===================|
|-------BYE------>| | |
| |----------BYE--------->| |
| | |-----REL---->|
| |<--------200 OK--------| |
|<-----200 OK-----| |<----RLC-----|
There are three distinct sorts of elements (from a functional point of view) in a SIP VoIP network that interconnects with the PSTN:
SIP VoIPネットワークには、PSTNと相互接続する3つの異なる種類の要素（機能的な観点から）があります。
1. The originators of SIP signaling
1. SIPシグナル伝達の創始者
2. The terminators of SIP signaling
2. SIPシグナル伝達のターミネーター
3. The intermediaries that route SIP requests from the originator to the terminator
3. SIPをルーティングする仲介者は、オリジネーターからターミネーターにリクエストします
Behavior for the Section 4.1, Section 4.2 and Section 4.3 intermediary roles in a SIP-T call are described in the following sections.
SIP-T呼び出しのセクション4.1、セクション4.2およびセクション4.3の中間役の動作については、次のセクションで説明します。
The function of the originating user agent client is to generate the SIP Call setup requests (i.e., INVITEs). When a call originates in the PSTN, a gateway is the UAC; otherwise some native SIP endpoint is the UAC. In either case, note that the originator generally cannot anticipate what sort of entity the terminator will be, i.e., whether final destination of the request is in a SIP network or the PSTN.
発生するユーザーエージェントクライアントの機能は、SIPコールのセットアップリクエストを生成することです（つまり、招待）。呼び出しがPSTNで発生する場合、ゲートウェイはUACです。それ以外の場合、一部のネイティブSIPエンドポイントはUACです。どちらの場合でも、オリジネーターは一般に、ターミネーターがどのようなエンティティになるか、つまりリクエストの最終宛先がSIPネットワークにあるかPSTNにあるかを予測できないことに注意してください。
In the case of calls originating in the PSTN (see Figure 3 and Figure 5), the originating gateway takes the necessary steps to preserve the ISUP information by encapsulating it in the SIP request it creates. The originating gateway is entrusted with the responsibility of identifying the version of the ISUP (ETSI, ANSI, etc.) that it has received and providing this information in the encapsulated ISUP (usually by adding a multipart MIME body with appropriate MIME headers). It then formulates the headers of the SIP INVITE request from the parameters of the ISUP that it has received from the PSTN as appropriate (see Section 5). This might, for instance, entail setting the 'To:' header field in the INVITE to the reflect dialed number (Called Party Number) of the received ISUP IAM.
PSTNに由来する呼び出しの場合（図3と図5を参照）、発信元のゲートウェイは、作成するSIPリクエストにカプセル化することにより、ISUP情報を保持するために必要な手順を実行します。発信元のゲートウェイには、ISUPのバージョン（ETSI、ANSIなど）を特定し、カプセル化されたISUPでこの情報を提供する責任が委託されています（通常、適切なMIMEヘッダーを使用してマルチパートMIMEボディを追加することにより）。次に、PSTNから受信したISUPのパラメーターから、SIP Inviteリクエストのヘッダーを適切に定式化します（セクション5を参照）。これは、たとえば、 'to：'ヘッダーフィールドを、受信したISUP IAMの反射ダイヤル番号（党番号と呼ばれる）に招待するヘッダーフィールドを設定することを伴う場合があります。
In other cases (like Figure 7), a SIP phone is the originator of a VoIP call. Usually, the SIP phone sends requests to a SIP proxy that is responsible for routing the request to an appropriate destination. There is no ISUP to encapsulate at the user agent client, as there is no PSTN interface. Although the call may terminate in the telephone network and need to signal ISUP in order for that to take place, the originator has no way to anticipate this and it would be foolhardy to require that all SIP VoIP user agents have the capability to generate ISUP. It is therefore not the responsibility of an IP endpoints like a SIP phone to generate encapsulated ISUP. Thus, an originator must generate the SIP signaling while performing ISUP encapsulation and translation when possible (meaning when the call has originated in the PSTN).
他の場合（図7のように）、SIP電話はVoIPコールの発信者です。通常、SIP電話は、リクエストを適切な宛先にルーティングする責任があるSIPプロキシにリクエストを送信します。PSTNインターフェイスがないため、ユーザーエージェントクライアントにカプセル化するisupはありません。電話は電話ネットワークで終了する場合があり、それが行われるためにはISUPを信号する必要がありますが、オリジネーターはこれを予測する方法がなく、すべてのSIP VoIPユーザーエージェントがISUPを生成する機能を持つことを要求することは愚かです。したがって、カプセル化されたISUPを生成するためのSIP電話のようなIPエンドポイントの責任ではありません。したがって、発信元は、可能な場合は、ISUPカプセル化と翻訳を実行しながらSIPシグナル伝達を生成する必要があります（コールがPSTNで発生した場合を意味します）。
Originator requirements: encapsulate ISUP, translate information from ISUP to SIP, multipart MIME support (for gateways only)
オリジネーターの要件：ISUPをカプセル化し、ISUPからSIPに翻訳し、マルチパートMIMEサポート（ゲートウェイのみ）
The SIP-T terminator is a consumer of the SIP calls. The terminator is a standard SIP UA that can be either a gateway that interworks with the PSTN or a SIP phone.
SIP-Tターミネーターは、SIPコールの消費者です。ターミネーターは、PSTNとのインターワークまたはSIP電話のいずれかである標準的なSIP UAです。
In case of PSTN terminations (see Figure 3 and Figure 7) the egress gateway terminates the call to its PSTN interface. The terminator generates the ISUP appropriate for signaling to the PSTN from the incoming SIP message. Values for certain ISUP parameters may be gleaned from the SIP headers or extracted directly from an encapsulated ISUP body. Generally speaking, a gateway uses any encapsulated ISUP as a template for the message it will send, but it overwrites parameter values in the template as it translates SIP headers or adds any parameter values that reflect its local policies (see Appendix A item 1).
PSTN終端の場合（図3と図7を参照）、出力ゲートウェイはそのPSTNインターフェイスへの呼び出しを終了します。ターミネーターは、着信SIPメッセージからPSTNへの信号に適したISUPを生成します。特定のISUPパラメーターの値は、SIPヘッダーから収集するか、カプセル化されたISUP本体から直接抽出される場合があります。一般的に言えば、ゲートウェイは、送信するメッセージのテンプレートとしてカプセル化されたISUPを使用しますが、SIPヘッダーを変換するか、ローカルポリシーを反映するパラメーター値を追加するため、テンプレート内のパラメーター値を上書きします（付録Aアイテム1を参照）。
In case of an IP termination (Figure 5), the SIP UAS that receives SIP messages with encapsulated ISUP typically disregards the ISUP message. This does introduce a general requirement, however, that devices like SIP phones handle multipart MIME messages and unknown MIME types gracefully (this is a baseline SIP requirement, but also a place where vendors have been known to make shortcuts).
IP終了の場合（図5）、カプセル化されたISUPを使用してSIPメッセージを受信するSIP UASは、通常ISUPメッセージを無視します。これにより、SIP電話などのデバイスがマルチパートMIMEメッセージと不明なMIMEタイプを優雅に処理するという一般的な要件が導入されます（これはベースラインSIP要件ですが、ベンダーがショートカットを作成することが知られている場所でもあります）。
Terminator requirements: standard SIP processing, interpretation of encapsulated ISUP (for gateways only), support for multipart MIME, graceful handling of unknown MIME content (for non-gateways only)
ターミネーターの要件：標準SIP処理、カプセル化されたISUPの解釈（ゲートウェイのみ）、マルチパートMIMEのサポート、不明なMIMEコンテンツの優雅な取り扱い（非ゲートウェイのみ）
Intermediaries like proxy servers are entrusted with the task of routing messages to one another, as well as gateways and SIP phones. Each proxy server makes a forwarding decision for a SIP request based on values of various headers, or 'routable elements' (including the Request-URI, route headers, and potentially many other elements of a SIP request).
プロキシサーバーのような仲介者は、メッセージを互いにルーティングするタスク、およびゲートウェイやSIP電話を委ねられます。各プロキシサーバーは、さまざまなヘッダーまたは「ルーティング可能な要素」（リクエスト-URI、ルートヘッダー、およびSIPリクエストの他の多くの要素を含む）の値に基づいて、SIP要求の転送決定を行います。
SIP-T does introduce some additional considerations for forwarding a request that could lead to new features and requirements for intermediaries. Feature transparency of ISUP is central to the notion of SIP-T. Compatibility between the ISUP variants of the originating and terminating PSTN interfaces automatically leads to feature transparency. Thus, proxy servers might take an interest in the variants of ISUP that are encapsulated with requests - the variant itself could become a routable element. The termination of a call at a point that results in greater proximity to the final destination (rate considerations) is also an important consideration. The preference of one over the other results in a trade-off between simplicity of operation and cost. The requirement of procuring a reasonable rate may dictate that a SIP-T call spans dissimilar PSTN interfaces (SIP bridging across different gateways that don't support any ISUP variants in common). In order to optimize for maximum feature transparency and rate, some operators of intermediaries might want to consider practices along the following lines: a) The need for ISUP feature transparency may necessitate ISUP variant translation (conversion), i.e., conversion from one variant of ISUP to another in order to facilitate the termination of that call over a gateway interface that does not support the ISUP variant of the originating PSTN interface. (See Appendix A item 2.) Although in theory conversion may be performed at any point in the path of the request, it is optimal to perform it at a point that is at the greatest proximity to the terminating gateway. This could be accomplished by delivering the call to an application that might perform the conversion between variants. Feature transparency in this case is contingent on the availability of resources to perform ISUP conversion, and it incurs an increase in the call-set up time.
SIP-Tは、仲介者の新機能と要件につながる可能性のあるリクエストを転送するためのいくつかの追加の考慮事項を導入します。ISUPの特徴の透明性は、SIP-Tの概念の中心です。PSTNインターフェイスの発信と終端のISUPバリエーション間の互換性は、自動的に透明度につながります。したがって、プロキシサーバーは、リクエストでカプセル化されたISUPのバリアントに関心を持っている可能性があります。バリアント自体がルーティング可能な要素になる可能性があります。最終目的地（レートの考慮事項）に大きな近接性をもたらすポイントでの呼び出しの終了も重要な考慮事項です。一方が他方よりも優先されると、操作の単純さとコストのトレードオフが生じます。合理的なレートを調達する要件は、SIP-Tコールが異なるPSTNインターフェイスに及ぶことを決定する可能性があります（共通のISUPバリアントをサポートしない異なるゲートウェイをSIPブリッジング）。最大の機能の透明性とレートのために最適化するために、仲介者の一部のオペレーターは、次の行に沿ったプラクティスを検討することをお勧めします。a）ISUP機能の透明性の必要性は、ISUPのバリアント変換（変換）、つまりISUPの1つのバリアントからの変換を必要とする場合があります。発信元のPSTNインターフェイスのISUPバリアントをサポートしていないゲートウェイインターフェイスを介したその呼び出しの終了を容易にするために別の人に。（付録A項目2を参照）理論では、リクエストのパスの任意の時点で理論的な変換が実行される場合がありますが、終端ゲートウェイに最も近い点で実行することが最適です。これは、バリアント間の変換を実行する可能性のあるアプリケーションへの呼び出しを配信することで実現できます。この場合の特徴の透明性は、ISUP変換を実行するためのリソースの可用性を条件としており、コールセットアップ時間の増加が生じます。
b) An alternative would be to sacrifice ISUP transparency by handing the call off to a gateway that does not support the version of the originating ISUP. The terminating MGC would then just ignore the encapsulated ISUP and use the information in the SIP header to terminate the call.
b) 別の方法は、コールオフを発信するISUPのバージョンをサポートしないゲートウェイにコールオフを引き渡すことにより、ISUPの透明性を犠牲にすることです。終了するMGCは、カプセル化されたISUPを無視し、SIPヘッダーの情報を使用してコールを終了します。
So, it may be desirable for proxy servers to have the intelligence to make a judicious choice given the options available to it.
したがって、プロキシサーバーが利用可能なオプションを考えると、賢明な選択をするためのインテリジェンスを持つことが望ましい場合があります。
Proxy requirements: ability to route based on choice of routable elements
プロキシ要件：ルーティング可能な要素の選択に基づいてルーティングする機能
If the SIP-T originator is a gateway that received an ISUP request, it must always perform both encapsulation and translation ISUP, regardless of where the originator might guess that the request will terminate.
SIP-TオリジネーターがISUPリクエストを受信したゲートウェイである場合、オリジネーターがリクエストが終了する場所に関係なく、常にカプセル化と翻訳ISUPの両方を実行する必要があります。
If the terminator does not understand ISUP, it ignores it while performing standard SIP processing. If the terminator does understand ISUP, and needs to signal to the PSTN, it should reuse the encapsulated ISUP if it understands the variant. The terminator should perform the following steps:
ターミネーターがISUPを理解していない場合、標準のSIP処理の実行中にそれを無視します。ターミネーターがISUPを理解し、PSTNに信号を送信する必要がある場合、バリアントを理解している場合、カプセル化されたISUPを再利用する必要があります。ターミネーターは次の手順を実行する必要があります。
o Extract the ISUP from the message body, and use this ISUP as a message template. Note that if there is no encapsulated ISUP in the message, the gateway should use a canonical template for the message type in question (a pre-populated ISUP message configured in the gateway) instead.
o メッセージ本文からiSUPを抽出し、このISUPをメッセージテンプレートとして使用します。メッセージにカプセル化されたISUPがない場合、ゲートウェイは、問題のメッセージタイプ（ゲートウェイで設定された事前に入力されたISUPメッセージ）に正規のテンプレートを使用する必要があることに注意してください。
o Translate the headers of the SIP request into ISUP parameters, overwriting any values in the message template.
o SIP要求のヘッダーをISUPパラメーターに変換し、メッセージテンプレート内の値を上書きします。
o Apply any local policies in populating parameters.
o 居住パラメーターにローカルポリシーを適用します。
An intermediary must be able to route a call based on the choice of routable elements in the SIP headers.
仲介者は、SIPヘッダーのルーティング可能な要素の選択に基づいて、コールをルーティングできる必要があります。
The mechanisms described in the following sections are the components of SIP-T that provide the protocol functions entailed by the requirements.
次のセクションで説明するメカニズムは、要件によって伴うプロトコル関数を提供するSIP-Tのコンポーネントです。
SIP-T uses the methods and procedures of SIP as defined by RFC 3261.
SIP-Tは、RFC 3261で定義されているSIPの方法と手順を使用します。
Encapsulation of the PSTN signaling is one of the major requirements of SIP-T. SIP-T uses multipart MIME bodies to enable SIP messages to contain multiple payloads (Session Description Protocol or SDP [5], ISUP, etc.). Numerous ISUP variants are in existence today; the ISUP MIME type enable recipients too recognize the ISUP type (and thus determine whether or not they support the variant) in the most expeditious possible manner. One scheme for performing ISUP encapsulation using multi-part MIME has been described in [2].
PSTNシグナル伝達のカプセル化は、SIP-Tの主要な要件の1つです。SIP-Tでは、マルチパートMIMEボディを使用して、SIPメッセージに複数のペイロードを含めることができます（セッション説明プロトコルまたはSDP [5]、ISUPなど）。今日、多数のISUPバリアントが存在しています。ISUP MIMEタイプを有効にして、受信者もISUPタイプを認識します（したがって、バリアントをサポートするかどうかを決定します）。マルチパートMIMEを使用してISUPカプセル化を実行するための1つのスキームは、[2]で説明されています。
Translation encompasses all aspects of signaling protocol conversion between SIP and ISUP. There are essentially two components to the problem of translation:
翻訳には、SIPとISUPの間のシグナル伝達プロトコル変換のすべての側面が含まれます。翻訳の問題には基本的に2つのコンポーネントがあります。
1. ISUP SIP message mapping: This describes a mapping between ISUP and SIP at the message level. In SIP-T deployments gateways are entrusted with the task of generating a specific ISUP message for each SIP message received and vice versa. It is necessary to specify the rules that govern the mapping between ISUP and SIP messages (i.e., what ISUP messages is sent when a particular SIP message is received: an IAM must be sent on receipt of an INVITE, a REL for BYE, and so on). A potential mapping between ISUP and SIP messages has been described in [10].
1. ISUP SIPメッセージマッピング：これは、メッセージレベルでのISUPとSIPの間のマッピングを説明します。SIP-T Deploymentsでは、ゲートウェイは、受信した各SIPメッセージの特定のISUPメッセージを生成するタスクを委託され、その逆も同様です。ISUPメッセージとSIPメッセージの間のマッピングを支配するルールを指定する必要があります（つまり、特定のSIPメッセージを受信したときにISUPメッセージが送信されます。IAMは、招待状の受領時に送信する必要があります。の上）。ISUPメッセージとSIPメッセージの間の潜在的なマッピングが[10]で説明されています。
2. ISUP parameter-SIP header mapping: A SIP request that is used to set up a telephone call should contain information that enables it to be appropriately routed to its destination by proxy servers in the SIP network - for example, the telephone number dialed by the originating user. It is important to standardize a set of practices that defines the procedure for translation of information from ISUP to SIP (for example, the Called Party Number in an ISUP IAM must be mapped onto the SIP 'To' header field and Request-URI, etc.). This issue becomes inherently more complicated by virtue of the fact that the headers of a SIP request (especially an INVITE) may be transformed by intermediaries, and that consequently, the SIP headers and encapsulated ISUP bodies come to express conflicting values - effectively, a part of the encapsulated ISUP may be rendered irrelevant and obsolete.
2. ISUPパラメーター-SIPヘッダーマッピング：電話の設定に使用されるSIPリクエストには、SIPネットワークのプロキシサーバーによって適切に宛先にルーティングできるようにする情報が含まれている必要があります。たとえば、発信元によってダイヤルされた電話番号ユーザー。ISUPからSIPへの情報の翻訳の手順を定義する一連のプラクティスを標準化することが重要です（たとえば、ISUP IAMの呼び出されたパーティー番号は、sip 'から'ヘッダーフィールドとリクエスト-uriなどにマッピングする必要があります。。）。この問題は、SIPリクエストのヘッダー（特に招待）が仲介者によって変換される可能性があるという事実により、本質的により複雑になり、その結果、SIPヘッダーとカプセル化されたISUPボディは矛盾する価値を表現するようになります。カプセル化されたISUPのうち、無関係で時代遅れになる可能性があります。
Pure SIP does not have any provision for carrying any mid-call control information that is generated during a session. The INFO [3] method should be used for this purpose. Note however that INFO is not suitable for managing overlap dialing (for one way of implementing overlap dialing see [11]). Also note that the use of INFO for signaling mid-call DTMF signals is not recommended (see RFC2833 [9] for a recommended mechanism).
純粋なSIPには、セッション中に生成される中間コール制御情報を携帯するための規定はありません。情報[3]メソッドは、この目的に使用する必要があります。ただし、情報はオーバーラップダイヤルの管理には適していないことに注意してください（オーバーラップダイヤルを実装する1つの方法[11]を参照）。また、ミッドコールDTMF信号を信号するための情報の使用は推奨されないことに注意してください（推奨されるメカニズムについてはRFC2833 [9]を参照）。
The originator of a SIP-T request might package both SDP and ISUP elements into the same SIP message by using the MIME multipart format. Traditionally in SIP, if the terminating device does not support a multipart payload (multipart/mixed) and/or the ISUP MIME type, it would then reject the SIP request with a 415 Unsupported Media Type specifying the media types it supports (by default, 'application/SDP'). The originator would subsequently have to re-send the SIP request after stripping out the ISUP payload (i.e. with only the SDP payload) and this would then be accepted.
SIP-Tリクエストのオリジネーターは、MIMEマルチパート形式を使用して、SDPとISUP要素の両方を同じSIPメッセージにパッケージ化する場合があります。従来、SIPでは、終端デバイスがマルチパートペイロード（マルチパート/混合）および/またはISUP MIMEタイプをサポートしていない場合、サポートするメディアタイプを指定する415のサポートされていないメディアタイプでSIPリクエストを拒否します（デフォルトでは、'アプリケーション/SDP'）。その後、オリジネーターは、ISUPペイロード（つまり、SDPペイロードのみ）を削除した後、SIPリクエストを再送信する必要があり、これは受け入れられます。
This is a rather cumbersome flow, and it is thus highly desirable to have a mechanism by which the originator could signify which bodies are required and which are optional so that the terminator can silently discard optional bodies that it does not understand (allowing a SIP phone to ignore an ISUP payload when processing ISUP is not critical). This is contingent upon the terminator having support for a Content-type of multipart/mixed and access to the Content-Disposition header to express criticality.
これはかなり面倒な流れであるため、ターミネーターが理解できないオプションのボディを静かに廃棄できるように、オリジネーターがどの体が必要であるかを示すメカニズムを持つことが非常に望ましいです（SIP電話を許可するオプションのボディを捨てることができますISUPの処理が重要ではないときにISUPペイロードを無視すること）。これは、ターミネーターがコンテンツタイプのマルチパート/混合をサポートし、重要性を表現するためのコンテンツ配置ヘッダーへのアクセスを条件とすることです。
1. Support for ISUP is optional. Therefore, UA2 accepts the INVITE irrespective of whether it can process the ISUP.
1. ISUPのサポートはオプションです。したがって、UA2は、ISUPを処理できるかどうかに関係なく、招待を受け入れます。
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=optional;)
<--18x
< - 18x
2. Support for ISUP is preferred. UA2 does not support the ISUP and rejects the INVITE with a 415 Unsupported Media Type. UA1 strips off the ISUP and re-sends the INVITE with SDP only and this is the accepted.
2. ISUPのサポートが推奨されます。UA2はISUPをサポートせず、415のサポートされていないメディアタイプで招待を拒否します。UA1はISUPを取り除き、SDPのみで招待状を再送信し、これは受け入れられます。
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
ack->
INVITE-->
(Content-type: application/sdp)
<--18x
< - 18x
3. Support for ISUP is mandatory for call establishment. UA2 does not support the ISUP and rejects the INVITE with a 415 Unsupported Media type. UA1 then directs its request to UA3.
3. ISUPのサポートは、コール設立に義務付けられています。UA2はISUPをサポートせず、415のサポートされていないメディアタイプで招待を拒否します。UA1はその要求をUA3に指示します。
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
ack->
UA1 UA3
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
Note that the exchanges of messages above are not complete; only the messages relevant to this discussion are shown. Specifics of the ISUP MIME type can be obtained from [2]. The 'version' and 'base' parameters are not shown here, but must be used in accordance with the rules of [2].
上記のメッセージの交換は完全ではないことに注意してください。この議論に関連するメッセージのみが表示されます。ISUP MIMEタイプの詳細は[2]から取得できます。「バージョン」と「ベース」パラメーターはここには表示されませんが、[2]のルールに従って使用する必要があります。
SIP-T can be employed as an interdomain signaling mechanism that may be subject to pre-existing trust relationships between administrative domains. In many legal environments, distribution of ISUP is restricted to licensed carriers; SIP-T introduces some challenges in so far as it bridges carrier signaling with end-user signaling. Any administrative domain implementing SIP-T should have an adequate security apparatus (including elements that manage any appropriate policies to manage fraud and billing in an interdomain environment) in place to ensure that the transmission of ISUP information does not result in any security violations.
SIP-Tは、管理ドメイン間の既存の信頼関係の影響を受ける可能性のあるドメイン間シグナル伝達メカニズムとして採用できます。多くの法的環境では、ISUPの分布はライセンスされたキャリアに制限されています。SIP-Tは、エンドユーザーシグナル伝達でキャリアシグナリングをブリッジする限り、いくつかの課題を導入します。SIP-Tを実装する管理ドメインには、ISUP情報の送信がセキュリティ違反をもたらさないことを確認するために、適切なセキュリティ装置（ドメイン間環境で詐欺と請求を管理する適切なポリシーを管理する要素を含む）を備えている必要があります。
Transporting ISUP in SIP bodies may provide opportunities for abuse, fraud, and privacy concerns, especially when SIP-T requests can be generated, inspected or modified by arbitrary SIP endpoints. ISUP MIME bodies should be secured (preferably with S/MIME [4]) to alleviate this concern, as is described in the Security Considerations of the core SIP specification [1]. Authentication properties provided by S/MIME would allow the recipient of a SIP-T message to ensure that the ISUP MIME body was generated by an authorized entity. Encryption would ensure that only carriers possessing a particular decryption key are capable of inspecting encapsulated ISUP MIME bodies in a SIP request.
SIP団体でのISUPの輸送は、特にSIP-Tのリクエストを任意のSIPエンドポイントによって生成、検査、または変更できる場合、虐待、詐欺、プライバシーの懸念の機会を提供する場合があります。コアSIP仕様[1]のセキュリティに関する考慮事項に記載されているように、この懸念を軽減するために、ISUP MIME体は（できればS/MIME [4]）を保護する必要があります。S/MIMEが提供する認証プロパティは、SIP-Tメッセージの受信者に、ISUP MIMEボディが認定エンティティによって生成されるようにすることができます。暗号化は、特定の復号化キーを所有するキャリアのみが、SIPリクエストでカプセル化されたISUP MIME体を検査できるようにすることを保証します。
SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and SHOULD support encryption (CMS EnvelopedData).
SIP-Tエンドポイントは、S/MIMEシグネチャ（CMS SignedData）をサポートする必要があり、暗号化（CMS EnvelopedData）をサポートする必要があります。
This document introduces no new considerations for IANA.
このドキュメントでは、IANAの新しい考慮事項は紹介されていません。
Normative References
引用文献
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年5月。
[2] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
[2] Zimmerer、E.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M.、M。Zonoun、「ISUPおよびQSIGオブジェクトのMIMEメディアタイプ」、RFC 3204、2001年12月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[4] Ramsdell、B。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
Non-Normative References
非規範的な参照
[6] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, September 1997, <http://www.itu.int>.
[6] International Telecommunications Union、「Signaling System No. 7; ISDNユーザーパーツシグナル伝達手順」、ITU-T Q.764、1997年9月、<http://www.itu.int>。
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[7] Faltstrom、P。、「E.164番号とDNS」、RFC 2916、2000年9月。
[8] Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[8] Rosenberg、J.、Salama、H。and M. Squire、「IP（Trip）を介したテレフォニールーティング」、RFC 3219、2002年1月。
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Schulzrinne、H。およびS. Petrack、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 2833、2000年5月。
[10] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP Mapping", Work in Progress.
[10] Camarillo、G.、Roach、A.、Peterson、J。and L. Ong、「Isup to Sip Mapping」、進行中の作業。
[11] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of ISUP Overlap Signaling to SIP", Work in Progress.
[11] Camarillo、G.、Roach、A.、Peterson、J。、およびL. Ong、「SIPへのISUPオーバーラップシグナルのマッピング」、進行中の作業。
1. Some terminating MGCs may alter the encapsulated ISUP in order to remove any conditions specific to the originating circuit; for example, continuity test flags in the Nature of Connection Indicators, etc.
1. 一部の終了MGCは、発信回路に固有の条件を削除するために、カプセル化されたISUPを変更する場合があります。たとえば、接続インジケーターなどの性質における連続性テストフラグ
2. Even so, the relevance of ANSI-specific information in an ETSI network (or vice versa) is questionable. Clearly, the strength of SIP-T is realized when the encapsulated ISUP involves the usage of proprietary parameters.
2. それでも、ETSIネットワーク（またはその逆）におけるANSI固有の情報の関連性は疑わしいです。明らかに、カプセル化されたISUPに独自のパラメーターの使用が含まれる場合、SIP-Tの強度が実現されます。
We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan Rosenberg, Dean Willis, Robert F. Penfield, Steve Donovan, Allison Mankin, Scott Bradner and Steve Bellovin for their valuable comments.
アンドリュー・デュガン、ロブ・メイドホフ、デイブ・マーティン、アダム・ローチ、ジョナサン・ローゼンバーグ、ディーン・ウィリス、ロバート・F・ペンフィールド、スティーブ・ドノヴァン、アリソン・マンキン、スコット・ブラッドナー、スティーブ・ベロヴィンの貴重なコメントに感謝します。
The original 'SIP+' proposal for interconnecting portions of the PSTN with SIP bridging was developed by Eric Zimmerer.
SIPブリッジングとのPSTNの相互接続部分に関するオリジナルの「SIP」提案は、Eric Zimmererによって開発されました。
Authors' Addresses
著者のアドレス
Aparna Vemuri-Pattisam Qwest Communications 6000 Parkwood Pl Dublin, OH 43016 US EMail: Aparna.Vemuri@Qwest.com vaparna10@yahoo.com
Aparna vemuri-pattisam qwest communications 6000 parkwood pl dublin、oh 43016 usメール：aparna.vemuri@qwest.com vaparna10@yahoo.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US電話：1 925/363-8720メール：jon.peterson@neustar.biz uri：http：//www.neustar.biz/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。