Network Working Group V. Gurbani
Request for Comments: 4904 Bell Laboratories, Alcatel-Lucent
Category: Standards Track C. Jennings
Cisco Systems
June 2007
Representing Trunk Groups in tel/sip
Uniform Resource Identifiers (URIs)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、SIPおよびTELユニフォームリソース識別子（URI）にトランクグループパラメータを伝えるために標準化されたメカニズムを説明しています。 TEL URIへの拡張は、この目的のために定義されています。
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
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.
公共の場でのコールのルーティングは、電話網（PSTN）時分割多重（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.
トランクグループ：トランクのセットは、トラフィックが内または経路の全てが交換された交換機間の接続の確立のために、ユニットとして操作します。単一のトランクグループは、冗長性のために複数のスイッチ間で共有することができます。
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）：デジタル信号Xは、DS0、64 kbpsの（通常は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.
（北米で）24の最小グループにおける端局間のDS0の割当てをもたらしユビキタスデジタルトランキングの導入以来、それはトランクとしてDS0の束を意味するために一般的になってきています。厳密に言えば、しかし、トランクは、二つのPSTNの端局との間の単一のDS0です。しかしながら、本文書の目的のために、ゲートウェイのPSTNインタフェース（すなわち、シグナリングシステム7（SS7）とゲートウェイインターフェイス場合、それはそれ自身のSS7ポイントコードを有している、など）端局として有効に作用します。トランクグループは、次に、ルーティングのための共通の管理ポリシーの下でグループ化されている（SS7トランク回線識別コード番号付けスキームにおける数値の連続である必要はない）DS0の束です。
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 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.
PSTNゲートウェイにセッション開始プロトコル（SIP）、[3]は、異なるキャリアに接続されているトランクを有していてもよいです。コールが、それはゲートウェイにセッションセットアップ要求をプロキシする際に送信されるキャリア - この文書で列挙されていない要因に基づいて - SIPプロキシが選択するのは完全に合理的です。複数のキャリアは、特定の電話番号にコールを輸送することができるので、電話番号自体は、ゲートウェイでのキャリアを識別するのに十分ではありません。トランクグループの形で情報の追加部分は、さらに、ゲートウェイでの選択肢をダウン削り取っするために使用することができます。この文書で使用されるように、トランクは必ずしもゲートウェイに接続されていて、特定のゲートウェイへのリクエストのルーティング時にトランクグループを使用するプロキシが知っていると、コールをゲートウェイコントロールがにルーティングされ、トランキングリソースがその上に存在しているかを知っていますゲートウェイ。
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]そのような方法を提供する）、この文書の範囲外です。トランクグループは時に決定された後しかし、この文書は、シグナリングメッセージでそれを表現するための標準化の手段を提供します。
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.定位置曖昧：のRequest-URI（R-URI）のユーザ部分のパラメータとしてトランクグループを挿入することができるIP（VoIP）のゲートウェイ上に出力音声にコールを送信したいSIPプロキシ、または月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つのベンダーからのプロキシを有効にします。プロキシ・ベンダは、それが（またはその逆）トランクグループパラメータが存在することを期待する場所にゲートウェイとしての期待に適合しなければならないように存在しないようなガイドラインは、相互運用性は、低下します。
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]標準化された方法での拡張としてトランクグループパラメータを表す方法を概説することです。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
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.
このセクションでは、トランクグループの仕様のための設計上の決定のための動機をキャプチャします。これらの動機は、この文書の最終的なトランクグループの仕様を誘導するために使用される要件のセットとして捕捉されます。
REQ 1: Trunk group parameters must be defined as an extension to the tel URI [4].
REQ 1：トランクグループパラメータは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).
トランクグループのパラメータは、SIP URIまたはTEL URIのいずれかで行うことができます。トランクグループが密接PSTNに関連付けられているので、そのRで、全体的にまたは部分的に、TEL URI（合理的にTEL URIを持つことが期待できゲートウェイに行くすべてのSIPリクエストへの拡張として、それらを定義するために合理的なようです-uriとにかく）。また、TEL URIを使用しても、このフォーマットは、（適切な情報要素が作成される場合、H.323にMGCP又はMegacoのからのものを含むことができる）、非SIPのVoIPプロトコルによって再利用されることを可能にします。
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から同等のSIP URIを導出するために使用することができます。
REQ 2: Inter-domain trunk group name collisions must be prevented.
REQ 2：ドメイン間トランクグループ名の衝突を防止しなければなりません。
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.
通常の動作の下で、トランクグループは、管理ドメイン（すなわち、ローカルスコープ）内に適切です。しかし、不注意によるクロスドメイントランクグループの名前の衝突が発生する可能性があることを考えると、それらを防止することが望ましいです。名前空間の賢明な使用は、この問題を解決します。したがって、それは名前空間によってスコープトランクグループに適切と思われます。
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の「電話・コンテキスト」パラメータの同等の機能を持つパラメータが、ローカルおよびグローバルの電話番号にも同様に適用可能なものです。
REQ 3: Originating trunk group and destination trunk group must be able to appear separately and concurrently in a SIP message.
REQ 3：発信トランクグループ及び宛先トランクグループは、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リクエストに実施することが必要です。
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.
REQ 4：SIPネットワーク仲介（プロキシサーバーおよびサーバーをリダイレクト）ルートが呼のために選択されるSIPセッションに宛先トランクグループ属性を追加することができなければなりません。
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]:
増補バッカスナウア記法[2]トランクグループ識別子の構文は下記とURI [4]で定義されたTELの「PAR」プロダクションルールを延びています。
par = parameter / extension / isdn-subaddress / trunk-group / trunk-context
PAR =パラメータ/拡張/ ISDN-サブアドレス/トランクグループ/トランクコンテキスト
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]で定義されているエスケープ。
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.
トランクグループを使用している場合、この仕様に準拠するすべての実装は、これらのパラメータの両方を発生させなければなりません。実装は一つだけ「tgrp」または「トランク・コンテキスト」パラメータのとTEL URIを受信した場合、全くその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」パラメータで指定されたトランクグループ、の範囲を確立します。 「トランク・コンテキストは、」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.「トランクコンテキスト」の値は、グローバルな番号またはその先頭の桁の任意の数です。これは、プロバイダ全体のスコープのために有用であり、ゲートウェイまたはゲートウェイのセットにわたってトランクグループを指定することに非常によく適していません。
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].
同値のために、トランクグループパラメータを含む2つのURIは、URIのベース比較ルールに従って同等です。 TEL URIのベース比較ルールは、[4]のセクション4で指定され、そして、SIP 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
SIP：SIP URI収量このTEL URIを変換;電話コンテキスト= + 1から630; tgrp = TG-1 5550100。 trunk-context=example.com@isp.example.net;ユーザー=電話
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
SIP URIに収量をこのTEL URIを変換する：SIP：16305550100; tgrp = TG-1。 trunk-context=example.com@isp.example.net;ユーザー=電話
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
SIP URIに収量をこのTEL URIを変換する：SIP：16305550100; tgrp = TG-1。 trunk-context=+1-630@isp.example.net;ユーザー=電話
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エンティティからの指示です。
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にトランクグループパラメータを使用することができます。 SIPネットワーク仲介トランクグループパラメータを含むように、R-URIを変更することができるので、これはまた、REQ 4満たします。
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.
このセクションで説明する動作が効果的にREQ 3に対応しています。
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.
トランクグループを使用し、この仕様をサポートして通話を開始するユーザエージェントクライアント（UAC）は、ContactヘッダのURIにおけるトランクグループパラメータを含まなければならない（連絡先URIは、SIPであるか、またはsips URIをしなければならないため、どのような連絡先のヘッダーに表示することですTEL URIのSIP翻訳、トランクグループパラメータとの完全な）。 Contactヘッダにおけるトランクグループパラメータは、発信トランク群を表します。 RFC 3261で定義された連絡先ヘッダの処理ルールの結果として[3]、このユーザエージェントに向かってダイアログ内の後続の要求は、R-URIにこの連絡先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.
注：おそらく、元のトランクグループからURIの一部にすることができます。しかしながら、意味的に、ヘッダからのURIは、このように長期的に識別されたリソースを表す抽象識別子です。トランクグループの存在は、他の一方で、それが唯一のセッションの期間中に有効である結合を意味し;トランクグループは、セッションが終わった後には意味がありません。このように、連絡先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節を参照してください）。
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.
ゲートウェイに関連付けられた処理ユーザエージェントサーバ（UAS）に、R-URIでトランクグループパラメータは、アウトバウンドコールの名前が付いたトランクグループを使用することを意味します。 UASは、トランクグループをサポートしていますが、その特定のトランクグループのすべてのトランク回路の識別コードが占有されていることを発見した場合、それは603衰退最終的な応答を送信することができます。
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で識別される特定のトランクグループに設定されていない場合は、パラメータで指定されたもの以外の他のトランクグループを使用しないでください。このような場合には、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」パラメータの値を無視しなければなりません。
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ヘッダにトランクグループパラメータを含む要求を受けたプロキシサーバは、これらのパラメータを変更しないでください。パラメータを埋めUACがプロキシはに関与しないかもしれないことをいくつかの正式な知識にそのようにしたので、これらのパラメータを変更すると、不利な結果をもたらす可能性があります。代わりに、プロキシはプロキシが下流のリクエストを送信するために作成し、クライアントのトランザクションに変わらない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に存在している場合、それは上流のクライアントは、それが元々R-URIにトランクグループパラメータを挿入しなかったよりも、ルーティングトポロジについての更なる信頼できる情報を持っている場合を除きしかし、プロキシがそれらを変更しないでください。
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ゲートウェイ以外の宛先に要求を、これらを使用するプロキシを考えます。
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).
そのドメイン、GW1、GW2及びGW3三のゲートウェイとルーティング関係にSIPプロキシを示す図1を考えます。リクエストはGW1を通じてSIPプロキシに到着します。ゲートウェイGW2及びGW3は、ドメインからの出口のゲートウェイとして使用されています。 GW2は、TG2-1及びTG2-2を設定された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
| |-------->
+-----+
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 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.
プロキシは、PSTNへの出口ゲートウェイとしてGW2及びGW3を使用します。なお、本明細書の範囲外である（このテーブルを構築する方法を正確にPSTNにコールを送信するときに使用するために適切なトランクグループを含むことをプロキシがGW2及びGW3のルーティングテーブルへのアクセスを有することが想定される。[6]でありますそうするための一つの方法は、手動で作成し、維持ルーティングテーブル）が別です。プロキシは、出口ゲートウェイのいずれかに要求を送信し、ゲートウェイルーティングテーブルがそのようにトランクグループがゲートウェイによって必要とされるように構成され、プロキシは、要求のSIP R-URIに表示するトランクグループを手配しなければならない場合そのゲートウェイ宛て。
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---+
+<--------------+ |
... ... ...
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：+16305550100@example.com;ユーザー=電話のSIP / 2.0 ...連絡先：：SIP INVITE <一口：0100;電話コンテキスト= example.com; tgrp = TG1-1を。 trunk-context=example.com@gw1.example.com;ユーザー=電話> ...
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に送信されます。
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>
...
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からの問い合わせが、今リクエストのR-URIであることに注意してください。 GW1は、この要求を受け取ると、リソースの割り当てを解除するために、適切なトランクグループにコールを関連付けることができます。
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：BYE SIP：0100;電話コンテキスト= example.com; tgrp = TG1-1。 trunk-context=example.com@gw1.example.com;ユーザー=電話SIP / 2.0経路：<SIP：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ヘッダに挿入するSIP URIを導くであろう。このSIP 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ヘッダに挿入されるように、SIP URIに変換されます。
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シグナリングメッセージが発信者番号が含まれていない場合のために義務付けられています。
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プロキシ1は、example.comドメインに属し、SIPプロキシ2は、別のドメイン、example.netに属します。コールは、GW1（F1）に到着し、example.netドメインにルーティングされます。以下のコールフローでは、特定のヘッダとメッセージは簡潔にするために省略されています。
example.com example.net
/-------------------------\ /-----------\
GW1 SIP Proxy 1 SIP Proxy 2
From | | |
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：+16305550100@example.com;ユーザー=電話のSIP / 2.0 ...連絡先：：SIP INVITE <一口：0100;電話コンテキスト= example.com; tgrp = TG1-1を。 trunk-context=example.com@gw1.example.com;ユーザー=電話> ...
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プロキシは、R-URIはexample.netドメイン内のリソースを参照するためにそのルーティングロジック、再ターゲットを実行します。
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：SIP INVITE：+16305550100@example.netと、ユーザー=電話SIP / 2.0 ...レコードルート<SIP：proxy.example.com; LR>連絡先：<SIP：0100;電話コンテキスト= example.com ; tgrp = TG1-1。 trunk-context=example.com@gw1.example.com;ユーザー=電話> ...
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：BYE SIP：0100;電話コンテキスト= example.com; tgrp = TG1-1。 trunk-context=example.com@gw1.example.com;ユーザー=電話ルート：<SIP：proxy.example.com; LR> ...
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と連絡先のヘッダーで運ばれます。彼らは単にアドレスの修飾子です。要求を処理する要求の発信元と中間（または最終受信者）との間の既存の信頼関係は、このような改質剤に影響されません。
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のトランクグループを修正すること、従ってコールに関与したリソースを使用しない攻撃に導く、別の上に1つのトランクを好む受信エンティティ（例えば、ゲートウェイ）を引き起こすことができます。例えば、ゲートウェイ上のフリーダイヤルトランクの名前を知っている攻撃者は、効果的に無料サービスを受けるために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]に指定されたものと同じです。セキュリティセッション開始プロトコルセキュア（SIPS）方式、そして得られたトランスポート層セキュリティ（TLS）のメカニズムは、それによってこれらの攻撃を軽減する、完全性保護を提供するために使用されるべきです。
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で説明したように、ドメイン内には、交換をシグナル。
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ダイジェストを使用する必要があります。プロキシからトランクグループパラメータを受信するユーザエージェント（またはゲートウェイ）は、HTTPダイジェストを使用してプロキシに挑戦することはできませんが、それはプロキシが挿入することを許可されているかどうかを決定するためにプロキシの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.
そのため、これらの考慮事項のため、トランクグループパラメータは、相互の信頼が存在する間のネットワーク・ノードのセット内でのみ適用されます。ノードは、それが信頼していない上流ノードからの要求をコールシグナリングを受信した場合には、トランクグループパラメータを削除する必要があります。
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は、輸送中の間、この情報を保護するために使用されるべきです。
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パラメータレジストリ文書をIANAに登録されている[7]。
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、ブライアンByerly、ジョン・ハーティ、アラン・ジョンストン、シャンルー、露伴マーイ、ジョンピーターソン、マイク・ピアース、アダムローチ、ブライアン・ローゼンを確認したいと思います、ジョナサン・ローゼンバーグ、デイブ・オラン、拓也澤田、トム・テイラー、そしてアルヴァーニー。
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.
それは一口に変換またはsips URIをされたときにアレックスMayrhoferは、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の比較およびセキュリティの考慮事項の周りのテキストを可能な限り明確なだったことを確認するために苦労しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, December 2004.
[4] Schulzrinneと、H.は、RFC 3966、2004年12月、 "電話のためのTEL URIコール"。
[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://telecom-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]ジェニングス、C.およびV. Gurbani、 "番号機関（IANA）のtel URI（Uniform Resource Identifier）でパラメータレジストリの割り当てインターネット"、進歩、2006年12月に作業。
Authors' Addresses
著者のアドレス
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA
ビジェイK. Gurbaniベル研究所、アルカテル・ルーセント2701ルーセントレーンRmの9F-546ライル、IL 60532 USA
Phone: +1 630 224 0216 EMail: vkg@alcatel-lucent.com
電話：+1 630 224 0216 Eメール：vkg@alcatel-lucent.com
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/3 San Jose, CA 95134 USA
カレンジェニングスシスコシステムズ170西タスマンドライブメールストップSJC-3分の21サンノゼ、CA 95134 USA
Phone: +1 408 421 9990 EMail: fluffy@cisco.com
電話：+1 408 421 9990 Eメール：fluffy@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。