[要約] RFC 5503は、PacketCable分散型呼制御アーキテクチャをサポートするためのPrivate Session Initiation Protocol (SIP) Proxy-to-Proxy拡張に関するものです。このRFCの目的は、PacketCableネットワークでの呼制御を改善し、SIPプロキシ間の通信を拡張することです。
Network Working Group F. Andreasen
Request for Comments: 5503 Cisco
Obsoletes: 3603 B. McKibben
Category: Informational CableLabs
B. Marshall
AT&T
March 2009
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
In order to deploy a residential telephone service at a 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, RFC 3261, 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.
さまざまなドメインにわたって非常に大規模に住宅電話サービスを展開するには、異なるサービスプロバイダーが所有する信頼できる要素が、コールに関係する当事者に関する顧客固有の情報と期待を伝える信頼できる情報を交換する必要があります。このドキュメントでは、パケット可能な分散コールシグナリングアーキテクチャの信頼できるエンティティ間の顧客情報の交換と請求情報の交換をサポートするためのセッション開始プロトコルRFC 3261のプライベートエクステンションについて説明します。これらの拡張機能は、サービスの盗難を防ぐためのアクセスネットワーク調整のメカニズムを提供し、顧客は嫌がらせのコールの痕跡、オペレーターサービスと緊急サービスのサポート、および他のさまざまな規制問題のサポートを提供します。拡張機能の使用は、クローズド管理ドメイン内、または充電およびその他の機能の調整が必要な以前に合意したポリシーを備えた管理ドメインの連合内でのみ適用されます。
Table of Contents
目次
1. Applicability Statement .........................................4
2. Introduction ....................................................4
3. Trust Boundary ..................................................6
4. Conventions Used in This Document ...............................7
5. P-DCS-TRACE-PARTY-ID ............................................7
5.1. Syntax .....................................................8
5.2. Procedures at an Untrusted User Agent Client (UAC) .........9
5.3. Procedures at a Trusted User Agent Client (UAC) ............9
5.4. Procedures at an Untrusted User Agent Server (UAS) .........9
5.5. Procedures at a Trusted User Agent Server (UAS) ............9
5.6. Procedures at Proxy .......................................10
5.6.1. Procedures at Originating Proxy ....................10
5.6.2. Procedures at Terminating Proxy ....................11
6. P-DCS-OSPS .....................................................11
6.1. Syntax ....................................................11
6.2. Procedures at an Untrusted User Agent Client (UAC) ........12
6.3. Procedures at a Trusted User Agent Client (UAC) ...........12
6.4. Procedures at an Untrusted User Agent Server (UAS) ........13
6.5. Procedures at a Trusted User Agent Server (UAS) ...........13
6.6. Procedures at Proxy .......................................14
7. P-DCS-BILLING-INFO .............................................14
7.1. Syntax ....................................................16
7.2. Procedures at an Untrusted User Agent Client (UAC) ........18
7.3. Procedures at a Trusted User Agent Client (UAC) ...........18
7.4. Procedures at an Untrusted User Agent Server (UAS) ........18
7.5. Procedures at a Trusted User Agent Server (UAS) ...........18
7.6. Procedures at Proxy .......................................19
7.6.1. Procedures at Originating Proxy ....................19
7.6.2. Procedures at Terminating Proxy ....................20
7.6.3. Procedures at Tandem Proxy .........................21
8. P-DCS-LAES and P-DCS-Redirect ..................................21
8.1. Syntax ....................................................23
8.2. Procedures at an Untrusted User Agent Client (UAC) ........24
8.3. Procedures at a Trusted User Agent Client (UAC) ...........24
8.4. Procedures at an Untrusted User Agent Server (UAS) ........25
8.5. Procedures at a Trusted User Agent Server (UAS) ...........25
8.6. Procedures at Proxy .......................................26
8.6.1. Procedures at Originating Proxy ....................26
8.6.2. Procedures at Terminating Proxy ....................28
9. Security Considerations ........................................29
10. IANA Considerations ...........................................29
11. Changes since RFC 3603 ........................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................33
The Session Initiation Protocol (SIP) [RFC3261] 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 [DCSARCH]. 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 [DCSARCH] is strongly encouraged in those domains as well.
このドキュメントで説明されているセッション開始プロトコル（SIP）[RFC3261]拡張は、ネットワークトポロジ、SIPと下層の間のリンク、および推移的信頼の可用性に関する特定の仮定を行います。これらの仮定は、一般的にインターネット全体に適用されません。これらのヘッダーの使用は、閉鎖された管理ドメイン内でのみ適用されます。たとえば、[DCSARCH]で提示されたアーキテクチャのように、充電やその他の機能の調整が必要な以前に合意したポリシーを備えた管理ドメインの連合です。そのようなドメインの外部で使用すると、潜在的に機密情報または個人情報が漏れている可能性があります。[DCSARCH]のポリシーのプライバシーへの影響に対するユーザーの同意は、これらのドメインでも強く奨励されています。
Although [RFC2119] 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.
[RFC2119]言語はこのドキュメントで使用されていますが、規範的言語の範囲はドキュメントの適用可能性の領域のみであり、テクノロジーと同様に、一般的なインターネットには適用されません。
In order to deploy a SIP based 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ベースの住宅電話サービスを展開するためには、異なるサービスプロバイダーが所有する信頼できる要素が、コールに関与する当事者に関する請求情報と期待を伝える信頼できる情報を交換する必要があります。
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 Distributed Call Signaling (DCS) architecture described in [DCSARCH] 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.
[DCSARCH]で説明されている分散コールシグナル伝達（DCS）アーキテクチャの重要な動機付け原則は、ネットワークサービスプロバイダーがネットワークリソースを制御および監視できる必要性です。収益は、これらのリソースの使用と、テレフォニーなどの強化されたサービスの提供から得られる場合があります。さらに、DCSアーキテクチャは、コールシグナルとリソース管理の間の調整の必要性を認識しています。この調整により、ネットワークリソースへのアクセスと請求可能な拡張サービスへのアクセスを受信する前に、ユーザーが認証および承認されます。
DCS Proxies, as defined in [DCSARCH], 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 [DCSARCH] for a description of the trust boundary and trusted versus untrusted entities.
[DCSARCH]で定義されているDCSプロキシは、サブスクライバー情報にアクセスし、コールシグナリングパスに沿ってポリシー決定ポイントと信頼できる仲介者として機能します。エッジルーターは、ネットワーク接続とリソースポリシーの実施メカニズムを提供し、ネットワークの接続性とリソース使用情報をキャプチャおよび報告します。エッジルーターには、レコードキーピングまたは請求サーバーで記録できる請求情報を提供する必要があります。DCSプロキシは、コールシグナル伝達とリソース管理の間の調整の中心的なポイントとして、呼び出しおよび呼び出されたパーティーの認証されたアイデンティティに基づいてこの情報を提供できます。DCSプロキシ間に信頼関係があるため、電話に関与する当事者に関する信頼できる請求情報を交換することに頼ることができます。信頼の境界と信頼されていないエンティティと信頼されていないエンティティの説明については、[DCSARCH]を参照してください。
For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. The extensions only appear on trusted network segments, are inserted upon entering a trusted network region, and are removed before leaving trusted network segments.
これらの理由から、SIPヘッダー拡張機能を定義して、DCSプロキシがコールセットアップ中に情報を交換できるようにすることを検討することが適切です。拡張機能は、信頼できるネットワークセグメントにのみ表示され、信頼できるネットワーク領域に入ると挿入され、信頼できるネットワークセグメントを離れる前に削除されます。
Significant amounts of information are 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 it 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一般ヘッダーフィールドを追加すると、請求情報をキャプチャし、コール期間中に請求書の識別が可能になります。
The billing extensions 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 for support of 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））、公共サービスアクセスポイント（PSAP）への9-1-1コールなどの緊急サービス、およびその後のコール処理、および該当する法律および裁判所命令で義務付けられている電子監視と法執行機関のアクセスの支援。これらのすべてのケースでは、コールに関する追加情報とコールに関与する加入者に関する追加情報は、プロキシ間で交換する必要があります。
The DCS architecture [DCSARCH] 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アーキテクチャ[DCSARCH]は、サービスプロバイダーによって所有、運用、および/または制御されるさまざまなシステムおよびサーバーの周りの信頼境界を定義します。これらの信頼できるシステムには、ブリッジサーバー、ボイスメールサーバー、アナウンスサーバーなどのプロキシやさまざまなサーバーが含まれます。トラスト境界の外側には、サードパーティのサービスプロバイダーが運営するさまざまなアプリケーションおよびメディアサーバーがあります。
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. Since UAs may support client and server functions, the UA sections include procedures for the User Agent Client (UAC) and User Agent Server (UAS).
したがって、ユーザーエージェントの手順を示す次のセクションは、信頼できるユーザーエージェントと信頼されていないユーザーエージェントに細分されます。UASはクライアントおよびサーバー機能をサポートする場合があるため、UAセクションには、ユーザーエージェントクライアント（UAC）およびユーザーエージェントサーバー（UAS）の手順が含まれます。
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, [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、[RFC2119]に記載されているように解釈される。
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 [RFC3325].
電話ネットワークでは、ID情報の呼び出しは、顧客起源のTrace Serviceなどの規制要件をサポートするために使用されます。このトレースサービスは、呼び出された当事者に、法執行機関にわいせつまたは嫌がらせを報告する能力を提供します。このサービスは、発信者IDとは独立して提供され、発信者が匿名性を要求したとしても機能します。ここでは、召し当事者は、コールを発信するステーションとして特定されています。このサービスが信頼できるためには、呼び出された当事者は、提示されている呼び出しのアイデンティティ情報が有効であることを信頼できなければなりません。これを達成する1つの方法は、[RFC3325]に記載されています。
To initiate a customer-originated-trace from an untrusted User Agent Client (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 untrusted UAC also includes the Target-Dialog header field, defined in [RFC4538], in the INVITE request in order to explicitly identify the call to be traced. 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と呼ばれ、他のリクエストや応答には表示されません。信頼されていないUACには、[RFC4538]で定義されたターゲットダイアログヘッダーフィールドも含まれています。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 [RFC3261]):
このヘッダーのABNF説明は（このABNFで使用されるいくつかの用語は[RFC3261]で定義されています）：
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
*1(SEMI timestamp-param) *(SEMI trace-param)
timestamp-param = "timestamp=" 1*DIGIT ["." 1*DIGIT]
trace-param = generic-param ; defined in RFC 3261
This document adds the following entry to Table 2 of [RFC3261]:
このドキュメントでは、次のエントリを[RFC3261]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dmr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
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には通常、セッションを確立するシグナリングメッセージに記載されているように、リモートエンドポイントのIDを与えるTel URLまたはSIP URIが含まれています。
The timestamp-param contains the value of the time the UA determines it received the session initiation request of the call requested to be traced. The timestamp-param is populated using the Network Time Protocol timestamp format defined in RFC 1305 [RFC1305] and used by the Simple Network Time Protocol [RFC4330]. The timestamp SHOULD be encoded in UTF-8 Format per [RFC3629]. The trace-param is a generic parameter for future extensions.
Timestamp-Paramには、UAがトレースされるように要求されたコールのセッション開始要求を受け取ったと判断した時間の値が含まれています。タイムスタンプパラムは、RFC 1305 [RFC1305]で定義され、単純なネットワークタイムプロトコル[RFC4330]で使用されているネットワークプロトコルタイムスタンプ形式を使用して入力されます。タイムスタンプは、[RFC3629]ごとにUTF-8形式でエンコードする必要があります。Trace-Paramは、将来の拡張機能の汎用パラメーターです。
An example of the P-DCS-Trace-Party-ID header is shown as follows:
P-DCS-Trace-Party-IDヘッダーの例を次のように示します。
P-DCS-Trace-Party-ID: <sip:+12345678912@domain.com;user=phone>;
timestamp=3434688831.2327
The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The trace request from the Untrusted User Agent Client is able to be initiated during the dialog or after the release of the dialog or call that is requested to be traced. 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. The [RFC3603] version of the P-DCS-Trace-Party-ID did not include the timestamp-param parameter; however, the syntax is backwards compatible with [RFC3603]. A UAC compliant to this updated specification MUST insert the timestamp and the Target-Dialog header field defined in [RFC4538] if known to the UAC.
UACは、P-DCS-TRACE-PARTY-IDヘッダーを顧客オリジネートされたTRACEリクエストの最初の招待メッセージに挿入する必要があります。信頼されていないユーザーエージェントクライアントからのトレースリクエストは、ダイアログ中、またはトレースされるように要求されるダイアログまたはコールのリリース後に開始することができます。UACは、userInfoを「コールトレース」に設定し、信頼されていないUAのコールトレースエンティティを識別するHOSTPORTを使用して、Request-URIでSIP URIを使用する必要があります。P-DCS-TRACE-PARTY-IDの[RFC3603]バージョンには、Timestamp-Paramパラメーターは含まれていませんでした。ただし、構文は[RFC3603]と逆方向に互換性があります。この更新された仕様に準拠したUACに準拠するには、UACに知られている場合、[RFC4538]で定義されたタイムスタンプとターゲットダイアログヘッダーフィールドを挿入する必要があります。
In case of an anonymous malicious call, where the remote party is not known to the Untrusted UAC, the Untrusted UAC SHOULD indicate the user as anonymous in the P-DCS-Trace-Party-ID, for example, as follows: sip:anonymous@anonymous.invalid.
リモートパーティが信頼されていないUACに知られていない匿名の悪意のある呼び出しの場合、信頼されていないUACは、ユーザーをP-DCS-Trace-Party-IDの匿名として示す必要があります。たとえば、次のように：sip：匿名@anonymous.invalid。
A trusted UAC performs the customer-originated-trace in a manner similar to the trusted User Agent Server (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 and associated trace parameters (if any) from the Target-Dialog header field 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から送信された応答に表示されてはなりません。
If the P-DCS-Trace-Party-ID header is not present in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" the UAS MUST reject the request.
P-DCS-TRACE-PARTY-IDヘッダーがUACからの最初の招待要求に存在しない場合、招待のリクエスト-URIがuserInfoを「call-trace」に設定している場合、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 an untrusted endpoint.
2セットのプロキシ手順が定義されています。（1）発信元のプロキシでの手順、および（2）終端プロキシでの手順。発信元のプロキシは、信頼されていないエンドポイントから招待リクエストを受け取ったプロキシです。
The terminating proxy is a proxy that sends the INVITE request to an untrusted 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 it 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 and trace parameters from the Target-Dialog header fields defined in [RFC4538]).
P-DCS-TRACE-PARTY-IDヘッダーがUACからの最初の招待リクエストに存在し、招待のリクエスト-URIが「call-trace」以外のuserInfoを持っている場合エンティティをトレースすると、プロキシはリクエストを拒否するか、リクエストからP-DCS-Trace-Party-IDヘッダーを削除する場合があります。ヘッダーが有効なリクエストに存在し、ホストポートのプロキシを識別するプライベートURLを含む場合、発信元のプロキシはプライベートURLを元のコンテンツ（つまり、セッションの発信者の確認されたアイデンティティを置き換える必要があります。これは、[RFC4538]で定義されているターゲットダイアログヘッダーフィールドからトレースされ、トレースパラメーターを追跡しています。
The proxy records the caller URL and target dialog IDs on sessions directed toward the untrusted UAC if provisioned to do so by the network operator. If the is P-DCS-Trace-Party-ID header is present in a valid request, and contains an anonymous caller indication in the name-addr parameter, the originating proxy MUST replace the anonymous URL with the verified identity of the caller of the session that is being traced if available and recorded by the proxy. Otherwise, the proxy does not replace the anonymous URL.
プロキシは、ネットワークオペレーターによって提供されるようにプロビジョニングされた場合、信頼されていないUACに向けられたセッションで、発信者URLおよびターゲットダイアログIDを記録します。IS P-DCS-TRACE-PARTY-IDヘッダーが有効な要求に存在し、Name-ADDRパラメーターに匿名の発信者の表示が含まれている場合、発信元のプロキシは、匿名のURLを、利用可能な場合に追跡され、プロキシによって記録されるセッション。それ以外の場合、プロキシは匿名のURLを置き換えません。
If the origination proxy is provisioned to store URLs and target dialog IDs for incoming calls, and if the proxy detects that the URL and target dialog ID in a trace request does not match a recorded incoming dialog request, then the proxy MUST reject the trace call request.
オリジネーションプロキシが、着信コールのURLとターゲットダイアログIDを保存するようにプロビジョニングされ、プロキシがトレースリクエストのURLおよびターゲットダイアログIDが記録された着信ダイアログリクエストと一致しないことを検出した場合、プロキシはトレースコールを拒否する必要がありますリクエスト。
The origination proxy does not add the P-DCS-Trace-Party-ID header from a request that does not already contain the header.
Origination Proxyは、まだヘッダーを含んでいないリクエストからP-DCS-Trace-Party-IDヘッダーを追加しません。
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 Public Switched Telephone Network (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, with a field that may be set to a value indicating when a special type of call processing is requested. We define three values in this header field, 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 [RFC3261]):
P-DCS-OSPSヘッダーのABNF説明は次のとおりです（このABNFで使用されるいくつかの用語は[RFC3261]で定義されています）：
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 [RFC3261]:
このドキュメントでは、次のエントリを[RFC3261]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - 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 [DCSARCH] 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に特別なトランクを備えたメディアゲートウェイを制御しているメディアゲートウェイコントローラー[DCSARCH]によってのみ挿入されます。このトランクグループは通常、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 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 preexisting dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a preexisting 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 preexisting dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a preexisting dialog established by a UAC to an operator or PSAP.
OSPS-TAGバリュー「リング」は、（1）オペレーターまたはPSAPへのUACによって確立された既存のダイアログ内のその後の招待、または（2）既存のダイアログ内の更新リクエスト内のリクエストを使用して、以外の招待状を除いて、リクエストまたは応答に表示されてはなりません。オペレーターまたはPSAPへのUAC。
If the UAS receives an INVITE request with an OSPS-Tag of "BLV", dialog identification that matches an existing dialog, it MUST reject the request with a 403 (Forbidden) response.
UASが、既存のダイアログと一致するダイアログ識別のOSPSタグで招待リクエストを受け取った場合、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 that was established with the OSPS-Tag value of "BLV", it MUST reject the request with a 403 (Forbidden) response.
UASが「EI」または「RING」のOSPSタグ値を持つ招待/更新リクエストを受け取った場合、「BLV」の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.
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 quality-of-service (QoS) pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port given in the Session Description Protocol (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 there is 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タグの招待状が受け入れられた場合（たとえば、すべてのサービス品質（QOS）前条件を満たすなど）、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一般ヘッダーフィールドを追加すると、請求情報をキャプチャし、コール期間中に請求書の識別が可能になります。
The billing extensions only appear on trusted network segments, and MAY be inserted by a proxy or trusted UA in INVITE and SUBSCRIBE 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 UAs. It is never sent to an untrusted UA. It is expected that untrusted UAs do not send this header.
請求拡張機能は、信頼できるネットワークセグメントにのみ表示され、信頼できるネットワークセグメントで招待および購読リクエストでプロキシまたは信頼できるUAによって挿入され、信頼できるネットワークセグメントを離れる前に削除されます。P-DCS-BILLING-INFOヘッダー拡張機能は、プロキシと信頼できるUAS間のリクエストと応答に従ってのみ使用されます。信頼されていないUAに送られることはありません。信頼されていないUASがこのヘッダーを送信しないことが予想されます。
The DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [RFC3261]):
DCS-BILLING-INFOヘッダーは、次のABNFによって定義されます（このABNFで使用されるいくつかの用語は[RFC3261]で定義されています）：
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 /
JIP-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
JIP-param = "jip" EQUAL jip
jip = LDQUOT 1*phonedigit-hex jip-context RDQUOT
jip-context = ";jip-context=" jip-descriptor
jip-descriptor = global-hex-digits
global-hex-digits = "+" 1*3(phonedigit) *phonedigit-hex
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
This document adds the following entry to Table 2 of [RFC3261]:
このドキュメントでは、次のエントリを[RFC3261]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
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 UAs.
P-DCS-BILLING-INFO拡張機能には、イベントレコーダーが使用して、おそらく異なるソースからの複数の使用記録を請求可能なアカウントで関連付けることができる識別子が含まれています。さらに、サブスクライバーアカウント情報と、サービスの正確な請求に必要なその他の情報が含まれています。このヘッダーは、プロキシと信頼できるUASの間でのみ使用されます。
The Billing-Correlation-ID, BCID, is specified in [PCEM] 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、BCIDは、[PCEM]で24バイトのバイナリ構造として指定されており、4バイトのNTPタイムスタンプ、IDを生成したネットワーク要素のユニークな識別子の8バイト、8バイトの時間を与えます。ゾーン、およびそのネットワーク要素での単調に増加するシーケンス番号の4バイト。この識別子は、数か月のウィンドウのためにシステム内でグローバルにユニークになるように選択されます。これは、最大48文字の16進文字列として、P-DCS-Billing-INFOヘッダーでエンコードする必要があります。先行ゼロは抑制される場合があります。
The Financial-Entity-ID (FEID) is specified in [PCEM] 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）は、[PCEM]で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-Loc-Routing-URI are each defined as URLs; they should all contain tel URLs with E.164 formatted addresses. These fields are further defined in [PCEM] 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-loc-routing-uriはそれぞれURLとして定義されています。それらはすべて、E.164フォーマットされたアドレスを持つTel URLを含める必要があります。これらのフィールドは、要素識別子 "Charge_Number"（要素ID 16）、「Calling_Party_Number "（要素ID 4）、「Call_Party_Number」（要素ID 5）、「ルーティング番号」（要素ID 25）、「要素ID 25）、[PCEM]でさらに定義されています。および「location_routing_number」（要素ID 22）。
The JIP-param contains the calling jurisdiction information, or numbering plan area, of the network in which the call originated. The field is further defined in [PCEM] under the element identifier "Jurisdiction_Information_Parameter" (element ID 82). An older [RFC3603] compliant implementation may not use the JIP-param.
Jip-Paramには、呼び出しが発生したネットワークの呼び出しの管轄情報、または番号付け計画領域が含まれています。このフィールドは、[PCEM]では、要素識別子「jurisdiction_information_parameter」（要素ID 82）の下の[PCEM]でさらに定義されています。古い[RFC3603]準拠の実装では、JIP-Paramを使用しない場合があります。
This header is never sent to an untrusted UA. It is expected that untrusted UAs do not send this header.
このヘッダーは、信頼されていないUAに送られることはありません。信頼されていないUASがこのヘッダーを送信しないことが予想されます。
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 or SUBSCRIBE message sent to the terminating entity, 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. If available to the UAC, the UAC MUST include the JIP-param.
UACは、コール用の請求相関IDを生成し、最初の招待状または接続するエンティティに送信された請求情報と、コールの充電情報にP-DCS-BILLING-INFOヘッダーに挿入する必要があります。UACには、FEIDと、UACが使用しているレコードキーピングサーバー用のRKS-Group-IDを含める必要があります。UACがローカル番号ポータビリティ（LNP）クエリを実行した場合、クエリによって返されるルーティング番号とロケーションルーティング番号を含める必要があります。UACで利用可能な場合、UACにはJip-Paramを含める必要があります。
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 field, 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 field values from the 3xx-Redirect response. If the UAC is acting as a back-to-back user agent (B2BUA), instead of generating a new INVITE it MAY generate a private-URL and place it in the Contact header field 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レディレクトである場合、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 or SUBSCRIBE 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 an 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 or SUBSCRIBE request from an untrusted endpoint.
発信元のプロキシは、信頼されていないエンドポイントから招待状または購読要求を受け取ったプロキシです。
The terminating proxy is a proxy that sends the INVITE or SUBSCRIBE request to an untrusted 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 an untrusted 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 request from an untrusted endpoint, and sends the request to an untrusted 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 or SUBSCRIBE message sent to the terminating entity, 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 an LNP query, it MUST include the Routing Number, Location Routing Number, and JIP-param 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クエリを実行した場合、ルーティング番号、ロケーションルーティング番号、およびクエリによって返されるJIP-Paramを含める必要があります。信頼されていない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 non-100 provisional response, the originating proxy generates a new initial INVITE request to the destination specified in the Contact header field, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a non-100 provisional response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response.
最初の招待への応答が、100以外の暫定的な応答の前に受信された3XXリダイレクトである場合、標準的なSIPに従って、コンタクトヘッダーフィールドで指定された宛先への新しい初期招待リクエストが生成されます。発信元のプロキシが、100以外の暫定的な応答の前に最初の招待に対する3XXリダイレクト応答を受信する場合、プロキシによって生成された招待には、3XXリダイレクト応答からP-DCS-BILLING-INFOヘッダーが含まれている必要があります。
If the response to the initial INVITE is a 3xx-Redirect, received after a non-100 provisional response, 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 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.
最初の招待への応答が100以外の暫定的な応答の後に受信された3XXレディレクトである場合、発信元のプロキシはプライベートURLを生成し、発信元のエンドポイントに送信される3XXリダイレクト応答のコンタクトヘッダーに配置します。このプライベート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 or SUBSCRIBE 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 an 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ヘッダーには、終了プロキシによって生成された請求相関ID、終了プロキシのFEID、および終了プロキシによって使用されているレコードキーピングサーバーのRKS-Group-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 indicates 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 an 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 [RFC2804], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The [RFC2119] 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 [RFC2804]によると、IETFは、それを開発する必要がある場合、合法的なインターセプトテクノロジーのドキュメントをサポートしています。次のセクションでは、そのようなドキュメントを提供します。上記の[RFC2119]言語は、上記の適用性ドメイン内で実装された場合にのみ、仕様の要件を説明しています。このテクノロジーに関連するプライバシー、セキュリティ、複雑さに関する問題の説明については、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 fields MAY also contain the associated BCID for the event stream as well as additional address and port for delivery of call content and associated cccid. The BCID is used to correlate a series of events associated with a single call or session. The cccid is used to identify an intercepted call content to an intercepted call. The P-DCS-LAES header is only used between proxies and trusted UAs. The P-DCS-LAES header defined here is not backwards compatible with that defined in [RFC3603], which is deprecated by the document. This version of the P-DCS-LAES header adds a cccid parameter to support the intercept of content, and deletes security key information. This version does not mandate the use of the BCID.
P-DCS-LAES拡張には、合法的に認可された電子監視をサポートするために必要な情報が含まれています。このヘッダーには、この呼び出しに関連するイベントメッセージの重複ストリームを配信するための電子監視配信機能のアドレスとポートが含まれています。ヘッダーフィールドには、イベントストリームに関連するBCIDと、コールコンテンツと関連するCCCIDの配信のための追加のアドレスとポートも含まれている場合があります。BCIDは、単一のコールまたはセッションに関連する一連のイベントを相関させるために使用されます。CCCIDは、インターセプトされた呼び出しに傍受された呼び出しコンテンツを識別するために使用されます。P-DCS-LAESヘッダーは、プロキシと信頼できるUASの間でのみ使用されます。ここで定義されているP-DCS-LAESヘッダーは、[RFC3603]で定義されているものと逆方向に互換性がありません。これは、ドキュメントによって非推奨です。P-DCS-LAESヘッダーのこのバージョンは、CCCIDパラメーターを追加してコンテンツのインターセプトをサポートし、セキュリティキー情報を削除します。このバージョンは、BCIDの使用を義務付けていません。
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 UAs.
P-DCS-Redirect拡張には、リダイレクトコールの合法的に承認された電子監視の要件をサポートするために必要なコール識別情報が含まれています。このヘッダーは、プロキシと信頼できるUASの間でのみ使用されます。
Note that there is overlap in function between the P-DCS-Redirect header and the History-Info header specified in RFC 4244. The original P-DCS-Redirect came to existence in RFC 3603 before the History-Info. Therefore, the P-DCS-Redirect header is continued here for backwards compatibility with existing implementations.
P-DCS-RedirectヘッダーとRFC 4244で指定されたHistory-INFOヘッダーとの間には関数が重複していることに注意してください。元のP-DCS redirectは、History-INFOの前にRFC 3603に存在しました。したがって、既存の実装との逆方向の互換性のために、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 [RFC3261] and [RFC5234]):
P-DCS-LAESおよびP-DCS-Redirectヘッダーの形式は、次のABNFによって与えられます（このABNFで使用されるいくつかの用語は[RFC3261]および[RFC5234]で定義されています）：
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig *(SEMI Laes-param) Laes-sig = hostport Laes-param = Laes-content / Laes-cccid Laes-bcid / generic-param Laes-content = "content" EQUAL hostport
p-dcs-laes = "p-dcs-laes" hcolon laes-sig *（semi laes-param）laes-sig = hostport laes-param = laes-content / laes-cccid laes-bcid / generic-param laes-content= "content"等しいホストポート
Laes-bcid = "bcid" EQUAL 1*48(HEXDIG)
Laes-cccid = "cccid" EQUAL 1*8(HEXDIG)
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(SEMI 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 [RFC3261]:
このドキュメントでは、次のエントリを[RFC3261]の表2に追加します。
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - - -
P-DCS-Redirect adr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
- - - - - - -
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-bcid contains a correlation ID that is used to link a sequence of intercepted call processing events related to a single call. Laes-cccid contains an identifier of the intercepted call content. The Laes-bcid field MAY be present. The BCID is included per network operator configuration to support events reported as defined in [PCEM]. The Laes-cccid field MAY be present when the Laes-content field is present. The Laes-cccid is included per network operator configuration for networks where entities receiving the intercepted contents may act a media relay functions to other surveillance functions that are the source of the content surveillance request. The design of multiple surveillance entities that receive call content is beyond the scope of this document.
Laes-SigとLaes-Contentの値は、電子監視配信機能のアドレスであり、それぞれ通話識別情報とコールコンテンツの宛先アドレスとして使用されます。LAES-BCIDには、単一の呼び出しに関連する傍受されたコール処理イベントのシーケンスをリンクするために使用される相関IDが含まれています。LAES-CCCIDには、傍受された呼び出しコンテンツの識別子が含まれています。LAES-BCIDフィールドが存在する場合があります。BCIDは、[PCEM]で定義されていると報告されたイベントをサポートするために、ネットワーク演算子構成ごとに含まれています。Laes-Contentフィールドが存在するとき、Laes-Cccidフィールドが存在する場合があります。LAES-CCCIDは、インターセプトされたコンテンツを受信するエンティティがコンテンツサーベイランス要求のソースである他の監視機能にメディアリレー関数を作用する可能性があるネットワークのネットワーク演算子構成ごとに含まれています。コールコンテンツを受信する複数の監視エンティティの設計は、このドキュメントの範囲を超えています。
The P-DCS-Redirect header contains redirection information. The Called-ID indicates the original destination requested by the user (e.g., number dialed originally), the redir-uri-param indicates the entity performing the redirection, and the Redir-count indicates the number of redirections that have occurred. For example, if A calls B, who forwards to C, who forwards to D, then, when C forwards to D, the Called-ID will be A, redir-uri-param will be C, and count will be 2.
P-DCS redirectヘッダーにはリダイレクト情報が含まれています。呼び出されたIDは、ユーザーが要求した元の宛先（元々ダイヤルされた番号など）を示し、Redir-URI-Paramはリダイレクトを実行するエンティティを示し、Redir-Countは発生したリダイレクトの数を示します。たとえば、cに転送するbがbに転送され、dに転送される場合、cがdに転送されると、call-idがaになり、redir-uri-paramはcになり、カウントは2になります。
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, MAY include this information in the Authorization for Quality of Service [PCDQOS] or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
UACは、発信元のサブスクライバーに対する未払いの合法的に承認された監視命令をチェックし、存在する場合、この情報をサービス品質の認可[PCDQO]に含めるか、この情報をインターセプトを実行するデバイスに通知する場合があります（例えば、メディア、メディアゲートウェイ）。それ以外の場合、インターセプトアクセスポイントは、このドキュメントの範囲外のメカニズムにより、コールコンテンツを実行したり、データインターセプトを呼び出したりするように指示されます。
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 MAY include this information in the Authorization for Quality of Service, or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
P-DCS-LAESヘッダーが最初の信頼できる1XX（100を除く）、2XX、または3XX応答（終端サブスクライバーではサーベイランスが必要であることを示すが、終端装置がその機能を実行できないことを示す）に存在する場合、UACはUACです。この情報をサービス品質の認可に含めることも、この情報をインターセプトを実行するデバイスに信号することもあります（たとえば、メディアゲートウェイ）。それ以外の場合、インターセプトアクセスポイントは、このドキュメントの範囲外のメカニズムにより、コールコンテンツを実行したり、データインターセプトを呼び出したりするように指示されます。
If a 3xx-Redirect response to the initial INVITE request is received, 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 most recent redirecting party, 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 UAC MAY also include a P-DCS-Redirect header. The P-DCS-LAES header MAY include the Laes-bcid parameter set to a value that uniquely identifies the call, 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 MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.
紹介リクエストに紹介ヘッダーを含むUACは、発信元のサブスクライバーが顕著に承認された監視命令を持っている場合、紹介に接続されたP-DCS-LAESヘッダーを含める必要があります。UACには、P-DCS Redirectヘッダーも含まれる場合があります。P-DCS-LAESヘッダーには、コールを一意に識別する値に設定されたLAES-BCIDパラメーターを含めることができます。コールのイベントメッセージのコピーのローカル電子監視配信機能の住所とポートを含める必要があります。コールコンテンツをインターセプトする場合は、コールコンテンツのコピーのローカル電子監視配信機能のポートを含め、呼び出しコンテンツを傍受する場合、傍受されたオーディオストリームを一意に識別する値に設定されたLAES-CCCIDパラメーターを含めることができます。
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 MAY include this information in the authorization for Quality of Service [PCDQOS]. Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
UASは、終了サブスクライバーの未払いの合法的に承認された監視命令、または招待リクエストにおけるP-DCS-LAESヘッダーの存在をチェックします。いずれかが存在する場合、UASには、サービス品質の許可[PCDQOS]にこの情報を含めることができます。それ以外の場合、インターセプトアクセスポイントは、このドキュメントの範囲外のメカニズムにより、コールコンテンツを実行したり、データインターセプトを呼び出したりするように指示されます。
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 1xx (except 100), 2xx, or 3xx response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header MAY include the Laes-bcid parameter with a value that uniquely identifies the call, 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 MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.
終了機器が必要な監視を実行できない場合（例：宛先がボイスメールサーバーである場合）、UASには最初の信頼できる1XX（100を除く）、2XX、または3XX応答のリクエストを要求するP-DCS-LAESヘッダーを含める必要があります監視を実行するための発生プロキシ。P-DCS-LAESヘッダーには、コールを一意に識別する値を持つLAES-BCIDパラメーターを含めることができます。コールのイベントメッセージのコピーのためにローカル電子監視配信機能の住所とポートを含める必要があります。コールコンテンツを傍受する場合は、コールコンテンツのコピーのローカル電子監視配信機能のポートを含め、呼び出しコンテンツが傍受される場合に傍受されたオーディオストリームを一意に識別する値に設定されたLAES-CCCIDパラメーターを含めることができます。
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 receives the INVITE request from an untrusted endpoint.
2セットのプロキシ手順が定義されています。（1）発信元のプロキシでの手順、および（2）終端プロキシでの手順。発信元のプロキシは、信頼されていないエンドポイントから招待要求を受信するプロキシです。
The terminating proxy is a proxy that sends the INVITE request to an untrusted endpoint.
終了プロキシは、招待リクエストを信頼されていないエンドポイントに送信するプロキシです。
For purposes of mid-call changes, such as call transfers, the proxy that receives the request from an untrusted endpoint is considered the initiating proxy; the proxy that sends the request to an untrusted 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 an untrusted 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, MAY include this information in the Authorization for Quality of Service [PCDQOS] or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
発信元のプロキシは、発生するサブスクライバーの未解決の合法的に承認された監視命令をチェックします。存在する場合は、この情報をサービス品質[PCDQO]の許可に含めるか、この情報をインターセプトを実行するデバイスに通知する場合があります（例えば、メディアゲートウェイ）。それ以外の場合、インターセプトアクセスポイントは、このドキュメントの範囲外のメカニズムにより、コールコンテンツを実行したり、データインターセプトを呼び出したりするように指示されます。
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 MAY include this information in the Authorization for Quality of Service, or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
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 and (if necessary) a P-DCS-REDIRECT header with the surveillance information.
最初の招待リクエストのリクエスト-URIにプライベートURLが含まれている場合、発信元のプロキシはuserInfo情報を復号化して、コールの実際の宛先やその他の特別な処理情報を見つける必要があります。電子監視情報が復号化されたuseriNfoに含まれている場合、発信元のプロキシはP-DCS-LAESと（必要に応じて）監視情報を含む（必要に応じて）P-DCS redirectヘッダーを生成する必要があります。
If a 3xx-Redirect response to the initial INVITE request is received prior to a non-100 provisional response, 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 most recent redirecting party, and the number of redirections that have occurred.
初期招待リクエストに対する3xxリダイレクト応答が100以外の暫定応答の前に受信され、P-DCS-LAESヘッダーが3XX応答に存在する場合、元のプロキシに再発行された招待状に変更されていないヘッダーを含める必要があります。元のプロキシには、元のダイヤル番号、最新のリダイレクトパーティ、および発生したリダイレクトの数を含むP-DCSレディレクトヘッダーも含める必要があります。
If a 3xx-Redirect response to the initial INVITE request is received after a non-100 provisional response, 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.
100以外の暫定的な応答の後に最初の招待リクエストに対する3XXリダイレクト応答が受信された場合、発信元のプロキシはプライベートURLを生成し、発信元のエンドポイントに送信される3XXリダイレクト応答のコンタクトヘッダーに配置します。P-DCS-LAESヘッダーが3XX応答に存在する場合、このプライベートURLには（1）3XX redirect応答からの電子監視情報、（2）元の宛先番号、（3）リダイレクトパーティー、および（4）この呼び出しのリダイレクトの数。
An originating proxy that processes a REFER request [RFC3515] 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. It MAY also include a P-DCS-Redirect header. 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. The P-DCS-LAES header MAY include (1) the Laes-bcid parameter set to a value that uniquely identifies the call, and (2) the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.
信頼されていないUAからの参照要求[RFC3515]を処理する発信元のプロキシは、発信されたサブスクライバーが優れた合法的に承認された監視命令を持っている場合、その要求のB2BUAになります。参照のURLに追加されたP-DCS-LAESヘッダーでリクエストを再発行する必要があります。また、P-DCS Redirectヘッダーを含めることもできます。P-DCS-LAESヘッダーには、（1）コールのイベントメッセージのコピーのローカル電子監視配信機能の住所とポートを含める必要があります。コールコンテンツが傍受される場合は、コンテンツを呼び出します。P-DCS-LAESヘッダーには、（1）コールを一意に識別する値に設定されたLAES-BCIDパラメーターを含めることができます。傍受することです。
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 MAY include this information in the authorization for Quality of Service [PCDQOS]. Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
終了プロキシは、終了サブスクライバーの未払いの合法的に承認された監視命令をチェックします。存在する場合、終了プロキシには、サービス品質[PCDQOS]の許可にこの情報を含めることができます。それ以外の場合、インターセプトアクセスポイントは、このドキュメントの範囲外のメカニズムにより、コールコンテンツを実行したり、データインターセプトを呼び出したりするように指示されます。
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 MAY include the Laes-bcid parameter set to a value that uniquely identifies the call, 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 MAY include the Laes-cccid parameter set to a value that uniquely identifies the audio stream if call content is to be intercepted.
終了機器が必要な監視を実行できない場合（例：宛先がボイスメールサーバーである場合）、終了プロキシには、最初の信頼できる1xx/2xx/3xx（100を除く）応答要求のP-dcs-laesヘッダーを含める必要があります。監視を実行するための発生プロキシ。P-DCS-LAESヘッダーには、コールを一意に識別する値に設定されたLAES-BCIDパラメーターを含めることができます。コールのイベントメッセージのコピーのローカル電子監視配信機能の住所とポートを含める必要があります。コールコンテンツをインターセプトする場合は、コールコンテンツのコピーのローカル電子監視配信機能のポートを含め、呼び出しコンテンツが傍受される場合にオーディオストリームを一意に識別する値に設定されたLAES-CCCIDパラメーターを含めることができます。
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 [RFC3515] 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 and P-DCS-Redirect information from the attached header fields.
MIDコールの参照要求[RFC3515]を受信するプロキシは、P-DCS-LAESヘッダーが添付された紹介ヘッダーを含むこのリクエストのB2BUAになります。プライベートURLを生成し、エンドポイントに送信される紹介ヘッダーに配置する必要があります。このプライベートURLには、添付のヘッダーフィールドからのP-DCS-LAESおよびP-DCSリダイレクト情報が含まれている必要があります。
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 and trusted UAs is REQUIRED. A minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [PCSEC]. 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とプロキシが、この情報を盗聴や改ざんから保護するための予防策を講じる必要があります。プロキシと信頼できるUAS間のIPSECまたはTLSの使用が必要です。DCSアーキテクチャの最小限の必須のIPSEC構成は、[PCSEC]によって与えられます。また、（1）プロキシと（2）信頼できるUASとプロキシの間の相互認証（1）と（2）どちらも、管理上恥ずかしさキーで、または別の信頼できる第三者との協議を通じて実装される場合があります。IPSECを使用する場合、これらのヘッダーが適用される管理ドメインのセキュリティポリシーと手順の指定（および連邦内の管理ドメイン間のすべての接続）は、相互運用可能なオプションセットを定義する必要があります。
The following changes to the Session Initiation Protocol (SIP) Parameters registry have been made by IANA.
セッション開始プロトコル（SIP）パラメーターレジストリの次の変更は、IANAによって行われました。
The Header Fields registry has been updated as follows:
ヘッダーフィールドレジストリは次のように更新されました。
Header Name compact Reference
----------------- ------- ---------
P-DCS-Trace-Party-ID [RFC5503]
P-DCS-OSPS [RFC5503]
P-DCS-Billing-Info [RFC5503]
P-DCS-LAES [RFC5503]
P-DCS-Redirect [RFC5503]
The following entries in the Header Field Parameters and Parameter Values registry have been updated:
ヘッダーフィールドパラメーターとパラメーター値レジストリの次のエントリが更新されました。
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-Billing-Info called No
[RFC5503]
P-DCS-Billing-Info calling No
[RFC5503]
P-DCS-Billing-Info charge No
[RFC5503]
P-DCS-Billing-Info locroute No
[RFC5503]
P-DCS-Billing-Info rksgroup No
[RFC5503]
P-DCS-Billing-Info routing No
[RFC3603]
P-DCS-LAES content No
[RFC5503]
P-DCS-Redirect count No
[RFC5503]
P-DCS-Redirect redirector-uri No
[RFC5503]
The following entry in the Header Field Parameters and Parameter Values registry has been marked "OBSOLETED":
ヘッダーフィールドパラメーターとパラメーター値レジストリの次のエントリは、「廃止」とマークされています。
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-LAES key (OBSOLETED) No
[RFC3603][RFC5503]
The following entries in the Header Field Parameters and Parameter
Values registry have been created:
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-Billing-Info jip No
[RFC5503]
P-DCS-LAES bcid No
[RFC5503]
P-DCS-LAES cccid No
[RFC5503]
P-DCS-Trace-Party-ID timestamp No
[RFC5503]
o A timestamp parameter is added to the P-DCS-Trace-Party-ID header when available. Procedures on the use of the Target-Dialog header used together with the P-DCS-Trace-Party-ID are added.
o 利用可能な場合、タイムスタンプパラメーターがP-DCS-TRACE-PARTY-IDヘッダーに追加されます。P-DCS-TRACE-PARTY-IDと一緒に使用されるターゲットダイアログヘッダーの使用に関する手順が追加されます。
o The JIP parameter is added to the P-DCS-Billing-Info header when available.
o JIPパラメーターは、利用可能な場合はP-DCS-Billing-INFOヘッダーに追加されます。
o The BCID billing correlation identifier and cccid (call content channel identifier) are added to the P-DCS-LAES header.
o BCID請求相関識別子とCCCID（コールコンテンツチャネル識別子）がP-DCS-LAESヘッダーに追加されます。
o P-DCS-Billing-Info header is applied to the SUBSCRIBE method.
o P-DCS-BILLING-INFOヘッダーがサブスクライブメソッドに適用されます。
o P-DCS-REDIRECT header is applied to the REFER method.
o P-DCS-Redirectヘッダーが参照メソッドに適用されます。
o The use of QoS authorization to establish content intercept is made optional in order not to preclude alternative content intercept provisioning mechanisms.
o コンテンツインターセプトを確立するためのQoS認証の使用は、代替コンテンツインターセプトプロビジョニングメカニズムを排除しないようにオプションになります。
o PUBLISH and MESSAGE methods are added to the SIP method applicability matrices throughout.
o 公開およびメッセージメソッドは、SIPメソッドの適用性マトリックスに追加されます。
o Correction is made to Table 2 to add m=modify.
o 修正は表2に行われ、M = Modifyを追加します。
o IANA considerations are updated.
o IANAの考慮事項が更新されます。
o Corrections are made to timestamp format, and references are updated.
o 修正はタイムスタンプ形式で行われ、参照が更新されます。
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, Brian Lindsay. 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; Lucent Cable Communications; and Miguel Garcia, Ericsson.
Packetcableプロジェクトでの分散コールシグナリング作業は、多くの人々の仕事であり、多くの異なる企業を代表しています。著者は、以下に支援を認識し、感謝したいと思います。ジョン・ウィーラー、モトローラ。デビッドボードマン、ダニエルポール、アリスインタラクティブ。ビル・ブルム、ジョン・フェロー、ジェイ・ストレーター、ジェフ・オリス、クライヴ・ホルボロー、モトローラ。Doug Newlin、Guido Schuster、Ikhlaq Sidhu、3com;Jiri Matousek、ベイネットワーク。ファルジ・ハザイ、ブライアン・リンゼイ。ノルテル;ジョン・チャップマン、ビル・ガッケル、マイケル・ラマルホ、シスコ。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; David Hancock (D.Hancock@ Cablelabs.com) and 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;David Hancock（d.hancock@ cablelabs.com）とグレンラッセル（g.russell@cablelabs.com）、cablelabs;Burcak Beser（burcak@juniper.net）ジュニパーネットワーク。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。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 4330、2006年1月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538] Rosenberg、J。、「セッション開始プロトコル（SIP）でのダイアログ識別による認可を要求する」、RFC 4538、2006年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[DCSARCH] Marshall, W., Osman, M., Andreasen, F., and D. Evans, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", January 2003.
[DCSARCH] Marshall、W.、Osman、M.、Andreasen、F。、およびD. Evans、「SIPベースの分散コールコントロールメカニズムを利用するキャリアクラステレフォニーサービスを提供するための建築上の考慮事項」、2003年1月。
[PCDQOS] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Dynamic Quality of Service", August 2005.
[PCDQOS] Cable Television Laboratories、Inc。、「Packetcable 1.5仕様、動的なサービス品質」、2005年8月。
[PCEM] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Event Messages", December 2005.
[PCEM] Cable Television Laboratories、Inc。、「Packetcable 1.5仕様、イベントメッセージ」、2005年12月。
[PCSEC] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Security", January 2005.
[PCSEC] Cable Television Laboratories、Inc。、「Packetcable 1.5仕様、セキュリティ」、2005年1月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804] IABおよびIESG、「盗聴に関するIETFポリシー」、RFC 2804、2000年5月。
[RFC3325] 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.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", RFC 3603, October 2003.
[RFC3603] Marshall、W。およびF. Andreasen、「プライベートセッション開始プロトコル（SIP）PacketCable分散コールシグナリングアーキテクチャをサポートするためのプロキシツープロキシ拡張機能」、RFC 3603、2003年10月。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Edison, NJ USA
フレミングアンドレアスセンシスコエジソン、ニュージャージー州アメリカ
EMail: fandreas@cisco.com
Bernie McKibben CableLabs Louisville, CO USA
Bernie McKibben Cablelabs Louisville、Co Co Co
EMail: B.McKibben@cablelabs.com
Bill Marshall AT&T Florham Park, NJ USA
ビルマーシャルAT＆Tフローハムパーク、ニュージャージー州アメリカ
EMail: wtm@research.att.com