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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
異なるドメイン間の非常に大規模で、住宅の電話サービスを展開するためには、コール当事者に関する顧客固有の情報や期待を伝える信頼できる情報を交換するために、異なるサービスプロバイダが所有している、信頼できる要素が必要です。この文書では、PacketCableの分散型コールシグナリングアーキテクチャにおける信頼されたエンティティ間の顧客情報や課金情報の交換をサポートするために、セッション開始プロトコル、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.
DCSプロキシは、[DCSARCH]で定義されるように、コールシグナリング経路に沿ってポリシー決定ポイントと、信頼できる仲介者として加入者情報と行為へのアクセスを有します。エッジルータは、ネットワーク接続およびリソースポリシー適用メカニズムを提供し、またネットワーク接続およびリソースの使用状況に関する情報をキャプチャし、報告します。エッジルータは、記録管理や課金サーバにログインすることができ課金情報を与えられる必要があります。 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.
これらの理由から、DCSプロキシは、コールセットアップ中に情報を交換できるようにするためにSIPヘッダの拡張を定義することを検討することが適切です。拡張子は、信頼できるネットワークセグメント上に表示され、信頼されたネットワーク領域に入る時に挿入され、信頼されたネットワークセグメントを離れる前に削除されます。
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コール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.
課金機能拡張は、信頼できるネットワークセグメントに表示され、信頼されたネットワークセグメントを離れる前に、信頼できるネットワークセグメント内INVITEやREFER要求およびINVITE応答で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は））、など9-1-1などの緊急サービスのための公共サービスアクセスポイント（PSAP）と、その後の通話処理を呼び出し、電子監視と法執行のアクセスをサポートするために適用される法律や裁判所の受注で必要とされます。これらすべての場合には、コールについて、コールに関与し、加入者に関する追加情報は、プロキシ間で交換する必要があります。
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).
したがって、ユーザーエージェントのための手順を与える次のセクションでは、信頼できるユーザーエージェントと信頼できないユーザエージェントに細分化されています。 UAは、クライアントとサーバーの機能をサポートするかもしれないので、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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を」文字列が含まれています。ユーザー情報は、典型的には、課金アカウント番号、電子監視指示、電子的監視パラメータとしてプロキシの信頼されたドメイン外に開示されている、およびリダイレクト情報を呼び出すべきではない（またはポイントへ）情報を含んでいます。その結果、情報がいずれかのプロキシでローカルに保存されている、またはURLのユーザ部分の文字列にプロキシにのみ知られており、エンコードされた秘密鍵で暗号化されています。チェックサムは、改ざんを検出するためのUserInfoデータに含まれています。プロキシはプライベート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情報は、法執行機関へのわいせつや嫌がらせ電話を報告する機能と呼ばれるパーティを提供し顧客起源トレース・サービス、などの規制要件をサポートするために使用されます。このサービスは、独立して、発信者IDの提供、および、発信者が匿名を要求した場合でも動作します。発信者は、ここでコールを発信するステーションとして識別されます。このサービスは、信頼されるために、着信側が提示されている呼び出し元の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
信頼できないユーザエージェントクライアント（UAC）から顧客由来のトレースを開始するために、追加のヘッダは、INVITE要求のために定義されています。このヘッダは、P-DCS-トレースパーティ-IDと呼ばれ、他の任意の要求または応答に表示されません。信頼できないUACはまた、
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.
明示的コールを識別するために、INVITE要求に、[RFC4538]で定義されたターゲット対話ヘッダフィールドは、追跡されます。要求URIによって対処エンティティは、記録のサービス・プロバイダ固有の機能を実行し、法執行活動のためのP-DCS-トレースパーティ-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
P-DCS-トレースパーティ-ID = "P-DCS-トレースパーティ-ID" HCOLON名-addrに* 1（SEMIタイムスタンプのparam）*（SEMIトレースのparam）タイムスタンプのparam = "タイムスタンプ=" 1 * DIGITの[ "" 1 * DIGIT]トレースのparam =ジェネリック-PARAM。 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.
名前-addrにに含まれているのaddr-specは、リモートエンドポイントを識別するURLが含まれています。 ADDR-specは、典型的にトレースするセッションを確立し、シグナリングメッセージにおいて提供されるよう、リモートエンドポイントのアイデンティティを与える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.
タイムスタンプ-paramがUAは、それがトレースされるように要求コールのセッション開始要求を受けた決定時間の値が含まれています。タイムスタンプPARAMは、RFC 1305 [RFC1305]で定義されており、簡易ネットワークタイムプロトコル[RFC4330]によって使用されるネットワーク・タイム・プロトコルのタイムスタンプ形式を使用して移入されます。タイムスタンプは、[RFC3629]あたりのUTF-8形式でエンコードされるべきです。トレース-paramが将来の拡張のための一般的なパラメータです。
An example of the P-DCS-Trace-Party-ID header is shown as follows:
次のようにP-DCS-トレース-Party-IDヘッダーの例が示されています。
P-DCS-Trace-Party-ID: <sip:+12345678912@domain.com;user=phone>; timestamp=3434688831.2327
P-DCS-トレースパーティ-ID：<SIP：+12345678912@domain.com;ユーザー=電話>。タイムスタンプ= 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は、顧客発信トレース要求の初期INVITEメッセージ内のP-DCS-トレース-Party-IDヘッダーを挿入する必要があります。信頼できないユーザエージェントクライアントからのトレース要求は、ダイアログの間、またはダイアログのリリース後に開始されるか、またはそれを呼び出すことができているトレースすることを要求されます。 UACは、信頼できないUAのためのエンティティを追跡コールを識別する「コールトレース」に設定ユーザー情報とホスト側とのRequest-URIにSIP URIを使用しなければなりません。 P-DCS-トレースパーティ-IDの[RFC3603]バージョンは、タイムスタンプ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-トレースパーティ-IDに匿名としてユーザーに示す必要があります@ 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-トレース-Party-IDヘッダーは、UACからの初期INVITE要求に存在し、INVITEのリクエストURIはUASに設定された「コールトレース」とのHostPortに設定ユーザー情報がある場合、UASは必須法執行アクションのターゲット対話ヘッダフィールドから記録と呼び出し元のIDを報告し、関連するトレースパラメータ（もしあれば）のサービス・プロバイダ固有の機能を実行します。 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-トレース-Party-IDヘッダーは、UACからの初期INVITE要求に存在しない、とのINVITEのRequest-URIは「コールトレース」に設定するユーザー情報がある場合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.
プロキシ手順の二組が定義される：（1）終端プロキシで発信プロキシでの手順、及び（2）の手順。発信プロキシは、信頼されていないエンドポイントからINVITE要求を受信したプロキシです。
The terminating proxy is a proxy that sends the INVITE request to an untrusted endpoint.
終端プロキシは、信頼されていないエンドポイントにINVITEリクエストを送信するプロキシです。
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.
両方が信頼されていないエンドポイントからINVITE要求を受信し、信頼されていないエンドポイントにINVITE要求を送るプロキシは、手順の両方のセットを実行します。
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-トレース-Party-IDヘッダーは、UACからの初期INVITE要求に存在し、「トレースを呼び出す」とのHostPortは、潜在的にプロビジョニングコール以外に設定以外のユーザー情報INVITEのRequest-URIが有する場合エンティティをトレースし、プロキシは、要求を拒否してもよいし、その要求からP-DCS-トレース-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.
プロキシは、呼び出し元のURLを記録し、ネットワークオペレータによってそうするようにプロビジョニングすると、信頼できないUACに向けたセッションにダイアログのIDをターゲットにしています。 P-DCS-トレース-Party-IDヘッダーは有効な要求に存在しており、名前-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.
発信プロキシは既にヘッダが含まれていない要求からP-DCS-トレース-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ヘッダを使用します。我々は（米国では例えば、ハウリング/持続的なトーンリング）オペレータ呼出用忙しいライン緊急割り込みの検証、「EI」、および「RING」のために、このヘッダフィールド、すなわち「BLV」の三つの値を定義します。
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」のいずれかでINVITEへのユーザエージェントの応答は、ビジー表示されません。 「EI」とのみ確立ダイアログ上で発生する「RING」以来、彼らはまた、UPDATEリクエストで表示されることがあります。
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
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPSタグOSPSタグ= "BLV" / "EI" / "RING" /トークン
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-トランクグループと呼ばれ、不注意による使用を防止する特殊なシグナリング手順を採用しています。 PSTN OSPSシステムで発信されるコールは、このトランクグループを介して送信され、そしてP-DCS-OSPSヘッダーを持つINVITEリクエストをもたらしています。
This header MAY be sent in an INVITE request, and MUST NOT appear in any message other than those listed below.
このヘッダーはINVITEリクエストで送信されてもよく、以下に列挙したもの以外のメッセージに現れてはいけません。
OSPS-Tag value "BLV" MUST NOT appear in any request other than an initial INVITE request establishing a new dialog.
OSPSタグ値「BLVは、」新しいダイアログを確立する最初のINVITE要求以外の要求に現れてはいけません。
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タグ値「EI」は、任意の要求または（1）以降は「BLV」のOSPSタグ値との間で確立既存のダイアログ内INVITE、または既存のダイアログ内（2）UPDATE要求以外応答して現れてはいけません「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タグ値「環」は、任意の要求または（1）以降は、によって確立された既存のダイアログ内のオペレータまたはPSAP、または（2）UPDATE要求にUACによって確立された既存のダイアログ内INVITE以外応答して現れてはいけませんオペレータまたは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は「BLV」、既存のダイアログに一致ダイアログ識別のOSPSタグ付きINVITEリクエストを受信した場合、それは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はそれは、「BLV」のOSPSタグ値で設立された既存のダイアログと一致していませんダイアログ識別して、「EI」または「RING」のOSPSタグ値を持つINVITE / UPDATE要求をしなければならない受信した場合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タグ値が含まれており、このサービスを提供に協力して喜んでないINVITEを受信した場合、それは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タグとINVITEを拒否すべきではありません。 UASは「BLV」OSPSタグでINVITEにの3xxリダイレクト応答コードに応じてはいけません。 「BLV」OSPSタグがINVITE中に存在する場合、UASは、着信コール試行のユーザーに警告すべきではありません。
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タグとINVITE場合（例えば、全てのサービス品質（QoS）の前提条件などを満たし）、UASは、指定されたアドレスとポートにこの接続のオーディオストリームを送らなければなりませんINVITEのセッション記述プロトコル（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タグ付きINVITE / UPDATEが受け入れられた場合、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.
「RING」のOSPSタグ付きINVITE / UPDATEが受け入れられた場合、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応答でINVITE要求に応答してはいけません。
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コール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.
請求拡張は、信頼できるネットワークセグメント上に表示され、信頼されたネットワークセグメントを出る前に、信頼できるネットワーク・セグメントにおけるINVITEとSUBSCRIBEリクエストにプロキシまたは信頼UAによって挿入、および除去することができます。 P-DCS-課金-Infoヘッダー拡張が唯一のプロキシと、信頼のUA間の要求と応答に使用されています。それは、信頼できないUAに送信されることはありません。信頼されていないUAはこのヘッダを送信しないことが期待されます。
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 = "-" / "." / "(" / ")"
P-DCS-BILLING-INFO = "P-DCS-BILLING-INFO" HCOLON請求-相関-ID "/" FEID *（SEMI請求-INFO-PARAM）請求-相関-ID = 1 * 48（HEXDIG）FEID = 1 * 16（HEXDIG）ホスト "@" 課金-INFO-PARAM = RKS-グループ-ID-PARAM /充電-PARAM /呼び出し-PARAM /呼び出され-PARAM /ルーティング-PARAM /のLoc-ルーティング-PARAM / JIP-PARAM /一般的な-のparam RKS-グループ-ID-のparam = "rksgroup" EQUAL RKS-グループID RKS-グループID =トークンチャージのparam = "充電" EQUALのAcct-チャージ-URIのAcct-チャージ-URI = LDQUOT addrのスペック= EQUALのAcct-呼び出し-URIのAcct-呼び出し-URI EQUALのAcct-呼び出さ-URIのAcct-呼び出さ-URI = LDQUOTのaddrスペックRDQUOTのルーティング "と呼ばれる"-PARAM呼び出さ= LDQUOTのaddrスペックRDQUOT = "呼び出し" RDQUOT呼び出し-PARAM -param = "ルーティング" EQUAL ACCT-ルーティング-URI ACCT-ルーティング-URI = LDQUOT ADDRスペックRDQUOT用のLocルーティング-PARAM = "locroute" EQUALのAcct-LOC-ルーティング-URIのAcct-LOC-ルーティング-URI = LDQUOTのADDR -spec RDQUOT JIP-PARAM = "JIP" EQUAL JIPのJIP = LDQUOT 1 * phonedigitヘキサJIP-コンテキストRDQUOTのJIP-コンテキスト= "; JIP-コンテキスト=" JIP-記述子JIP-ディスクリプタ=グローバルヘクス桁グローバルヘキサ桁= "+" 1 * 3（phonedigit）* phonedigitヘキサphonedigit = DIGIT / [ビジュアルセパレータ] phonedigitヘキサ= HEXDIG / "*" / "＃" / [視覚セパレータ]ビジュアル・セパレータ= " - " / "" / "（" / "）"
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拡張は、請求可能なアカウントを使用して、おそらく異なるソースから、複数の使用状況レコードを関連付けるイベントレコーダによって使用することができる識別子を含みます。さらに、加入者口座情報、およびサービスの正確な課金のために必要なその他の情報が含まれています。このヘッダーは、プロキシと信頼のUAとの間で使用されます。
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、時間を与えNTPタイムスタンプの4バイト、IDを生成したネットワーク要素の一意の識別子の8バイト、8つのバイトを含む24バイトのバイナリ構造ようPCEM]で指定されゾーン、および単調そのネットワーク要素にシーケンス番号を増加させるの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.
金融エンティティ-ID（FEID）は、ドメイン名に続いて、そのドメインの金融識別子を含む、8バイトの構造ようPCEM]で指定されています。 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-グループ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チャージ-URI、ACCT-URIを呼び出す、ACCT-URIと呼ばれる各URLとして定義され、ACCTルーティング-URI、およびACCT-LOC-ルーティング-URI。彼らはすべてのE.164フォーマットされたアドレスを持つTEL URLを含める必要があります。これらのフィールドは、さらに[PCEM]要素識別子 "Charge_Number"（要素ID 16）、 "Calling_Party_Number"（要素ID 4）、 "Called_Party_Number"（要素ID 5）の下に、 "ルーティング番号"（要素ID 25）で定義され、そして "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がコールが発信されているネットワークの呼び出し管轄情報、または番号計画エリアが含まれています。フィールドは、さらに、要素識別子「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に送信されることはありません。信頼されていないUAはこのヘッダを送信しないことが期待されます。
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を生成し、呼に対する課金情報と共に、終端エンティティへ送信される初期INVITEまたはSUBSCRIBEメッセージ内のP-DCS-BILLING-INFOヘッダに挿入しなければなりません。 UACは、UACで使用されている記録保管サーバー用のFEID、およびRKS-グループ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.
最初のINVITEに対する応答が3XX、リダイレクトされた場合、UACは、標準SIPに従って、Contactヘッダフィールドで指定された宛先への新しい初期INVITE要求を生成します。 UACは、最初のINVITEへの3xxリダイレクト応答を受信した場合、INVITE UACによって生成された新しいは3XXリダイレクト応答のP-DCS-BILLING-INFOヘッダフィールド値を含まなければなりません。 UACは、代わりに、それは民間URLを生成し、発信エンドポイントに送信されたの3xxリダイレクト応答のContactヘッダーフィールドに配置してもよい（MAY）新しいINVITEを生成する、バックツーバックユーザエージェント（B2BUA）として動作している場合。このプライベート・URLが含まれている（またはポインタに含まれている）発信者の能力を制限するために、将来的には非常にすぐに新しいコールの充電配置を示してP-DCS-課金-情報値、および有効期限をしなければなりませんするために複数の呼び出しのために、このプライベート・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-課金-Infoヘッダーを含まなければならないREFERリクエストのヘッダー。このP-DCS-BILLING-INFOヘッダは、REFERのイニシエータの課金情報を含まなければなりません。
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は最初の信頼性（100を除く）1XXまたは初期INVITEまたはSUBSCRIBEメッセージへの2xx応答してP-DCS-BILLING-INFOヘッダを含まなければなりません。このP-DCS-BILLING-INFOヘッダは、UASが使用しているUAS、UASのFEID、および記録管理サーバのRKS-グループIDによって生成される請求-相関-IDを含まなければなりません。それは、INVITE（例えば、フリーダイヤル通話用）中に存在した課金情報を上書きしたい場合UASはACCT-チャージ-URIの値を変更することができます。これを行うための決断と新しいのAcct-チャージ-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は、転送先の宛先に送信先からのコールセグメントに対して、コール転送機能のための課金情報を与え、最初のINVITEへの3xxリダイレクト応答をP-DCS-BILLING-INFOヘッダを追加しなければなりません。
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.
発信プロキシは、信頼されていないエンドポイントからINVITEまたはSUBSCRIBEリクエストを受信したプロキシです。
The terminating proxy is a proxy that sends the INVITE or SUBSCRIBE request to an untrusted endpoint.
終端プロキシは、信頼されていないエンドポイントにINVITEまたはSUBSCRIBEリクエストを送信するプロキシです。
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
発信プロキシは、呼に対する課金-相関-IDを生成し、呼に対する課金情報と共に、終端エンティティへ送信される初期INVITEまたはSUBSCRIBEメッセージ内のP-DCS-BILLING-INFOヘッダに挿入しなければなりません。元のプロキシは、そのFEIDとのためのRKS-グループIDを含まなければなりません
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.
記録管理サーバは、発信プロキシによって使用されています。元のプロキシは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.
要求URIがプライベート・URLが含まれており、デコードされたユーザ名は、課金情報が含まれている場合は、元のプロキシはP-DCS-課金-情報は、その復号化された情報を持つヘッダを生成しなければなりません。そうでなければ、発信プロキシは、発信者のために課金情報を決定し、その情報を含む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.
最初のINVITEに対する応答が3XX、リダイレクトされた場合、前の非100暫定応答を受信し、発信プロキシは新たな初期の標準SIPに従って、Contactヘッダフィールドで指定された宛先へINVITEリクエストを生成します。発信プロキシが最初に3XXリダイレクト応答を受信した場合、先行非100暫定応答にINVITE、プロキシによって生成されたINVITEの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.
最初のINVITEに対する応答が3xxの、リダイレクトされた場合は、非100暫定応答の後に受信、発信プロキシは、プライベート・URLを生成し、発信エンドポイントに送信されたの3xxリダイレクト応答のContactヘッダにそれを配置します。このプライベート・URLが含まれている（またはポインタに含まれている）発信者の能力を制限するために、将来的には非常にすぐに新しいコールの充電配置を示してP-DCS-課金-情報値、および有効期限をしなければなりませんするために複数の呼び出しのために、このプライベート・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からのREFER要求を処理し、発信プロキシは、参照してください-へのURLにP-DCS-課金-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.
終端プロキシは最初の信頼性（100を除く）1XXまたは初期INVITEまたはSUBSCRIBEメッセージへの2xx応答してP-DCS-BILLING-INFOヘッダを含まなければなりません。このP-DCS-BILLING-INFOヘッダは、着信プロキシによって使用されている着信プロキシによって生成される請求-相関-ID、終端プロキシのFEID、および記録管理サーバのRKSグループIDを含まなければなりません。それは、INVITE（例えば、フリーダイヤル通話用）中に存在した課金情報を上書きしたい場合、終端プロキシはACCT-チャージ-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.
終端プロキシは、転送され、先に宛先からの呼セグメントに対して、コール転送機能のための課金情報を与え、最初のINVITEへの3xxリダイレクト応答を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.
半ば呼び出す参照してください-にヘッダを含んでREFERリクエストを受信したプロキシは、プライベート・URLを生成し、参照してください-するためにエンドポイントに送信されたヘッダにそれを配置します。このプライベート-URLは、この民間のを再利用するエンドポイントの能力を制限するために、将来的には非常にすぐに新しいコールの充電配置を示してP-DCS-課金-情報値、および有効期限を含まなければなりません複数の呼び出しのための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クエリーを実行した場合、それは応答（100を除く）第一信頼1XX / 2XX / 3XXに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ヘッダは、プロキシと信頼のUAとの間で使用されます。ここで定義された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-リダイレクト拡張子がリダイレクトされたコールの合法的に認定電子監視の要件をサポートするために必要なコールの識別情報が含まれています。このヘッダーは、プロキシと信頼のUAとの間で使用されます。
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-リダイレクト履歴-INFO前RFC 3603に存在に来RFC 4244.に指定されたヘッダP-DCS-リダイレクトヘッダと履歴-INFOの間の機能の重複があることに留意されたいです。したがって、P-DCS-リダイレクトヘッダは、既存の実装との後方互換性のためにここに続けられます。
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-リダイレクトの使用に従わなければなりません法律、規制、および裁判所命令の組み合わせによって制御されます。特定の場合において、これらのヘッダーを含めることが義務付けされ、したがって示さ要求及び応答に存在していなければなりません。他の場合では、これらのヘッダーを含めることは禁止され、したがって示さ要求及び応答に存在してはなりません。これらの競合状況を捕捉することを意図している「SHOULD」の使用に従うサブセクション、例えばでは、P-DCS-LAESヘッダは初期INVITE手段のいずれかが含まれなければならないか、してはならないことことが含まれるべきです該当する裁判所命令に基づいて、含まれています。
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-リダイレクトのフォーマットは、ヘッダーは次の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
天井-SIG =のHostPort天井PARAM =天井コンテンツ/天井cccid天井BCID /ジェネリック-PARAM天井コンテンツにおいてP-DCS-天井= "P-DCS-天井" HCOLON天井-SIG×（SEMI天井PARAM） =「コンテンツ」EQUALホスト側
Laes-bcid = "bcid" EQUAL 1*48(HEXDIG) Laes-cccid = "cccid" EQUAL 1*8(HEXDIG)
天井cccid = "cccid" EQUAL 1 * 8（HEXDIG）で天井BCID = "BCID" EQUAL 1 * 48（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
P-DCS-リダイレクト-IDと呼ばれる= "P-DCS-リダイレクト" HCOLON *（SEMI REDIR-のparams）と呼ばれる-ID = LDQUOT addrのスペックRDQUOTのREDIR-のparams = REDIR-URI-PARAM / REDIRカウント-PARAM /ジェネリック-param REDIR-URI-のparam = "リダイレクタ-URI" EQUALリダイレクタリダイレクタ= LDQUOTのaddrスペックRDQUOTのREDIR-カウントのparam = "カウント" EQUAL REDIRカウントREDIRカウント= 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含有量の値は、電子監視配信機能のアドレスであり、呼識別情報の宛先アドレスとして使用し、それぞれ、コンテンツを呼び出します。 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-リダイレクトヘッダは、リダイレクト情報を含みます。呼び出さ-IDは、ユーザによって要求元の宛先（例えば、番号が最初にダイヤルされた）を示し、REDIR-URI-paramがリダイレクトを実行するエンティティを示し、REDIRカウントが発生しているリダイレクトの数を示します。 AはDに転送Cに転送Bを呼び出した場合、次に、DのCの転送は、着信IDがされる場合、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の発信加入者のための卓越した合法的に許可された監視順序をチェックし、そして、存在する場合は、[PCDQOS】サービス品質の認可にこの情報を含むことができるか、切片（例えば、メディアを行う装置にこの情報をシグナリングすることができますゲートウェイ）。そうでなければ、インターセプトアクセスポイントは、この文書の範囲外であるメカニズムによってコールコンテンツ及び/又はコールデータインターセプトを実行するように指示されます。
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ヘッダは、（100を除く）最初の信頼1XX、2XX、又は3XX応答（指示監視を着信加入者に必要な、しかし終端装置がその機能を実行することができないということである）、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.
最初のINVITE要求への3xxリダイレクト応答を受信した場合、及びP-DCS-LAESヘッダは3xx応答中に存在する場合、UACは、再発行INVITEに不変そのヘッダを含むべきです。 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は、発信加入者が未処理の合法的に許可された監視順序を有する場合、参照の-TOをに取り付けP-DCS-LAESヘッダを含むべきです。 UACはまた、P-DCS-リダイレクトヘッダを含むかもしれません。 P-DCS-LAESヘッダはアドレスを含むべきである、コールのイベントメッセージのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきである、一意のコールを特定の値に設定Laes-BCIDパラメータを含んでもよい（MAY）通話内容のコピーのための局所的な電子監視配信機能のポートは、通話内容を傍受することで、通話内容を傍受する場合は一意に傍受されたオーディオストリームを識別する値に設定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-リダイレクトヘッダを送ってはいけません。
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は、優れた合法的に許可された監視着信加入者のため、またはINVITE要求内の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は、（100を除く）最初の信頼1XXに2XX、又は3XX応答要求をP-DCS-LAESヘッダを含むべきです監視を実行するために、発信プロキシ。 P-DCS-LAESヘッダは、コールのイベントメッセージのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきアドレスを含むべきであると、一意のコールを識別する値とLaes-BCIDパラメータを含んでもよい（MAY）コール・コンテンツのコピーのための局所的な電子監視配信機能のポートは、通話内容を傍受することで、通話内容を傍受する場合は一意に傍受されたオーディオストリームを識別する値に設定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.
最初のINVITE要求に対する応答が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-リダイレクトヘッダを送ってはいけません。
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.
プロキシ手順の二組が定義される：（1）終端プロキシで発信プロキシでの手順、及び（2）の手順。元のプロキシは、信頼されていないエンドポイントからのINVITEリクエストを受信するプロキシです。
The terminating proxy is a proxy that sends the INVITE request to an untrusted endpoint.
終端プロキシは、信頼されていないエンドポイントにINVITEリクエストを送信するプロキシです。
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.
両方が信頼されていないエンドポイントからINVITE要求を受信し、信頼されていないエンドポイントにINVITE要求を送るプロキシは、P-DCS-LAESもP-DCS-リダイレクトヘッダを生成してはいけません。
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-リダイレクトヘッダを通過させなければなりません。
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.
発信プロキシは、任意のP-DCS-LAES及び又は信頼できないプロキシまたは信頼できないUAからの要求または応答のP-DCS-リダイレクトヘッダを削除する必要があります。
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.
サービス【PCDQOS]又は傍受を行うデバイス（例えば、メディア・ゲートウェイ）にこの情報をシグナリングすることができます。そうでなければ、インターセプトアクセスポイントは、この文書の範囲外であるメカニズムによってコールコンテンツ及び/又はコールデータインターセプトを実行するように指示されます。
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ヘッダは、（100を除く）最初の信頼1XXに存在する場合、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.
初期でのRequest-URIは、要求がプライベート・URLが含まれているINVITE場合は、発信プロキシは、コールのための本当の目的地、および他の特別な処理情報を見つけることの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.
初期INVITE要求への3xxリダイレクト応答は、非100暫定応答の前に受信され、P-DCS-LAESヘッダは3xx応答中に存在する場合、発信プロキシは、INVITE再発行に不変そのヘッダを含むかどうか。発信プロキシは、元のダイヤルされた番号、最新のリダイレクトパーティ、および発生したリダイレクト数を含む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.
最初のINVITEリクエストに対する3xxの-リダイレクト応答が非100暫定応答後に受信された場合、元のプロキシは、プライベート・URLおよび発信エンドポイントに送信されたの3xxリダイレクト応答のContactヘッダ内の場所、それを生成します。 P-DCS-LAESヘッダは3xx応答中に存在する場合、このプライベートURL（3）の同一性を、（2）元の宛先番号、3XXリダイレクト応答を（1）から電子監視情報を含まなければなりませんパーティをリダイレクト、および（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からREFER要求[RFC3515]を処理し、発信プロキシは、発信加入者が未処理の合法的に許可された監視順序を有する場合に、その要求のB2BUAなります。これは、参照してください-へのURLに追加P-DCS-LAESヘッダーを持つ要求を再発行すべきです。また、P-DCS-リダイレクトヘッダを含むかもしれません。 P-DCS-LAESヘッダは、コピー（1）アドレスおよび呼び出しのイベント・メッセージのコピーのローカル電子監視配信機能のポート、（2）アドレスとローカル電子監視配信機能のポートを含むべきです通話内容を傍受する場合は、コンテンツを呼び出します。 P-DCS-LAESヘッダが一意的コールを特定の値に設定（1）Laes-BCIDパラメータ、及び一意的コールコンテンツ場合インターセプトオーディオストリームを特定の値に設定（2）Laes-cccidパラメータを含むかもしれ傍受されます。
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.
参照してください-Toヘッダーを含むREFERリクエストを半ば呼び出す送信開始プロキシは、開始加入者が優れた合法的に許可された監視順序を持っている場合、参照してください-への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-リダイレクトヘッダを送ってはいけません。
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.
終端プロキシは、任意のP-DCS-LAES及び又は信頼できないプロキシまたはUAからの要求または応答のP-DCS-リダイレクトヘッダを削除する必要があります。
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.
終端プロキシは、いずれかの要求または応答にヘッダとして、又は要求又は応答におけるURIに取り付けられたヘッダーとして、信頼できないエンティティにP-DCS-LAES及びP-DCS-リダイレクトヘッダを送ってはいけません。
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.
終端装置は、（宛先がボイスメール・サーバである場合、例えば、）必要な監視を行うことができない場合、終端プロキシは、応答が要求し（100を除く）第一信頼1XX / 2XX / 3XXにおけるP-DCS-LAESヘッダを含むべきです監視を実行するために、発信プロキシ。 P-DCS-LAESヘッダはアドレスを含むべきである、コールのイベントメッセージのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきである、一意のコールを特定の値に設定Laes-BCIDパラメータを含んでもよい（MAY）通話内容のコピーのためにローカル電子監視配信機能のポートは、通話内容を傍受することで、通話内容を傍受される場合、一意のオーディオストリームを特定の値に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.
最初のINVITE要求に対する応答が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.
参照の-に取り付けられたP-DCS-LAESヘッダを持つヘッダこの要求のB2BUAなる含み、通話要求をREFER [RFC3515]を受信するプロキシ。これは、民間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のゲートの調整、課金情報、および電子監視情報は、すべての盗聴から保護し、さらに整合性のチェックを必要としなければならない機密情報であると考えられています。信頼UAとプロキシが盗聴や改ざんからこの情報を保護するための予防策を講じることが必要です。プロキシと信頼されたUAの間のIPsecまたはTLSの使用が必要となります。 DCSアーキテクチャの最小必須ツー実装IPsec構成は[PCSEC]によって与えられます。必要管理事前共有キーで、または別の信頼できる第三者との協議を通じて実現されてもよいどちらも信頼UAとプロキシとの間のプロキシと（2）との間の相互認証（1）です。 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]
P-DCS-課金-情報はありません[RFC5503] P-DCS-課金-情報はありませんを呼び出し、[RFC5503] P-DCS-課金-情報と呼ばれるん[RFC5503] P-DCS-課金-情報はなし[RFC5503] P-をlocrouteない充電NO [RFC3603] P-DCS-LAESコンテンツなしをルーティングしないDCS-課金-情報rksgroupません[RFC5503] P-DCS-課金-情報[RFC5503] P-DCS-リダイレクトなし[RFC5503] P-DCS-リダイレクトリダイレクタ-URIをカウントしませんなし[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.
利用可能な場合、タイムスタンプパラメータはP-DCS-トレース-Party-IDヘッダーに追加され、O。 P-DCS-トレースパーティ-IDと一緒に使用されるターゲット対話ヘッダの使用に関する手順が追加されます。
o The JIP parameter is added to the P-DCS-Billing-Info header when available.
利用可能な場合JIPパラメータはP-DCS-BILLING-INFOヘッダに付加される、O。
o The BCID billing correlation identifier and cccid (call content channel identifier) are added to the P-DCS-LAES header.
BCID課金相関識別子とcccid O（コンテンツチャネル識別子を呼び出す）P-DCS-LAESヘッダに追加されます。
o P-DCS-Billing-Info header is applied to the SUBSCRIBE method.
O P-DCS-BILLING-INFOヘッダは、SUBSCRIBEメソッドに適用されます。
o P-DCS-REDIRECT header is applied to the REFER method.
O P-DCS-REDIRECTヘッダは、REFERメソッドに適用されます。
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 PUBLISHとMESSAGEメソッドは全体SIPメソッド適用マトリックスに添加されます。
o Correction is made to Table 2 to add m=modify.
O補正= Mを追加、変更するには、表2を参照されたいです。
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のプロジェクトにおける分散型コールシグナリングの仕事は、多くの異なる企業を代表する多数の人々の仕事です。著者は認識し、彼らの支援のために次のことを感謝したいと思います：ジョン・ホイーラー、モトローラ。デビッド・ボードマン、ダニエル・ポール、ARRISインタラクティブ。ビル・ブラム、ジョン・フェロー、ジェイストラター、ジェフOllis、クライヴHolborow、モトローラ。ダグNewlin、グイド・シュスター、Ikhlaqシドゥ、3Com社。ジリ・マトゥーセック、ベイネットワーク。 Farzi Khazai、ブライアン・リンゼイ。ノーテル;ジョン・チャップマン、ビルGuckel、マイケルRamalho、シスコ;チャックKalmanek、ダグNortz、ジョンLawser、ジェームズ・チェン、桐-ハイシャオ、Parthoミシュラ、AT＆T; Telcordia Technologies社;ルーセントケーブルコミュニケーションズ。そして、ミゲル・ガルシア、エリクソン。
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.
紙幣マーシャル（wtm@research.att.com）及びK. K.ラマクリシュナン（kkrama@research.att.com）、AT＆T。エド・ミラー（edward.miller@terayon.com）、Terayon。デビッド・ハンコック（D.Hancock @ Cablelabs.com）とグレン・ラッセル（G.Russell@Cablelabs.com）、CableLabsの。 Burcak Beser（burcak@juniper.net）ジュニパーネットワークス。マイクMannette（Michael_Mannette@3com.com）とクルト・スタインブレナー（Kurt_Steinbrenner@3com.com）、3Com社。デイブ・オラン（oran@cisco.com）とフレミングアンドレア（fandreas@cisco.com）、シスコシステムズ、ジョン・ピケンズ（jpickens@com21.com）、COM21。 Poornima Lalwaney（poornima.lalwaney@nokia.com）、ノキア。ジョン・フェローズ（jfellows@coppermountain.com）、カッパーマウンテンネットワーク。ドック・エバンス（n7dr@arrisi.com）ARRIS、そしてキース・ケリー（keith@netspeak.com）、NetSpeak。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、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]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（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]、RFC 4538、2006年6月ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）におけるダイアログ識別介して要求承認"。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、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]マーシャル、W.、オスマン、M.、アンドレア、F.、およびD.エヴァンス、「SIPベースの分散型コール制御メカニズムを利用し、キャリアクラスのテレフォニーサービスを提供するためのアーキテクチャの考慮事項」、2003年1月。
[PCDQOS] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Dynamic Quality of Service", August 2005.
[PCDQOS]ケーブルテレビラボラトリーズ社は、 "PacketCableの1.5仕様、サービスの動的品質"、2005年8月。
[PCEM] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Event Messages", December 2005.
[PCEM]ケーブルテレビラボラトリーズ社、 "PacketCableの1.5仕様、イベント・メッセージ"、2005年12月。
[PCSEC] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Security", January 2005.
[PCSEC]ケーブルテレビラボラトリーズ社は、 "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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（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]マーシャル、W.およびF.アンドレア、「プライベート・セッション開始プロトコル（SIP）プロキシ・ツー・プロキシ呼シグナリングアーキテクチャ分散のPacketCableサポートするための拡張機能」、RFC 3603、2003年10月。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Edison, NJ USA
フレミングAndreasenのシスコエジソン、NJ USA
EMail: fandreas@cisco.com
メールアドレス：fandreas@cisco.com
Bernie McKibben CableLabs Louisville, CO USA
バーニー・マッキベンCableLabsのルイビル、CO USA
EMail: B.McKibben@cablelabs.com
メールアドレス：B.McKibben@cablelabs.com
Bill Marshall AT&T Florham Park, NJ USA
ビル・マーシャルAT＆Tフローラムパーク、NJ USA
EMail: wtm@research.att.com
メールアドレス：wtm@research.att.com