RFC4904 日本語訳
4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers(URIs). V. Gurbani, C. Jennings. June 2007. (Format: TXT=41027 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Gurbani
Request for Comments: 4904 Bell Laboratories, Alcatel-Lucent
Category: Standards Track C. Jennings
Cisco Systems
June 2007
Gurbaniがコメントのために要求するワーキンググループV.をネットワークでつないでください: 4904年のベル研究所、アルカテル透明なカテゴリ: 標準化過程C.ジョニングスシスコシステムズ2007年6月
Representing Trunk Groups in tel/sip
Uniform Resource Identifiers (URIs)
tel/一口Uniform Resource IdentifierでTrunk Groupsを表します。(URI)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose.
このドキュメントは、一口におけるトランクグループパラメタとtel Uniform Resource Identifier(URI)を伝えるために標準化されたメカニズムについて説明します。 tel URIへの拡大はこのために定義されます。
Gurbani & Jennings Standards Track [Page 1] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[1ページ]RFC4904Trunk Groups
Table of Contents
目次
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements and Rationale . . . . . . . . . . . . . . . . . . 5
4.1. sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 5
4.2. Trunk Group Namespace: Global or Local? . . . . . . . . . 5
4.3. Originating Trunk Group and Terminating Trunk Group . . . 6
4.4. Intermediary Processing of Trunk Groups . . . . . . . . . 6
5. Trunk Group Identifier: ABNF and Examples . . . . . . . . . . 6
6. Normative Behavior of SIP Entities Using Trunk Groups . . . . 8
6.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 9
6.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 10
6.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10
7. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Reference Architecture . . . . . . . . . . . . . . . . . . 11
7.2. Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 12
7.3. Inter-Domain Call Flow . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 問題声明. . . . . . . . . . . . . . . . . . . . . . 4 3。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 5 4。 要件とRationale. . . . . . . . . . . . . . . . . . 5 4.1一口URIですかそれともtel URIですか? . . . . . . . . . . . . . . . . . . . 5 4.2. トランクグループ名前空間: グローバルですか、地方ですか? . . . . . . . . . 5 4.3. トランクグループを溯源して、トランクグループ. . . 6 4.4を終えます。 トランクグループ. . . . . . . . . 6 5の仲介者処理。 トランクグループ識別子: ABNFと例. . . . . . . . . . 6 6。 トランクグループ. . . . 8 6.1を使用する一口実体の標準の振舞い。 ユーザエージェントクライアントの振舞い. . . . . . . . . . . . . . . . 9 6.2。 ユーザエージェントサーバの振舞い. . . . . . . . . . . . . . . . 10 6.3。 プロキシの振舞い. . . . . . . . . . . . . . . . . . . . . . 10 7。 例の呼び出し流れ. . . . . . . . . . . . . . . . . . . . . . 11 7.1。 参照構造. . . . . . . . . . . . . . . . . . 11 7.2。 基本的な呼び出し流動. . . . . . . . . . . . . . . . . . . . . 12 7.3。 相互ドメイン呼び出し流動. . . . . . . . . . . . . . . . . . 14 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 16 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 16 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 17 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 17
Gurbani & Jennings Standards Track [Page 2] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[2ページ]RFC4904Trunk Groups
1. Background
1. バックグラウンド
Call routing in the Public Switched Telephone Network (PSTN) is accomplished by routing calls over specific circuits (commonly referred to as "trunks") between Time Division Multiplexed (TDM) circuit switches. In switches, a group of trunks that connect to the same target switch or network is called a "trunk group". Consequently, trunk groups have labels, which are used as the main indication for the previous and next TDM switch participating in routing the call.
Public Switched Telephone Network(PSTN)での呼び出しルーティングはTime事業部Multiplexed(TDM)回線交換機の間で特定のサーキットの上のルーティング呼び出しで達成されます(一般的に「トランクス」と呼ばれます)。 スイッチでは、同じ目標スイッチかネットワークに接続するトランクスのグループは「トランクグループ」と呼ばれます。 その結果、トランクグループにはラベルがあります。(ラベルは前のための主な指示と呼び出しを発送するのに関与する次のTDMスイッチとして使用されます)。
Formally, we define a trunk and trunk group and related terminology as follows (definition of "trunk" and "trunk group" is from [5]).
正式に、私たちはトランク、トランクグループ、および以下の関連用語を定義します。(「トランク」と「トランクグループ」の定義は[5])から来ています。
Trunk: In a network, a communication path connecting two
switching systems used in the establishment of an end-to-end
connection. In selected applications, it may have both its
terminations in the same switching system.
トランク: ネットワーク、2つの交換システムが終わりから終わりとの接続の設立に使用した通信路接続で。 選択されたアプリケーションでは、それは同じ交換システムにおける両方の終了を持っているかもしれません。
Trunk Group: A set of trunks, traffic engineered as a unit, for
the establishment of connections within or between switching
systems in which all of the paths are interchangeable. A single
trunk group can be shared across multiple switches for redundancy
purposes.
トランクグループ: 1セットのトランクス、交換システム、または、経路のすべてが交換可能である交換システムの間の関係の設立のために一体にして設計された交通。 冗長目的のために複数のスイッチの向こう側にただ一つのトランクグループを共有できます。
Digital Signal 0 (DS0): Digital Signal X is a term for a series
of standard digital transmission rates based on DS0, a
transmission rate of 64 kbps (the bandwidth normally used for one
telephone voice channel). The European E-carrier system of
transmission also operates using the DS series as a base multiple.
ディジタル信号0(DS0): デジタルSignal XはDS0(64キロビット毎秒(通常、1個の電話音声チャンネルに使用される帯域幅)の通信速度)に基づく一連の標準のデジタル通信速度のための用語です。 また、トランスミッションのヨーロッパのE-キャリヤーシステムは、ベース倍数としてDSシリーズを使用することで作動します。
Since the introduction of ubiquitous digital trunking, which resulted in the allocation of DS0s between end offices in minimum groups of 24 (in North America), it has become common to refer to bundles of DS0s as a trunk. Strictly speaking, however, a trunk is a single DS0 between two PSTN end offices; however, for the purposes of this document, the PSTN interface of a gateway acts effectively as an end office (i.e., if the gateway interfaces with Signaling System 7 (SS7), it has its own SS7 point code, and so on). A trunk group, then, is a bundle of DS0s (that need not be numerically contiguous in an SS7 Trunk Circuit Identification Code numbering scheme) that are grouped under a common administrative policy for routing.
遍在しているデジタル中継方式の導入以来、DS0sのバンドルをトランクと呼ぶのは一般的になっています。(中継方式は24人(北アメリカの)の最小のグループで端局の間のDS0sの配分をもたらしました)。 しかしながら、厳密に言うと、トランクは2つのPSTN端局の間の独身のDS0です。 しかしながら、このドキュメントの目的のために、ゲートウェイのPSTNインタフェースは端局として有効に機能します(すなわち、ゲートウェイがSignaling System7(SS7)に連結するなら、それには、それ自身のSS7ポイントコードなどがあります)。 そして、トランクグループはルーティングのために一般的な施政方針の下で分類されるDS0s(それはSS7 Trunk Circuit Identification Codeナンバリングスキームで数の上で隣接である必要はない)のバンドルです。
A Session Initiation Protocol (SIP) [3] to PSTN gateway may have trunks that are connected to different carriers. It is entirely reasonable for a SIP proxy to choose -- based on factors not enumerated in this document -- which carrier a call is sent to when it proxies a session setup request to the gateway. Since multiple
PSTNゲートウェイへのSession Initiationプロトコル(SIP)[3]は異なったキャリヤーに接続されるトランクスを持っているかもしれません。 SIPプロキシが選ぶのは、完全に妥当です--本書では列挙されなかった要素(プロキシaセッションセットアップはそれであるときに呼び出しが送られるそれの運送業者をゲートウェイに要求する)に基づいています。 倍数以来
Gurbani & Jennings Standards Track [Page 3] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[3ページ]RFC4904Trunk Groups
carriers can transport a call to a particular phone number, the phone number itself is not sufficient to identify the carrier at the gateway. An additional piece of information in the form of a trunk group can be used to further pare down the choices at the gateway. As used in this document, trunks are necessarily tied to gateways, and a proxy that uses trunk groups during routing of the request to a particular gateway knows and controls which gateway the call will be routed to, and knows what trunking resources are present on that gateway.
キャリヤーは特定の電話番号に呼び出しを輸送できて、電話番号自体は、ゲートウェイでキャリヤーを特定するために十分ではありません。 ゲートウェイでさらに選択を切り詰めるのにトランクグループの形の追加情報を使用できます。 トランクスが必ず本書では使用されるようにゲートウェイに結ばれて、要求のルーティングの間に特定のゲートウェイにトランクグループを使用するプロキシは、そのゲートウェイの上で知っていて、呼び出しがどのゲートウェイに発送されるかを制御して、どんな中継方式リソースが存在しているかを知っています。
As another example, consider the case where an IP network is being used as a transit network between two PSTN networks. Here, a SIP proxy can apply the originating trunk group to its routing logic to ensure that the same ingress and egress carrier is chosen.
別の例と、IPネットワークが2つのPSTNネットワークの間のトランジットネットワークとして使用されているケースを考えてください。 ここで、SIPプロキシはそんなに同じイングレスを確実にするために由来しているトランクグループをルーティング論理に適用できます、そして、出口キャリヤーは選ばれています。
How the proxy picked a particular trunk group is outside the scope of this document ([6] provides one such way); however, once trunk group has been decided upon, this document provides a standardized means to represent it in the signaling messages.
([6]がそのような方法の1つに提供するこのドキュメントの範囲の外に特定のトランクグループに選ばれたプロキシがどうあるか)、。 しかしながら、トランクグループがいったん決められると、このドキュメントはシグナリングメッセージにそれを表す標準化された手段を提供します。
2. Problem Statement
2. 問題声明
Currently, there isn't any standardized manner of transporting trunk groups between Internet signaling entities. This leads to ambiguity on at least two fronts:
現在、インターネットシグナリング実体の間には、トランクグループを輸送する少しの標準化された方法もありません。 これは少なくとも2つの前部のあいまいさに通じます:
1. Positional ambiguity: A SIP proxy that wants to send a call to
an egress Voice over IP (VoIP) gateway may insert the trunk group
as a parameter in the user portion of the Request-URI (R-URI), or
it may insert it as a parameter to the R-URI itself. This
ambiguity persists in the reverse direction as well, that is,
when an ingress VoIP gateway wants to send an incoming call
notification to its default outbound proxy.
1. 位置のあいまいさ: 出口ボイス・オーバー IP(VoIP)ゲートウェイに呼び出しを送りたがっているSIPプロキシがパラメタとしてRequest-URI(R-URI)のユーザ部分にトランクグループを挿入するかもしれませんか、またはそれはパラメタとしてR-URI自体にそれを挿入するかもしれません。 このあいまいさはまた、反対の方向に固執します、すなわち、イングレスVoIPゲートウェイがデフォルトの外国行きのプロキシにかかってきた電話通知を送りたがっているとき。
2. Semantic ambiguity: The lack of any standardized grammar to
represent trunk groups leads to the unfortunate choice of ad hoc
names and values.
2. 意味的あいまい性: トランクグループを代表するどんな標準化された文法の不足も臨時の名前と値の不適切な選択につながります。
VoIP routing entities in the Internet, such as SIP proxies, may be interested in using trunk groups for normal operations. To that extent, any standards-driven requirements will enable proxies from one vendor to interoperate with gateways from yet another vendor. Absent such guidelines, interoperability will suffer, as a proxy vendor must conform to the expectations of a gateway as to where it expects trunk group parameters to be present (and vice versa).
インターネットのSIPプロキシなどのVoIPルーティング実体は通常操作にトランクグループを使用したがっているかもしれません。 その程度まで、どんな規格駆動の要件も、1つの業者からのプロキシがゲートウェイでさらに別の業者から共同利用するのを可能にするでしょう。 そのようなガイドラインがなければ、相互運用性に苦しむでしょう、プロキシ業者がそれがトランクグループパラメタが現在であると予想するところ(逆もまた同様である)に関してゲートウェイへの期待に従わなければならないとき。
Gurbani & Jennings Standards Track [Page 4] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[4ページ]RFC4904Trunk Groups
The aim of this specification is to outline how to structure and represent the trunk group parameters as an extension to the tel URI [4] in a standardized manner.
この仕様の目的は拡大として標準化された方法でtel URI[4]にトランクグループパラメタを構造化して、どう表すかを概説することです。
3. Conventions
3. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
4. Requirements and Rationale
4. 要件と原理
This section captures the motivations for the design decisions for the specification of a trunk group. These motivations are captured as a set of requirements that are used to guide the eventual trunk group specification in this document.
このセクションはトランクグループの仕様のためのデザイン決定に関する動機を得ます。 最後のトランクを誘導するのに使用される1セットの要件が本書では仕様を分類するとき、これらの動機は捕らわれています。
4.1. sip URI or tel URI?
4.1. 一口URIですかそれともtel URIですか?
REQ 1: Trunk group parameters must be defined as an extension to the tel URI [4].
REQ1: tel URI[4]への拡大とトランクグループパラメタを定義しなければなりません。
The trunk group parameters can be carried in either the sip URI or the tel URI. Since trunk groups are intimately associated with the PSTN, it seems reasonable to define them as extensions to the tel URI (any SIP request that goes to a gateway could reasonably be expected to have a tel URI, in whole or in part, in its R-URI anyway). Furthermore, using the tel URI also allows this format to be reused by non-SIP VoIP protocols (which could include anything from MGCP or Megaco to H.323, if the proper information elements are created).
一口URIかtel URIのどちらかでトランクグループパラメタを運ぶことができます。 トランクグループが親密にPSTNに関連づけられるので、tel URIへの拡大とそれらを定義するのは妥当に思えます(合理的に、ゲートウェイに行くどんなSIP要求もR-URIでtel URIを全体か一部とにかく持っていると予想できました)。 その上、また、tel URIを使用するのは、非SIP VoIPプロトコル(適切な情報要素が作成されるなら、MGCPかMegacoからH.323までの何でも含むかもしれない)によってこの形式が再利用されるのを許容します。
Finally, once the trunk group is defined for a tel URI, the normative procedures of Section 19.1.6 of [3] can be used to derive an equivalent sip URI from a tel URI, complete with the trunk group parameters.
かつて、最終的に、トランクグループはtel URI、セクション19.1.6の標準の手順のために[3]について定義されます。tel URIから同等な一口URIを得るのに使用できます、トランクグループパラメタで、完全です。
4.2. Trunk Group Namespace: Global or Local?
4.2. トランクグループ名前空間: グローバルですか、地方ですか?
REQ 2: Inter-domain trunk group name collisions must be prevented.
REQ2: 相互ドメイントランクグループ名前衝突を防がなければなりません。
Under normal operations, trunk groups are pertinent only within an administrative domain (i.e., local scope). However, given that inadvertent cross-domain trunk group name collisions may occur, it is desirable to prevent them. The judicious use of namespaces is a solution to this problem. Thus, it seems appropriate to scope the trunk group through a namespace.
通常操作で、トランクグループは管理ドメイン(すなわち、地方の範囲)だけの中で適切です。 しかしながら、不注意な交差しているドメイントランクグループ名前衝突が起こるかもしれないなら、それらを防ぐのは望ましいです。 名前空間の賢明な使用はこの問題の解決です。 したがって、名前空間を通してトランクグループを範囲に当てるように思えます。
Gurbani & Jennings Standards Track [Page 5] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[5ページ]RFC4904Trunk Groups
Note: At first glance, it would appear that the use of the tel
URI's "phone-context" parameter provides a satisfactory means of
imposing a namespace on a trunk group. The "phone-context"
parameter identifies the scope of validity of a local telephone
number. And therein lies the problem. Semantically, a "phone-
context" tel URI parameter is applicable only to a local telephone
number and not a global one (i.e., one preceded by a '+'). Trunk
groups, on the other hand, may appear in local or global telephone
numbers. Thus, what is needed is a new parameter with equivalent
functionality of the "phone-context" parameter of the tel URI, but
one that is equally applicable to local and global telephone
numbers.
以下に注意してください。 一見したところでは、tel URIの「電話文脈」パラメタの使用が名前空間をトランクグループに課す満足できる手段を提供するように見えるでしょう。 「電話文脈」パラメタはローカルの電話番号の正当性の範囲を特定します。 そして、そこに、問題があります。 「電話文脈」tel URIパラメタはグローバルなものではなく、ローカルの電話番号だけに意味的に、適切です(すなわち、1つは'+'で先行しました)。 他方では、トランクグループは地方の、または、グローバルな電話番号に現れるかもしれません。 したがって、必要であるものはしかし、tel URIの「電話文脈」パラメタの同等な機能性、等しく地方の、そして、グローバルな電話番号に適切なものがある新しいパラメタです。
4.3. Originating Trunk Group and Terminating Trunk Group
4.3. トランクグループを溯源して、トランクグループを終えます。
REQ 3: Originating trunk group and destination trunk group must be able to appear separately and concurrently in a SIP message.
REQ3: 由来しているトランクグループと目的地トランクグループは別々に、そして、同時にSIPメッセージに現れることができなければなりません。
SIP routing entities can make informed routing decisions based on either the originating or the terminating trunk groups. Thus, it is required that both of these trunk groups be carried in SIP requests.
SIPルーティング実体は、どちらかに基づいた知識があるルーティング決定を由来にするか、または終わりをトランクグループにすることができます。 したがって、これらのトランクグループの両方がSIP要求で運ばれるのが必要です。
4.4. Intermediary Processing of Trunk Groups
4.4. トランクグループの仲介者処理
REQ 4: SIP network intermediaries (proxy servers and redirect servers) should be able to add the destination trunk group attribute to SIP sessions as a route is selected for a call.
REQ4: ルートが呼び出しのために選択されるとき、SIPネットワーク仲介者(プロキシサーバと再直接のサーバ)は目的地トランクグループ属性をSIPセッションに加えることができるべきです。
5. Trunk Group Identifier: ABNF and Examples
5. トランクグループ識別子: ABNFと例
The Augmented Backus Naur Form [2] syntax for a trunk group identifier is given below and extends the "par" production rule of the tel URI defined in [4]:
トランクグループ識別子のためのAugmentedバッカスナウアForm[2]構文は、[4]で定義されたtel URIの「平価」プロダクションルールを下で与えられていて、広げています:
par = parameter / extension / isdn-subaddress / trunk-group /
trunk-context
平価はトランク拡大/ isdn-subaddress /パラメタ/トランクグループ/文脈と等しいです。
trunk-group = ";tgrp=" trunk-group-label
trunk-context = ";trunk-context=" descriptor
「=をトランクで分類してください」; tgrpが」 トランクグループラベルトランク文脈=と等しい、」、;トランク文脈が」 記述子と等しい
trunk-group-label = 1*( unreserved / escaped /
trunk-group-unreserved )
trunk-group-unreserved = "/" / "&" / "+" / "$"
「トランクが無遠慮な状態で分類されたトランクグループラベル=1*(トランクが無遠慮な状態で分類されていた状態で、無遠慮な/は/から逃げた)は」 /と等しく」/“&"/「+」/「$」
descriptor is defined in [4].
unreserved is defined in [3] and [4].
escaped is defined in [3].
記述子は[4]で定義されます。無遠慮であるのは、定義されたコネ[3]と[4]です。逃げられているのは、定義されたコネ[3]です。
Gurbani & Jennings Standards Track [Page 6] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[6ページ]RFC4904Trunk Groups
Trunk groups are identified by two parameters: "tgrp" and "trunk- context"; both parameters MUST be present in a tel URI to identify a trunk group. Collectively, these two parameters are called "trunk group parameters" in this specification.
トランクグループは2つのパラメタによって特定されます: "tgrp"と「トランク文脈」。 両方のパラメタは、トランクグループを特定するためにtel URIで存在していなければなりません。 これらの2つのパラメタがこの仕様にまとめて、「トランクグループパラメタ」と呼ばれます。
All implementations conforming to this specification MUST generate both of these parameters when using trunk groups. If an implementation receives a tel URI with only one of the "tgrp" or "trunk-context" parameter, it MUST act as if there were not any trunk group parameters present at all in that URI. Whether or not to further process such an URI is up to the discretion of the implementation; however, if a decision is made to process it, the implementation MUST act as if there were not any trunk group parameters present in the URI.
トランクグループを使用するとき、この仕様に従うすべての実現がこれらのパラメタの両方を発生させなければなりません。 実現が1だけでtel URIを受けるなら、"tgrp"か「トランク文脈」パラメタでは、まるでそのURIには全く現在のどんなトランクグループパラメタもないかのようにそれは行動しなければなりません。 さらにそのようなURIを処理するかどうかが実現の思慮深さまで達しています。 しかしながら、それを処理するのを決定をするなら、まるでURIにおける現在のどんなトランクグループパラメタもないかのように実現は行動しなければなりません。
The "trunk-context" parameter imposes a namespace on the trunk group by specifying a global number or any number of its leading digits (e.g., +33), or a domain name. Syntactically, it is modeled after the "phone-context" parameter of the tel URI [4], except that unlike the "phone-context" parameter, the "trunk-context" parameter can appear in either a local or global tel URI.
「トランク文脈」パラメタは、グローバルな数、いろいろな主なケタ(例えば、+33)、またはドメイン名を指定することによって、名前空間をトランクグループに課します。 シンタクス上、それはtel URI[4]の「電話文脈」パラメタに倣われます、「電話文脈」パラメタと異なって「トランク文脈」パラメタが地方の、または、グローバルなtel URIで見えることができるのを除いて。
Semantically, the "trunk-context" parameter establishes a scope of the trunk group specified in the "tgrp" parameter, i.e., whether it is valid at a single gateway, a set of gateways, or an entire domain managed by a service provider. The "trunk-context" can contain four discrete value types:
意味的に、「トランク文脈」パラメタは"tgrp"パラメタで指定されたトランクグループの範囲を確立します、すなわち、それが1門で有効であるか否かに関係なく、ゲートウェイ、またはサービスプロバイダーによって管理された全体のドメインの1セット。 「トランク文脈」は4つの離散的な値のタイプを含むことができます:
1. The value in the "trunk-context" literally identifies a host (a
gateway), in which case, the trunk groups are scoped to the
specific host.
1. 「トランク文脈」の値は文字通り、ホスト(ゲートウェイ)を特定します、その場合、トランクグループが特定のホストにとって見られます。
2. The value in the "trunk-context" is a subdomain (e.g.,
"north.example.com"), which identifies a subset of the gateways
in a domain across which the trunk groups are shared.
2. 「トランク文脈」の値はサブドメイン(例えば、"north.example.com")です。(そのサブドメインはトランクグループが共有されるドメインのゲートウェイの部分集合を特定します)。
3. The value in the "trunk-context" is a service provider domain
(e.g., "example.com"), which identifies all gateways in the
specific domain.
3. 「トランク文脈」の値はサービスプロバイダードメイン(例えば、"example.com")です。(そのドメインは特定のドメインのすべてのゲートウェイを特定します)。
4. The value in the "trunk-context" is a global number or any number
of its leading digits; this is useful for provider-wide scoping
and does not lend itself very well to specifying trunk groups
across a gateway or a set of gateways.
4. 「トランク文脈」の値は、グローバルな数かそのいろいろな主なケタです。 これは、プロバイダー全体の見ることの役に立って、ゲートウェイかゲートウェイのセットの向こう側にそれほどトランクグループを指定するのにそれ自体をよく与えません。
Gurbani & Jennings Standards Track [Page 7] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[7ページ]RFC4904Trunk Groups
For equivalency purposes, two URIs containing trunk group parameters are equivalent according to the base comparison rules of the URIs. The base comparison rules of a tel URI are specified in Section 4 of [4], and the base comparison rules of a sip URI are specified in Section 19.1.4 of [3].
同等目的のために、URIのベース比較規則に従って、トランクグループパラメタを含む2つのURIが同等です。 tel URIのベース比較規則は[4]のセクション4で指定されます、そして、一口URIのベース比較規則は[3]についてセクション19.1.4で指定されます。
Examples:
例:
1. Trunk group in a local number, with a phone-context parameter
(line breaks added for readability):
1. 電話文脈パラメタに従った市内番号(読み易さのために加えられたラインブレイク)におけるトランクグループ:
tel:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com
tel:5550100; 電話文脈は+1-630と等しいです; tgrp=TG-1 トランク文脈=example.com
Transforming this tel URI to a sip URI yields:
sip:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
このtel URIを一口URIに変えるのはもたらされます: 一口: 5550100; 電話文脈は+1-630と等しいです; tgrp=TG-1 トランク文脈= example.com@isp.example.net;user は電話と等しいです。
2. Trunk group in a global number, with a domain name
trunk-context:
2. ドメイン名トランク文脈があるグローバルな数におけるトランクグループ:
tel:+16305550100;tgrp=TG-1;trunk-context=example.com
tel: +16305550100; tgrp=TG-1; トランク文脈=example.com
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
このtel URIを一口URIに変えるのはもたらされます: +16305550100に以下をちびちび飲んでください; tgrp=TG-1 トランク文脈= example.com@isp.example.net;user は電話と等しいです。
3. Trunk group in a global number, with a number prefix trunk-
context:
3. トランクはグローバルな数で分類されて、数で、トランク文脈を前に置いてください:
tel:+16305550100;tgrp=TG-1;trunk-context=+1-630
tel: +16305550100; tgrp=TG-1; トランク文脈は+1-630と等しいです。
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=+1-630@isp.example.net;user=phone
このtel URIを一口URIに変えるのはもたらされます: +16305550100に以下をちびちび飲んでください; tgrp=TG-1 トランク文脈=+ 1-630@isp.example.net;user は電話と等しいです。
6. Normative Behavior of SIP Entities Using Trunk Groups
6. トランクグループを使用する一口実体の標準の振舞い
The terminating (or egress) trunk group parameters MUST be specified in the R-URI. This is an indication from a SIP entity to the next downstream entity that a specific terminating (or egress) trunk group should be used.
R-URIで終わり(または、出口)トランクグループパラメタを指定しなければなりません。 SIP実体から川下の次の実体までこれは特定の終わり(または、出口)トランクグループが使用されるべきであるという指示です。
Gurbani & Jennings Standards Track [Page 8] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[8ページ]RFC4904Trunk Groups
Note: This is consistent with using the R-URI as a routing
element; SIP routing entities may use the trunk group parameter in
the R-URI to make intelligent routing decisions. Furthermore,
this also satisfies REQ 4, since a SIP network intermediary can
modify the R-URI to include the trunk group parameters.
以下に注意してください。 これはルーティング要素としてR-URIを使用すると一致しています。 SIPルーティング実体は、知的なルーティング決定をするのにR-URIにトランクグループパラメタを使用するかもしれません。 その上、また、これはREQ4を満たします、SIPネットワーク仲介者がトランクグループパラメタを含むようにR-URIを変更できるので。
Conversely, the appearance of the trunk group parameters in the Contact header URI signifies the trunk group over which the call arrived on, i.e., the originating (or ingress) trunk group. Thus, the originating (or ingress) trunk group MUST appear in the Contact header of a SIP request.
逆に、ContactヘッダーURIにおける、トランクグループパラメタの外観は到着した呼び出し、すなわち、由来している(または、イングレス)トランクが分類されるトランクグループを意味します。 したがって、由来している(または、イングレス)トランクグループはSIP要求のContactヘッダーに現れなければなりません。
The behavior described in this section effectively addresses REQ 3.
このセクションで有効に説明された振舞いはREQ3を記述します。
6.1. User Agent Client Behavior
6.1. ユーザエージェントクライアントの振舞い
A User Agent Client (UAC) initiating a call that uses trunk groups and supports this specification MUST include the trunk group parameters in the Contact header URI (a Contact URI MUST be a sip or sips URI; thus, what appears in the Contact header is a SIP translation of the tel URI, complete with the trunk group parameters). The trunk group parameters in the Contact header represent the originating trunk group. As a consequence of the processing rules for the Contact header defined in RFC 3261 [3], subsequent requests in the dialog towards this user agent will contain this Contact URI in the R-URI. Note that the user part of this URI, which contains the trunk group parameters, will be copied as a consequence of this processing.
トランクグループを使用して、この仕様を支持する呼び出しを開始するUserエージェントClient(UAC)はContactヘッダーURIにトランクグループパラメタを含まなければなりません(Contact URIは、一口でなければならないかURIをちびちび飲みます; その結果、Contactヘッダーに現れることはtel URIに関するSIP翻訳です、トランクグループパラメタで、完全です)。 Contactヘッダーのトランクグループパラメタは由来しているトランクグループを代表します。 Contactヘッダーのための処理規則の結果がRFCで3261[3]を定義したので、このユーザエージェントに向かったとの対話におけるその後の要求はR-URIにおけるこのContact URIを含むでしょう。 トランクグループパラメタを含むこのURIのユーザ部分がこの処理の結果としてコピーされることに注意してください。
Note: Arguably, the originating trunk group can be part of the
From URI. However, semantically, the URI in a From header is an
abstract identifier that represents the resource thus identified
on a long-term basis. The presence of a trunk group, on the other
hand, signifies a binding that is valid for the duration of the
session only; a trunk group has no significance once the session
is over. Thus, the Contact URI is the best place to impart this
information since it has exactly those semantics.
以下に注意してください。 論証上、由来しているトランクグループはFrom URIの一部であるかもしれません。 しかしながら、FromヘッダーのURIは意味的に、このようにして長期的には特定されたリソースを表す抽象的な識別子です。 他方では、トランクグループの存在はセッションの持続時間だけに、有効な結合を意味します。 トランクグループには、セッションがいったん終わるようになると、意味が全くありません。その結果、Contact URIはそれにはまさにそれらの意味論があるのでこの情報を伝える最も良い場所です。
If the UAC is aware of the routing topology, it MAY insert the destination trunk group parameters in the R-URI of the request. However, in most deployments, the UAC will use the services of a proxy to further route the request, and it will be up to the proxy to insert such parameters in the R-URI (see Section 6.3).
UACがルーティングトポロジーを意識しているなら、それは要求のR-URIに目的地トランクグループパラメタを挿入するかもしれません。 しかしながら、ほとんどの展開では、UACはさらに要求を発送するのにプロキシのサービスを利用するでしょう、そして、R-URIにそのようなパラメタを挿入するのは、プロキシ次第(セクション6.3を見る)でしょう。
Gurbani & Jennings Standards Track [Page 9] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[9ページ]RFC4904Trunk Groups
6.2. User Agent Server Behavior
6.2. ユーザエージェントサーバの振舞い
To the processing User Agent Server (UAS) associated with a gateway, the trunk group parameters in the R-URI implies that it should use the named trunk group for the outbound call. If a UAS supports trunk groups, but finds that all the trunk circuit identification codes for that particular trunk group are occupied, it MAY send a 603 Decline final response.
処理Userに、R-URIにおけるゲートウェイ、トランクグループパラメタに関連しているエージェントServer(UAS)は、外国行きの呼び出しに命名されたトランクグループを使用するべきであるのを含意します。 UASが、トランクグループを支持しますが、その特定のトランクグループのためのすべてのトランクサーキット識別コードが占領されているのがわかるなら、それは603のDeclineの最終的な応答を送るかもしれません。
If a UAS supports trunk groups but is not configured with the particular trunk group identified in the R-URI, it SHOULD NOT use any other trunk group other than the one specified in the parameters. In such a case, it MAY reject the request with a 404 final response; or if it makes a decision to process the request in any case, it MUST disregard the values in the "trunk-context" and the "tgrp" parameters.
UASがトランクグループを支持しますが、事項によって構成されないなら、トランクグループは中でR-URIを特定して、それはもの以外のいかなる他のトランクグループもパラメタで指定したSHOULD NOT使用です。 このような場合には、404の最終的な応答で要求を拒絶するかもしれません。 または、どのような場合でも、要求を処理するという決定をするなら、それは「トランク文脈」と"tgrp"パラメタの値を無視しなければなりません。
If the receiver of a SIP request is not authoritatively responsible for the value specified in the "trunk-context", it MUST treat the value in the "tgrp" parameter as if it were not there. Whether or not to process the request further is up to the discretion of the processing entity; the request MAY be rejected with a 404 final response. Alternatively, if a decision is made to process the request further, the processing entity MUST disregard the values in the "trunk-context" and the "tgrp" parameters since it is not authoritatively responsible for the value specified in "trunk- context".
SIP要求の受信機が厳然と「トランク文脈」で指定された値に原因とならないなら、それはまるでないかのように"tgrp"パラメタの値を扱わなければなりません。 さらに要求を処理するかどうかが処理実体の思慮深さまで達しています。 要求は404の最終的な応答で拒絶されるかもしれません。 あるいはまた、さらに要求を処理するのを決定をするなら、それは厳然と「トランク文脈」で指定された値に責任がないので、処理実体は「トランク文脈」と"tgrp"パラメタの値を無視しなければなりません。
6.3. Proxy Behavior
6.3. プロキシの振舞い
A proxy server receiving a request that contains the trunk group parameter in the Contact header SHOULD NOT change these parameters as the request traverses through it. Changing these parameters may have adverse consequences, since the UAC that populated the parameters did so on some authoritative knowledge that the proxy may not be privy to. Instead, the proxy SHOULD pass the trunk group parameters in the Contact header unchanged to the client transaction that the proxy creates to send the request downstream.
ContactヘッダーSHOULD NOTにトランクグループパラメタを含む要求を受け取るプロキシサーバはそれを通した要求横断としてこれらのパラメタを変えます。 これらのパラメタを変えるのにおいて、不利な結果があるかもしれません、パラメタに居住したUACがなどに、プロキシが関与していないかもしれない何らかの正式の知識をしたので。 代わりに、プロキシSHOULDはプロキシが要求を川下に送るために作成するクライアント取引に変わりのないContactヘッダーでトランクグループパラメタを通過します。
A proxy that is aware of the routing topology and supports this specification MAY insert destination trunk group parameters in the R-URI if none are present (see Sections 7.1 and 7.2 for an example). However, if destination trunk group parameters are already present in the R-URI, the proxy SHOULD NOT change them unless it has further authoritative information about the routing topology than the upstream client did when it originally inserted the trunk group parameters in the R-URI.
なにも存在していないなら(例に関してセクション7.1と7.2を見てください)、ルーティングトポロジーを意識していて、この仕様を支持するプロキシは目的地トランクグループパラメタをR-URIに挿入するかもしれません。 しかしながら、目的地トランクグループパラメタがR-URIで既に存在していて、元々トランクグループパラメタを挿入したとき、上流のクライアントが持っていたほどルーティングトポロジーに関するさらなる信頼できる情報を持っていない場合、プロキシSHOULD NOTはR-URIでそれらを変えます。
Gurbani & Jennings Standards Track [Page 10] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[10ページ]RFC4904Trunk Groups
Depending on the specific situation, it is perfectly reasonable
for a proxy not to insert the destination trunk group parameters
in the R-URI. Consider, for instance, a proxy that understands
the originating trunk group parameters and, in accordance with
local policy, uses these to route the request to a destination
other than a PSTN gateway.
特定の状況によって、プロキシが目的地トランクグループパラメタをR-URIに挿入しないのは、完全に妥当です。 例えば、考えてください、由来しているトランクグループパラメタを理解して、ローカルの方針によると、PSTNゲートウェイ以外の目的地に要求を発送するのにこれらを使用するプロキシ。
7. Example Call Flows
7. 例の呼び出し流れ
7.1. Reference Architecture
7.1. 参照構造
Consider Figure 1, which depicts a SIP proxy in a routing relationship with three gateways in its domain, GW1, GW2, and GW3. Requests arrive at the SIP proxy through GW1. Gateways GW2 and GW3 are used as egress gateways from the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. GW3 also has two trunk groups configured, TG3-1 and TG2-2 (TG2-2 is shared between gateways GW2 and GW3).
図1を考えてください。(それは、ドメイン、GW1、GW2、およびGW3の3門とのルーティング関係でSIPプロキシについて表現します)。 要求はGW1を通してSIPプロキシに到着します。 ゲートウェイのGW2とGW3は出口ゲートウェイとしてドメインから使用されます。 GW2には、グループが構成した2トランク、TG2-1、およびTG2-2があります。 また、GW3には、グループが構成した2トランク、TG3-1、およびTG2-2があります(TG2-2はゲートウェイのGW2とGW3の間で共有されます)。
+-----+ TG2-1
| |--------> To
TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN
From ----->| | | SIP | | | |-------->
PSTN | GW1 |--->| Proxy |-----+ +-----+
----->| | +-------+ | +-----+ TG3-1
+-----+ | | |--------> To
+---->| GW3 | TG2-2 PSTN
| |-------->
+-----+
+-----+ TG2-1| |--------TG1-1+への>。-----+ +-------+ +---->| GW2| TG2-2 PSTN----->|、|、| 一口| | | |-------->PSTN| GW1|、-、--、>| プロキシ|-----+ +-----+ ----->|、| +-------+ | +-----+ TG3-1+-----+ | | |--------+への>。---->| GW3| TG2-2 PSTN| |-------->+-----+
Reference Architecture
参照構造
GW1 in Figure 1 is always cognizant of any requests that arrive over trunk group TG1-1. If it wishes to propagate the ingress trunk group to the proxy, it must arrange for the trunk group to appear in the Contact header of the SIP request destined to the proxy. The proxy will, in turn, propagate the ingress trunk group in the Contact header further downstream.
図1のGW1はいつもトランクグループTG1-1の上で到着するどんな要求も認識しています。 イングレストランクグループをプロキシに伝播したいなら、それは、トランクグループがプロキシに運命づけられたSIP要求のContactヘッダーに現れるように手配しなければなりません。 プロキシはContactヘッダーで順番にさらにイングレストランクグループを川下に伝播するでしょう。
The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is assumed that the proxy has access to a routing table for GW2 and GW3 that includes the appropriate trunk groups to use when sending a call to the PSTN (exactly how this table is constructed is out of scope for this specification; [6] is one way to do so, a manually created and maintained routing table is another). When the proxy sends a request to either of the egress gateways, and the gateway routing
プロキシはPSTNへの出口ゲートウェイとしてGW2とGW3を使用します。 プロキシがGW2と呼び出しをPSTNに送るとき、使用するのが適切であるトランクグループを含んでいるGW3のために経路指定テーブルに近づく手段を持っている(この仕様のための範囲の外にこのテーブルがちょうどどう組み立てられるかがあります; [6]がそうすることにおいて一方通行である、手動で作成されて、維持された経路指定テーブルは別のものである)と思われます。 プロキシが出口ゲートウェイのどちらか、およびゲートウェイルーティングに要求を送るとき
Gurbani & Jennings Standards Track [Page 11] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[11ページ]RFC4904Trunk Groups
table is so configured that a trunk group is required by the gateway, the proxy must arrange for the trunk group to appear in the SIP R-URI of the request destined to that gateway.
トランクグループがゲートウェイによって必要とされるように、テーブルは構成されて、プロキシは、トランクグループがそのゲートウェイに運命づけられた要求のSIP R-URIに現れるように手配しなければなりません。
7.2. Basic Call Flow
7.2. 基本的な呼び出し流動
This example uses the reference architecture of Figure 1. Gateways GW1, GW2, and GW3, and the SIP proxy are assumed to be owned by a service provider whose domain is example.com.
この例は図1の参照構造を使用します。 ゲートウェイGW1、GW2、GW3、およびSIPプロキシはドメインがexample.comであるサービスプロバイダーによって所有されていると思われます。
GW1 SIP Proxy GW2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
... ... ...
| | | Send to PSTN
| | | --> and receive Answer
| | | Complete Message
-----------------------------------------
Call in progress
-----------------------------------------
| | |
| |<-----------F3---+
+<--------------+ |
... ... ...
GW1はプロキシGW2をちびちび飲みます。| | | PSTN-->|、|、| +---F1--------->|、|、| +---F2----------->| ... ... ... | | | PSTNに発信してください。| | | -->、Answerを受けてください。| | | 完全なメッセージ----------------------------------------- 進歩について電話で報告してください。----------------------------------------- | | | | | <、-、-、-、-、-、-、-、-、-、--F3---+ + <。--------------+ | ... ... ...
Basic Call Flow
基本的な呼び出し流動
In the call flow below, certain headers and messages have been omitted for brevity. In F1, GW1 receives a call setup request from the PSTN over a certain trunk group. GW1 arranges for this trunk group to appear in the Contact header of the request destined to the SIP proxy.
以下での呼び出し流動では、確信しているヘッダーとメッセージは簡潔さのために省略されました。 F1では、GW1はPSTNから呼び出しセットアップ要求をあるトランクグループの上に受け取ります。 GW1は、このトランクグループがSIPプロキシに運命づけられた要求のContactヘッダーに現れるように手配します。
F1:
INVITE sip:+16305550100@example.com;user=phone SIP/2.0
...
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
F1: INVITEはちびちび飲みます: 電話+ 16305550100@example.com;user =SIP/2.0 接触: <一口: 0100; 電話文脈はexample.comと等しいです; tgrp=TG1-1 トランク文脈= example.com@gw1.example.com;user が電話と等しい、gt;、…
In F2, the SIP proxy translates the R-URI and adds a destination trunk group to the R-URI. The request is then sent to GW2.
F2では、SIPプロキシは、R-URIを翻訳して、R-URIに目的地トランクグループを加えます。 そして、要求をGW2に送ります。
Gurbani & Jennings Standards Track [Page 12] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[12ページ]RFC4904Trunk Groups
F2:
INVITE sip:+16305550100;tgrp=TG2-1;
trunk-context=example.com@gw2.example.com;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
F2: 一口: +16305550100を招待してください; tgrp=TG2-1 トランク文脈= example.com@gw2.example.com;user は電話SIP/2.0と等しいです… 記録的なルート: <一口: proxy.example.com; lr>接触: <一口: 0100; 電話文脈はexample.comと等しいです; tgrp=TG1-1 トランク文脈= example.com@gw1.example.com;user が電話と等しい、gt;、…
Once the call is established, either end can tear the call down. For illustrative purposes, F3 depicts GW2 tearing the call down. Note that the Contact from F1, including the trunk group parameters, is now the R-URI of the request. When GW1 gets this request, it can associate the call with the appropriate trunk group to deallocate resources.
呼び出しがいったん確立されると、どちらの終わりにも、呼び出しを取りこわすことができます。 説明に役立った目的のために、F3は呼び出しを取りこわすGW2について表現します。 トランクグループパラメタを含むF1からのContactが現在要求のR-URIであることに注意してください。 GW1がこの要求を得るとき、それはdeallocateリソースへの適切なトランクグループに呼び出しを関連づけることができます。
F3:
BYE sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone SIP/2.0
Route: <sip:proxy.example.com;lr>
...
F3: さようなら一口: 0100; 電話文脈はexample.comと等しいです; tgrp=TG1-1 トランク文脈= example.com@gw1.example.com;user は電話SIP/2.0Routeと等しいです: <一口: proxy.example.com; lr>…
It is worth documenting the behavior when an incoming call from the PSTN is received at a gateway without a calling party number. Consider Figure 1, and assume that GW1 gets a call request from the PSTN without a calling party number. This is not an uncommon case, and may happen for a variety of reasons, including privacy and interworking between different signaling protocols before the request reached GW1. Under normal circumstances (i.e., instances where the calling party number is present in signaling), GW1 would derive a sip URI to insert into the Contact header. This sip URI will contain, as its user portion, the calling party number from the incoming SS7 signaling information. The trunk group parameters then becomes part of the user portion as discussed previously.
ゲートウェイで起呼側番号なしでPSTNからのかかってきた電話を受けるとき振舞いを記録する価値があります。 図1を考えてください、そして、GW1がPSTNから起呼側番号なしで発呼要求を得ると仮定してください。 これは、珍しいケースでなく、さまざまな理由で起こるかもしれません、要求がGW1に達する前に異なったシグナリングプロトコルの間のプライバシーと織り込むことを含んでいて。 通常の状況下で(すなわち、起呼側番号がシグナリングで存在している例)、GW1はContactヘッダーに挿入する一口URIを引き出すでしょう。 この一口URIはユーザ部分として入って来るSS7シグナリング情報からの起呼側番号を含むでしょう。 そして、トランクグループパラメタは以前に議論するようにユーザ部分の一部になります。
If a gateway receives an incoming call where the calling party number is not available, it MUST create a tel URI containing a token that is generated locally and has local significance to the gateway. Details of generating such a token are implementation dependent; potential candidates include the gateway line number or port number where the call was accepted. This tel URI is subsequently converted to a sip URI to be inserted in the Contact header of the SIP request going downstream from the gateway.
ゲートウェイが局所的に発生する象徴を含んでいて、起呼側番号が利用可能です、tel URIを作成しなければならないということでないところでかかってきた電話を受けて、ローカルの意味をゲートウェイに持っているなら。 そのような象徴を発生させる詳細は実現に依存しています。 有力候補は、ゲートウェイ行番号を含んでいるか、または呼び出しが受け入れられたところに数を移植します。 このtel URIは、次に、ゲートウェイから流れを下るSIP要求のContactヘッダーに挿入されるために一口URIに変換されます。
Gurbani & Jennings Standards Track [Page 13] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[13ページ]RFC4904Trunk Groups
Note: The tel scheme does not allow for an empty URI; thus, the
global-number or local-number production rule of the tel URI [4]
cannot contain an empty string. Consequently, the behavior in the
above paragraph is mandated for cases where the incoming SS7
signaling message does not contain a calling party number.
以下に注意してください。 tel計画は空のURIを考慮しません。 したがって、tel URI[4]のグローバルな数か市内番号プロダクションルールは空のストリングを含むことができません。 その結果、振舞いは入って来るSS7シグナリングメッセージが起呼側番号を含まないケースのために前の段落で強制されます。
7.3. Inter-Domain Call Flow
7.3. 相互ドメイン呼び出し流動
This example demonstrates the advantage of namespaces in trunk groups. In the example flow below, GW1 and SIP Proxy 1 belong to the example.com domain, and SIP Proxy 2 belongs to another domain, example.net. A call arrives at GW1 (F1) and is routed to the example.net domain. In the call flow below, certain headers and messages have been omitted for brevity.
この例はトランクグループにおける、名前空間の利点を示します。 以下での例の流動では、GW1とSIP Proxy1はexample.comドメインに属します、そして、SIP Proxy2は別のドメイン(example.net)に属します。 呼び出しは、GW1(F1)に到着して、example.netドメインに発送されます。 以下での呼び出し流動では、確信しているヘッダーとメッセージは簡潔さのために省略されました。
example.com example.net
/-------------------------\ /-----------\
GW1 SIP Proxy 1 SIP Proxy 2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
| | |
... ... ...
| +<--F3------------+
... ... ...
example.com example.net/-------------------------\ /-----------GW1がプロキシ1一口2プロキシをちびちび飲む\| | | PSTN-->|、|、| +---F1--------->|、|、| +---F2----------->|、|、|、| ... ... ... | +<--F3------------+ ... ... ...
Inter-Domain Call Flow
相互ドメイン呼び出し流動
F1:
INVITE sip:+16305550100@example.com;user=phone SIP/2.0
...
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
F1: INVITEはちびちび飲みます: 電話+ 16305550100@example.com;user =SIP/2.0 接触: <一口: 0100; 電話文脈はexample.comと等しいです; tgrp=TG1-1 トランク文脈= example.com@gw1.example.com;user が電話と等しい、gt;、…
In F2, the SIP proxy executes its routing logic and re-targets the R-URI to refer to a resource in example.net domain.
F2では、SIPプロキシは、ルーティング論理を実行して、example.netドメインにリソースを示すためにR-URIを再狙います。
F2:
INVITE sip:+16305550100@example.net;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
F2: INVITEはちびちび飲みます: 電話+ 16305550100@example.net;user =SIP/2.0 記録的なルート: <一口: proxy.example.com; lr>接触: <一口: 0100; 電話文脈はexample.comと等しいです; tgrp=TG1-1 トランク文脈= example.com@gw1.example.com;user が電話と等しい、gt;、…
Gurbani & Jennings Standards Track [Page 14] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[14ページ]RFC4904Trunk Groups
In F3, the example.net domain sends a request in the backwards direction. The example.net domain does not interpret the trunk group parameters in the Contact header since they do not belong to that domain. The Contact header, including the trunk group parameters, is simply used as the R-URI in a subsequent request going towards the example.com domain.
F3では、example.netドメインは遅れている指示での要求を送ります。 example.netドメインは、そのドメインに属さないので、Contactヘッダーでトランクグループパラメタを解釈しません。 トランクグループパラメタを含むContactヘッダーは、example.comドメインの方へ行きながら、R-URIとしてその後の要求で単に使用されます。
F3:
BYE sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone
Route: <sip:proxy.example.com;lr>
...
F3: さようなら一口: 0100; 電話文脈はexample.comと等しいです; tgrp=TG1-1 トランク文脈= example.com@gw1.example.com;user は電話Routeと等しいです: <一口: proxy.example.com; lr>…
8. Security Considerations
8. セキュリティ問題
The trunk group parameters are carried in R-URIs and Contact headers; they are simply a modifier of an address. Any existing trust relationship between the originator of a request and an intermediary (or final recipient) that processes the request is not affected by such a modifier.
トランクグループパラメタはR-URIとContactヘッダーで運ばれます。 それらは単にアドレスの修飾語です。 要求の創始者と仲介者(または、最終的な受取人)との要求を処理する少しの既存の信用関係もそのような修飾語で影響を受けません。
Maliciously modifying a trunk group of a R-URI in transit may cause the receiving entity (say, a gateway) to prefer one trunk over another, thus leading to attacks that use resources not privy to the call. For example, an attacker who knows the name of a toll-free trunk on a gateway may modify the trunk group in the R-URI to effectively receive free service, or he may modify the trunk group in a R-URI to affect the flow of traffic across trunks. Similarly, modifying the trunk group in a Contact header may cause the routing intermediary to erroneously associate a call with a different source than it would normally be associated with.
陰湿にトランジットにおけるR-URIのトランクグループを変更すると、別のものよりあるトランクを好む(たとえば、ゲートウェイ)は受信実体に引き起こされるかもしれません、その結果、呼び出しに関与していないリソースを使用する攻撃に通じます。 例えば、ゲートウェイの上でフリーダイヤルトランクの名前を知っている攻撃者が事実上、無料奉仕を受けるようにR-URIにおけるトランクグループを変更するかもしれませんか、または彼は、トランクスの向こう側に交通の流れに影響するようにR-URIにおけるトランクグループを変更するかもしれません。 同様に、Contactヘッダーでトランクグループを変更するのに、ルーティング仲介者は誤って通常、それが関連しているだろうというのと異なったソースに呼び出しを関連づけるかもしれません。
Although this specification imparts more information to the R-URI and the Contact header in the form of trunk groups, the class of attacks and possible protection mechanism are the same as that specified for baseline SIP systems [3]. The Security Session Initiation Protocol Secure (SIPS) scheme and the resulting Transport Layer Security (TLS) mechanism SHOULD be used to provide integrity protection, thereby mitigating these attacks.
この仕様はR-URIとトランクグループの形のContactヘッダーに詳しい情報を伝えますが、攻撃と可能な保護メカニズムのクラスは基線SIPシステム[3]に指定されたそれと同じです。 保全保護を提供するのに使用されて、その結果これらの攻撃を緩和するSecurity Session InitiationプロトコルSecure(SIPS)計画と結果として起こるTransport Layer Security(TLS)メカニズムSHOULD。
A question naturally arises: how does the receiver determine whether the sender is authorized to use the resources represented by the trunk group parameters? There are two cases to consider: intra- domain signaling exchange as discussed in Section 7.2, and inter- domain signaling exchange as discussed in Section 7.3.
質問は自然に起こります: 受信機は、送付者がトランクグループパラメタによって表されたリソースを使用するのに権限を与えられるかどうかどのように決定しますか? 考える2つのケースがあります: セクション7.2で議論するイントラドメインシグナリング交換、およびセクション7.3で議論する相互ドメインシグナリング交換。
Gurbani & Jennings Standards Track [Page 15] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[15ページ]RFC4904Trunk Groups
In the intra-domain case, a proxy receiving trunk group parameters from an upstream user agent (typically a gateway) should only accept them using the SIPS URI scheme; furthermore, it should use HTTP Digest to challenge and properly authorize the sender. A user agent (or a gateway) receiving the trunk group parameters from a proxy will not be able to challenge the proxy using HTTP Digest, but it should examine the X.509 certificate of the proxy to determine whether the proxy is authorized to insert the resources represented by the trunk group parameters into the signaling flow.
イントラドメイン場合では、上流のユーザエージェント(通常ゲートウェイ)からトランクグループパラメタを受け取るプロキシはSIPS URI計画を使用することでそれらを受け入れるだけであるべきです。 その上、それは、挑戦して、適切に送付者に権限を与えるのにHTTP Digestを使用するべきです。 プロキシからトランクグループパラメタを受け取るユーザエージェント(または、ゲートウェイ)はHTTP Digestを使用するのにおいてプロキシに挑戦できないでしょうが、それは、プロキシがトランクグループパラメタによってシグナリング流動に表されたリソースを挿入するのに権限を与えられるかどうか決定するためにプロキシのX.509証明書を調べるべきです。
In the inter-domain case, a receiving proxy may depend on the identity stored in the X.509 certificate of the sending proxy to determine whether the sender is authorized to insert the resources represented by the trunk group parameters in the signaling message.
相互ドメイン場合では、受信プロキシは送付者がシグナリングメッセージのトランクグループパラメタによって表されたリソースを挿入するのに権限を与えられるかどうか決定するために送付プロキシのX.509証明書に格納されたアイデンティティを当てにするかもしれません。
Because of these considerations, the trunk group parameters are only applicable within a set of network nodes among which there is mutual trust. If a node receives a call signaling request from an upstream node that it does not trust, it SHOULD remove the trunk group parameters.
これらの問題のために、トランクグループパラメタは1セットのネットワーク・ノードで中信頼関係がある適切であるだけです。 ノードが呼び出しを受けるなら、上流のノードからどんな信用もしないで、SHOULDであると要求に合図して、トランクグループパラメタを取り除いてください。
The privacy information revealed with a trunk group does not generally advertise much information about a particular (human) user. It does, however, convey two pieces of potentially private information that may be considered sensitive by carriers. First, it may reveal how a carrier may be performing least-cost routing and peering; and secondly, it does introduce an additional means for network topology and information of a carrier. It is up to the discretionary judgment of the carrier if it wants to include the trunk group parameters and reveal potentially sensitive information on its network topology. If confidentiality is desired, TLS SHOULD be used to protect this information while in transit.
一般に、トランクグループと共に明らかにされたプライバシー情報は特定(人間の)のユーザの多くの情報の広告を出しません。 しかしながら、それは潜在的に敏感であるとキャリヤーによって考えられるかもしれない個人情報の2つの断片を伝えます。 まず最初に、キャリヤーがどう最低回線料金自動選択機能を実行して、じっと見ているかもしれないかを明らかにするかもしれません。 そして、第二に、それはキャリヤーのネットワーク形態と情報のために追加手段を導入します。 トランクグループパラメタを含んで、ネットワーク形態の潜在的に機密の情報を明らかにしたいなら、それはキャリヤーの任意の判断まで達しています。 TLS SHOULD、秘密性は望まれています。トランジットにはある間、この情報を保護するのが使用されてください。
9. IANA considerations
9. IANA問題
This specification does not require any IANA considerations.
この仕様はどんなIANA問題も必要としません。
The tel URI parameters introduced in this document are registered with IANA through the tel URI parameter registry document [7].
本書では紹介されたtel URIパラメタはtel URIパラメタ登録ドキュメント[7]を通してIANAに示されます。
10. Acknowledgments
10. 承認
The authors would like to acknowledge the efforts of the participants of the SIPPING and IPTEL working group, especially Jeroen van Bemmel, Bryan Byerly, John Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran, Takuya Sawada, Tom Taylor, and Al Varney.
作者はSIPPING、IPTELワーキンググループ、特にジョロエンバンBemmel、ブライアンバイエル、ジョンHearty、アラン・ジョンストン、シャンLu、Rohanマーイ、ジョン・ピーターソン、マイク・ピアス、アダム・ローチ、ブライアン・ローゼン、ジョナサン・ローゼンバーグ、デーヴ・オラン、Takuya Sawada、トム・テイラー、およびアル・ヴァーニーの関係者の努力を承諾したがっています。
Gurbani & Jennings Standards Track [Page 16] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[16ページ]RFC4904Trunk Groups
Jon Peterson was also instrumental in the original formulation of this work.
また、ジョン・ピーターソンもこの仕事のオリジナルの定式化で手段になっていました。
Alex Mayrhofer brought up the issue of lexicographic ordering of tel URI parameters when it is converted to a sip or sips URI.
一口に変換されるか、またはURIをちびちび飲むとき、アレックス・マイルホーファーはtel URIパラメタの辞書編集の注文の問題を持って来ました。
Ted Hardie, Sam Hartman, and Russ Housley took pains to ensure that the text around URI comparisons and security considerations was as unambiguous as possible.
テッド・ハーディー、サム・ハートマン、およびラスHousleyは、URI比較とセキュリティ問題の周りのテキストが確実にできるだけ明白だっなるようにするために苦心をしました。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[2] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966,
December 2004.
[4]Schulzrinne、2004年12月のH.、「Telephone Callsのためのtel URI」RFC3966。
11.2. Informative References
11.2. 有益な参照
[5] "Telcordia Notes on the Network", Telcordia SR-2275, Issue 04,
October 2000, <http://telecom-info.telcordia.com>.
[5] 「ネットワークに関するTelcordia注」(Telcordia SR-2275)は04、2000年10月を発行して、<http://電子通信-info.telcordia.comは>です。
[6] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D.
Shah, "A Telephony Gateway REgistration Protocol (TGREP)", Work
in Progress, January 2007.
[6] バンガロール、M.、クマー、R.、ローゼンバーグ、J.、サラマ、H.、およびD.シャー、「電話ゲートウェイ登録プロトコル(TGREP)」は進行中(2007年1月)で働いています。
[7] Jennings, C. and V. Gurbani, "The Internet Assigned Number
Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
Registry", Work in Progress, December 2006.
[7] Progress(2006年12月)のジョニングスとC.とV.Gurbani、「ISOCの機関の一つで(IANA)tel Uniform Resource Identifier(URI)パラメタRegistry」Work。
Gurbani & Jennings Standards Track [Page 17] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[17ページ]RFC4904Trunk Groups
Authors' Addresses
作者のアドレス
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA
ビジェイK.Gurbaniベル研究所、アルカテル透明な2701年の透明なレーンRm9F546ライル糸、IL60532米国
Phone: +1 630 224 0216 EMail: vkg@alcatel-lucent.com
以下に電話をしてください。 +1 0216年の630 224メール: vkg@alcatel-lucent.com
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/3 San Jose, CA 95134 USA
西タスマン・ドライブMailstop SJC-21/3カレンジョニングスシスコシステムズ170カリフォルニア95134サンノゼ(米国)
Phone: +1 408 421 9990 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 9990年の408 421メール: fluffy@cisco.com
Gurbani & Jennings Standards Track [Page 18] RFC 4904 Trunk Groups in tel/sip URIs June 2007
tel/一口URI2007年6月のGurbaniとジョニングスStandards Track[18ページ]RFC4904Trunk Groups
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Gurbani & Jennings Standards Track [Page 19]
Gurbaniとジョニングス標準化過程[19ページ]
一覧
スポンサーリンク
