[要約] RFC 4904は、tel/sip Uniform Resource Identifiers (URIs)でトランクグループを表現するための仕様です。このRFCの目的は、トランクグループを識別するための一貫した方法を提供することです。
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)
TEL/SIPユニフォームリソース識別子（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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は、64 kbps（1つの電話音声チャネルに通常使用される帯域幅）であるDS0に基づく一連の標準デジタル伝送速度の用語です。ヨーロッパの電子キャリアシステムは、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のバンドルをトランクと呼ぶことが一般的になりました。しかし、厳密に言えば、トランクは2つのPSTNエンドオフィスの間の単一のDS0です。ただし、このドキュメントの目的のために、ゲートウェイのPSTNインターフェイスはエンドオフィスとして効果的に機能します（つまり、ゲートウェイがシグナリングシステム7（SS7）とインターフェイスする場合、独自のSS7ポイントコードなどを備えています）。トランクグループは、ルーティングの一般的な管理ポリシーの下でグループ化されたDS0の束（SS7トランク回路識別コード番号スキームで数値的に連続する必要はありません）です。
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.
セッション開始プロトコル（SIP）[3]からPSTNゲートウェイへのセッションには、異なるキャリアに接続されているトランクがある場合があります。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]はそのような方法の1つを提供します）。ただし、トランクグループが決定されると、このドキュメントは、シグナリングメッセージでそれを表すための標準化された手段を提供します。
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プロキシは、リクエスト-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ルーティングエンティティは、通常の操作にトランクグループを使用することに関心がある場合があります。その程度まで、標準主導の要件により、あるベンダーのプロキシがさらに別のベンダーからのゲートウェイと相互運用できます。そのようなガイドラインがなければ、プロキシベンダーは、トランクグループパラメーターが存在することを期待する場所に関するゲートウェイの期待に適合しなければならないため、相互運用性が低下します（および逆も同様です）。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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].
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).
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に対して定義されると、[3]のセクション19.1.6の規範的手順を使用して、トランクグループパラメーターを備えた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パラメーターは、グローバルな電話番号（つまり、先行するもの）ではなく、ローカルの電話番号にのみ適用できます。一方、トランクグループは、ローカルまたはグローバルの電話番号に表示される場合があります。したがって、必要なのは、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セッションに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]:
トランクグループ識別子の拡張されたBackus naurフォーム[2]構文を以下に示し、[4]で定義されているTel URIの「PAR」生産ルールを拡張します。
par = parameter / extension / isdn-subaddress / trunk-group /
trunk-context
trunk-group = ";tgrp=" trunk-group-label
trunk-context = ";trunk-context=" descriptor
trunk-group-label = 1*( unreserved / escaped /
trunk-group-unreserved )
trunk-group-unreserved = "/" / "&" / "+" / "$"
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.
トランクグループは、「TGRP」と「トランクコンテキスト」の2つのパラメーターで識別されます。トランクグループを識別するには、両方のパラメーターを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」または「Trunk-Context」パラメーターの1つだけの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.
「Trunk-Context」パラメーターは、グローバルな数字またはその先行数字（33など）またはドメイン名を指定することにより、トランクグループに名前空間を課します。構文的には、「電話コンテキスト」パラメーターとは異なり、「トランクコンテキスト」パラメーターがローカルまたはグローバルテルURIに表示される可能性があることを除いて、Tel URI [4]の「電話コンテキスト」パラメーターの後にモデル化されます。
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」パラメーターで指定されているトランクグループの範囲、つまり、単一のゲートウェイ、ゲートウェイのセット、またはサービスプロバイダーが管理するドメイン全体で有効であるかどうかを確立します。「Trunk-Context」には、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. 「トランクコンテキスト」の値は、文字通りホスト（ゲートウェイ）を識別します。その場合、トランクグループは特定のホストにscopedされます。
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. 「Trunk-Context」の値は、特定のドメイン内のすべてのゲートウェイを識別するサービスプロバイダードメイン（「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
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
2. Trunk group in a global number, with a domain name trunk-context:
2. ドメイン名Trunk-Contextを持つグローバル番号のトランクグループ：
tel:+16305550100;tgrp=TG-1;trunk-context=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
3. Trunk group in a global number, with a number prefix trunk-context:
3. グローバルな数のトランクグループ、数字のプレフィックストランクコンテキスト：
tel:+16305550100;tgrp=TG-1;trunk-context=+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
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.
逆に、コンタクトヘッダーURIのトランクグループパラメーターの外観は、コールが到着したトランクグループ、つまり発信（またはイングレス）トランクグループを意味します。したがって、SIPリクエストのコンタクトヘッダーに発信（またはイングレス）トランクグループが表示される必要があります。
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）この仕様をサポートするコールを開始する必要があります。コンタクトヘッダーURIにトランクグループパラメーターを含める必要があります（連絡先URIはSIPまたはSIPS URIでなければなりません。トランクグループパラメーターを備えたTel URIのSIP翻訳）。コンタクトヘッダーのトランクグループパラメーターは、発生するトランクグループを表します。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の一部になる可能性があります。ただし、意味的には、From Headerの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".
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.
コンタクトヘッダーにトランクグループパラメーターを含むリクエストを受信するプロキシサーバーは、リクエストが通過するときにこれらのパラメーターを変更してはなりません。これらのパラメーターを変更すると、パラメーターに浸透したUACは、プロキシが賢明ではない可能性のある権威ある知識についてそうしたため、悪影響が生じる可能性があります。代わりに、プロキシは、プロキシが作成してリクエストを下流に送信するクライアントトランザクションに変更されていないコンタクトヘッダーのトランクグループパラメーターを渡す必要があります。
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.
ルーティングトポロジーを認識し、この仕様をサポートするプロキシは、存在しない場合はR-URIに宛先トランクグループパラメーターを挿入する場合があります（例については、セクション7.1および7.2を参照）。ただし、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.
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を考えてみましょう。これは、ドメインの3つのゲートウェイ、GW1、GW2、およびGW3の3つのゲートウェイとのルーティング関係のSIPプロキシを示しています。リクエストは、GW1を介してSIPプロキシに到着します。ゲートウェイGW2およびGW3は、ドメインからの出口ゲートウェイとして使用されます。GW2には、TG2-1とTG2-2の2つのトランクグループが構成されています。GW3には、TG3-1とTG2-2の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を介して到着するリクエストを常に認識しています。Ingress Trunkグループをプロキシに伝播したい場合は、トランクグループがプロキシに運命づけられたSIPリクエストのコンタクトヘッダーに表示されるように手配する必要があります。プロキシは、コンタクトヘッダーのイングレストランクグループをさらに下流に伝播します。
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]そのための1つの方法は、手動で作成され、維持されたルーティングテーブルが別のものです）。プロキシが出力ゲートウェイのいずれかにリクエストを送信し、ゲートウェイルーティングテーブルが非常に構成されているため、トランクグループがゲートウェイで必要とされる場合、プロキシはトランクグループがリクエストの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の参照アーキテクチャを使用しています。GATWAYSGW1、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プロキシに任命されたリクエストのコンタクトヘッダーに表示されるように手配します。
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>
...
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>
...
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は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 URIに変換され、Gatewayから下流に進むSIP要求のコンタクトヘッダーに挿入されます。
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 Proxy 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>
...
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>
...
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ドメインは、コンタクトヘッダーのトランクグループパラメーターをそのドメインに属さないため、トランクグループパラメーターを解釈しません。トランクグループパラメーターを含むコンタクトヘッダーは、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>
...
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のトランクグループを変更してフローに影響を与える可能性があります。トランク全体のトラフィックの。同様に、コンタクトヘッダーでトランクグループを変更すると、ルーティング中間層が通常関連するものとは異なるソースに誤って呼び出しを関連付けることがあります。
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とコンタクトヘッダーにより多くの情報を与えますが、攻撃のクラスと可能な保護メカニズムは、ベースラインSIPシステムに指定されたものと同じです[3]。セキュリティセッション開始プロトコルセキュア（SIP）スキームと結果の輸送層セキュリティ（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パラメーターレジストリドキュメント[7]を介してIANAに登録されています。
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.
著者は、飲みやイプテルのワーキンググループの参加者の努力、特にJeroen Van Bemmel、Bryan Byerly、John Hearty、Alan Johnston、Shan Lu、Rohan Mahy、Jon Peterson、Mike Pierce、Adam Roach、Brian Rosenenen、ジョナサン・ローゼンバーグ、デイブ・オラン、タクヤ・サワダ、トム・テイラー、アル・ヴァーニー。
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.
Alex Mayrhoferは、SIPまたはSIPS 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.
Ted Hardie、Sam Hartman、およびRuss Housleyは、URIの比較とセキュリティに関する考慮事項に関するテキストが可能な限り明確であることを保証するために苦労しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, December 2004.
[4] Schulzrinne、H。、「電話のためのTel URI」、RFC 3966、2004年12月。
[5] "Telcordia Notes on the Network", Telcordia SR-2275, Issue 04, October 2000, <http://telecom-info.telcordia.com>.
[5] 「ネットワーク上のTelcordiaノート」、Telcordia SR-2275、Issue 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] Bangalore、M.、Kumar、R.、Rosenberg、J.、Salama、H。、およびD. Shah、「テレフォニーゲートウェイ登録プロトコル（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] Jennings、C。and V. Gurbani、「インターネットが割り当てられた番号局（IANA）TELユニフォームリソース識別子（URI）パラメーターレジストリ」、2006年12月の進行中の作業。
Authors' Addresses
著者のアドレス
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA
Vijay K. Gurbani Bell Laboratories、Alcatel-Lucent 2701 Lucent Lane RM 9F-546 Lisle、IL 60532 USA
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/3 San Jose, CA 95134 USA
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/3 San Jose、CA 95134 USA
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。