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
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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ゲートウェイの使用をtaxonomizesケースを使用して提供し、インターワーキングのために必要なメカニズムを識別する。 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は、IP（VoIP）のボイスオーバーを実装するために使用される主要プロトコルの一つです。テレフォニーコールシグナリングを実行し、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外部の専門知識の不足は、IETFがSIP PSTNのコアプロトコルと比較して、流量の相対的状態にある、特にので、この作業をステージングするのに最適な場所であることを示唆しています。また、SIP（SIP及びSIPPING）に焦点を当てる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に関して機能透過性です。そのようなそのような信号システム第7号（SS7 [6]）ユーザ体験一方における任意の衰弱差を排除するようにSIPネットワークによって提供されるようにPSTNプロトコルに実装等コールウェイティング、フリーダイヤル番号、等の伝統的な電気通信サービスSIPの柔軟性を制限するものではありません。一方で、SIP終点は、通常のSIP電話機（以下のセクション2で定義を参照）よりもむしろSS7に堪能である装置であるそのようなサービスの提供のためのプリミティブをサポートすることが必要です。しかし、SS7情報がゲートウェイで利用可能であることも必須である、SS7-SIP相互接続点は、そうでなければ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テレフォニーネットワークのもう一つの重要な特徴は、SIPリクエストのルーティング性である - 電話の呼を設定するSIPリクエストを適切SIPネットワークでプロキシサーバがその宛先にルーティングすることを可能にするために、そのヘッダーに十分な情報が含まれている必要があります。最も一般的には、これはダイヤルした番号のような呼び出しのパラメータはSIPリクエストにSS7シグナリングから引き継がれるべきであることを必要とします。 [7] [8]又はENUM順に例えばTRIPなどのメカニズムによって影響され得るSIPネットワークにおけるルーティング。
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）努力がSIPメッセージにシグナリングレガシー電話の統合のための枠組みを提供します。 SIP-Tは、それぞれ、「カプセル化」と「翻訳」として知られている技術によって上記二つの特徴を提供します。 SIP-ISUPゲートウェイに、SS7 ISUPメッセージは、サービスに必要な情報をSIP要求に破棄されないようにするためにSIP内に封入されています。しかし、SIPリクエストのルーティング決定を行うプロキシサーバのような仲介者がそう同時に、ISUPを理解することは期待できない、いくつかの重要な情報は、SIP要求をルーティングする方法を決定するために、対応するSIPヘッダにISUPメッセージから翻訳されます。
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ヘッダにISUPにISUP情報の依存関係の翻訳をSIPメッセージのルータビリティ
Transfer of mid-call ISUP signaling Use of the INFO Method for mid-messages call signaling
半ばメッセージについてINFOメソッドの使用を知らせる通話中ISUPの転送がコールシグナリング
Table 1: SIP-T features that fulfill PSTN-IP inter-connection Requirements
表1：SIP-TのPSTN-IP相互接続要件を満たす機能
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、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相互接続の点を横切るプロトコル変換および機能透明性を提供することです。 （この文書の目的のためにSIPネットワーク）VoIPネットワークは、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を決定そのゲートウェイがサポートしている変異体です。ゲートウェイは、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.
PSTN O（公衆交換電話網）：これは、ローカル、長距離の全体の相互接続されたコレクションと国際電話会社を指します。以下の実施例では、用語ローカル交換キャリヤ（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およびシグナリングのタイプの間の変換、ならびに任意の関連ベアラ音声メディアを交換する責任があります。
* 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クラウドは、VoIPプロトコルを設定し、これらのVoIP通話を切断するために使用されるSIPを採用するのLEC、一対の発信通話の中継ネットワークとして機能します。示したネットワークのエッジで、MGCは、要求をSIPにISUP信号を変換し、ターン経路内の他のMGCに呼び出しプロキシサーバに送信します。この図は、2つだけのMGCを示しているが、VoIPの導入は、一般的に（通常はPSTN率・センター間で多様化する）PSTNとの相互接続の多くのこのような点を持っているでしょう。コールLEC1由来およびLEC2で終端するため、SIP-Tにおける発信は、VoIPコールのためのSIP要求を生成するゲートウェイであり、及びターミネーターは、SIP要求の消費者であるゲートウェイです。 MGC1は、このように創始し、MGC2、ターミネータだろう。一つ以上のプロキシがルート終端に発信者からの呼び出しに使用されてもよいことに留意されたいです。
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.
このフローでは、シームレスにPSTNとIPネットワークを統合するために、発信ゲートウェイで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の能力交渉システム、および。ヘッダフィールドをSIPする受信ISUPメッセージパラメータからの情報の翻訳は、それらが要求を処理するようにこの情報を考慮するSIP仲介を可能にします。 SIP-Tは、このように、コール確立を容易にすると同時に、PSTNと豊富な機能を備えた相互接続の方法を提供しながら、IPネットワーク上で新しい電話サービスの有効化。
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を使用することができるいくつかの流れのひとつである - 音声通話は、常に両方の発信していないと（ゲートウェイを介して）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を受信し、それが終端SIPユーザエージェントに向かって導くことSIPメッセージ（カプセル化と翻訳を介して）このISUP情報を保存します。ターミネータは、カプセル化された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発信 - 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発信 - IPの終了：これは純粋なSIPの場合です。何のPSTNインターワーキングがないとしてSIP-Tは、（ISUPのカプセル化または翻訳）遊びに来ていません。
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要求をルーティングする責任があるので、SIP要求は、一般的に発信者に知られていない終了するときの最終的なエンドポイント（要求URIに基づいて）ことに留意されたいです。そう発信者は静的な構成の問題として、またはコールごとに、このセクションで説明するフローから選択しない - むしろ、各コールは、独立して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の二つのセグメントを接続するシナリオは、「SIPブリッジ」と呼ばれます。 SIPネットワーク宛の呼がPSTNに由来する場合、SS7のISUPメッセージは、最終的にPSTNネットワークとの相互接続点であるゲートウェイによって受信されます。このゲートウェイは、この呼設定要求のためのSIPプロトコルユーザエージェントクライアントの観点からです。伝統的なSIPルーティングは終了の適切な点（この例ではゲートウェイ）を決定し、SIPダイアログを確立し、発信および終端エンドポイント間のメディアセッションの交渉を開始するために、IPネットワークで使用されています。出口ゲートウェイは、それが適宜受信SIP要求に任意にカプセル化ISUP存在を再利用する、PSTNへの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
図3：PSTN発信 - IP終了
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.
コールが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:
単純なコールフローISUPを示すとSIPは、SIPエンドポイントで終端PSTN発信呼のためのシグナリングは、以下：
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で終了します。前の二つの流れとは異なり、従って要求には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:
PSTNと相互接続SIP VoIPネットワーク内の（機能的な観点から）要素3つの異なる種類があります。
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に発信呼の場合には、発信側ゲートウェイは、それが作成要求SIPにそれをカプセル化することによってISUP情報を保存するために必要なステップをとる（図3及び図5を参照）。発信側ゲートウェイは、それが受信したISUP（ETSI、ANSI等）のバージョンを識別し、（通常、適切なMIMEヘッダとマルチパートMIME本体を追加することにより）カプセル化ISUPにこの情報を提供する責任を委託されています。次に、SIPのヘッダは、それが適切なPSTN（セクション5を参照）から受信したISUPのパラメータからINVITE要求を定式化します。受信ISUP IAMの（党ナンバーと呼ばれる）を反映ダイヤルした番号にINVITEのヘッダフィールド：これは、たとえば、「に」を設定伴うかもしれません。
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エンドポイントの責任ではありません。可能な場合（コールがPSTNに発信した場合を意味する）ISUPカプセル化と変換を実行しつつ、発信者はSIPシグナリングを生成しなければなりません。
Originator requirements: encapsulate ISUP, translate information from ISUP to SIP, multipart MIME support (for gateways only)
発信要件：（ゲートウェイのみのため）SIPにISUPからの情報を翻訳し、ISUPをカプセル化し、マルチパート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終端の場合に出口ゲートウェイは、PSTNインターフェイスにコールを終了する（図3及び図7を参照）。ターミネーターは、着信SIPメッセージからPSTNへのシグナリングのためのISUPの適切なを生成します。特定のISUPパラメータの値は、SIPヘッダから収集又はカプセル化ISUP本体から直接抽出することができます。一般的に言えば、ゲートウェイは、それが送信するメッセージのためのテンプレートとして任意のカプセル化ISUPを使用し、それはSIPヘッダを変換またはローカルポリシーを（付録項目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の要件ですが、また、ベンダーはショートカットを作成することが知られている場所）SIP電話機のようなデバイスが正常マルチパートMIMEメッセージと未知のMIMEタイプを扱うこと、しかし、一般的な要件を導入しません。
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)
ターミネーターの要件：マルチパートMIME、未知のMIMEコンテンツの優雅な取り扱いのため、サポート（のみゲートウェイ用）標準SIP処理、カプセル化ISUPの解釈（非ゲートウェイ用のみ）
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の概念の中心です。発信元のISUPバリアントと終端PSTNインターフェイス間の互換性は自動的に透明性を備えていますにつながります。このように、プロキシサーバは、要求にカプセル化されているISUPの変種に興味を取るかもしれない - バリアント自体は、ルーティング可能な要素になる可能性があります。最終的な宛先（レートの考慮）に大きく接近をもたらす点でのコールの終了もまた重要な考慮事項です。動作およびコストの単純さの間のトレードオフで他の結果の上で1つの嗜好。合理的な速度を調達の要件は、SIP-Tコールが異なるPSTNインターフェイス（SIPは、一般的に任意のISUPバリアントをサポートしていない異なるゲートウェイを横切って橋渡しする）に及ぶことを指示してもよいです。最大の特徴は、透明性と速度を最適化するためには、仲介者の一部の事業者は、次の線に沿って実践を検討する必要があります。a）ISUP機能の透明性の必要性はISUPの一つの変形からすなわち、変換、ISUPバリアント翻訳（変換）を必要とするかもしれません発信PSTNインターフェイスのISUPバリアントをサポートしていないゲートウェイ・インタフェース上そのコールの終了を容易にするために別のものです。理論変換に要求のパスの任意の時点で行ってもよいが（項目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メッセージテンプレート内の任意の値を上書きし、ISUPパラメータにSIPリクエストのヘッダーを翻訳します。
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.
RFC 3261によって定義されるSIP-Tは、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の主要な要件の一つです。 SIP-Tは、複数のペイロード（セッション記述プロトコルまたはSDP [5]、ISUP、等）を含むようにSIPメッセージを有効にするマルチパートMIMEボディを使用します。多くの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にゲートウェイがそれぞれ受信したSIPメッセージとその逆のための特定のISUPメッセージを生成するタスクを委託されているデプロイメント。 IAMは、BYEためのRELをINVITEの受信時に送信される必要があり、そのため：すなわち、どのようなISUPメッセージ特定のSIPメッセージを受信したときに送信される（ISUPとSIPメッセージとの間のマッピングを管理するルールを指定する必要がありますオン）。 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ネットワークでプロキシサーバがその宛先にルーティングすることを可能にする情報を含まなければならない - 例えば、電話番号がダイヤル発信ユーザ。それはSIPにISUPからの情報の翻訳のための手順を定義するプラクティスのセットを標準化することが重要である（例えば、ISUP IAMに着信側番号は、ヘッダフィールドとRequest-URIなど「」へのSIPにマッピングされなければなりません。）。効果的に、部分 - この問題は、SIPリクエスト（特にINVITE）のヘッダが仲介することによって形質転換することができる、それが結果として、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は、セッション中に生成される任意の半ば呼制御情報を搬送するためのいずれかの条項を持っていません。 INFO [3]の方法は、この目的のために使用されるべきです。注しかしその情報（[11]参照重複ダイヤルを実施する1つの方法のために）オーバーラップダイヤルを管理するには適していません。また、通話中、DTMF信号をシグナリングするための情報の使用は推奨されないことに注意してください（[9]推奨機構にRFC2833を参照）。
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マルチパートフォーマットを使用して、同じSIPメッセージにSDPとISUP要素の両方をパッケージ化するかもしれません。終端装置は、マルチペイロード（マルチパート/混合）および/またはISUP MIMEタイプをサポートしない場合、伝統的にSIPで、それは、次いで、415サポートされていないメディアタイプは、デフォルトで（それがサポートするメディアタイプを指定してSIPリクエストを拒絶するであろう、 'アプリケーション/ SDP'）。発信者は、その後、（のみSDPペイロードを持つすなわち）ISUPペイロードを除去した後、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ペイロードを無視します。これは、混合/マルチパートと臨界を発現するようにContent-Dispositionヘッダーへのアクセスのコンテンツタイプのための支持体を有するターミネーター次第です。
1. Support for ISUP is optional. Therefore, UA2 accepts the INVITE irrespective of whether it can process the ISUP.
ISUP 1.サポートはオプションです。したがって、UA2に関係なく、それはISUPを処理できるかどうかのINVITEを受け付けます。
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.
ISUP 2.サポートが好ましいです。 UA2はISUPをサポートし、415サポートされていないメディアタイプにINVITEを拒否していません。 UA1はISUPを取り除きのみSDPと共にINVITEを再送信し、これが受け入れられます。
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)
INVITE - >（コンテンツタイプ：アプリケーション/ 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.
ISUP 3.サポートは、呼の確立のために必須です。 UA2はISUPをサポートし、415サポートされていないメディアタイプにINVITEを拒否していません。 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仕様のセキュリティの考慮事項に記載されているようにISUP MIME本体は、この問題を軽減する（[4]は、好ましくはS / MIMEで）固定されるべきである[1]。 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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 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.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.およびM. Zonoun、 "ISUPとQSIGオブジェクトのMIMEメディアタイプ"、RFC 3204 、2001年12月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3]ドノバン、S.、 "SIP INFOメソッド"、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]ハンドリー、M.および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]国際電気通信連合 "をシグナリングシステム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]ローゼンバーグ、J.、サラマ、H.およびM.スクワイア、 "オーバー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. 2000 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]キャマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オング、 "SIPへのマッピングISUP"、進行中の作業。
[11] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of ISUP Overlap Signaling to SIP", Work in Progress.
[11]キャマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オング、 "SIPするISUPオーバーラップシグナリングのマッピング"、ProgressのWork。
Appendix A. Notes
付録A.ノート
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の強度が実現されます。
Appendix B. Acknowledgments
付録B.謝辞
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.
私たちは、彼らの貴重なコメントのためにアンドリューデュガン、ロブMaidhof、デイブ・マーティン、アダムローチ、ジョナサン・ローゼンバーグ、ディーンウィリス、ロバート・F・ペンフィールド、スティーブ・ドノバン、アリソンマンキン、スコット・ブラッドナーとスティーブBellovin氏に感謝します。
The original 'SIP+' proposal for interconnecting portions of the PSTN with SIP bridging was developed by Eric Zimmerer.
SIPブリッジとPSTNの部分を相互接続するための元の「SIP +」提案はエリック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クエスト・コミュニケーションズ6000パークウッドP1のダブリン、OH 43016米国電子メール：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/
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。