RFC3372 日本語訳
3372 Session Initiation Protocol for Telephones (SIP-T): Context andArchitectures. A. Vemuri, J. Peterson. September 2002. (Format: TXT=49893 bytes) (Also BCP0063) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Vemuri
Request for Comments: 3372 Qwest Communications
BCP: 63 J. Peterson
Category: Best Current Practice NeuStar
September 2002
Vemuriがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3372クエストコミュニケーションズBCP: 63J.ピーターソンカテゴリ: 最も良い現在の練習NeuStar2002年9月
Session Initiation Protocol for Telephones (SIP-T):
Context and Architectures
電話(一口T)のためのセッション開始プロトコル: 文脈と構造
Status of this Memo
この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.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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(公共のSwitched Telephone Network)とSIPの間でネットワークを織り込むゲートウェイの人気は実現の向こう側に一貫した振舞いを保証できる1セットの一般的な習慣の公表を動機づけました。 このドキュメントは、PSTN-SIPゲートウェイの用途をtaxonomizesして、ケースを用途に供給して、織り込むのに必要なメカニズムを特定します。 メカニズムはSIPがどう'カプセル化'(SIPネットワークの向こう側にPSTNシグナリングに橋を架ける)と'翻訳'(gatewaying)の両方に備えるかを詳しく述べます。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ISUP-一口インタコネクト. . . . . . . . . . . . . 4 3のための一口T。 SIP-T Flows. . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1SIP Bridging(PSTN--IP--PSTN).83.2PSTN創作--IP終了. . . . . . . . . . . . . . 9 3.3IP創作--PSTN終了. . . . . . . . . . . . . . 11 4。 一口Tの役割と振舞い. . . . . . . . . . . . . . . . . . . 12 4.1のターミネーター. . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3の仲介者の.144.4の行動の要件創始者.124.2概要. . . . . . . . . . . . . . . 15 5 一口Tプロトコル. . . . . . . . . . . . . . . 16 5.1コア一口. . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2カプセル化. . . . . . . . . . . . . . . . . . . . . . . . 16 5.3翻訳. . . . . . . . . . . . . . . . . . . . . . . . . 16の成分
Vemuri & Peterson Best Current Practice [Page 1] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[1ページ]RFC3372一口T2002年9月
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
5.4は中間の呼び出しのためにシグナリング. . . . . . . . . . . . . . . . 17 6を支持します。 満足している交渉. . . . . . . . . . . . . . . . . . . 17 7をちびちび飲んでください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 20 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 10参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20A.は.21のB.承認. . . . . . . . . . . . . . . . . . . . . . . 21作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 22の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 23に注意します。
1. Introduction
1. 序論
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.
Session Initiationプロトコル、(SIP[1])はマルチメディアセッションを確立して、変更して、終えることができる応用層制御プロトコルであるか呼びます。 これらのマルチメディアセッションはマルチメディア会議、インターネット電話、および同様のアプリケーションを含んでいます。 SIPはボイス・オーバー 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の間でネットワークを織り込むゲートウェイの人気は実現の向こう側に一貫した振舞いを保証できる1セットの一般的な習慣の公表を動機づけました。 IETFの外のSIP専門的技術への不足は、IETFがこの仕事を上演する最も良い場所であると示唆します、特にPSTNのコアプロトコルと比べて、SIPがフラックスの相対的な状態にあるので。 そのうえ、何かSIPへの新しい拡大がPSTNの織り込むために正当化されるかどうかを確かめるために、SIP(SIPとSIPPING)に焦点を合わせるIETFワーキンググループは最もいい、な位置にあります。 この枠組みはゲートウェイを織り込む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
どんなSIP電話ネットワークの重要な特性もPSTNに関する特徴透明です。 キャッチホンなどの伝統的な電子通信サービス、フリーダイヤル番号などはPSTNでSignaling System No.7などのプロトコルを実行しました。(SS7[6])はSIPの柔軟性を制限していない間にユーザー・エクスペリエンスのどんな弱らせる違いも排除する方法でSIPネットワークによって提供されるべきです。 一方では、SIPがそのようなサービスの配送のための終わりポイントがSS7が流暢な装置よりむしろ通常のSIP電話(以下のセクション2との定義を見る)である基関数を支持するのが必要です。 しかしながら、また、SS7情報がゲートウェイ、ポイントで利用可能であるのも、不可欠です。
Vemuri & Peterson Best Current Practice [Page 2] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[2ページ]RFC3372一口T2002年9月
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.
そうでなければ、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要求のroutabilityです--通話をセットアップするSIP要求は、それが適切に目的地に発送されるのを可能にするためにヘッダーに十分な情報を含むべきです。代理人を通してSIPネットワークにおけるサーバ。 最も一般的に、ダイヤルされた数がSIP要求に合図するSS7から持ち越されるべきであるようにこれは呼び出しのそのパラメタを伴います。 SIPネットワークにおけるルート設定はTRIP[8]かENUM[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(TelephonesのためのSIP)の努力は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呼び出しの状態かセッションのパラメタにおける少しの変化ももたらしません。 また、そのような任意の応用層情報を伝える支給が必要です。
Vemuri & Peterson Best Current Practice [Page 3] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[3ページ]RFC3372一口T2002年9月
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
要件一口Tが機能であると織り込むSS7-一口================================================================== Signaling SIPボディーのISUPのISUP Encapsulationの透明
Routability of SIP messages with Translation of ISUP information dependencies on ISUP into the SIP header
SIPヘッダーへのISUPにおけるISUP情報の依存のTranslationがあるSIPメッセージのRoutability
Transfer of mid-call ISUP signaling Use of the INFO Method for mid- messages call signaling
中間のメッセージのためにINFO MethodのUseに合図するISUPが、シグナリングと呼ぶという中間の要求の転送
Table 1: SIP-T features that fulfill PSTN-IP inter-connection
Requirements
テーブル1: PSTN-IP相互接続Requirementsを実現させる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、MF Q.931など)で使用されることに注意してください。 このドキュメントは、ISUP-SIPインタフェースだけの向こう側に振舞いを指定するためにSS7 ISUPと目的に焦点を合わせます。 SIP-T企業の範囲は時間がたつにつれて、また、他のシグナリングシステムを包含するようになるかもしれません。
2. SIP-T for ISUP-SIP Interconnections
2. ISUP-一口インタコネクトのための一口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に連結するための1セットのメカニズムです。 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で起こる呼び出しはSIP終点で終わるためにゲートウェイを横断できます、IP電話のように。 逆に、IP電話はPSTNで終わるためにゲートウェイを横断する電話をかけることができます。 最終的に、SIPを使用するIPネットワークはゲートウェイの間のトランジットネットワークとして機能するかもしれません--呼び出しは、PSTNで由来して、終わるかもしれませんが、SIPを拠点とするネットワークに中央のどこかと交差してください。
Vemuri & Peterson Best Current Practice [Page 4] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[4ページ]RFC3372一口T2002年9月
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.
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などの)とパケットで切り換えられたオーディオメディアの間の変換のポイントを提供します。 また、メディアという用語ゲートウェイController(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).
* 施政方針が励行されるネットワーク(潜在的にmiddleboxes、プロキシサーバ、またはゲートウェイ)の間のポイントを連結してください。
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 Proxyサーバ: プロキシサーバはSIP要求をそれらの目的地に発送するSIP仲介者です。 例えば、プロキシサーバは別のプロキシ、ゲートウェイまたはSIP電話にSIP要求を向けるかもしれません。
Vemuri & Peterson Best Current Practice [Page 5] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[5ページ]RFC3372一口T2002年9月
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------
******************** *** *** * * * ------- * * |プロキシ| * * ------- * |----| |----| /|MGC1| VoIPネットワーク|MGC2|\ / ---- ---- \SS7/**\SS7/*------- * \ / * |プロキシ| * \ -------- * ------- * --------- | 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が議定書を作るときSIPが採用しているLECsの1組で起こる通話のためのトランジットネットワークが電話をするようにVoIP雲は役立ちます。 表現されたネットワークの縁では、MGCはISUP信号をSIP要求に変換して、他のMGCsで順番に呼び出しを発送するプロキシサーバにそれらを送ります。 この図は2MGCsだけについて表現しますが、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),
それだけは言いました、ゲートウェイの間のISUPの交換だけがここで関連しているならシグナリング情報の輸送のためのどんなプロトコルもこれを達成するのに使用されるかもしれません、SIP-TのSIPとその結果ものの必要性を取り除いて。 SIP-TはSIPを利用する本質的な利益に投機するために採用しています: ルーティングを要求してください、そして、コントロールをプロキシサーバに投機すると呼んでください(分岐の使用を含んでいて)。
Vemuri & Peterson Best Current Practice [Page 6] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[6ページ]RFC3372一口T2002年9月
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.
SIPサービス創造、SIPの能力交渉システムなどの容易さ。 彼らが要求を扱うとき、受信されたISUPメッセージパラメタからSIPヘッダーフィールドまでの情報の翻訳は、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を使用できる数回の流れの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メッセージにこの情報を保存します(カプセル化と翻訳で)。 ターミネータは受信して、PSTNに送られたシグナリングにおけるこの情報を再利用するというSIPメッセージからISUP内容を抜粋します。
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シグナリングに変えて、適切なPSTNインタフェースに呼び出しを向けます、容認されたSIPヘッダーに存在している情報に基づいて。
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に関するカプセル化か翻訳のどちらか)はプレーに入りません。
3. SIP-T Flows
3. 一口Tは流れます。
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
尾行部は詳細に不可欠のSIP-T流れについて調査します。 一般に、プロキシサーバが通常ルーティングSIPに原因となるので、SIP要求が終わる最後の終点を要求する(Request-URIに基づいています)注意が創始者にとって知られていません。 創始者が流れから選び抜かないで
Vemuri & Peterson Best Current Practice [Page 7] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[7ページ]RFC3372一口T2002年9月
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.
このセクションか、静的な構成の問題か1呼び出しあたり1個のベースの上でむしろ説明されて、各呼び出しはSIPネットワークによって独自に発送されます、そして、ネットワークのルーティング理論が命令するようにそれは以下の流れのいずれも例示するかもしれません。
3.1 SIP Bridging (PSTN - IP - PSTN)
3.1 一口の橋を架けること(PSTN--IP--PSTN)
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|---| |---|
/|MGC| VoIP Network |MGC|\
/ --- --- \
/ * * \
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| PSTN | *** *** | PSTN |
-------- ********************* ---------
******************** *** *** * * * ------- * * |プロキシ| * * ------- * |---| |---| /|MGC| VoIPネットワーク|MGC|\ / --- --- \ / * * \ / * ------- * \ / * |プロキシ| * \ -------- * ------- * --------- | PSTN| *** *** | PSTN| -------- ********************* ---------
Figure 2: PSTN origination - PSTN termination (SIP Bridging)
図2: PSTN創作--PSTN終了(一口の橋を架けること)
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ネットワークがあるインタコネクトのポイントであるゲートウェイはSS7 ISUPメッセージを受け取るでしょう。 このゲートウェイはこの呼び出しセットアップ要求のためにSIPの見解からユーザエージェントのクライアントについて議定書の中で述べることです。 伝統的なSIPルーティングは、創作と終了終点の間で終了(この場合ゲートウェイ)の適切なポイントを決定して、SIP対話を確立して、メディアセッションの交渉を始めるのにIPネットワークに使用されます。 PSTNへの出口ゲートウェイの当時の信号ISUP、いずれかも再利用すると、それが適宜受け取るSIP要求の現在のISUPは要約されました。
Vemuri & Peterson Best Current Practice [Page 8] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[8ページ]RFC3372一口T2002年9月
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------|
| | | | |
PSTN MGC#1プロキシMGC#2PSTN|-------IAM------>|、|、|、|、| |-----招待---->|、|、|、|、| |-----IAM----->|、| | <--100 トライ---| | | | | | <、-、-、--ACM------| | | <、-、-、-、--18x-------| | | <、-、-、-、-、--ACM-------| | | | | | | | <、-、-、--ANM------| | | <、-、-、--200 OK-----| | | <、-、-、-、-、--ANM-------| | | | | |------ACK------>|、| |====================会話=================| |-------REL------>|、|、|、| | <、-、-、-、-、--RLC-------|------さようなら------>|、|、|、|、| |-----REL----->|、| | <、-、-、--200 OK-----| | | | | | <、-、-、--RLC------| | | | | |
3.2 PSTN origination - IP termination
3.2PSTN創作--IP終了
********************
*** ***
* *
* *
* *
* *
|----| |-----|
/|MGC | VoIP Network |proxy|\
/ ---- ----- \
/ * * \
/ * * \
/ * * \
-------- * * -------------
| PSTN | ** ** | SIP phone |
-------- ********************* -------------
******************** *** *** * * * * * * * * |----| |-----| /|MGC| VoIPネットワーク|プロキシ|\ / ---- ----- \ / * * \ / * * \ / * * \ -------- * * ------------- | PSTN| ** ** | SIP電話| -------- ********************* -------------
Figure 3: PSTN origination - IP termination
図3: PSTN創作--IP終了
Vemuri & Peterson Best Current Practice [Page 9] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[9ページ]RFC3372一口T2002年9月
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:
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-------| |
| | | |
PSTN MGC Proxy SIP電話|----IAM----->|、|、|、| |--------招待------>|、|、|、| |-------招待------->|、| | <、-、-、-、-、--100 トライ----| | | | | <、-、-、-、-、-、--18x----------| | | <、-、-、-、-、-、-、-、--18x--------| | | <、-、-、--ACM-----| | | | | | <、-、-、-、-、-、--200 OK-------| | | <、-、-、-、-、-、--200 OK-------| | | <、-、-、--ANM-----| | | | |---------ACK-------->|、|、|、| |---------ACK-------->| |=====================会話========================| |-----REL---->|、|、|、| |----------さようなら------->|、| | <、-、-、--RLC-----| |---------さようなら-------->|、|、| | <、-、-、-、-、-、--200 OK-------| | | <、-、-、-、-、-、--200 OK-------| | | | | |
Vemuri & Peterson Best Current Practice [Page 10] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[10ページ]RFC3372一口T2002年9月
3.3 IP origination - PSTN termination
3.3IP創作--PSTN終了
********************
*** ***
* *
* *
* *
* *
|-----| |----|
/|proxy| VoIP Network |MGC |\
/ ----- ---- \
/ * * \
/ * * \
/ * * \
------------ * * ---------
|SIP phone | ** ** | PSTN |
------------ ********************* ---------
******************** *** *** * * * * * * * * |-----| |----| /|プロキシ| VoIPネットワーク|MGC|\ / ----- ---- \ / * * \ / * * \ / * * \ ------------ * * --------- |SIP電話| ** ** | 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.
以下で示されるとして呼び出しで異なった脚を例証する簡単な呼び出し流動があります。
Vemuri & Peterson Best Current Practice [Page 11] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[11ページ]RFC3372一口T2002年9月
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-----|
SIP電話Proxy MGC PSTN|-----招待----->|、|、|、| |--------招待-------->|、| | <、-、--100 トライ---| |-----IAM---->|、| | <、-、-、-、-、--100 トライ------| | | | | <、-、-、--ACM-----| | | <、-、-、-、-、-、-、-、--18x----------| | | <、-、-、-、-、--18x-------| | | | | | <、-、-、--ANM-----| | | <、-、-、-、-、-、-、--200 OK--------| | | <、-、-、-、--200 OK-----| | | |-------ACK------>|、|、|、| |----------ACK--------->|、| |========================会話===================| |-------さようなら------>|、|、|、| |----------さようなら--------->|、|、|、| |-----REL---->|、| | <、-、-、-、-、-、-、--200 OK--------| | | <、-、-、-、--200 OK-----| | <、-、-、--RLC-----|
4. SIP-T Roles and Behavior
4. 一口Tの役割と振舞い
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種類の要素(機能的な観点からの)があります:
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.
セクション4.1のための振舞い、SIP-T呼び出しにおけるセクション4.2とセクション4.3仲介人の役割は以下のセクションで説明されます。
4.1 Originator
4.1 創始者
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 Callセットアップ要求(すなわち、INVITEs)を発生させることです。 呼び出しがPSTNで起こるとき、ゲートウェイはUACです。 さもなければ、いくつかのネイティブのSIP終点がUACです。 どちらかのケース、一般に、創始者がターミネータが予期するどういう実体を予期できないかというメモに、いてください、すなわち、要求の最終的な目的地がSIPネットワークかPSTNにあるか否かに関係なく。
Vemuri & Peterson Best Current Practice [Page 12] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[12ページ]RFC3372一口T2002年9月
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を見てください)。 例えば、これが、INVITEの'To:'ヘッダーフィールドを設定するのを伴うかもしれない、容認されたISUP IAMのダイヤルされた数(パーティNumberと呼ばれる)を反映してください。
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を発生させる能力があるのが必要であるのは無鉄砲でしょう。 したがって、発生させるSIP電話がISUPを要約したようにそれはIP終点の責任ではありません。 したがって、可能であるときに(呼び出しがいつPSTNで起こったかを意味して)、ISUPカプセル化と翻訳を実行している間、創始者はSIPシグナリングを発生させなければなりません。
Originator requirements: encapsulate ISUP, translate information from ISUP to SIP, multipart MIME support (for gateways only)
創始者要件: ISUPを要約してください、そして、ISUPから複合SIP、MIMEサポートまで情報を翻訳してください。(ゲートウェイだけへの)
4.2 Terminator
4.2 ターミネーター
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です。
Vemuri & Peterson Best Current Practice [Page 13] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[13ページ]RFC3372一口T2002年9月
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ヘッダーを翻訳するときテンプレートでパラメタ値を上書きするか、またはローカルの方針を反映するどんなパラメタ値も加えます(Appendix 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内容の優雅な取り扱い(非ゲートウェイだけへの)
4.3 Intermediary
4.3 仲介者
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電話と同様に。 各プロキシサーバは様々なヘッダー、または'発送可能要素'の値に基づくSIP要求のための推進決定をします(SIP要求のRequest-URI、ルートヘッダー、および他の潜在的に多くの要素を含んでいて)。
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:
SIP-Tは、仲介者のための新機能と要件につながることができた要求を転送するためにいくつかの追加問題を紹介します。 ISUPの特徴透明はSIP-Tの概念に主要です。 由来していて終わっているPSTNインタフェースのISUP異形の間の互換性は自動的に特徴透明につながります。 したがって、プロキシサーバは要求で要約されるISUPの異形に興味を持つかもしれません--異形自体は発送可能要素になることができました。 また、最終的な目的地(レート問題)の、より大きい近接をもたらすポイントでの呼び出しの終了は重要な考慮すべき事柄です。 もう片方の上の1の好みは操作と費用の簡単さの間のトレードオフをもたらします。 妥当なレートを調達する要件は、SIP-T呼び出しが異なったPSTNインタフェースにかかると決めるかもしれません(異なったゲートウェイの向こう側にそれに橋を架けるSIPが一般的のどんなISUP異形も支持しません)。 最大の特徴透明ために最適化して、評価するために、仲介者の何人かのオペレータが以下のやり方で習慣を考えたがっているかもしれません:
Vemuri & Peterson Best Current Practice [Page 14] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[14ページ]RFC3372一口T2002年9月
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.
a) ISUP特徴透明の必要性は、由来しているPSTNインタフェースのISUP異形を支持しないゲートウェイインタフェースの上でその呼び出しの終了を容易にするためにISUPの1つの異形から別の異形までISUP異形翻訳(変換)、すなわち、変換を必要とするかもしれません。 (Appendix 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
プロキシ要件: 発送可能要素の選択に基づいて発送する能力
4.4 Behavioral Requirements Summary
4.4 行動の要件概要
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メッセージ)に代わりに正準なテンプレートを使用するはずであることに注意してください。
Vemuri & Peterson Best Current Practice [Page 15] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[15ページ]RFC3372一口T2002年9月
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ヘッダーでの発送可能要素の選択に基づく呼び出しを発送できなければなりません。
5. Components of the SIP-T Protocol
5. 一口Tプロトコルの成分
The mechanisms described in the following sections are the components of SIP-T that provide the protocol functions entailed by the requirements.
以下のセクションで説明されたメカニズムは要件によって伴われたプロトコル機能を提供するSIP-Tの部品です。
5.1 Core SIP
5.1 コア一口
SIP-T uses the methods and procedures of SIP as defined by RFC 3261.
RFC3261によって定義されるようにSIP-TはSIPの方法と手順を用います。
5.2 Encapsulation
5.2 カプセル化
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は、複数のペイロード(セッション記述プロトコルやSDP[5]、ISUPなど)を含むSIPメッセージを可能にするのに複合MIME本体を使用します。 多数のISUP異形は今日、現存しています。 ISUP MIMEの種類は受取人も可能にします。ISUPがタイプするのを(その結果、彼らが異形を支持するかどうか決定してください)可能な限り迅速な方法で見分けてください。 複合MIMEを使用することでISUPカプセル化を実行することの1つの計画が[2]で説明されます。
5.3 Translation
5.3 翻訳
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メッセージを発生させるタスクはゲートウェイに預けられます。 ISUPとSIPメッセージの間のマッピングを支配する規則を指定するのが必要です(特定のSIPメッセージが受信されているとき、ISUPにすなわち、何を通信させますか: INVITE、BYEのためのRELなどを受け取り次第IAMを送らなければなりません)。 ISUPとSIPメッセージの間の潜在的マッピングは[10]で説明されます。
Vemuri & Peterson Best Current Practice [Page 16] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[16ページ]RFC3372一口T2002年9月
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までの情報の翻訳のための手順を定義する習慣のセットを標準化するのは重要です(例えば、SIP 'To'ヘッダーフィールドとRequest-URIなどにISUP IAMのCalledパーティNumberを写像しなければなりません)。 この問題は本来SIPのヘッダーが、(特にINVITE)が仲介者によって変えられるかもしれないよう要求して、その結果、SIPヘッダーと要約のISUPボディーが闘争値を言い表すようになるという事実によるより複雑になります--事実上、要約のISUPの一部が無関係で時代遅れにされるかもしれません。
5.4 Support for mid-call signaling
5.4 中間の呼び出しシグナリングのサポート
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]方法はこのために使用されるべきです。 しかしながら、INFOがオーバラップのダイヤルすることを管理するのに適当でないことに注意してください。(オーバラップのダイヤルすることを実行する1つの方法に関しては、[11])を見てください。 また、INFOのシグナリング中間の呼び出しDTMF信号の使用が推薦されないことに注意してください(お勧めのメカニズムに関してRFC2833[9]を見てください)。
6. SIP Content Negotiation
6. 満足している交渉をちびちび飲んでください。
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メッセージにパッケージするかもしれません。 次に、終わり装置が複合ペイロード(複合の、または、混ぜられた)、そして/または、ISUP MIMEの種類を支持しないなら、SIPでは、415UnsupportedメディアTypeがそれが支持するメディアタイプを指定している状態で伝統的に、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.
これはかなり厄介な流れです、そして、その結果、創始者が意味できたメカニズムを持つために、どのボディーが必要であるか、そして、ターミネータが静かに、それがする任意のボディーを捨てることができるくらいどれが任意であるかが分からないのは(処理ISUPが重要でないときに、SIP電話がISUPペイロードを無視するのを許容して)、非常に望ましいです。 臨界を言い表すために、これは複合か混ぜられることの文書内容のサポートとアクセスをContent-気質ヘッダーに持っているターミネータ次第であります。
Vemuri & Peterson Best Current Practice [Page 17] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[17ページ]RFC3372一口T2002年9月
1. Support for ISUP is optional. Therefore, UA2 accepts the INVITE
irrespective of whether it can process the ISUP.
1. ISUPのサポートは任意です。 したがって、ISUPを処理できるかどうかの如何にかかわらずUA2は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;)
UA1 UA2招待-->。(文書内容: 複合の、または、複雑な; 文書内容: アプリケーション/sdp;満足している気質: セッション; =が必要とした取り扱い; 文書内容: アプリケーション/isup; 満足している気質: 合図してください; 取り扱い=任意です)
<--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を支持しないで、415UnsupportedメディアTypeと共に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;)
UA1 UA2招待-->。(文書内容: 複合の、または、複雑な; 文書内容: アプリケーション/sdp;満足している気質: セッション; =が必要とした取り扱い; 文書内容: アプリケーション/isup; 満足している気質: 合図してください; 取り扱いが=必要です;)
<--415
(Accept: application/sdp)
<--415(: アプリケーション/sdpを受け入れます)
ACK-->
ACK-->。
INVITE--> (Content-type: application/sdp)
招待-->。(文書内容: アプリケーション/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を支持しないで、415UnsupportedメディアタイプでINVITEを拒絶します。 そして、UA1はUA3に要求を向けます。
Vemuri & Peterson Best Current Practice [Page 18] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[18ページ]RFC3372一口T2002年9月
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;)
UA1 UA2招待-->。(文書内容: 複合の、または、複雑な; 文書内容: アプリケーション/sdp;満足している気質: セッション; =が必要とした取り扱い; 文書内容: アプリケーション/isup; 満足している気質: 合図してください; 取り扱いが=必要です;)
<--415
(Accept: application/sdp)
<--415(: アプリケーション/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;)
UA1 UA3招待-->。(文書内容: 複合の、または、複雑な; 文書内容: アプリケーション/sdp;満足している気質: セッション; =が必要とした取り扱い; 文書内容: アプリケーション/isup; 満足している気質: 合図してください; 取り扱いが=必要です;)
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].
メッセージの上の交換が完全でないことに注意してください。 この議論に関連しているメッセージだけが示されます。 [2]からISUP MIMEの種類の詳細を得ることができます。 'バージョン'と'ベース'パラメタをここに示されませんが、[2]の規則に従って、使用しなければなりません。
7. Security Considerations
7. セキュリティ問題
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.
管理ドメインの間の信用関係を先在させるのを受けることがあるかもしれないinterdomainシグナル伝達機構としてSIP-Tを使うことができます。 多くの法的環境では、ISUPの分配は認可されたキャリヤーに制限されます。 エンドユーザシグナリングでキャリヤーシグナリングに橋を架ける限り、SIP-Tはいくつかの挑戦を導入します。 SIP-Tを実行するどんな管理ドメインも、ISUP情報の伝達が少しの安全の侵害ももたらさないのを保証するために、適所に十分な安全性装置(interdomain環境に詐欺と支払いを管理するためにどんな適切な方針も管理する要素を含んでいる)を持つべきです。
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
SIPボディーでISUPを輸送すると、機会は乱用、詐欺、およびプライバシーの問題に与えられるかもしれません、特に、任意のSIP終点でSIP-T要求を発生するか、点検されるか、または変更できるとき。 ISUP MIMEボディーを安全にするべきです。(望ましくはコアSIP仕様[1]のSecurity Considerationsで説明されていた状態でそのままなこの関心を軽減するS/MIME[4])で。 S/MIMEによって提供された認証資産はISUP MIMEボディーが発生した確実にするSIP-Tメッセージの受取人を許容するでしょう。
Vemuri & Peterson Best Current Practice [Page 19] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[19ページ]RFC3372一口T2002年9月
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 MIMEボディーを点検できるのを確実にするでしょう。
SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and SHOULD support encryption (CMS EnvelopedData).
SIP-T終点はS/MIME署名(CMS SignedData)を支持しなければなりません、そして、SHOULDは暗号化(CMS EnvelopedData)を支持します。
8. IANA Considerations
8. IANA問題
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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」(RFC3261)は2002がそうするかもしれません。
[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メディアタイプ」RFC3204(2001年12月)。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] ドノヴァン、S.、「一口インフォメーション方法」、RFC2976、2000年10月。
[4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[4]Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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]国際電気通信組合、「シグナリングシステムNo.7」。 「ISDN User Part Signaling手順」、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」、RFC2916、9月2000日
[8] Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[8] ローゼンバーグ、J.、サラマ、H.、およびM.は2002年1月に「電話はIP(旅行)の上で掘る」RFC3219に付き添います。
[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有効搭載量」、RFC2833)は2000がそうするかもしれません。
[10] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP
Mapping", Work in Progress.
[10] 「マッピングをちびちび飲むISUP」というキャマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オングは進行中で働いています。
Vemuri & Peterson Best Current Practice [Page 20] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[20ページ]RFC3372一口T2002年9月
[11] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of
ISUP Overlap Signaling to SIP", Work in Progress.
[11] 「一口に合図するISUPオーバラップに関するマッピング」というキャマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オングは進行中で働いています。
Vemuri & Peterson Best Current Practice [Page 21] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[21ページ]RFC3372一口T2002年9月
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. いくつかの終わりMGCsが由来しているサーキットに特定のどんな状態も取り除くために要約のISUPを変更するかもしれません。 例えば、連続テストはConnection Indicatorsなどのネイチャーで弛みます。
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
6000年のAparna Vemuri-Pattisamクエストコミュニケーションズおお、Parkwood Pl43016ダブリン(米国)メール: 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一致、カリフォルニア94520米国電話: +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
Vemuri & Peterson Best Current Practice [Page 22] RFC 3372 SIP-T September 2002
Vemuriとピーターソン最も良い現在の習慣[22ページ]RFC3372一口T2002年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Vemuri & Peterson Best Current Practice [Page 23]
VemuriとピーターソンBest現在の習慣[23ページ]
一覧
スポンサーリンク
