[要約] RFC 3603は、PacketCable分散型呼制御アーキテクチャをサポートするためのPrivate SIP Proxy-to-Proxy拡張に関するものです。このRFCの目的は、PacketCableネットワークでのセッション開始プロトコル（SIP）プロキシ間の通信を拡張することです。
Network Working Group W. Marshall, Ed.
Request for Comments: 3603 AT&T
Category: Informational F. Andreasen, Ed.
Cisco
October 2003
Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
PacketCable分散コールシグナリングアーキテクチャをサポートするためのプライベートセッション開始プロトコル（SIP）プロキシからプロキシへの拡張機能
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.
さまざまなドメインにわたって非常に大規模に住宅電話サービスを展開するには、異なるサービスプロバイダーが所有する信頼できる要素が、通話に関与する当事者に関する顧客固有の情報と期待を伝える信頼できる情報を交換する必要があります。このドキュメントでは、パケット可能な分散コールシグナルアーキテクチャの信頼できるエンティティ間の顧客情報の交換と請求情報をサポートするためのセッション開始プロトコル（SIP）（RFC3261）のプライベート拡張について説明します。これらの拡張機能は、サービスの盗難を防ぐためのアクセスネットワーク調整のメカニズムを提供し、顧客は嫌がらせのコールの痕跡、オペレーターサービスと緊急サービスのサポート、および他のさまざまな規制問題のサポートを提供します。拡張機能の使用は、クローズド管理ドメイン内、または充電およびその他の機能の調整が必要な以前に合意したポリシーを備えた管理ドメインの連合内でのみ適用されます。
Table of Contents
目次
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . . 5
4. Conventions used in this document . . . . . . . . . . . . . . 6
5. P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . . 6
5.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures at an Untrusted User Agent Client (UAC). . . 7
5.3. Procedures at a Trusted User Agent Client (UAC) . . . . 7
5.4. Procedures at an Untrusted User Agent Server (UAS). . . 7
5.5. Procedures at a Trusted User Agent Server (UAS) . . . . 7
5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 8
5.6.1. Procedures at Originating Proxy . . . . . . . . 8
5.6.2. Procedures at Terminating Proxy . . . . . . . . 8
6. P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Procedures at an Untrusted User Agent Client (UAC). . . 9
6.3. Procedures at a Trusted User Agent Client (UAC) . . . . 10
6.4. Procedures at an Untrusted User Agent Server (UAS). . . 10
6.5. Procedures at a Trusted User Agent Server (UAS) . . . . 11
6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 11
7. P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11
7.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Procedures at an Untrusted User Agent Client (UAC). . . 14
7.3. Procedures at a Trusted User Agent Client (UAC) . . . . 14
7.4. Procedures at an Untrusted User Agent Server (UAS). . . 15
7.5. Procedures at a Trusted User Agent Server (UAS) . . . . 15
7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 16
7.6.1. Procedures at Originating Proxy . . . . . . . . 16
7.6.2. Procedures at Terminating Proxy . . . . . . . . 17
7.6.3. Procedures at Tandem Proxy. . . . . . . . . . . 18
8. P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18
8.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Procedures at an Untrusted User Agent Client (UAC). . . 20
8.3. Procedures at a Trusted User Agent Client (UAC) . . . . 20
8.4. Procedures at an Untrusted User Agent Server (UAS). . . 21
8.5. Procedures at a Trusted User Agent Server (UAS) . . . . 21
8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 21
8.6.1. Procedures at Originating Proxy . . . . . . . . 22
8.6.2. Procedures at Terminating Proxy . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References. . . . . . . . . . . . . . . . . . 25
12.2. Informative References. . . . . . . . . . . . . . . . . 26
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
The SIP extensions described in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally not applicable in the Internet as a whole. The use of these headers is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required, as in for example the architecture presented in [6]. Use outside such a domain could result in the leakage of potentially sensitive or private information. User consent to the privacy implications of the policies in [6] is strongly encouraged in those domains as well.
このドキュメントで説明されているSIP拡張機能は、ネットワークトポロジ、SIPと下層の間のリンク、および推移的信頼の可用性に関する特定の仮定を行います。これらの仮定は、一般的にインターネット全体に適用されません。これらのヘッダーの使用は、閉鎖された管理ドメイン内、または[6]で提示されたアーキテクチャのように、充電やその他の機能の調整が必要な以前に合意したポリシーを備えた管理ドメインの連合にのみ適用されます。そのようなドメインの外部で使用すると、潜在的に機密情報または個人情報が漏れている可能性があります。[6]のポリシーのプライバシーへの影響に対するユーザーの同意は、これらのドメインでも強く奨励されています。
Although RFC 2119 language is used in this document, the scope of the normative language is only for the area of applicability of the document and, like the technology, it does not apply to the general Internet.
このドキュメントではRFC 2119言語が使用されていますが、規範的言語の範囲はドキュメントの適用可能性の領域のみであり、テクノロジーと同様に、一般的なインターネットには適用されません。
In order to deploy a SIP-based [2] residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys billing information and expectations about the parties involved in the call.
SIPベースの[2]住宅用電話サービスを異なるドメインで非常に大規模に展開するには、異なるサービスプロバイダーが所有する信頼できる要素が、コールに関係する当事者に関する請求情報と期待を伝える信頼できる情報を交換する必要があります。。
There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.
今日、テレフォニーサービスから収益を得るのに多くの請求モデルが使用されています。テレフォニーサービスの充電は、ネットワークリソースの使用と密接に結びついています。これらの多数のさまざまな方法の詳細を議論するのは、このドキュメントの範囲外です。
A key motivating principle of the DCS architecture described in [6] is the need for network service providers to be able to control and monitor network resources; revenue may be derived from the usage of these resources as well as from the delivery of enhanced services such as telephony. Furthermore, the DCS architecture recognizes the need for coordination between call signaling and resource management. This coordination ensures that users are authenticated and authorized before receiving access to network resources and billable enhanced services.
[6]で説明されているDCSアーキテクチャの重要な動機付けの原則は、ネットワークサービスプロバイダーがネットワークリソースを制御および監視できる必要性です。収益は、これらのリソースの使用と、テレフォニーなどの強化されたサービスの提供から得られる場合があります。さらに、DCSアーキテクチャは、コールシグナルとリソース管理の間の調整の必要性を認識しています。この調整により、ネットワークリソースへのアクセスと請求可能な拡張サービスへのアクセスを受信する前に、ユーザーが認証および承認されます。
DCS Proxies, as defined in [6], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connectivity and resource policy enforcement mechanism and also capture and report network connectivity and resource usage information. Edge routers need to be given billing information that can be logged with Record Keeping or Billing servers. The DCS Proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among DCS Proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call. See [6] for a description of the trust boundary and trusted versus untrusted entities.
[6]で定義されているDCSプロキシは、サブスクライバー情報にアクセスでき、コールシグナリングパスに沿ってポリシー決定ポイントと信頼できる仲介者として機能します。エッジルーターは、ネットワーク接続とリソースポリシーの実施メカニズムを提供し、ネットワークの接続性とリソース使用情報をキャプチャおよび報告します。エッジルーターには、レコード保持または請求サーバーで記録できる請求情報を提供する必要があります。DCSプロキシは、コールシグナル伝達とリソース管理の間の調整の中心的なポイントとして、呼び出しおよび呼び出されたパーティーの認証されたアイデンティティに基づいてこの情報を提供できます。DCSプロキシ間に信頼関係があるため、電話に関与する当事者に関する信頼できる請求情報を交換することに頼ることができます。信頼の境界と信頼性と信頼されていないエンティティの説明については、[6]を参照してください。
For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. It is the intent that the extensions would only appear on trusted network segments, should be inserted upon entering a trusted network region, and removed before leaving trusted network segments.
これらの理由から、SIPヘッダー拡張機能を定義して、DCSプロキシがコールセットアップ中に情報を交換できるようにすることを検討することが適切です。拡張機能は、信頼できるネットワークセグメントにのみ表示され、信頼できるネットワーク領域に入ると挿入され、信頼できるネットワークセグメントを離れる前に削除する必要があります。
Significant amounts of information is retrieved by an originating DCS Proxy in its handling of a connection setup request from a user agent. Such information includes location information about the subscriber (essential for emergency services calls), billing information, and station information (e.g., coin operated phone). In addition, while translating the destination number, information such as the local-number-portability office code is obtained and will be needed by all other proxies handling this call.
ユーザーエージェントからの接続セットアップリクエストの処理において、発信されるDCSプロキシによってかなりの量の情報が取得されます。このような情報には、サブスクライバーに関する位置情報（緊急サービスコールに不可欠）、請求情報、およびステーション情報（コイン運用電話など）が含まれます。さらに、宛先番号を翻訳している間、ローカル番号のポータブルオフィスコードなどの情報が取得され、この呼び出しを処理する他のすべてのプロキシが必要になります。
For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.
使用する会計記録のために、コール用に作成されたすべてのイベントレコードに関連付けられる識別子を持つ必要があります。SIP Call-IDヘッダーフィールドは、発信元のユーザーエージェントによって選択されているため、そのような識別子として使用することはできません。また、過去の呼び出しや現在の呼び出しの中で一意ではない場合があります。さらに、この識別子はサービスプロバイダーが使用するため、サービスプロバイダーのニーズを満たす方法で選択する必要があります。
Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split-charging where multiple entities are billed for portions of the call.
請求情報は、必ずしも各ユーザーにとって一意ではない場合があります（オフィスからの呼び出しの場合はすべて同じアカウントに請求されます）。請求情報は、単一のユーザーが行ったすべての通話に対して必ずしも同一ではない場合があります（プリペイドコール、クレジットカード通話、コールコールなどを検討してください）。したがって、通話および呼び出された当事者の識別とは別に請求情報を携帯する必要があります。さらに、一部の請求モデルでは、コールの一部に対して複数のエンティティが請求される場合、スプリットチャージを求めています。
The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.
SIP一般ヘッダーフィールドを追加することで、請求情報をキャプチャし、コール期間中に請求書の識別が可能になります。
It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a DCS Proxy in INVITE and REFER requests and INVITE responses in a trusted network segment, and removed before leaving trusted network segments.
請求拡張機能は、信頼できるネットワークセグメントにのみ表示されることを目的としており、信頼できるネットワークセグメントでリクエストと招待対応を招待して参照して紹介するDCSプロキシによって挿入され、信頼できるネットワークセグメントを離れる前に削除されます。
In addition to support for billing, current residential telephone service includes the need for customer originated trace (of harassing or obscene calls), for operator services such as busy line verification and emergency interrupt (initiated by an operator from an Operator Services Position System (OSPS)), for emergency services such as 9-1-1 calls to a Public Service Access Point (PSAP) and the subsequent call handling, and support for Electronic Surveillance and Law Enforcement access as required by applicable legislation and court orders. In all of these cases, additional information about the call and about the subscribers involved in the call needs to be exchanged between the proxies.
請求のサポートに加えて、現在の住宅用電話サービスには、ビジーライン検証や緊急中割り込みなどのオペレーターサービス（オペレーターサービスポジションシステムのオペレーターによって開始された顧客起源のトレース（嫌がらせまたはわいせつコール）の必要性が含まれます（OSPS（OSPS）））、公共サービスアクセスポイント（PSAP）への9-1-1コールなどの緊急サービスの場合、およびその後のコール処理、および該当する法律および裁判所命令で要求される電子監視と法執行機関のアクセスのサポート。これらのすべてのケースでは、コールに関する追加情報とコールに関与する加入者に関する追加情報は、プロキシ間で交換する必要があります。
The DCS architecture [6] defines a trust boundary around the various systems and servers that are owned, operated by, and/or controlled by the service provider. These trusted systems include the proxies and various servers such as bridge servers, voicemail servers, announcement servers, etc. Outside of the trust boundary lie the customer premises equipment, and various application and media servers operated by third-party service providers.
DCSアーキテクチャ[6]は、サービスプロバイダーによって所有、運用、および/または制御されるさまざまなシステムおよびサーバーの周りの信頼境界を定義します。これらの信頼できるシステムには、ブリッジサーバー、ボイスメールサーバー、アナウンスサーバーなどのプロキシやさまざまなサーバーが含まれます。トラスト境界の外側には、サードパーティのサービスプロバイダーが運営するさまざまなアプリケーションおよびメディアサーバーがあります。
Certain subscriber-specific information, such as billing and accounting information, stays within the trust boundary. Other subscriber-specific information, such as endpoint identity, may be presented to untrusted endpoints or may be withheld based on subscriber profiles.
請求や会計情報などの特定の加入者固有の情報は、信託境界内にとどまります。エンドポイントIDなどのその他の加入者固有の情報は、信頼されていないエンドポイントに提示されるか、サブスクライバープロファイルに基づいて差し控えられる場合があります。
The User Agent (UA) may be either within the trust boundary or outside the trust boundary, depending on exactly what function is being performed and exactly how it is being performed. Accordingly, the procedures followed by a User Agent are different depending on whether the UA is within the trust boundary or outside the trust boundary.
ユーザーエージェント（UA）は、実行されている機能とその実行方法を正確に正確に異なります。したがって、UAが信託境界内にあるのか、信託境界の外側にあるのかによって、ユーザーエージェントがそれに続く手順は異なります。
The following sections giving procedures for User Agents therefore are subdivided into trusted user agents and untrusted user agents.
したがって、ユーザーエージェントの手順を示す次のセクションは、信頼できるユーザーエージェントと信頼されていないユーザーエージェントに細分されます。
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 BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
The term "private-URL" used in this document refers to a SIP URI that is generated by a proxy, contains a "hostport" that identifies the proxy, and contains a "userinfo" string that is generated by the proxy. The "userinfo" typically contains (or points to) information that is not to be disclosed outside the trusted domain of the proxies, such as billing account numbers, electronic surveillance indication, electronic surveillance parameters, and call redirection information. Consequently, the information is either stored locally by the proxy, or encrypted with a private key known only to the proxy and encoded in a character string in the "userinfo" portion of the URL. A checksum is included in the "userinfo" data to detect tampering. The mechanism by which a proxy recognizes a "userinfo" as a private-URL and decodes and recovers the original information is local to the proxy and is not subject to standardization. Some possible implementations include an initial magic cookie (e.g., z9hG4Bk followed by the pointer/information), or use of a reserved "user" name (e.g., "private") with the optional "password" containing the pointer/information.
このドキュメントで使用されている「プライベートURL」という用語は、プロキシによって生成されるSIP URIを指し、プロキシを識別する「ホストポート」を含み、プロキシによって生成される「userinfo」文字列が含まれています。「userInfo」には、通常、請求勘定番号、電子監視適応、電子監視パラメーター、コールリダイレクト情報など、プロキシの信頼できるドメインの外で開示されない情報が含まれています（またはポイント）。したがって、情報はプロキシによってローカルに保存されるか、プロキシのみに知られている秘密鍵で暗号化され、URLの「userInfo」部分の文字文字列にエンコードされます。チェックサムは、改ざんを検出するために「userinfo」データに含まれています。プロキシが「userinfo」をprivate-urlとして認識し、元の情報がプロキシにローカルであり、標準化の対象ではないメカニズム。いくつかの可能な実装には、ポインター/情報を含むオプションの「パスワード」を備えた予約された「ユーザー」名（例えば、「プライベート」）の予約された「ユーザー」名（「プライベート」）の使用（ポインター/情報が続くZ9HG4BKなど）が含まれます。
In the telephone network, calling identity information is used to support regulatory requirements such as the Customer Originated Trace service, which provide the called party with the ability to report obscene or harassing phone calls to law enforcement. This service is provided independently of caller-id, and works even if the caller requested anonymity. The calling party is here identified as the station originating the call. In order for this service to be dependable, the called party must be able to trust that the calling identity information being presented is valid. One way to achieve this is described in [10].
電話ネットワークでは、ID情報の呼び出しは、顧客起源のTrace Serviceなどの規制要件をサポートするために使用されます。このトレースサービスは、呼び出された当事者に、法執行機関にわいせつまたは嫌がらせを報告する能力を提供します。このサービスは、発信者IDとは独立して提供され、発信者が匿名性を要求したとしても機能します。ここでは、召し当事者は、コールを発信するステーションとして特定されています。このサービスが信頼できるためには、呼び出された当事者は、提示されている呼び出しのアイデンティティ情報が有効であることを信頼できなければなりません。これを達成する1つの方法は、[10]に記載されています。
To initiate a customer-originated-trace from an untrusted UAC, an additional header is defined for the INVITE request. This header is called P-DCS-Trace-Party-ID, and does not appear in any other request or response. The entity addressed by the Request-URI performs the service-provider-specific functions of recording and reporting the caller identity in the P-DCS-Trace-Party-ID for law enforcement action. It then forwards the call to either an announcement server or to the service-provider's business office to collect further information about the complaint. A trusted UAC does not use this header, as it initiates this action locally.
信頼されていないUACから顧客に起因するトレースを開始するために、招待リクエスト用に追加のヘッダーが定義されています。このヘッダーはP-DCS-TRACE-PARTY-IDと呼ばれ、他のリクエストや応答には表示されません。Request-URIによって扱われるエンティティは、法執行措置のためにP-DCS-Trace-Party-IDの発信者IDの記録と報告のサービスプロバイダー固有の機能を実行します。次に、アナウンスサーバーまたはサービスプロバイダーのビジネスオフィスのいずれかに通話を転送して、苦情に関するさらなる情報を収集します。信頼できるUACは、このアクションをローカルで開始するため、このヘッダーを使用しません。
The ABNF description of this header is (some terms used in this ABNF are defined in [2]):
このヘッダーのABNF説明は（このABNFで使用されるいくつかの用語は[2]で定義されています）：
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
p-dcs-trace-party-id = "p-dcs-trace-party-id" hcolon name-addr
This document adds the following entry to Table 2 of [2]:
このドキュメントは、次のエントリを[2]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
The addr-spec contained in name-addr contains a URL that identifies the remote endpoint. Addr-spec typically contains a tel: URL or SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that established the session to be traced.
name-addrに含まれるaddr-specには、リモートエンドポイントを識別するURLが含まれています。ADDR-Specには、通常、Tel：URLまたはSIP URIが含まれています。これは、セッションを確立するシグナリングメッセージに記載されているように、リモートエンドポイントの身元を示します。
The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The UAC MUST use a SIP URI in the Request-URI with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA.
UACは、P-DCS-TRACE-PARTY-IDヘッダーを顧客オリジネートされたTRACEリクエストの最初の招待メッセージに挿入する必要があります。UACは、userInfoを「コールトレース」に設定し、信頼されていないUAのコールトレースエンティティを識別するHOSTPORTを使用して、Request-URIでSIP URIを使用する必要があります。
A trusted UAC performs the customer-originated-trace in a manner similar to the trusted UAS, described below. A trusted UAC MUST NOT include this header in any request.
信頼できるUACは、以下で説明する信頼できるUASと同様の方法で顧客に由来するトレースを実行します。信頼できるUACは、このヘッダーをいかなる要求に含めてはなりません。
This header MUST NOT appear in any response sent by a UAS.
このヘッダーは、UASから送信された応答に表示されてはなりません。
If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" and hostport set to the UAS, the UAS MUST perform the service-provider-specific functions of recording and reporting the caller identity for law enforcement action. The UAS then MUST redirect the call, via a 3xx response, to either an announcement server or to the service-provider's business office to collect further information about the complaint.
P-DCS-TRACE-PARTY-IDヘッダーがUACからの最初の招待要求に存在し、招待のリクエスト-URIがuserInfoを「call-trace」に設定し、uasに設定した場合、UASはUASに設定されている場合法執行措置のために発信者の身元を記録および報告するサービスプロバイダー固有の機能を実行します。その後、UASは、3XX応答を介して、アナウンスサーバーまたはサービスプロバイダーの営業所に通話をリダイレクトして、苦情に関するさらなる情報を収集する必要があります。
This header MUST NOT appear in any response sent by a UAS.
このヘッダーは、UASから送信された応答に表示されてはなりません。
Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
2セットのプロキシ手順が定義されています。（1）発信元のプロキシでの手順、および（2）終端プロキシでの手順。発信元のプロキシは、トラストされていないエンドポイントから招待リクエストを受け取ったプロキシです。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
終了プロキシは、招待状リクエストを非信頼性エンドポイントに送信するプロキシです。
A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to an untrusted endpoint, performs both sets of procedures.
どちらも信頼できないエンドポイントから招待リクエストを受信し、信頼できないエンドポイントに招待リクエストを送信するプロキシは、両方のプロシージャを実行します。
If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace" and hostport set to other than a potentially provisioned call tracing entity, then the Proxy MAY reject the request, or MAY remove the P-DCS-Trace-Party-ID header from the request. If the header is present in a valid request, and contains a private-URL that identifies the Proxy in the hostport, then the Originating Proxy SHOULD replace the private-URL with its original contents (i.e., the verified identity of the caller of the session that is being traced).
P-DCS-TRACE-PARTY-IDヘッダーがUACからの最初の招待リクエストに存在し、招待のリクエスト-URIが「call-trace」以外のuserInfoを持っている場合エンティティをトレースすると、プロキシはリクエストを拒否するか、P-DCS-Trace-Party-IDヘッダーをリクエストから削除する場合があります。ヘッダーが有効なリクエストに存在し、ホストポートのプロキシを識別するプライベートURLを含む場合、発信元のプロキシはプライベートURLを元のコンテンツ（つまり、セッションの発信者の確認されたアイデンティティを置き換える必要があります。それは追跡されています）。
This header MUST NOT appear in any request or response sent by a terminating proxy to an untrusted endpoint.
このヘッダーは、プロキシの終了によって送信されたリクエストまたは応答で、信頼できないエンドポイントに表示されてはなりません。
Some calls have special call processing requirements that may not be satisfied by normal user agent call processing. For example, when a user is engaged in a call and another call arrives, such a call might be rejected with a busy indication. However, some PSTN operator services require special call processing. In particular, the Busy Line Verification (BLV) and Emergency Interrupt (EI) services initiated by an operator from an Operator Services Position System (OSPS) on the PSTN network have such a need. Similarly, emergency calls to a 9-1-1 Public Service Access Point (PSAP) may result in trunk signaling causing operator ringback using a howling tone or sustained ring on the originating line (country-specific variations may exist).
一部のコールには、通常のユーザーエージェントコール処理では満たされない特別なコール処理要件があります。たとえば、ユーザーが通話に従事し、別のコールが到着すると、そのような電話が忙しい兆候で拒否される可能性があります。ただし、一部のPSTNオペレーターサービスには、特別なコール処理が必要です。特に、PSTNネットワーク上のオペレーターサービスポジションシステム（OSPS）からオペレーターによって開始されたビジーライン検証（BLV）および緊急割り込み（EI）サービスには、そのようなニーズがあります。同様に、9-1-1の公共サービスアクセスポイント（PSAP）への緊急コールにより、トランクシグナル伝達が発生する可能性があります。
In order to inform the SIP user agent that special treatment should be given to a call, we use a new P-DCS-OSPS header field, which may be set to a value indicating when a special type of call processing is requested. We define three values in this header, namely "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (e.g., howling/sustained tone ring in the US).
SIPユーザーエージェントに特別な治療を呼び出しに行う必要があることを通知するために、新しいP-DCS-OSPSヘッダーフィールドを使用します。これは、特別なタイプのコール処理が要求されるときを示す値に設定できます。このヘッダーの3つの値、すなわちビジーライン検証用の「BLV」、緊急中割り込みの「EI」、オペレーターのリングバックの「リング」（たとえば、米国のハウリング/持続的なトーンリング）を定義します。
If the user agent decides to honor such a request, the response of the user agent to an INVITE with either "BLV" or "EI" will not be a busy indication. Since "EI" and "RING" only occur on established dialogs, they may also appear in UPDATE requests.
ユーザーエージェントがそのようなリクエストを尊重することを決定した場合、ユーザーエージェントの「BLV」または「EI」のいずれかの招待への応答は忙しい兆候ではありません。「EI」と「リング」は確立されたダイアログでのみ発生するため、更新リクエストにも表示される場合があります。
The ABNF description of the P-DCS-OSPS header is as follows (some terms used in this ABNF are defined in [2]):
P-DCS-OSPSヘッダーのABNF説明は次のとおりです（このABNFで使用されるいくつかの用語は[2]で定義されています）：
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag
OSPS-Tag = "BLV" / "EI" / "RING" / token
This document adds the following entry to Table 2 of [2]:
このドキュメントは、次のエントリを[2]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - o -
The OSPS-Tag value of "token" is defined for extensibility, and is reserved for future use.
「トークン」のOSPSタグ値は、拡張性のために定義されており、将来の使用のために予約されています。
The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted UAC.
P-DCS-OSPSヘッダーは、信頼されていないUACからのリクエストで送信されてはなりません。
This header is typically only inserted by a Media Gateway Controller [6] that is controlling a Media Gateway with special trunks to a PSTN OSPS system or PSAP. This trunk group is usually referred to as a BLV-trunk group and employs special signaling procedures that prevent inadvertent use. Calls originating at the PSTN OSPS system are sent over this trunk group, and result in an INVITE request with the P-DCS-OSPS header.
このヘッダーは、通常、PSTN OSPSシステムまたはPSAPに特別なトランクを備えたメディアゲートウェイを制御しているメディアゲートウェイコントローラー[6]によってのみ挿入されます。このトランクグループは通常、BLV-Trunkグループと呼ばれ、不注意な使用を妨げる特別なシグナル伝達手順を採用しています。PSTN OSPSシステムで発信される呼び出しは、このトランクグループに送信され、P-DCS-OSPSヘッダーの招待リクエストが行われます。
This header MAY be sent in an INVITE request, and MUST NOT appear in any message other than those listed below.
このヘッダーは招待状リクエストで送信される場合があり、以下にリストされているもの以外のメッセージに表示されてはなりません。
OSPS-Tag value "BLV" MUST NOT appear in any request or response other than an initial INVITE request establishing a new dialog.
OSPS-TAG値「BLV」は、新しいダイアログを確立する最初の招待リクエスト以外のリクエストまたは応答に表示されてはなりません。
OSPS-Tag value "EI" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a pre-existing dialog established with the OSPS-Tag value of "BLV".
OSPS-TAG値「EI」は、（1）「BLV」のOSPSタグ値で確立された既存のダイアログ内の後続の招待、または（2）内の更新リクエストで確立されたダイアログ内のその後の招待状に表示されてはなりません。「BLV」のOSPSタグ値で確立された既存のダイアログ。
OSPS-Tag value "RING" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a pre-existing dialog established by a UAC to an operator or PSAP.
OSPS-TAG値「リング」は、（1）オペレーターまたはPSAPへのUACによって確立された既存のダイアログ内の後続の招待状、または（2）事前の更新リクエストを以外のリクエストまたは応答に表示してはなりません。UACによってオペレーターまたはPSAPに確立された既存のダイアログ。
If the UAS receives an INVITE request with an OSPS-Tag of "BLV", dialog identification that matches an existing dialog, and the existing call was not established with the OSPS-Tag, it MUST reject the request with a 403-Forbidden error code.
UASが「BLV」のOSPSタグで招待リクエストを受信し、既存のダイアログと一致するダイアログ識別、および既存の呼び出しがOSPS-TAGで確立されなかった場合、403浸透エラーコードでリクエストを拒否する必要があります。
If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value of "EI" or "RING", with dialog identification that does not match an existing dialog, it MUST reject the request with a 403-Forbidden response code.
UASが、既存のダイアログと一致しないダイアログ識別を使用して、「EI」または「リング」のOSPSタグ値を持つ招待/更新リクエストを受信した場合、403戸産の応答コードでリクエストを拒否する必要があります。
If the UAS receives an INVITE that contains an OSPS-Tag value of "BLV" and is not willing to cooperate in offering this service, it MUST reject the request with a 403-Forbidden response code.
UASが「BLV」のOSPSタグ値を含む招待状を受け取り、このサービスの提供に協力する意思がない場合、403戸惑った応答コードでリクエストを拒否する必要があります。
The UAS SHOULD NOT reject an INVITE with a BLV OSPS-Tag due to a busy condition. The UAS MUST NOT respond with a 3xx-Redirect response code to an INVITE with a BLV OSPS-Tag. The UAS SHOULD NOT alert the user of the incoming call attempt if the BLV OSPS-Tag is present in the INVITE.
UASは、忙しい状態のためにBLV OSPSタグで招待を拒否すべきではありません。UASは、BLV OSPS-TAGを使用した招待への3XXリダイレクト応答コードで応答してはなりません。UASは、BLV OSPSタグが招待状に存在する場合、着信コールの試行についてユーザーに警告すべきではありません。
If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all QoS pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port given in the SDP of the INVITE. The UAS MAY perform a mixing operation between the two ends of an existing active call and send the resulting media stream to the address and port indicated. Alternatively, the UAS MAY send a copy of the local voice stream, and (if no activity on the local voice stream) send a copy of the received voice stream of an existing call. If the state of the UAS is idle, the UAS SHOULD send a stream of silence packets to OSPS. If the state of the UAS is ringing or ringback, the UAS SHOULD send a ringback stream to OSPS.
「BLV」のOSPSタグの招待状が受け入れられた場合（たとえば、すべてのQOの事前条件を満たすなど）、UASは招待のSDPに与えられたアドレスとポートにこの接続でオーディオストリームを送信する必要があります。UASは、既存のアクティブコールの両端間に混合操作を実行し、結果のメディアストリームを指定されたアドレスとポートに送信する場合があります。あるいは、UASはローカル音声ストリームのコピーを送信し、（ローカルボイスストリームにアクティビティがない場合）既存の呼び出しの受信した音声ストリームのコピーを送信する場合があります。UASの状態がアイドル状態の場合、UASは沈黙のパケットのストリームをOSPSに送信する必要があります。UASの状態が鳴っているか、リングバックがある場合、UASはOSPSにリングバックストリームを送信する必要があります。
If an INVITE/UPDATE with OSPS-Tag of "EI" is accepted, the UAS MUST enable communication between the UAC and the local user. The UAS MAY put any existing call on hold, or initiate an ad-hoc conference.
「EI」のOSPSタグを使用した招待/更新が受け入れられた場合、UASはUACとローカルユーザー間の通信を有効にする必要があります。UASは、既存の呼び出しを保留にするか、アドホック会議を開始する場合があります。
If an INVITE/UPDATE with OSPS-Tag of "RING" is accepted, the UAS MUST perform operator ringback in accordance with local procedures, e.g., generate a 3-second howling tone or a sustained ring, depending on the state of the user equipment.
「リング」のOSPSタグを招待/更新する場合、UASはローカル手順に従ってオペレーターのリングバックを実行する必要があります。たとえば、ユーザー機器の状態に応じて、3秒のハウリングトーンまたは持続リングを生成する必要があります。。
The procedures at a trusted UAS MUST be identical to those described in 6.4.
信頼できるUASでの手順は、6.4に記載されているものと同一でなければなりません。
In the DCS architecture, the OSPS is considered a trusted UAC. If a proxy receives a P-DCS-OSPS header in a request from an untrusted source, it MUST either remove the header or reject the request with a 403-Forbidden response.
DCSアーキテクチャでは、OSPSは信頼できるUACと見なされています。プロキシが信頼されていないソースからのリクエストでP-DCS-OSPSヘッダーを受信した場合、ヘッダーを削除するか、403戸外の応答でリクエストを拒否する必要があります。
A proxy that implements a call-forwarding service MUST NOT respond to an INVITE request with a 3xx response, if the request contained the P-DCS-OSPS header.
リクエストにP-DCS-OSPSヘッダーが含まれている場合、コールフォードサービスを実装するプロキシは、3XX応答で招待リクエストに応答してはなりません。
There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.
今日、テレフォニーサービスから収益を得るのに多くの請求モデルが使用されています。テレフォニーサービスの充電は、ネットワークリソースの使用と密接に結びついています。これらの多数のさまざまな方法の詳細を議論するのは、このドキュメントの範囲外です。
Proxies have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connection and resource policy enforcement mechanism and also capture and report network connection and resource usage information. Edge routers need to be given billing information that can be logged with Record Keeping or Billing servers. The proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call.
プロキシはサブスクライバー情報にアクセスし、コールシグナリングパスに沿ってポリシー決定ポイントと信頼できる仲介者として機能します。エッジルーターは、ネットワーク接続とリソースポリシーの実施メカニズムを提供し、ネットワーク接続とリソースの使用情報をキャプチャおよび報告します。エッジルーターには、レコード保持または請求サーバーで記録できる請求情報を提供する必要があります。コールシグナルとリソース管理の間の調整の中心的なポイントとしてのプロキシは、呼び出しと呼び出しのパーティーの認証されたアイデンティティに基づいてこの情報を提供できます。プロキシ間に信頼関係があるため、彼らは電話に関係する当事者に関連する信頼できる請求情報を交換することに頼ることができます。
For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.
使用する会計記録のために、コール用に作成されたすべてのイベントレコードに関連付けられる識別子を持つ必要があります。SIP Call-IDヘッダーフィールドは、発信元のユーザーエージェントによって選択されているため、そのような識別子として使用することはできません。また、過去の呼び出しや現在の呼び出しの中で一意ではない場合があります。さらに、この識別子はサービスプロバイダーが使用するため、サービスプロバイダーのニーズを満たす方法で選択する必要があります。
Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split-charging where multiple entities are billed for portions of the call.
請求情報は、必ずしも各ユーザーにとって一意ではない場合があります（オフィスからの呼び出しの場合はすべて同じアカウントに請求されます）。請求情報は、単一のユーザーが行ったすべての通話に対して必ずしも同一ではない場合があります（プリペイドコール、クレジットカード通話、コールコールなどを検討してください）。したがって、通話および呼び出された当事者の識別とは別に請求情報を携帯する必要があります。さらに、一部の請求モデルでは、コールの一部に対して複数のエンティティが請求される場合、スプリットチャージを求めています。
The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.
SIP一般ヘッダーフィールドを追加することで、請求情報をキャプチャし、コール期間中に請求書の識別が可能になります。
It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a proxy or trusted UA in INVITE requests in a trusted network segment, and removed before leaving trusted network segments. The P-DCS-Billing-Info header extension is used only on requests and responses between proxies and trusted User Agents. It is never sent to, nor sent by, an untrusted UA.
請求拡張機能は信頼できるネットワークセグメントにのみ表示され、信頼できるネットワークセグメントの招待リクエストでプロキシまたは信頼できるUAによって挿入され、信頼できるネットワークセグメントを離れる前に削除することが意図されています。P-DCS-Billing-INFOヘッダー拡張機能は、プロキシと信頼できるユーザーエージェント間のリクエストと応答に従ってのみ使用されます。信頼されていないUAに送られたり、送信されたりすることはありません。
The DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [2]):
DCS-BILLING-INFOヘッダーは、次のABNFによって定義されます（このABNFで使用されるいくつかの用語は[2]で定義されています）：
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON
Billing-Correlation-ID "/" FEID
*(SEMI Billing-Info-param)
Billing-Correlation-ID = 1*48(HEXDIG)
FEID = 1*16(HEXDIG) "@" host
Billing-Info-param = RKS-Group-ID-param / Charge-param /
Calling-param / Called-param /
Routing-param / Loc-Routing-param /
generic-param
RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID
RKS-Group-ID = token
Charge-param = "charge" EQUAL Acct-Charge-URI
Acct-Charge-URI = LDQUOT addr-spec RDQUOT
Calling-param = "calling" EQUAL Acct-Calling-URI
Acct-Calling-URI = LDQUOT addr-spec RDQUOT
Called-param = "called" EQUAL Acct-Called-URI
Acct-Called-URI = LDQUOT addr-spec RDQUOT
Routing-param = "routing" EQUAL Acct-Routing-URI
Acct-Routing-URI = LDQUOT addr-spec RDQUOT
Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI
Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT
This document adds the following entry to Table 2 of [2]:
このドキュメントは、次のエントリを[2]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
The P-DCS-Billing-Info extension contains an identifier that can be used by an event recorder to associate multiple usage records, possibly from different sources, with a billable account. It further contains the subscriber account information, and other information necessary for accurate billing of the service. This header is only used between proxies and trusted User Agents.
P-DCS-BILLING-INFO拡張機能には、イベントレコーダーが使用して、おそらく異なるソースからの複数の使用記録を請求可能なアカウントで関連付けることができる識別子が含まれています。さらに、サブスクライバーアカウント情報と、サービスの正確な請求に必要なその他の情報が含まれています。このヘッダーは、プロキシと信頼できるユーザーエージェントの間でのみ使用されます。
The Billing-Correlation-ID is specified in [9] as a 24-byte binary structure, containing 4 bytes of NTP timestamp, 8 bytes of the unique identifier of the network element that generated the ID, 8 bytes giving the time zone, and 4 bytes of monotonically increasing sequence number at that network element. This identifier is chosen to be globally unique within the system for a window of several months. This MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 48 characters. Leading zeroes MAY be suppressed.
請求相関IDは、[9]で4バイトのバイナリ構造として指定されており、4バイトのNTPタイムスタンプ、IDを生成したネットワーク要素の一意の識別子の8バイト、タイムゾーンを与えた8バイト、およびタイムゾーンを与え、そのネットワーク要素で4バイトの単調に増加するシーケンス番号。この識別子は、数か月のウィンドウのためにシステム内でグローバルにユニークになるように選択されます。これは、最大48文字の16進文字列として、P-DCS-Billing-INFOヘッダーでエンコードする必要があります。先行ゼロは抑制される場合があります。
The Financial-Entity-ID (FEID) is specified in [9] as an 8-byte structure, containing the financial identifier for that domain, followed by a domain name. FEID can be associated with a type of service and could be assigned to multiple domains by the same provider. A domain could contain multiple assigned FEIDs. This 8- byte structure MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 16 characters. Trailing zeroes MAY be suppressed. "Host" contains the domain name.
Financial-Entity-ID（FEID）は、[9]で8バイト構造として指定されており、そのドメインの財務識別子を含み、その後にドメイン名が続きます。Feidは、タイプのサービスに関連付けられ、同じプロバイダーによって複数のドメインに割り当てることができます。ドメインには、割り当てられた複数のFeidsを含めることができます。この8バイト構造は、最大16文字の16進文字列として、P-DCS-Billing-INFOヘッダーでエンコードする必要があります。トレーリングゼロが抑制される場合があります。「ホスト」にはドメイン名が含まれています。
The RKS-Group-ID specifies a record keeping server (or group of cooperating servers) for event messages relating to this call. It is used to control certain optimizations of procedures when multiple event message streams are being sent to the same Record Keeping Server.
RKS-Group-IDは、この呼び出しに関連するイベントメッセージのレコードキーピングサーバー（または協力サーバーのグループ）を指定します。複数のイベントメッセージストリームが同じレコード保持サーバーに送信されている場合、手順の特定の最適化を制御するために使用されます。
Additional parameters contain the information needed for generation of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and Acct-Location-Routing-URI are each defined as URLs; they should all contain tel: URLs with E.164 formatted addresses. These fields are further defined in [9] under the element identifiers "Charge_Number" (element ID 16), "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element ID 5), "Routing Number" (element ID 25), and "Location_Routing_Number" (element ID 22).
追加のパラメーターには、イベントメッセージレコードの生成に必要な情報が含まれています。Acct-charge-uri、acct-calling-uri、acct-called-uri、acct-routing-uri、およびacct-location-routing-uriはそれぞれURLとして定義されています。それらはすべて、E.164フォーマットされたアドレスを備えたTel：URLを含める必要があります。これらのフィールドは、要素識別子「Charge_Number」（要素ID 16）、「Calling_Party_Number」（要素ID 4）、「Call_Party_Number」（要素ID 5）、「ルーティング番号」（要素ID 25）、「要素ID 4）の下で[9]でさらに定義されています。および「location_routing_number」（要素ID 22）。
This header is never sent to an untrusted UAC, and is never sent by an untrusted UAC.
このヘッダーは信頼されていないUACに送られることはなく、信頼されていないUACによって送信されることもありません。
The UAC MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The UAC MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the UAC. If the UAC performed a Local Number Portability (LNP) query, it MUST include the Routing Number and Location Routing Number returned by the query.
UACは、コール用の請求相関IDを生成し、終了プロキシに送信された最初の招待メッセージにP-DCS-BILLING INFOヘッダーに挿入する必要があります。UACには、そのFeid、およびUACが使用するレコードキーピングサーバー用のRKS-Group-IDを含める必要があります。UACがローカル番号ポータビリティ（LNP）クエリを実行した場合、クエリによって返されるルーティング番号とロケーションルーティング番号を含める必要があります。
If the response to the initial INVITE is a 3xx-Redirect, the UAC generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If a UAC receives a 3xx-Redirect response to an initial INVITE, the new INVITE generated by the UAC MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response. If the UAC is acting as a B2BUA, instead of generating a new INVITE it MAY generate a private-URL and place it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.
最初の招待への応答が3XX redirectである場合、UACは、標準SIPに従って、連絡先で指定された宛先への新しい初期招待要求を生成します。UACが最初の招待に対する3XXリダイレクト応答を受信した場合、UACによって生成された新しい招待には、3XX redirect応答からP-DCS-BILLING-INFOヘッダーを含める必要があります。UACがB2BUAとして機能している場合、新しい招待を生成する代わりに、プライベートURLを生成し、発信元エンドポイントに送信される3XXリダイレクト応答のコンタクトヘッダーに配置する場合があります。このプライベートURLは、新規コールの充電配置を示し、将来的には非常に間もなく有効期限を示すP-DCS-BILLING-INFO値を含む（またはポインターを含む）必要があります。複数の呼び出しのためにこのプライベートURLを再利用します。
A UAC that includes a Refer-to header in a REFER request MUST include a P-DCS-Billing-Info header in the Refer-to's URL. This P-DCS-Billing-Info header MUST include the accounting information of the initiator of the REFER.
参照要求に紹介ヘッダーを含むUACには、紹介のURLにP-DCS-BILLING-INFOヘッダーを含める必要があります。このP-DCS-BILLING-INFOヘッダーには、紹介のイニシエーターの会計情報を含める必要があります。
This header is never sent to an untrusted UAS, and is never sent by an untrusted UAS.
このヘッダーは信頼されていないUASに送られることはなく、信頼されていないUASによって送信されることもありません。
The UAS MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the UAS, the FEID of the UAS, and the RKS-Group-ID of the Record-Keeping-Server being used by the UAS. The UAS MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the new Acct-Charge-URI MUST be determined by service provider policy provisioned in the UAS. If the UAS performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
UASには、最初の信頼できる1XX（100を除く）または最初の招待メッセージに対する2XX応答にP-DCS-BILLING-INFOヘッダーを含める必要があります。このP-DCS-BILLING-INFOヘッダーには、UASによって生成された請求相関ID、UASのFeid、およびUASが使用するレコードキーピングサーバーのRKS-Group-IDを含める必要があります。UASは、招待状に存在する請求情報をオーバーライドしたい場合（たとえば、フリーコールの場合）、ACCT-charge-URIの値を変更する場合があります。これを行うという決定と新しいACCT-charge-URIの内容は、UASで提供されたサービスプロバイダーポリシーによって決定されなければなりません。UASがLNPクエリを実行した場合、クエリによって返されるルーティング番号とロケーションルーティング番号を含める必要があります。
The UAS MUST add a P-DCS-Billing-Info header to a 3xx-redirect response to an initial INVITE, giving the accounting information for the call forwarder, for the call segment from the destination to the forwarded-to destination.
UASは、PS-DCS-BILLING-INFOヘッダーを最初の招待への3XXレディレクト応答に追加する必要があり、宛先から転送された宛先までのコールセグメントのコールフォワーダーの会計情報を提供する必要があります。
Three sets of proxy procedures are defined: (1) the procedures at an originating proxy, (2) the procedures at a terminating proxy, and (3) the procedures at a tandem proxy.
3セットのプロキシ手順が定義されています。（1）元のプロキシでの手順、（2）終端プロキシでの手順、および（3）タンデムプロキシでの手順。
The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
発信元のプロキシは、トラストされていないエンドポイントから招待リクエストを受け取ったプロキシです。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
終了プロキシは、招待状リクエストを非信頼性エンドポイントに送信するプロキシです。
A proxy that is neither an originating proxy, nor a terminating proxy, is a tandem proxy.
プロキシのプロキシでも終了プロキシでもないプロキシは、タンデムプロキシです。
For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non-trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.
コール転送などの中間コールの変更の目的のために、トラストされていないエンドポイントからリクエストを受信するプロキシは、開始プロキシと見なされます。リクエストを非トラストエンドポイントに送信するプロキシは、受信者プロキシと見なされます。プロキシの開始手順は、プロキシの発信元の手順とともに含まれますが、受信者プロキシの手順はプロキシを終了するための手順に含まれています。
A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, performs both sets of procedures.
どちらも信頼できないエンドポイントから招待リクエストを受信し、招待状リクエストを信頼されていないエンドポイントに送信するプロキシは、両方のプロシージャを実行します。
The originating proxy MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The originating proxy MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the originating proxy. If the originating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query. Any P-DCS-Billing-Info header present from an untrusted UA MUST be removed.
発信元のプロキシは、コール用の請求相関IDを生成し、終了プロキシに送信された最初の招待メッセージにP-DCS-BILLING INFOヘッダーに挿入する必要があります。発信元のプロキシには、そのFEIDと、発信元プロキシで使用されているレコードキーピングサーバーのRKS-Group-IDを含める必要があります。発信元のプロキシがLNPクエリを実行した場合、クエリによって返されるルーティング番号とロケーションルーティング番号を含める必要があります。信頼されていないUAから存在するP-DCS-BILLING-INFOヘッダーを削除する必要があります。
If the Request-URI contains a private-URL, and the decoded username contains billing information, the originating proxy MUST generate a P-DCS-Billing-Info header with that decrypted information. Otherwise, the originating proxy MUST determine the accounting information for the call originator, and insert a P-DCS-Billing-Info header including that information.
Request-URIにプライベートURLが含まれており、デコードされたユーザー名に請求情報が含まれている場合、発信元のプロキシは、その復号化された情報を使用してP-DCS-Billing-INFOヘッダーを生成する必要があります。それ以外の場合、発信元のプロキシは、コールオリジネーターの会計情報を決定し、その情報を含むP-DCS-Billing-INFOヘッダーを挿入する必要があります。
If the response to the initial INVITE is a 3xx-Redirect, received prior to a 18x, the originating proxy generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a 18x response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response.
最初の招待への応答が18Xより前に受信された3XXレディレクトである場合、元のプロキシは、標準SIPに従って、連絡先で指定された宛先への新しい初期招待要求を生成します。発信元のプロキシが18倍の応答の前に最初の招待に対する3XXリダイレクト応答を受信する場合、プロキシによって生成された招待には、3XXレディレクト応答からP-DCS-BILLING-INFOヘッダーを含める必要があります。
If the response to the initial INVITE is a 3xx-Redirect, received after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.
最初の招待への応答が18倍後に受信された3xxリダイレクトである場合、発信元のプロキシはプライベートURLを生成し、発信元のエンドポイントに送信された3xx redirect応答のコンタクトヘッダーに配置します。このプライベートURLは、新規コールの充電配置を示すP-DCS-BILLING INFO値を含む（またはポインターを含む）（またはポインターを含む）必要があります。複数の呼び出しのためにこのプライベートURLを再利用します。
An originating proxy that processes a REFER request from an untrusted UA MUST include a P-DCS-Billing-Info header in the Refer-to's URL. This P-DCS-Billing-Info header MUST include the accounting information of the initiator.
信頼されていないUAからの紹介要求を処理する発信プロキシには、紹介のURLにP-DCS-Billing-INFOヘッダーを含める必要があります。このP-DCS-BILLING-INFOヘッダーには、イニシエーターの会計情報を含める必要があります。
The terminating proxy MUST NOT send the P-DCS-Billing-Info header to an untrusted destination.
終了プロキシは、P-DCS-BILLING-INFOヘッダーを信頼できない宛先に送信してはなりません。
The terminating proxy MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the terminating proxy, the FEID of the terminating proxy, and the RKS-Group-ID of the Record-Keeping-Server being used by the terminating proxy. The terminating proxy MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the resulting P-DCS-Billing-Info header MUST be determined by service provider policy provisioned in the terminating proxy. If the terminating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
終了プロキシには、最初の信頼できる1XX（100を除く）または最初の招待メッセージに対する2XX応答にP-DCS-BILLING-INFOヘッダーを含める必要があります。このP-DCS-BILLING-INFOヘッダーには、終了プロキシのFEID、および終了プロキシによって使用されているレコードキーピングサーバーのRKS-Group-IDによって生成された請求相関IDを含める必要があります。。終了プロキシは、招待状に存在する請求情報をオーバーライドしたい場合（たとえば、フリーダイヤルの通話など）、ACCT-charge-URIの値を変更する場合があります。これを行うという決定と、結果のP-DCS-BILLING-INFOヘッダーの内容は、終了プロキシで提供されるサービスプロバイダーポリシーによって決定されなければなりません。終了プロキシがLNPクエリを実行した場合、クエリによって返されるルーティング番号とロケーションルーティング番号を含める必要があります。
The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx-redirect response to an initial INVITE, giving the accounting information for the call forwarder, for the call segment from the destination to the forwarded-to destination.
終了プロキシは、先住民から転送された宛先までのコールセグメントのコールフォワーダーの会計情報を提供する最初の招待へのP-DCS-BILLING-INFOヘッダーを最初の招待に追加する必要があります。
A proxy receiving a mid-call REFER request that includes a Refer-to header generates a private-URL and places it in the Refer-to header sent to the endpoint. This private-URL MUST contain the P-DCS-Billing-Info value, which indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the endpoint to re-use this private-URL for multiple calls.
紹介ヘッダーを含むミッドコール参照要求を受信するプロキシは、プライベートURLを生成し、エンドポイントに送信される紹介ヘッダーに配置します。このプライベートURLには、新しいコールの充電配置を示すP-DCS-BILLING-INFO値が含まれている必要があります。複数の呼び出しのURL。
If the tandem proxy performed a LNP query, it MUST insert the Routing Number and Location Routing Number returned by the query into the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 100) response.
タンデムプロキシがLNPクエリを実行した場合、クエリによって返されたルーティング番号とロケーションルーティング番号を、最初の信頼できる1XX/2XX/3XX（100を除く）応答でP-DCS-Billing-INFOヘッダーに挿入する必要があります。
NOTE: According to RFC 2804 [5], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The RFC 2119 language, as stated above, describes the requirements of the specification only if implemented, and strictly within the applicability domain described above. See RFC 2804 for description of issues regarding privacy, security, and complexity in relation to this technology.
注：RFC 2804 [5]によると、IETFは、それを開発する必要がある場合、合法的なインターセプトテクノロジーのドキュメントをサポートしています。次のセクションでは、そのようなドキュメントを提供します。上記のように、RFC 2119言語は、実装された場合にのみ、上記の適用性ドメイン内の仕様の要件を説明しています。このテクノロジーに関連するプライバシー、セキュリティ、複雑さに関する問題の説明については、RFC 2804を参照してください。
The P-DCS-LAES extension contains the information needed to support Lawfully Authorized Electronic Surveillance. This header contains the address and port of an Electronic Surveillance Delivery Function for delivery of a duplicate stream of event messages related to this call. The header may also contain an additional address and port for delivery of call content. Security key information is included to enable pairs of Delivery Functions to securely exchange surveillance information. This header is only used between proxies and trusted User Agents.
P-DCS-LAES拡張には、合法的に認可された電子監視をサポートするために必要な情報が含まれています。このヘッダーには、この呼び出しに関連するイベントメッセージの重複ストリームを配信するための電子監視配信機能のアドレスとポートが含まれています。ヘッダーには、コールコンテンツの配信のための追加のアドレスとポートが含まれている場合があります。セキュリティキー情報が含まれており、配信機能のペアを有効にして監視情報を安全に交換します。このヘッダーは、プロキシと信頼できるユーザーエージェントの間でのみ使用されます。
The P-DCS-Redirect extension contains call identifying information needed to support the requirements of Lawfully Authorized Electronic Surveillance of redirected calls. This header is only used between proxies and trusted User Agents.
P-DCS-Redirect拡張には、リダイレクトコールの合法的に許可された電子監視の要件をサポートするために必要なコール識別情報が含まれています。このヘッダーは、プロキシと信頼できるユーザーエージェントの間でのみ使用されます。
Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination of legislation, regulation, and court orders, which MUST be followed. In certain cases inclusion of these headers will be mandated, and therefore MUST be present in the requests and responses indicated. In other cases inclusion of these headers will be forbidden, and therefore MUST NOT be present in the request and responses indicated. In the sub-sections that follow, use of "SHOULD" is intended to capture these conflicting situations, e.g., a P-DCS-LAES header SHOULD be included in an initial INVITE means either that it MUST be included or that it MUST NOT be included, based on the applicable court orders.
P-DCS-LAESおよびP-DCS-Redirectの使用は、法律、規制、および裁判所命令の組み合わせによって制御されます。特定の場合、これらのヘッダーを含めることが義務付けられているため、示されている要求と応答に存在する必要があります。他の場合には、これらのヘッダーを含めることは禁止されているため、指定された要求と応答に存在してはなりません。以下のサブセクションでは、「必要」の使用は、これらの矛盾する状況をキャプチャすることを目的としています。たとえば、P-DCS-LAESヘッダーは、それを含める必要があるか、そうでないことを最初の招待状に含める必要があります。該当する裁判所命令に基づいて含まれています。
The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by the following ABNF (some terms used in this ABNF are defined in [2] and [3]):
P-DCS-LAESおよびP-DCS-Redirectヘッダーの形式は、次のABNFによって与えられます（このABNFで使用されるいくつかの用語は[2]および[3]で定義されています）：
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig
*(SEMI Laes-param)
Laes-sig = hostport
Laes-param = Laes-content / Laes-key / generic-param
Laes-content = "content" EQUAL hostport
Laes-key = "key" EQUAL token
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(redir-params)
Called-ID = LDQUOT addr-spec RDQUOT
redir-params = redir-uri-param / redir-count-param /
generic-param
redir-uri-param = "redirector-uri" EQUAL Redirector
Redirector = LDQUOT addr-spec RDQUOT
redir-count-param = "count" EQUAL Redir-count
Redir-count = 1*DIGIT
This document adds the following entry to Table 2 of [2]:
このドキュメントは、次のエントリを[2]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - -
P-DCS-Redirect adr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
- - - - - -
The values of Laes-sig and Laes-content are addresses of the Electronic Surveillance Delivery Function, and used as the destination address for call-identifying information and call-content, respectively. Laes-key is a string generated by the proxy that is used by the Delivery Function to securely transfer information between them [8].
Laes-SigとLaes-Contentの値は、電子監視配信機能のアドレスであり、それぞれ通話識別情報とコールコンテンツの宛先アドレスとして使用されます。Laes-Keyは、配信機能によって使用されるプロキシによって生成された文字列です。
The P-DCS-Redirect header contains redirection information. The redir-uri-param indicates the original destination requested by the user (e.g., dialed number), the Redirector indicates the new destination, and the Redir-count indicates the number of redirections that have occurred.
P-DCS redirectヘッダーにはリダイレクト情報が含まれています。Redir-uri-Paramは、ユーザーが要求した元の宛先（ダイヤル番号など）を示し、リダイレクターは新しい宛先を示し、リダイヤカウントは発生したリダイレクトの数を示します。
This header MUST NOT be sent to an untrusted UAC, and MUST NOT be sent by an untrusted UAC.
このヘッダーは信頼できないUACに送られてはならず、信頼されていないUACによって送信されてはなりません。
The UAC checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).
UACは、発信元のサブスクライバーに対する未払いの合法的に承認された監視命令をチェックし、存在する場合は、サービス品質の認可[7]にこの情報を含めるか、インターセプトを実行するデバイスにこの情報を示します（例：メディアゲートウェイ）。
If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the UAC MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway).
P-DCS-LAESヘッダーが最初の信頼できる1XX（100を除く）、2XX、または3XX応答（終端サブスクライバーでサーベイランスが必要であることを示すが、終端機器がその機能を実行できないことを示す）に存在する場合、UACは必要でなければなりませんこの情報をサービス品質の許可に含めるか、この情報をインターセプトを実行するデバイスに信号を送信する必要があります（メディアゲートウェイなど）。
If a 3xx-Redirect response is received to the initial INVITE request, and if a P-DCS-LAES header is present in the 3xx response, the UAC SHOULD include that header unchanged in the reissued INVITE. The UAC SHOULD also include a P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred. Although it is technically possible for the originating equipment to perform this surveillance (or add to its existing surveillance of the call), the design of the surveillance system has the terminating equipment performing the surveillance for all the intermediate forwardings.
最初の招待リクエストに対して3XXリダイレクト応答が受信され、P-DCS-LAESヘッダーが3XX応答に存在する場合、UACは再発行された招待に変更されていないヘッダーを含める必要があります。UACには、元のダイヤル番号、新しい宛先番号、および発生したリダイレクトの数を含むP-DCSリダイレクトヘッダーも含める必要があります。発信元の機器がこの監視を実行することは技術的には可能ですが（または既存のコールの監視に追加される）、監視システムの設計には、すべての中間転送の監視を実行する終了機器があります。
A UAC that includes a Refer-to header in a REFER request, when the originating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header attached to the Refer-to. The P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.
紹介リクエストに紹介ヘッダーを含むUACは、発信元のサブスクライバーが顕著に承認された監視命令を持っている場合、紹介に接続されたP-DCS-LAESヘッダーを含める必要があります。P-DCS-LAESヘッダーには、コールのイベントメッセージのコピーのローカル電子監視配信機能の住所とポートを含める必要があります。コールコンテンツのコピーの場合、地元の電子監視配信機能の住所とポートを含める必要があります。コンテンツはインターセプトされ、配信関数間のセキュリティキーとして使用するためのランダムな文字列を含める必要があります。
The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
信頼できるUACは、P-DCS-LAESおよびP-DCS-Redirectヘッダーを信頼されていないエンティティに送信してはなりません。
This header MUST NOT be sent to an untrusted UAS, and MUST NOT be sent by an untrusted UAS.
このヘッダーは信頼できないUASに送られてはならず、信頼されていないUASによって送信されてはなりません。
The UAS checks for an outstanding lawfully authorized surveillance order for the terminating subscriber, or presence of the P-DCS-LAES header in the INVITE request. If either is present, the UAS includes this information in the authorization for Quality of Service [7].
UASは、終了サブスクライバーの未払いの合法的に承認された監視命令、または招待リクエストにおけるP-DCS-LAESヘッダーの存在をチェックします。どちらかが存在する場合、UASにはサービス品質の許可にこの情報が含まれています[7]。
If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), the UAS SHOULD include a P-DCS-LAES header in the first reliable non-100 response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.
終了機器が必要なサーベイランスを実行できない場合（例：宛先がボイスメールサーバーである場合）、UASには、監視を実行するために発生プロキシを要求する最初の信頼できる非100応答にP-DCS-LAESヘッダーを含める必要があります。P-DCS-LAESヘッダーには、コールのイベントメッセージのコピーのローカル電子監視配信機能の住所とポートを含める必要があります。コールコンテンツのコピーの場合、地元の電子監視配信機能の住所とポートを含める必要があります。コンテンツはインターセプトされ、配信関数間のセキュリティキーとして使用するためのランダムな文字列を含める必要があります。
If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the UAS SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.
最初の招待リクエストへの応答が3XXリダイレクト応答であり、終了サブスクライバーに対して優れた合法的に承認された監視命令がある場合、UASには3XXリダイレクト応答にP-DCS-LAESヘッダーを含める必要があります。上記で説明しています。
The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
信頼できるUASは、P-DCS-LAESおよびP-DCS-Redirectヘッダーを信頼されていないエンティティに送信してはなりません。
Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
2セットのプロキシ手順が定義されています。（1）発信元のプロキシでの手順、および（2）終端プロキシでの手順。発信元のプロキシは、トラストされていないエンドポイントから招待リクエストを受け取ったプロキシです。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
終了プロキシは、招待状リクエストを非信頼性エンドポイントに送信するプロキシです。
For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non-trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.
コール転送などの中間コールの変更の目的のために、トラストされていないエンドポイントからリクエストを受信するプロキシは、開始プロキシと見なされます。リクエストを非トラストエンドポイントに送信するプロキシは、受信者プロキシと見なされます。プロキシの開始手順は、プロキシの発信元の手順とともに含まれますが、受信者プロキシの手順はプロキシを終了するための手順に含まれています。
A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers.
どちらも信頼されていないエンドポイントから招待要求を受信し、招待リクエストを信頼できないエンドポイントに送信するプロキシは、P-DCS-LAESまたはP-DCS-Redirectヘッダーを生成してはなりません。
A proxy that is neither an originating proxy nor a terminating proxy SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers in requests and responses.
プロキシのプロキシでも終了プロキシでもないプロキシは、リクエストと応答でP-DCS-LAESおよびP-DCS-Redirectヘッダーを渡す必要があります。
The Originating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or untrusted UA.
発信元のプロキシは、信頼されていないプロキシまたは信頼できないUAに対するリクエストまたは応答で、P-DCS-LAESおよびP-DCS-Redirectヘッダーを削除する必要があります。
The originating proxy checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).
発信元のプロキシは、発信元のサブスクライバーの未解決の合法的に承認された監視命令をチェックし、存在する場合は、サービス品質の認可にこの情報を含め[7]、またはインターセプトを実行するデバイスにこの情報を信号します（たとえば、メディアゲートウェイなど）。
If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the originating proxy MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway).
P-DCS-LAESヘッダーが最初の信頼できる1XX（100を除く）、2XX、または3XX応答（終端サブスクライバーでサーベイランスが必要であることを示すが、終端機器がその機能を実行できないことを示す）に存在する場合、発生プロキシはこの情報をサービス品質の許可に含めるか、この情報をインターセプトを実行するデバイスに信号を送信する必要があります（メディアゲートウェイなど）。
If the Request-URI in an initial INVITE request contains a private-URL, the originating proxy MUST decrypt the userinfo information to find the real destination for the call, and other special processing information. If electronic surveillance information is contained in the decrypted userinfo, the originating proxy SHOULD generate a P-DCS-LAES header with the surveillance information.
最初の招待リクエストのリクエスト-URIにプライベートURLが含まれている場合、発信元のプロキシはuserInfo情報を復号化して、コールの実際の宛先やその他の特別な処理情報を見つける必要があります。電子監視情報が復号化されたuseriNFOに含まれている場合、発信元のプロキシは監視情報を使用してP-DCS-LAESヘッダーを生成する必要があります。
If a 3xx-Redirect response is received to the initial INVITE request prior to a 18x, and if a P-DCS-LAES header is present in the 3xx response, the originating proxy SHOULD include that header unchanged in the reissued INVITE. The originating proxy SHOULD also include a P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred.
18Xの前に3xxリダイレクト応答が最初の招待リクエストに受信され、3xx応答にP-DCS-LAESヘッダーが存在する場合、元のプロキシに再発行された招待に変更されていないヘッダーを含める必要があります。元のプロキシには、元のダイヤル番号、新しい宛先番号、および発生したリダイレクトの数を含むP-DCSレディレクトヘッダーも含める必要があります。
If a 3xx-Redirect response is received to the initial INVITE request after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. If a P-DCS-LAES header is present in the 3xx response, this private-URL MUST contain (1) the electronic surveillance information from the 3xx-Redirect response, (2) the original destination number, (3) the identity of the redirecting party, and (4) the number of redirections of this call.
18Xの後に3xxリダイレクト応答が最初の招待リクエストに受信された場合、発信元のプロキシはプライベートURLを生成し、発信元のエンドポイントに送信される3XX redirect応答のコンタクトヘッダーに配置します。P-DCS-LAESヘッダーが3XX応答に存在する場合、このプライベートURLには（1）3XX redirect応答からの電子監視情報、（2）元の宛先番号、（3）リダイレクトパーティー、および（4）この呼び出しのリダイレクトの数。
An originating proxy that processes a REFER request [4] from an untrusted UA, when the originating subscriber has an outstanding lawfully authorized surveillance order, becomes a B2BUA for that request. It SHOULD reissue the request with a P-DCS-LAES header added to the Refer-to's URL. The P-DCS-LAES header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, (2) the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and (3) a random string for use as a security key between the Delivery Functions.
信頼されていないUAからの参照要求[4]を処理する発信元のプロキシは、発信されているサブスクライバーが優れた合法的に承認された監視命令を持っている場合、その要求のB2BUAになります。参照のURLに追加されたP-DCS-LAESヘッダーでリクエストを再発行する必要があります。P-DCS-LAESヘッダーには、（1）コールのイベントメッセージのコピーのローカル電子監視配信機能の住所とポートを含める必要があります。コンテンツを呼び出すと、コンテンツがインターセプトされる場合は、（3）配信関数間のセキュリティキーとして使用するランダムな文字列。
An initiating proxy that sends a mid-call REFER request including a Refer-to header, when the initiating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header in the Refer-to's URL.
紹介ヘッダーを含むミッドコールの紹介要求を送信する開始プロキシは、開始サブスクライバーが優れた合法的に承認された監視命令を持っている場合、紹介のURLにP-DCS-LAESヘッダーを含める必要があります。
The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
発信元のプロキシは、P-DCS-LAESおよびP-DCS-Redirectヘッダーを信頼されていないエンティティに送信してはなりません。
The Terminating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or UA.
終了プロキシは、信頼されていないプロキシまたはUAに対するリクエストまたは応答で、P-DCS-LAESおよびP-DCS-Redirectヘッダーを削除する必要があります。
The terminating proxy checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. If present, the terminating proxy includes this information in the authorization for Quality of Service [7].
終了プロキシは、終了サブスクライバーの未払いの合法的に承認された監視命令をチェックします。存在する場合、終了プロキシには、サービス品質の許可にこの情報が含まれています[7]。
The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity, either as headers in the request or response, or as headers attached to URIs in the request or response.
終了プロキシは、リクエストまたは応答のヘッダーとして、またはリクエストまたは応答でURISに添付されているヘッダーとして、P-DCS-LAESおよびP-DCS-Redirectヘッダーを信頼されていないエンティティに送信してはなりません。
If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), the terminating proxy SHOULD include a P-DCS-LAES header in the first reliable 1xx/2xx/3xx (except 100) response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.
終了機器が必要な監視を実行できない場合（例：宛先がボイスメールサーバーである場合）、終了プロキシには、最初の信頼できる1XX/2XX/3XX（100を除く）応答要求のPS-DCS-LAESヘッダーを含める必要があります。監視を実行するための発生プロキシ。P-DCS-LAESヘッダーには、コールのイベントメッセージのコピーのローカル電子監視配信機能の住所とポートを含める必要があります。コールコンテンツのコピーの場合、地元の電子監視配信機能の住所とポートを含める必要があります。コンテンツはインターセプトされ、配信関数間のセキュリティキーとして使用するためのランダムな文字列を含める必要があります。
If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the terminating proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.
最初の招待リクエストへの応答が3XXリダイレクト応答であり、終了サブスクライバーに対して優れた合法的に承認された監視命令がある場合、終了プロキシには、内容のある3XXレディレクト応答にP-DCS-LAESヘッダーを含める必要があります。上記のように。
A proxy receiving a mid-call REFER request [4] that includes a Refer-to header with a P-DCS-LAES header attached becomes a B2BUA for this request. It MUST generate a private-URL and place it in the Refer-to header sent to the endpoint. This private-URL MUST contain the P-DCS-LAES information from the attached header.
Mid-Callの紹介要求[4]を受信するプロキシは、P-DCS-LAESヘッダーが添付された紹介ヘッダーを含むこのリクエストのB2BUAになります。プライベートURLを生成し、エンドポイントに送信される紹介ヘッダーに配置する必要があります。このプライベートURLには、添付のヘッダーからのP-DCS-LAES情報が含まれている必要があります。
QoS gate coordination, billing information, and electronic surveillance information are all considered to be sensitive information that MUST be protected from eavesdropping and furthermore require integrity checking. It is therefore necessary that the trusted UAs and proxies take precautions to protect this information from eavesdropping and tampering. Use of IPsec or TLS between Proxies is REQUIRED. A minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [8]. Also REQUIRED is mutual authentication (1) between Proxies and (2) between trusted UAs and Proxies, both of which MAY be implemented with administratively pre-shared keys, or through consultation with another trusted third party. If IPsec is to be used, the specification of the security policies and procedures of the administrative domain where these headers are applicable (and all connections between administrative domains in the federation) MUST define an interoperable set of options.
QoSゲートの調整、請求情報、および電子監視情報はすべて、盗聴から保護され、さらに整合性チェックが必要な機密情報であると考えられています。したがって、信頼できるUASとプロキシが、この情報を盗聴や改ざんから保護するための予防策を講じる必要があります。プロキシ間のIPSECまたはTLSの使用が必要です。DCSアーキテクチャの最低限の必須のIPSEC構成は、[8]によって与えられます。また、（1）プロキシと（2）信頼できるUASとプロキシの間の相互認証（1）と（2）どちらも、管理上恥ずかしさキーで、または別の信頼できる第三者との協議を通じて実装される場合があります。IPSECを使用する場合、これらのヘッダーが適用される管理ドメインのセキュリティポリシーと手順の指定（および連邦内の管理ドメイン間のすべての接続）は、相互運用可能なオプションセットを定義する必要があります。
This document defines a number of SIP extension headers, which have been included in the registry of SIP headers defined in [2]. Registration information for new headers is as follows:
このドキュメントでは、[2]で定義されているSIPヘッダーのレジストリに含まれている多くのSIP拡張ヘッダーを定義しています。新しいヘッダーの登録情報は次のとおりです。
Header Field Name: P-DCS-Trace-Party-ID RFC Number: 3603 Compact Form: none
ヘッダーフィールド名：P-DCS-TRACE-PARTY-ID RFC番号：3603コンパクトフォーム：なし
Header Field Name: P-DCS-OSPS RFC Number: 3603 Compact Form: none
ヘッダーフィールド名：P-DCS-OSPS RFC番号：3603コンパクトフォーム：なし
Header Field Name: P-DCS-Billing-Info RFC Number: 3603 Compact Form: none
ヘッダーフィールド名：P-DCS-BILLING-INFO RFC番号：3603コンパクトフォーム：なし
Header Field Name: P-DCS-LAES RFC Number: 3603 Compact Form: none
ヘッダーフィールド名：P-DCS-LAES RFC番号：3603コンパクトフォーム：なし
Header Field Name: P-DCS-Redirect RFC Number: 3603 Compact Form: none
ヘッダーフィールド名：P-DCS-Redirect RFC番号：3603コンパクトフォーム：なし
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
[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] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[5] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[5] IABおよびIESG、「盗聴に関するIETFポリシー」、RFC 2804、2000年5月。
[6] DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", Work in Progress.
[6] DCSグループ、「SIPベースの分散コールコントロールメカニズムを利用してキャリアクラステレフォニーサービスを提供するための建築上の考慮事項」、進行中の作業。
[7] PacketCable Dynamic Quality of Service Specification, pkt-sp-dqos-i07-030815, August 2003.
[7] PacketCable Dynamic Quality of Service Specification、PKT-SP-DQOS-I07-030815、2003年8月。
[8] PacketCable Security Specification, pkt-sp-sec-i09-030728, July 2003.
[8] PacketCableセキュリティ仕様、PKT-SP-SEC-I09-030728、2003年7月。
[9] PacketCable Event Message Specification, pkt-sp-em-i07-030815, August 2003.
[9] PacketCableイベントメッセージ仕様、PKT-SP-EM-I07-030815、2003年8月。
[10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[10] Jennings、C.、Peterson、J。and M. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications.
Packetcableプロジェクトでの分散コールシグナリング作業は、多くの人々の仕事であり、多くの異なる企業を代表しています。著者は、以下に支援を認識し、感謝したいと思います。ジョン・ウィーラー、モトローラ。デビッドボードマン、ダニエルポール、アリスインタラクティブ。ビル・ブルム、ジョン・フェロー、ジェイ・ストレーター、ジェフ・オリス、クライヴ・ホルボロー、モトローラ。Doug Newlin、Guido Schuster、Ikhlaq Sidhu、3com;Jiri Matousek、ベイネットワーク。Farzi Khazai、ノルテル;ジョン・チャップマン、ビル・ガッケル、マイケル・ラマルホ、シスコ。Chuck Kalmanek、Doug Nortz、John Lawer、James Cheng、Tung- Hai Hsiao、Partho Mishra、AT＆T;Telcordia Technologies;そして、Lucent Cable Communications。
Previous versions further acknowledged, as co-authors, several people for providing the text of this document. They are:
以前のバージョンは、共著者として、このドキュメントのテキストを提供するために複数の人々をさらに認めました。彼らです：
Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan (kkrama@research.att.com), AT&T; Ed Miller (edward.miller@terayon.com), Terayon; Glenn Russell (G.Russell@Cablelabs.com), CableLabs; Burcak Beser (burcak@juniper.net) Juniper Networks, Mike Mannette (Michael_Mannette@3com.com) and Kurt Steinbrenner (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens (jpickens@com21.com), Com21; Poornima Lalwaney (poornima.lalwaney@nokia.com), Nokia; Jon Fellows (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans (n7dr@arrisi.com) Arris, and Keith Kelly (keith@netspeak.com), NetSpeak.
Bill Marshall（wtm@research.att.com）およびK. K. Ramakrishnan（kkrama@research.att.com）、at＆t;エド・ミラー（edward.miller@terayon.com）、Terayon;グレンラッセル（g.russell@cablelabs.com）、cablelabs;Burcak Beser（burcak@juniper.net）Juniper Networks、Mike Mannette（Michael_mannette@3com.com）およびKurt Steinbrenner（kurt_steinbrenner@3com.com）、3com;Dave Oran（oran@cisco.com）およびフレミングアンドレアセン（fandreas@cisco.com）、Cisco Systems;John Pickens（jpickens@com21.com）、com21;Poornima Lalwaney（poornima.lalwaney@nokia.com）、Nokia;Jon Fellows（jfellows@coppermountain.com）、Copper Mountain Networks;Doc Evans（n7dr@arrisi.com）Arris、およびKeith Kelly（keith@netspeak.com）、netspeak。
Bill Marshall AT&T Florham Park, NJ 07932
ビルマーシャルAT＆Tフローハムパーク、ニュージャージー07932
EMail: wtm@research.att.com
Flemming Andreasen Cisco Edison, NJ
フレミングアンドレアセンシスコエジソン、ニュージャージー州
EMail: fandreas@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。