Network Working Group                                   W. Marshall, Ed.
Request for Comments: 3603                                          AT&T
Category: Informational                                F. Andreasen, Ed.
                                                                   Cisco
                                                            October 2003
        

Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture

プロキシ・ツー・プロキシの拡張コール・シグナリング・アーキテクチャ分散のPacketCableをサポートするためのプライベートセッション開始プロトコル(SIP)

Status of this Memo

このメモの位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2003). All Rights Reserved.

著作権(C)インターネット協会(2003)。全著作権所有。

Abstract

抽象

In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

異なるドメイン間の非常に大規模で、住宅の電話サービスを展開するためには、顧客固有の情報とコール当事者についての期待を伝える信頼できる情報を交換するために、異なるサービスプロバイダが所有している、信頼できる要素が必要です。この文書では、PacketCableの分散型コールシグナリングアーキテクチャにおける信頼されたエンティティ間の顧客情報や課金情報の交換をサポートするためのセッション開始プロトコル(SIP)(RFC3261)にプライベート拡張機能について説明します。これらの拡張機能は、サービスの盗難を防ぐために、アクセスネットワークの調整のためのメカニズムを提供し、顧客が他のさまざまな規制上の問題のために嫌がらせのコールのトレース、オペレータサービスや緊急サービスのサポート、およびサポートを開始しました。エクステンションの使用は、閉じた管理ドメイン内、または充電の調整や他の機能が必要とされる以前に合意された政策と管理ドメインの連合の間でのみ適用されます。

Table of Contents

目次

   1.  Applicability Statement . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Conventions used in this document . . . . . . . . . . . . . .  6
        
   5.  P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . .  6
       5.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  7
       5.2.  Procedures at an Untrusted User Agent Client (UAC). . .  7
       5.3.  Procedures at a Trusted User Agent Client (UAC) . . . .  7
       5.4.  Procedures at an Untrusted User Agent Server (UAS). . .  7
       5.5.  Procedures at a Trusted User Agent Server (UAS) . . . .  7
       5.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . .  8
             5.6.1.  Procedures at Originating Proxy . . . . . . . .  8
             5.6.2.  Procedures at Terminating Proxy . . . . . . . .  8
   6.  P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . .  8
       6.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  9
       6.2.  Procedures at an Untrusted User Agent Client (UAC). . .  9
       6.3.  Procedures at a Trusted User Agent Client (UAC) . . . . 10
       6.4.  Procedures at an Untrusted User Agent Server (UAS). . . 10
       6.5.  Procedures at a Trusted User Agent Server (UAS) . . . . 11
       6.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . . 11
   7.  P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11
       7.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13
       7.2.  Procedures at an Untrusted User Agent Client (UAC). . . 14
       7.3.  Procedures at a Trusted User Agent Client (UAC) . . . . 14
       7.4.  Procedures at an Untrusted User Agent Server (UAS). . . 15
       7.5.  Procedures at a Trusted User Agent Server (UAS) . . . . 15
       7.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . . 16
             7.6.1.  Procedures at Originating Proxy . . . . . . . . 16
             7.6.2.  Procedures at Terminating Proxy . . . . . . . . 17
             7.6.3.  Procedures at Tandem Proxy. . . . . . . . . . . 18
   8.  P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18
       8.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19
       8.2.  Procedures at an Untrusted User Agent Client (UAC). . . 20
       8.3.  Procedures at a Trusted User Agent Client (UAC) . . . . 20
       8.4.  Procedures at an Untrusted User Agent Server (UAS). . . 21
       8.5.  Procedures at a Trusted User Agent Server (UAS) . . . . 21
       8.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . . 21
             8.6.1.  Procedures at Originating Proxy . . . . . . . . 22
             8.6.2.  Procedures at Terminating Proxy . . . . . . . . 23
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . 24
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
   11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . 25
       12.1. Normative References. . . . . . . . . . . . . . . . . . 25
       12.2. Informative References. . . . . . . . . . . . . . . . . 26
   13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26
   14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
   15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
        
1. Applicability Statement
1.適用性に関する声明

The SIP extensions described in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally not applicable in the Internet as a whole. The use of these headers is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required, as in for example the architecture presented in [6]. Use outside such a domain could result in the leakage of potentially sensitive or private information. User consent to the privacy implications of the policies in [6] is strongly encouraged in those domains as well.

この文書に記載されたSIP拡張機能は、ネットワークトポロジ、SIPと下層との間の結合、及び推移的な信頼の可用性に関する一定の仮定を行います。これらの仮定は、全体として、インターネットで一般的に適用されません。これらのヘッダーの使用は、閉じた管理ドメイン内に、又は例えばアーキテクチャ[6]に示されるよう充電の調整及び他の機能は、必要とされる以前に合意された方針に管理ドメインの連合の間のみ適用可能です。潜在的に機密情報や個人情報の漏洩につながる可能性があり、そのようなドメインの外に使用します。 [6]における政策のプライバシーへの影響へのユーザーの同意を強く同様にそれらのドメインに奨励されています。

Although RFC 2119 language is used in this document, the scope of the normative language is only for the area of applicability of the document and, like the technology, it does not apply to the general Internet.

RFC 2119の言語がこの文書で使用されているが、規範的な言語の範囲は、文書のみの適用領域のためであると、技術のように、それは一般的なインターネットには適用されません。

2. Introduction
2.はじめに

In order to deploy a SIP-based [2] residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys billing information and expectations about the parties involved in the call.

異なるドメイン間の非常に大規模で、SIPベース[2]住宅用電話サービスを展開するためには、コール当事者に関する課金情報と期待を伝える信頼できる情報を交換するために、異なるサービスプロバイダが所有している、信頼できる要素が必要です。

There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.

今日の電話サービスからの収入を導出する際に使用される多くの課金モデルがあります。電話サービスのために充電するしっかりとネットワーク資源の利用に連結されています。これは、これらの数多くの様々な方法の詳細を議論するために、このドキュメントの範囲外です。

A key motivating principle of the DCS architecture described in [6] is the need for network service providers to be able to control and monitor network resources; revenue may be derived from the usage of these resources as well as from the delivery of enhanced services such as telephony. Furthermore, the DCS architecture recognizes the need for coordination between call signaling and resource management. This coordination ensures that users are authenticated and authorized before receiving access to network resources and billable enhanced services.

〔6〕に記載のDCSアーキテクチャの主要な動機原理を制御し、ネットワークリソースを監視できるようにするネットワークサービスプロバイダーの必要性です。売上高は、これらのリソースの使用状況から、ならびに電話など高度なサービスの提供に由来することができます。さらに、DCSのアーキテクチャは、コールシグナリングとリソース管理の間の調整の必要性を認識しています。この調整は、ユーザーが認証され、ネットワークリソースや請求可能な拡張サービスへのアクセスを受信する前に承認されていることを保証します。

DCS Proxies, as defined in [6], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connectivity and resource policy enforcement mechanism and also capture and report network connectivity and resource usage information. Edge routers need to be given billing information that can be logged with Record Keeping or Billing servers. The DCS Proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among DCS Proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call. See [6] for a description of the trust boundary and trusted versus untrusted entities.

DCSプロキシは、[6]で定義されるように、パスシグナリング呼沿っ情報とポリシー決定ポイントとして機能し、信頼できる仲介者を加入者にアクセス権を持っています。エッジルータは、ネットワーク接続およびリソースポリシー適用メカニズムを提供し、またネットワーク接続およびリソースの使用状況に関する情報をキャプチャし、報告します。エッジルータは、レコードキーピングや課金サーバにログインすることができ課金情報を与えられる必要があります。 DCSプロキシは、コールシグナリングとリソース管理の間の調整の中心点として、発信側と着信側の認証された識別情報に基づいて、この情報を提供することができます。 DCSプロキシ間の信頼関係があるので、彼らは、コール当事者に関する信頼できる課金情報を交換するために依拠することができます。信頼境界の説明については、[6]を参照してくださいと信頼できないエンティティに対する信頼できます。

For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. It is the intent that the extensions would only appear on trusted network segments, should be inserted upon entering a trusted network region, and removed before leaving trusted network segments.

これらの理由から、DCSプロキシは、コールセットアップ中に情報を交換できるようにするためにSIPヘッダの拡張を定義することを検討することが適切です。拡張子が信頼できるネットワークセグメントを離れる前に、信頼できるネットワーク領域に入ると、挿入、および削除する必要があり、信頼できるネットワークセグメント上に現れるであろうとの意図です。

Significant amounts of information is retrieved by an originating DCS Proxy in its handling of a connection setup request from a user agent. Such information includes location information about the subscriber (essential for emergency services calls), billing information, and station information (e.g., coin operated phone). In addition, while translating the destination number, information such as the local-number-portability office code is obtained and will be needed by all other proxies handling this call.

大量の情報をユーザエージェントからの接続セットアップ要求の取り扱いに起因するDCSプロキシによって取得されます。そのような情報は、加入者の位置情報(緊急サービス・コールのために必須)、課金情報、及び局情報を(例えば、コインが電話を操作する)を含みます。宛先番号を変換しながら加えて、そのようなローカル・ナンバー・ポータビリティ・オフィス・コードなどの情報が得られ、このコールを処理し、他のすべてのプロキシによって必要とされます。

For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.

使用状況アカウンティングレコードの場合は、呼び出しのために作成されたすべてのイベントレコードに関連付けることができ識別子を持つことが必要です。 SIPコールIDヘッダフィールドは、それが発信ユーザエージェントによって選択されているので、このような識別子として使用することができず、すべての過去の通話と同様に現在のコールの中で一意でなくてもよいです。この識別子は、サービスプロバイダによって使用されるので、それはのようにして、サービスプロバイダのニーズを満たしているフォーマットに選択されるべきです。

Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split-charging where multiple entities are billed for portions of the call.

課金情報は、必ずしも(すべて同じアカウントに請求オフィスからの通話の場合を考えて)各ユーザーの一意ではないかもしれません。課金情報は、必ずしも(プリペイド通話、クレジットカード通話、コレクトコール、などを考慮して)単一のユーザーによって行われたすべてのコールのために同一ではないかもしれません。呼び出し元とは別のパーティの識別と呼ばれる課金情報を運ぶために必要があります。さらに、一部の課金モデルは、複数のエンティティがコールの部分に対して請求されているスプリット・充電のために呼び出します。

The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.

SIP一般ヘッダーフィールドの添加は、呼の持続時間情報及び課金識別子を課金の捕捉を可能にします。

It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a DCS Proxy in INVITE and REFER requests and INVITE responses in a trusted network segment, and removed before leaving trusted network segments.

課金機能拡張は、信頼できるネットワークセグメント上に現れるであろうとの意図で、INVITEやREFERリクエストにDCSプロキシによって挿入され、信頼されるネットワークセグメントで応答をINVITE、および信頼できるネットワークセグメントを離れる前に除去することができます。

In addition to support for billing, current residential telephone service includes the need for customer originated trace (of harassing or obscene calls), for operator services such as busy line verification and emergency interrupt (initiated by an operator from an Operator Services Position System (OSPS)), for emergency services such as 9-1-1 calls to a Public Service Access Point (PSAP) and the subsequent call handling, and support for Electronic Surveillance and Law Enforcement access as required by applicable legislation and court orders. In all of these cases, additional information about the call and about the subscribers involved in the call needs to be exchanged between the proxies.

課金のサポートに加えて、現在の住宅用電話サービスは、顧客の必要性を含むオペレータサービスポジションシステムからオペレータによって開始され、このような忙しいラインの確認や緊急割り込みとしてオペレータサービスは、((OSPSのために、(嫌がらせやわいせつ呼び出しの)トレースを発し適用される法律や裁判所の命令により必要とされる))、など9-1-1などの緊急サービスのための公共サービスアクセスポイント(PSAP)と、その後の通話処理、および電子監視と法執行機関のアクセスのためのサポートを呼び出します。これらすべての場合には、コールについて、コールに関与し、加入者に関する追加情報は、プロキシ間で交換する必要があります。

3. Trust Boundary
3.信頼境界

The DCS architecture [6] defines a trust boundary around the various systems and servers that are owned, operated by, and/or controlled by the service provider. These trusted systems include the proxies and various servers such as bridge servers, voicemail servers, announcement servers, etc. Outside of the trust boundary lie the customer premises equipment, and various application and media servers operated by third-party service providers.

DCSアーキテクチャ[6]は、所有によって操作、及び/又はサービスプロバイダによって制御される様々なシステムおよびサーバの周りの信頼境界を画定します。これらの高信頼性システムは、信頼境界の外のプロキシや、ブリッジサーバなどの各種サーバ、ボイスメールサーバ、アナウンスサーバなどが含まれる顧客宅内機器をうそ、およびサードパーティのサービスプロバイダは、様々なアプリケーションサーバーおよびメディアサーバー。

Certain subscriber-specific information, such as billing and accounting information, stays within the trust boundary. Other subscriber-specific information, such as endpoint identity, may be presented to untrusted endpoints or may be withheld based on subscriber profiles.

そのような請求や会計情報などの特定の加入者固有の情報は、信頼境界内に留まります。そのようなエンドポイントIDとして他の加入者固有の情報は、信頼されていないエンドポイントに提示され得るか、または加入者プロファイルに基づいて、保留されてもよいです。

The User Agent (UA) may be either within the trust boundary or outside the trust boundary, depending on exactly what function is being performed and exactly how it is being performed. Accordingly, the procedures followed by a User Agent are different depending on whether the UA is within the trust boundary or outside the trust boundary.

ユーザーエージェント(UA)は、関数が実行されて、それが正確にどのように実行されている正確に何に応じて、信頼境界内または信頼境界の外のいずれであってもよいです。従って、ユーザエージェントによってその後の手順は、UAは、信頼境界内または信頼境界外にあるかどうかに応じて異なります。

The following sections giving procedures for User Agents therefore are subdivided into trusted user agents and untrusted user agents.

したがって、ユーザエージェントのための手順を与える次のセクションでは、信頼できるユーザーエージェントと信頼できないユーザエージェントに細分化されています。

4. Conventions used in this document
この文書で使用されている4.表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。

The term "private-URL" used in this document refers to a SIP URI that is generated by a proxy, contains a "hostport" that identifies the proxy, and contains a "userinfo" string that is generated by the proxy. The "userinfo" typically contains (or points to) information that is not to be disclosed outside the trusted domain of the proxies, such as billing account numbers, electronic surveillance indication, electronic surveillance parameters, and call redirection information. Consequently, the information is either stored locally by the proxy, or encrypted with a private key known only to the proxy and encoded in a character string in the "userinfo" portion of the URL. A checksum is included in the "userinfo" data to detect tampering. The mechanism by which a proxy recognizes a "userinfo" as a private-URL and decodes and recovers the original information is local to the proxy and is not subject to standardization. Some possible implementations include an initial magic cookie (e.g., z9hG4Bk followed by the pointer/information), or use of a reserved "user" name (e.g., "private") with the optional "password" containing the pointer/information.

この文書で使用される用語「民間-URLは、」プロキシによって生成されたSIP URIを指し、プロキシを識別する「ホスト側」が含まれており、プロキシによって生成された「userinfoを」文字列が含まれています。そのような請求アカウント番号、電子監視指示、電子的監視パラメータ、呼リダイレクト情報としてプロキシの信頼されたドメイン外に開示されるべきではなく、典型的には(にまたはポイント)が含まれ、「ユーザー情報」の情報。その結果、情報がいずれかのプロキシでローカルに保存されている、またはURLの「userinfoを」部分の文字列にプロキシにのみ知られており、エンコードされた秘密鍵で暗号化されています。チェックサムは、改ざんを検出するために、「userinfoを」データに含まれています。プロキシはプライベートURL及び復号などの「ユーザー情報」を認識し、元の情報を回復するメカニズムは、プロキシにローカルであり、標準化の対象ではありません。いくつかの可能な実装は、ポインタ/情報を含むオプションの「パスワード」と名前(例えば、「プライベート」)初期のマジッククッキー(ポインタ/情報続い例えば、z9hG4Bk)、または予約「ユーザ」の使用を含みます。

5. P-DCS-TRACE-PARTY-ID
5. P-DCS-TRACE-PARTY-ID

In the telephone network, calling identity information is used to support regulatory requirements such as the Customer Originated Trace service, which provide the called party with the ability to report obscene or harassing phone calls to law enforcement. This service is provided independently of caller-id, and works even if the caller requested anonymity. The calling party is here identified as the station originating the call. In order for this service to be dependable, the called party must be able to trust that the calling identity information being presented is valid. One way to achieve this is described in [10].

電話ネットワークでは、呼び出し元のID情報は、法執行機関へのわいせつや嫌がらせ電話を報告する機能と呼ばれるパーティを提供し顧客起源トレース・サービス、などの規制要件をサポートするために使用されます。このサービスは、独立して、発信者IDの提供、および、発信者が匿名を要求した場合でも動作します。発信者は、ここでコールを発信するステーションとして識別されます。このサービスは、信頼されるために、着信側が提示されている呼び出し元のID情報が有効であることを信頼できなければなりません。これを達成する1つの方法は、[10]に記載されています。

To initiate a customer-originated-trace from an untrusted UAC, an additional header is defined for the INVITE request. This header is called P-DCS-Trace-Party-ID, and does not appear in any other request or response. The entity addressed by the Request-URI performs the service-provider-specific functions of recording and reporting the caller identity in the P-DCS-Trace-Party-ID for law enforcement action. It then forwards the call to either an announcement server or to the service-provider's business office to collect further information about the complaint. A trusted UAC does not use this header, as it initiates this action locally.

信頼できないUACから顧客由来のトレースを開始するために、追加のヘッダーは、INVITE要求のために定義されています。このヘッダは、P-DCS-トレースパーティ-IDと呼ばれ、他の任意の要求または応答に表示されません。要求URIによって対処エンティティは、記録のサービス・プロバイダ固有の機能を実行し、法執行活動のためのP-DCS-トレースパーティ-IDに、発信者の身元を報告します。その後、苦情についての更なる情報を収集するためにどちらかのアナウンスサーバやサービスプロバイダーのビジネスオフィスにコールを転送します。それがローカルにこのアクションを開始として信頼UACは、このヘッダーを使用していません。

5.1. Syntax
5.1. 構文

The ABNF description of this header is (some terms used in this ABNF are defined in [2]):

このヘッダのABNF記述(このABNFで使用されるいくつかの用語が定義されている[2])です。

P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr

P-DCS-トレースパーティ-ID = "P-DCS-トレースパーティ-ID" HCOLON名-addrに

This document adds the following entry to Table 2 of [2]:

この文書では、[2]の表2に次のエントリを追加します。

      Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
      ------------         ----- -----  ---  ---  ---  ---  ---  ---
      P-DCS-Trace-Party-ID   R     dr    -    -    -    o    -    -
        
                                        SUB  NOT  REF  INF  UPD  PRA
                                        ---  ---  ---  ---  ---  ---
                                         -    -    -    -    -    -
        

The addr-spec contained in name-addr contains a URL that identifies the remote endpoint. Addr-spec typically contains a tel: URL or SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that established the session to be traced.

名前-addrにに含まれているのaddr-specは、リモートエンドポイントを識別するURLが含まれています。 ADDR-specは通常、TELが含まれています:トレースするセッションを確立したシグナリングメッセージで提供されるURLまたはSIP URIは、リモートエンドポイントのアイデンティティを与えます。

5.2. Procedures at an Untrusted User Agent Client (UAC)
5.2. 信頼できないユーザエージェントクライアントでの手順(UAC)

The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The UAC MUST use a SIP URI in the Request-URI with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA.

UACは、顧客発信トレース要求の初期INVITEメッセージ内のP-DCS-トレース-Party-IDヘッダーを挿入する必要があります。 UACは、信頼できないUAのためのエンティティを追跡コールを識別する「コールトレース」に設定ユーザー情報とホスト側とのRequest-URIにSIP URIを使用しなければなりません。

5.3. Procedures at a Trusted User Agent Client (UAC)
5.3. 信頼できるユーザエージェントクライアントでの手順(UAC)

A trusted UAC performs the customer-originated-trace in a manner similar to the trusted UAS, described below. A trusted UAC MUST NOT include this header in any request.

信頼されたUACは、後述する信頼UASと同様に、顧客由来トレースを行います。信頼されたUACは、任意のリクエストでこのヘッダーを含んではいけません。

5.4. Procedures at an Untrusted User Agent Server (UAS)
5.4. 信頼できないユーザエージェントサーバ(UAS)での手続き

This header MUST NOT appear in any response sent by a UAS.

このヘッダは、UASによって送信された応答に現れてはいけません。

5.5. Procedures at a Trusted User Agent Server (UAS)
5.5. 信頼できるユーザエージェントサーバ(UAS)での手続き

If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" and hostport set to the UAS, the UAS MUST perform the service-provider-specific functions of recording and reporting the caller identity for law enforcement action. The UAS then MUST redirect the call, via a 3xx response, to either an announcement server or to the service-provider's business office to collect further information about the complaint.

P-DCS-トレース-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によって送信された応答に現れてはいけません。

5.6. Procedures at Proxy
5.6. プロキシでの手続き

Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.

プロキシ手順の二組が定義される:(1)終端プロキシで発信プロキシでの手順、及び(2)の手順。元のプロキシは、信頼されていないエンドポイントからINVITE要求を受信したプロキシです。

The terminating proxy is a proxy that sends the INVITE request to a non-trusted 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要求を送るプロキシは、手順の両方のセットを実行します。

5.6.1. Procedures at Originating Proxy
5.6.1. 発信プロキシでの手順

If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace" and hostport set to other than a potentially provisioned call tracing entity, then the Proxy MAY reject the request, or MAY remove the P-DCS-Trace-Party-ID header from the request. If the header is present in a valid request, and contains a private-URL that identifies the Proxy in the hostport, then the Originating Proxy SHOULD replace the private-URL with its original contents (i.e., the verified identity of the caller of the session that is being traced).

P-DCS-トレース-Party-IDヘッダーは、UACからの初期INVITE要求に存在し、「トレースを呼び出す」とのHostPortは、潜在的にプロビジョニングコール以外に設定以外のユーザー情報INVITEのRequest-URIが有する場合エンティティをトレースし、プロキシは、要求を拒否してもよいし、要求からP-DCS-トレース-Party-IDヘッダーを除去することができます。ヘッダが有効な要求に存在し、ホスト側でのプロキシを特定のプライベート・URLが含まれている場合、発信プロキシは、その元の内容(すなわち、セッションの呼び出し側の検証アイデンティティとプライベート-URLを置き換える必要がありますそれは)トレースされています。

5.6.2. Procedures at Terminating Proxy
5.6.2. 終端プロキシでの手順

This header MUST NOT appear in any request or response sent by a terminating proxy to an untrusted endpoint.

このヘッダは信頼できないエンドポイントに終端プロキシによって送信された任意の要求または応答に現れてはいけません。

6. P-DCS-OSPS
前記P-DCS-OSPS

Some calls have special call processing requirements that may not be satisfied by normal user agent call processing. For example, when a user is engaged in a call and another call arrives, such a call might be rejected with a busy indication. However, some PSTN operator services require special call processing. In particular, the Busy Line Verification (BLV) and Emergency Interrupt (EI) services initiated by an operator from an Operator Services Position System (OSPS) on the PSTN network have such a need. Similarly, emergency calls to a 9-1-1 Public Service Access Point (PSAP) may result in trunk signaling causing operator ringback using a howling tone or sustained ring on the originating line (country-specific variations may exist).

いくつかの呼び出しは、通常のユーザエージェント呼処理によって満たされないことがあり、特殊な呼処理の要件を持っています。たとえば、ユーザーが呼び出しに従事し、別のコールが到着したとき、そのような呼び出しがビジー表示を拒否されることがあります。ただし、一部のPSTNのオペレータサービスは、特別なコール処理が必要です。具体的には、PSTNネットワーク上のオペレータサービス位置システム(OSPS)からオペレータによって開始さビジー・ラインの検証(BLV)と緊急割り込み(EI)のサービスは、このようなニーズを持っています。同様に、9-1-1公共サービスアクセスポイント(PSAP)に緊急呼を発信線(国特有のバリエーションが存在していてもよい)にハウリング音や持続リングを使用して、オペレータのリングバックを引き起こすトランクシグナリングをもたらすことができます。

In order to inform the SIP user agent that special treatment should be given to a call, we use a new P-DCS-OSPS header field, which may be set to a value indicating when a special type of call processing is requested. We define three values in this header, namely "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (e.g., howling/sustained tone ring in the US).

特別な処理は、呼に与えられるべきであることをSIPユーザエージェントに通知するために、我々は、呼処理の特殊なタイプが要求されたときを示す値に設定することができる新たなP-DCS-OSPSヘッダフィールドを使用します。私たちは忙しいライン検証のため、このヘッダ、すなわち「BLV」の三つの値を定義し、(米国では例えば、ハウリング/持続トーンリング)オペレータのリングバックのための緊急割り込み、および「RING」のための「EI」。

If the user agent decides to honor such a request, the response of the user agent to an INVITE with either "BLV" or "EI" will not be a busy indication. Since "EI" and "RING" only occur on established dialogs, they may also appear in UPDATE requests.

ユーザエージェントは、このような要求を尊重することを決定した場合、「BLV」または「EI」のいずれかでINVITEへのユーザエージェントの応答は、ビジー表示されません。 「EI」とのみ確立ダイアログ上で発生する「RING」以来、彼らはまた、UPDATEリクエストで表示されることがあります。

6.1. Syntax
6.1. 構文

The ABNF description of the P-DCS-OSPS header is as follows (some terms used in this ABNF are defined in [2]):

次のようにP-DCS-OSPSヘッダのABNF記述がある(このABNFで使用されるいくつかの用語が定義されている[2])。

P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag OSPS-Tag = "BLV" / "EI" / "RING" / token

P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPSタグOSPSタグ= "BLV" / "EI" / "RING" /トークン

This document adds the following entry to Table 2 of [2]:

この文書では、[2]の表2に次のエントリを追加します。

      Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
      ------------         ----- -----  ---  ---  ---  ---  ---  ---
      P-DCS-OSPS             R     dr    -    -    -    o    -    -
        
                                        SUB  NOT  REF  INF  UPD  PRA
                                        ---  ---  ---  ---  ---  ---
                                         -    -    -    -    o    -
        

The OSPS-Tag value of "token" is defined for extensibility, and is reserved for future use.

「トークン」のOSPSタグ値は、拡張性のために定義されており、将来の使用のために予約されています。

6.2. Procedures at an Untrusted User Agent Client (UAC)
6.2. 信頼できないユーザエージェントクライアントでの手順(UAC)

The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted UAC.

P-DCS-OSPSヘッダは信頼できないUACからの要求で送信されてはいけません。

6.3. Procedures at a Trusted User Agent Client (UAC)
6.3. 信頼できるユーザエージェントクライアントでの手順(UAC)

This header is typically only inserted by a Media Gateway Controller [6] that is controlling a Media Gateway with special trunks to a PSTN OSPS system or PSAP. This trunk group is usually referred to as a BLV-trunk group and employs special signaling procedures that prevent inadvertent use. Calls originating at the PSTN OSPS system are sent over this trunk group, and result in an INVITE request with the P-DCS-OSPS header.

このヘッダーは、典型的にのみPSTN OSPSシステムまたはPSAPへの特別なトランクでメディアゲートウェイを制御している[6]メディアゲートウェイコントローラによって挿入されます。このトランク・グループは、通常、BLV-トランクグループと呼ばれ、不注意による使用を防止する特殊なシグナリング手順を採用しています。 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 or response 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 pre-existing dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a pre-existing dialog established with the OSPS-Tag value of "BLV".

OSPSタグ値「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 pre-existing dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a pre-existing dialog established by a UAC to an operator or PSAP.

OSPSタグ値「環」は、任意の要求または(1)以降は、前内オペレータまたはPSAP、または(2)UPDATE要求にUACによって確立された既存のダイアログ内INVITE以外応答して現れてはいけませんオペレータまたはPSAPにUACによって確立された既存のダイアログ。

6.4. Procedures at an Untrusted User Agent Server (UAS)
6.4. 信頼できないユーザエージェントサーバ(UAS)での手続き

If the UAS receives an INVITE request with an OSPS-Tag of "BLV", dialog identification that matches an existing dialog, and the existing call was not established with the OSPS-Tag, it MUST reject the request with a 403-Forbidden error code.

UASはOSPSタグとの間で確立されていなかった「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, it MUST reject the request with a 403-Forbidden response code.

UASは、既存のダイアログと一致しないダイアログ識別と「EI」又は「RING」のOSPSタグ値を持つINVITE /更新要求を受信した場合、それは403禁止応答コードとの要求を拒絶しなければなりません。

If the UAS receives an INVITE that contains an OSPS-Tag value of "BLV" and is not willing to cooperate in offering this service, it MUST reject the request with a 403-Forbidden response code.

UASはそれが「BLV」のOSPSタグ値が含まれており、このサービスを提供に協力して喜んではありません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 QoS pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port given in the SDP of the INVITE. The UAS MAY perform a mixing operation between the two ends of an existing active call and send the resulting media stream to the address and port indicated. Alternatively, the UAS MAY send a copy of the local voice stream, and (if no activity on the local voice stream) send a copy of the received voice stream of an existing call. If the state of the UAS is idle, the UAS SHOULD send a stream of silence packets to OSPS. If the state of the UAS is ringing or ringback, the UAS SHOULD send a ringback stream to OSPS.

「BLV」のOSPSタグと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秒ハウリングトーンまたは持続環を生成します。

6.5. Procedures at a Trusted User Agent Server (UAS)
6.5. 信頼できるユーザエージェントサーバ(UAS)での手続き

The procedures at a trusted UAS MUST be identical to those described in 6.4.

信頼されたUASの手順は、6.4に記載されたものと同じでなければなりません。

6.6. Procedures at Proxy
6.6. プロキシでの手続き

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要求に応答してはいけません。

7. P-DCS-BILLING-INFO
7. P-DCS-BILLING-INFO

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一般ヘッダーフィールドの添加は、呼の持続時間情報及び課金識別子を課金の捕捉を可能にします。

It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a proxy or trusted UA in INVITE requests in a trusted network segment, and removed before leaving trusted network segments. The P-DCS-Billing-Info header extension is used only on requests and responses between proxies and trusted User Agents. It is never sent to, nor sent by, an untrusted UA.

課金機能拡張は、信頼できるネットワークセグメント上に現れるであろうとの意図で、プロキシによって挿入または信頼できるネットワークセグメント内のINVITEリクエストにUAを信頼して、信頼できるネットワークセグメントを離れる前に除去することができます。 P-DCS-課金-Infoヘッダー拡張が唯一のプロキシや、信頼できるユーザエージェント間の要求と応答に使用されています。それはに送信されません、また信頼できないUAによって送りません。

7.1. Syntax
7.1. 構文

The DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [2]):

DCS-BILLING-INFOヘッダは以下のABNFによって定義される(このABNFで使用されるいくつかの用語が定義されている[2])。

P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON Billing-Correlation-ID "/" FEID *(SEMI Billing-Info-param) Billing-Correlation-ID = 1*48(HEXDIG) FEID = 1*16(HEXDIG) "@" host Billing-Info-param = RKS-Group-ID-param / Charge-param / Calling-param / Called-param / Routing-param / Loc-Routing-param / generic-param RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID RKS-Group-ID = token Charge-param = "charge" EQUAL Acct-Charge-URI Acct-Charge-URI = LDQUOT addr-spec RDQUOT Calling-param = "calling" EQUAL Acct-Calling-URI Acct-Calling-URI = LDQUOT addr-spec RDQUOT Called-param = "called" EQUAL Acct-Called-URI Acct-Called-URI = LDQUOT addr-spec RDQUOT Routing-param = "routing" EQUAL Acct-Routing-URI Acct-Routing-URI = LDQUOT addr-spec RDQUOT Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT

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 /ジェネリック-PARAM RKS -group-ID-のparam = "rksgroup" EQUAL RKS-グループID RKS-グループID =トークンチャージ-paramが=-PARAMを呼び出すEQUALのAcct-チャージ-URIのAcct-チャージ-URI = LDQUOTのaddrスペックRDQUOTを "充電します" = EQUALのAcct-呼び出し-URI」= EQUALのAcct-呼び出さ-URIのAcct-呼び出さ-URI = LDQUOTのaddrスペックRDQUOTルーティング-のparam "と呼ばれる"-PARAM呼び出さ= LDQUOTのaddrスペックRDQUOT =アカウンティングが--URI呼び出し "を呼び出します"ルーティング」EQUAL ACCT-ルーティング-URI ACCT-ルーティング-URIが= LDQUOT ADDR仕様RDQUOTのLocルーティング-PARAM = "locroute" EQUALのAcct-LOC-ルーティング-URIのAcct-LOC-ルーティング-URI = LDQUOT ADDRスペックRDQUOT

This document adds the following entry to Table 2 of [2]:

この文書では、[2]の表2に次のエントリを追加します。

   Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
   ------------         ----- -----  ---  ---  ---  ---  ---  ---
   P-DCS-Billing-Info         admr    -    -    -    o    -    -
        
                                     SUB  NOT  REF  INF  UPD  PRA
                                     ---  ---  ---  ---  ---  ---
                                      -    -    -    -    -    -
        

The P-DCS-Billing-Info extension contains an identifier that can be used by an event recorder to associate multiple usage records, possibly from different sources, with a billable account. It further contains the subscriber account information, and other information necessary for accurate billing of the service. This header is only used between proxies and trusted User Agents.

P-DCS-BILLING-INFO拡張は、請求可能なアカウントを使用して、おそらく異なるソースから、複数の使用状況レコードを関連付けるイベントレコーダによって使用することができる識別子を含みます。さらに、加入者口座情報、およびサービスの正確な課金のために必要なその他の情報が含まれています。このヘッダーは、プロキシ、信頼できるユーザーエージェントとの間で使用されます。

The Billing-Correlation-ID is specified in [9] as a 24-byte binary structure, containing 4 bytes of NTP timestamp, 8 bytes of the unique identifier of the network element that generated the ID, 8 bytes giving the time zone, and 4 bytes of monotonically increasing sequence number at that network element. This identifier is chosen to be globally unique within the system for a window of several months. This MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 48 characters. Leading zeroes MAY be suppressed.

請求-相関-IDが指定されている[9] NTPタイムスタンプの4バイト、ID、時間帯を与える8つのバイトを生成したネットワーク要素の一意の識別子の8つのバイトを含む24バイトのバイナリ構造、などと単調そのネットワーク要素にシーケンス番号を増加させるの4バイト。この識別子は、数ヶ月の窓のためのシステム内でグローバルに一意であるように選択されます。これは、最大48文字の16進数の文字列としてP-DCS-BILLING-INFOヘッダで符号化されなければなりません。先行ゼロを抑制することができます。

The Financial-Entity-ID (FEID) is specified in [9] as an 8-byte structure, containing the financial identifier for that domain, followed by a domain name. FEID can be associated with a type of service and could be assigned to multiple domains by the same provider. A domain could contain multiple assigned FEIDs. This 8- byte structure MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 16 characters. Trailing zeroes MAY be suppressed. "Host" contains the domain name.

金融エンティティ-ID(FEID)は、ドメイン名に続いて、そのドメインの金融識別子を含む、8バイトの構造として[9]で指定されています。 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-Location-Routing-URI are each defined as URLs; they should all contain tel: URLs with E.164 formatted addresses. These fields are further defined in [9] under the element identifiers "Charge_Number" (element ID 16), "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element ID 5), "Routing Number" (element ID 25), and "Location_Routing_Number" (element ID 22).

追加のパラメータは、イベントメッセージレコードの生成に必要な情報が含まれています。 ACCTチャージ-URI、ACCT呼出-URI、ACCTいわゆる-URI、ACCTルーティング-URI、およびACCT - ロケーションルーティング-URIは、各URLとして定義されます。彼らはすべてのTELが含まれている必要がありますE.164フォーマットされたアドレスを持つURLを。これらのフィールドはさらに、要素識別子 "Charge_Number"(要素ID 16)、 "Calling_Party_Number"(要素ID 4)、 "Called_Party_Number"(要素番号5)、 "ルーティング番号"(要素ID 25)の[9]で定義されていますそして "Location_Routing_Number"(要素ID 22)。

7.2. Procedures at an Untrusted User Agent Client (UAC)
7.2. 信頼できないユーザエージェントクライアントでの手順(UAC)

This header is never sent to an untrusted UAC, and is never sent by an untrusted UAC.

このヘッダは信頼できないUACに送信されることはない、信頼できないUACによって送信されることはありません。

7.3. Procedures at a Trusted User Agent Client (UAC)
7.3. 信頼できるユーザエージェントクライアントでの手順(UAC)

The UAC MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The UAC MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the UAC. If the UAC performed a Local Number Portability (LNP) query, it MUST include the Routing Number and Location Routing Number returned by the query.

UACは、呼の課金-相関-IDを生成し、呼に対する課金情報と共に、終端プロキシに送信された初期INVITEメッセージ中のP-DCS-BILLING-INFOヘッダに挿入しなければなりません。 UACは、UACで使用されている記録保持-Server用のFEID、およびRKS-グループIDを含まなければなりません。 UACは、ローカル番号ポータビリティ(LNP)クエリを実行した場合、それは、クエリによって返されるルーティング番号と場所ルーティング番号を含める必要があります。

If the response to the initial INVITE is a 3xx-Redirect, the UAC generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If a UAC receives a 3xx-Redirect response to an initial INVITE, the new INVITE generated by the UAC MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response. If the UAC is acting as a B2BUA, instead of generating a new INVITE it MAY generate a private-URL and place it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.

標準SIPに従って、ヘッダ:INVITE初期に対する応答が3XX、リダイレクトされた場合、UACは、連絡先に指定された目的地までの新たな初期INVITE要求を生成します。 UACは、最初のINVITEへの3xxリダイレクト応答を受信した場合、INVITE UACによって生成された新しいは3XXリダイレクト応答のP-DCS-BILLING-INFOヘッダを含まなければなりません。 UACは、B2BUAとして動作している場合は、代わりに新しいINVITEを生成するには、民間URLを生成し、発信エンドポイントに送信されたの3xxリダイレクト応答のContactヘッダに配置してもよい(MAY)。このプライベート・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-BILLING-INFOヘッダを含まなければなりません。このP-DCS-BILLING-INFOヘッダは、REFERのイニシエータの課金情報を含まなければなりません。

7.4. Procedures at an Untrusted User Agent Server (UAS)
7.4. 信頼できないユーザエージェントサーバ(UAS)での手続き

This header is never sent to an untrusted UAS, and is never sent by an untrusted UAS.

このヘッダは信頼できないUASに送信されることはない、信頼できないUASによって送信されることはありません。

7.5. Procedures at a Trusted User Agent Server (UAS)
7.5. 信頼できるユーザエージェントサーバ(UAS)での手続き

The UAS MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the UAS, the FEID of the UAS, and the RKS-Group-ID of the Record-Keeping-Server being used by the UAS. The UAS MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the new Acct-Charge-URI MUST be determined by service provider policy provisioned in the UAS. If the UAS performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.

UASは最初の信頼性(100を除く)1XXまたは初期INVITEメッセージへの2xx応答してP-DCS-BILLING-INFOヘッダを含まなければなりません。このP-DCS-BILLING-INFOヘッダは、UAS、UASのFEID、およびUASによって使用されている記録管理、サーバの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ヘッダを追加しなければなりません。

7.6. Procedures at Proxy
7.6. プロキシでの手続き

Three sets of proxy procedures are defined: (1) the procedures at an originating proxy, (2) the procedures at a terminating proxy, and (3) the procedures at a tandem proxy.

プロキシ手順3組が定義される:(1)発信プロキシで手順、(2)タンデムプロキシで終端プロキシにおける手順、及び(3)の手順。

The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.

元のプロキシは、信頼されていないエンドポイントからINVITE要求を受信したプロキシです。

The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.

終端プロキシは信頼されないエンドポイントにINVITEリクエストを送信するプロキシです。

A proxy that is neither an originating proxy, nor a terminating proxy, is a tandem proxy.

発信プロキシ、また終端プロキシでもないプロキシは、タンデムプロキシです。

For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non-trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.

そのようなコール転送、開始プロキシとみなされ、信頼されていないエンドポイントからの要求を受けたプロキシとして通話中の変更の目的のために、信頼されていないエンドポイントに要求を送信するプロキシは、受信者のプロキシと考えられています。受信者のプロキシの手順は、プロキシを終了するためのものに含まれていながら、開始プロキシの手順は、プロキシを発信するためのもので、以下に含まれています。

A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, performs both sets of procedures.

両方は、信頼されていないエンドポイントからINVITE要求を受信し、非信頼できるエンドポイントにINVITE要求を送るプロキシは、手順の両方のセットを実行します。

7.6.1. Procedures at Originating Proxy
7.6.1. 発信プロキシでの手順

The originating proxy MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The originating proxy MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the originating proxy. If the originating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query. Any P-DCS-Billing-Info header present from an untrusted UA MUST be removed.

発信プロキシは、呼に対する課金-相関-IDを生成し、呼に対する課金情報と共に、終端プロキシに送信された初期INVITEメッセージ中のP-DCS-BILLING-INFOヘッダに挿入しなければなりません。元のプロキシは、発信プロキシが使用されているそのFEID、および記録保持-ServerのRKS-グループIDを含まなければなりません。元のプロキシはLNPクエリーを実行した場合、それは、クエリによって返されるルーティング番号と場所ルーティング番号を含める必要があります。信頼できないUAから存在する任意のP-DCS-BILLING-INFOヘッダが除去されなければなりません。

If the Request-URI contains a private-URL, and the decoded username contains billing information, the originating proxy MUST generate a P-DCS-Billing-Info header with that decrypted information. Otherwise, the originating proxy MUST determine the accounting information for the call originator, and insert a P-DCS-Billing-Info header including that information.

要求URIがプライベート・URLが含まれており、デコードされたユーザ名は、課金情報が含まれている場合は、元のプロキシはP-DCS-課金-情報は、その復号化された情報を持つヘッダを生成しなければなりません。そうでなければ、発信プロキシは、発信者のために課金情報を決定し、その情報を含むP-DCS-BILLING-INFOヘッダを挿入する必要があります。

If the response to the initial INVITE is a 3xx-Redirect, received prior to a 18x, the originating proxy generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a 18x response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response.

標準SIPに従って、ヘッダ:INVITE初期に対する応答が3XX、リダイレクトされた場合、18Xの前に、発信プロキシは新たな初期の問い合わせで指定された宛先へINVITEリクエストを生成しました。発信プロキシが最初に3XXリダイレクト応答を受信した場合に前18X応答にINVITE、プロキシによって生成されたINVITEの3xxリダイレクト応答のP-DCS-BILLING-INFOヘッダを含まなければなりません。

If the response to the initial INVITE is a 3xx-Redirect, received after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.

最初のINVITEに対する応答が3xxの、リダイレクトされた場合は、18Xの後に受信、発信プロキシは、プライベート・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-BILLING-INFOヘッダを含まなければなりません。このP-DCS-BILLING-INFOヘッダは、イニシエータの課金情報を含まなければなりません。

7.6.2. Procedures at Terminating Proxy
7.6.2. 終端プロキシでの手順

The terminating proxy MUST NOT send the P-DCS-Billing-Info header to an untrusted destination.

終端プロキシは、信頼されていない宛先へのP-DCS-BILLING-INFOヘッダを送ってはいけません。

The terminating proxy MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the terminating proxy, the FEID of the terminating proxy, and the RKS-Group-ID of the Record-Keeping-Server being used by the terminating proxy. The terminating proxy MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the resulting P-DCS-Billing-Info header MUST be determined by service provider policy provisioned in the terminating proxy. If the terminating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.

終端プロキシは最初の信頼性(100を除く)1XXまたは初期INVITEメッセージへの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 indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the endpoint to re-use this private-URL for multiple calls.

半ば呼び出す参照してください-するヘッダを含むREFERリクエストを受信したプロキシは、プライベート・URLを生成し、参照してください-するエンドポイントに送信されたヘッダにそれを配置します。このプライベート-URLは、この民間のを再利用するエンドポイントの能力を制限するために、将来的には非常にすぐに新しいコールの充電配置を示すP-DCS-課金-情報値、および有効期限を含まなければなりません複数の呼び出しのためのURL。

7.6.3. Procedures at Tandem Proxy
7.6.3. タンデムプロキシでの手順

If the tandem proxy performed a LNP query, it MUST insert the Routing Number and Location Routing Number returned by the query into the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 100) response.

タンデムプロキシがLNPクエリーを実行した場合、それは応答(100を除く)第一信頼1XX / 2XX / 3XXにP-DCS-BILLING-INFOヘッダにクエリによって返されるルーティング番号とロケーションルーティング番号を挿入する必要があります。

8. P-DCS-LAES and P-DCS-REDIRECT
8. P-DCS-LAES及びP-DCS-REDIRECT

NOTE: According to RFC 2804 [5], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The RFC 2119 language, as stated above, describes the requirements of the specification only if implemented, and strictly within the applicability domain described above. See RFC 2804 for description of issues regarding privacy, security, and complexity in relation to this technology.

注:それを開発する必要がある場合は、RFC 2804によると、[5]、IETFは、合法的傍受技術のドキュメントをサポートしています。次のセクションでは、このような資料を用意しています。 RFC 2119の言語は、上述したように、実装、および厳密に上記の適用ドメイン内場合にのみ、仕様書の要​​件について説明します。この技術に関連して、プライバシー、セキュリティ、および複雑さに関する問題の詳細については、RFC 2804を参照してください。

The P-DCS-LAES extension contains the information needed to support Lawfully Authorized Electronic Surveillance. This header contains the address and port of an Electronic Surveillance Delivery Function for delivery of a duplicate stream of event messages related to this call. The header may also contain an additional address and port for delivery of call content. Security key information is included to enable pairs of Delivery Functions to securely exchange surveillance information. This header is only used between proxies and trusted User Agents.

P-DCS-LAES拡張子が合法的に承認された電子監視をサポートするために必要な情報が含まれています。このヘッダは、この呼び出しに関連したイベントメッセージの複製ストリームの配信のための電子監視配信機能のアドレスとポートが含まれています。ヘッダはまた、呼のコンテンツの配信のための追加アドレスおよびポートを含んでいてもよいです。セキュリティキー情報が確実に監視情報を交換するために、配信機能のペアを可能にするために含まれています。このヘッダーは、プロキシ、信頼できるユーザーエージェントとの間で使用されます。

The P-DCS-Redirect extension contains call identifying information needed to support the requirements of Lawfully Authorized Electronic Surveillance of redirected calls. This header is only used between proxies and trusted User Agents.

P-DCS-リダイレクト拡張子がリダイレクトされたコールの合法的に認定電子監視の要件をサポートするために必要なコールの識別情報が含まれています。このヘッダーは、プロキシ、信頼できるユーザーエージェントとの間で使用されます。

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手段のいずれかが含まれなければならないか、してはならないことことが含まれるべきです該当する裁判所命令に基づいて、含まれています。

8.1. Syntax
8.1. 構文

The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by the following ABNF (some terms used in this ABNF are defined in [2] and [3]):

P-DCS-LAES及びP-DCS-リダイレクトヘッダは、以下のABNFによって与えられるのフォーマット(このABNFで使用されるいくつかの用語が定義されている[2]及び[3])。

P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig *(SEMI Laes-param) Laes-sig = hostport Laes-param = Laes-content / Laes-key / generic-param Laes-content = "content" EQUAL hostport Laes-key = "key" EQUAL token

天井-SIG =のHostPort天井PARAM =天井コンテンツ/天井キー/ジェネリック-PARAMの天井含量=「コンテンツにP-DCS-天井= "P-DCS-天井" HCOLON天井-SIG×(SEMI天井PARAM) 「EQUALホスト側の天井キー=」キー「EQUALトークン

P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID *(redir-params) Called-ID = LDQUOT addr-spec RDQUOT redir-params = redir-uri-param / redir-count-param / generic-param redir-uri-param = "redirector-uri" EQUAL Redirector Redirector = LDQUOT addr-spec RDQUOT redir-count-param = "count" EQUAL Redir-count Redir-count = 1*DIGIT

P-DCS-リダイレクト= "P-DCS-リダイレクト" HCOLON呼び出さ-ID *(REDIR-のparams)と呼ばれる-ID = LDQUOTのaddrスペックRDQUOT REDIR-のparams = REDIR-URI-PARAM / REDIRカウント-PARAM / generic- 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 [2]:

この文書では、[2]の表2に次のエントリを追加します。

      Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
      ------------         ----- -----  ---  ---  ---  ---  ---  ---
      P-DCS-LAES                  adr    -    -    -    o    -    -
      P-DCS-Redirect              adr    -    -    -    o    -    -
        
                                        SUB  NOT  REF  INF  UPD  PRA
                                        ---  ---  ---  ---  ---  ---
                                         -    -    -    -    -    -
                                         -    -    -    -    -    -
        

The values of Laes-sig and Laes-content are addresses of the Electronic Surveillance Delivery Function, and used as the destination address for call-identifying information and call-content, respectively. Laes-key is a string generated by the proxy that is used by the Delivery Function to securely transfer information between them [8].

Laes-SIGとLaes含有量の値は、電子監視配信機能のアドレスであり、呼識別情報の宛先アドレスとして使用し、それぞれ、コンテンツを呼び出します。 Laesキー[8]安全にそれらの間で情報を転送する配信機能によって使用されるプロキシによって生成された文字列です。

The P-DCS-Redirect header contains redirection information. The redir-uri-param indicates the original destination requested by the user (e.g., dialed number), the Redirector indicates the new destination, and the Redir-count indicates the number of redirections that have occurred.

P-DCS-リダイレクトヘッダは、リダイレクト情報を含みます。 REDIR-URI-paramは、ユーザ(例えば、ダイヤルされた番号)によって要求元の宛先を示し、リダイレクタは、新しい宛先を示し、REDIRカウントが発生しているリダイレクトの数を示します。

8.2. Procedures at an Untrusted User Agent Client (UAC)
8.2. 信頼できないユーザエージェントクライアントでの手順(UAC)

This header MUST NOT be sent to an untrusted UAC, and MUST NOT be sent by an untrusted UAC.

このヘッダは信頼できないUACに送信されてはならず、信頼できないUACによって送ってはいけません。

8.3. Procedures at a Trusted User Agent Client (UAC)
8.3. 信頼できるユーザエージェントクライアントでの手順(UAC)

The UAC checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).

UACの発信加入者のための卓越した合法的に許可された監視順序をチェックし、そして、存在する場合、[7]または信号の情報をインターセプト(例えば、メディアゲートウェイ)を行う装置へサービス品質のための認可にこの情報を含みます。

If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the UAC MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway).

P-DCS-LAESヘッダは、最初の信頼1XXに存在する場合(指示監視を着信加入者に必要な、しかし終端装置がその機能を実行することができないということである)、(100を除く)2XX、又は3XX応答、UACは必須サービス品質の認可にこの情報が含まれ、またはインターセプト(例えば、メディアゲートウェイ)を実行するデバイスにこの情報を通知しなければなりません。

If a 3xx-Redirect response is received to the initial INVITE request, and if a P-DCS-LAES header is present in the 3xx response, the UAC SHOULD include that header unchanged in the reissued INVITE. The UAC SHOULD also include a P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred. Although it is technically possible for the originating equipment to perform this surveillance (or add to its existing surveillance of the call), the design of the surveillance system has the terminating equipment performing the surveillance for all the intermediate forwardings.

3XXリダイレクト応答は、初期INVITE要求を受信し、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 P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.

参照してください - を参照して要求にヘッダを含むUACは、発信加入者が未処理の合法的に許可された監視順序を有する場合、参照の対に取り付けられたP-DCS-LAESヘッダを含むべきです。 P-DCS-LAESヘッダが呼び出した場合、コールコンテンツのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきである、コールのイベントメッセージのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきですコンテンツを傍受することで、配信機能間のセキュリティキーとして使用するためのランダムな文字列を含むべきです。

The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.

信頼されたUACは、信頼できないエンティティにP-DCS-LAESとP-DCS-リダイレクトヘッダを送ってはいけません。

8.4. Procedures at an Untrusted User Agent Server (UAS)
8.4. 信頼できないユーザエージェントサーバ(UAS)での手続き

This header MUST NOT be sent to an untrusted UAS, and MUST NOT be sent by an untrusted UAS.

このヘッダは信頼できないUASに送信してはいけません、そして信頼できないUASによって送ってはいけません。

8.5. Procedures at a Trusted User Agent Server (UAS)
8.5. 信頼できるユーザエージェントサーバ(UAS)での手続き

The UAS checks for an outstanding lawfully authorized surveillance order for the terminating subscriber, or presence of the P-DCS-LAES header in the INVITE request. If either is present, the UAS includes this information in the authorization for Quality of Service [7].

UASは、優れた合法的に許可された監視着信加入者のため、またはINVITE要求内のP-DCS-LAESヘッダの存在をチェックします。どちらかが存在する場合、UASは、[7]サービス品質(Quality of Service)の承認にこの情報が含まれています。

If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), the UAS SHOULD include a P-DCS-LAES header in the first reliable non-100 response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.

終端装置は、(宛先がボイスメール・サーバである場合、例えば、)必要な監視を行うことができない場合、UASは、監視を実行するために発信プロキシを要求する第1の信頼性の非100応答におけるP-DCS-LAESヘッダを含むべきです。 P-DCS-LAESヘッダが呼び出した場合、コールコンテンツのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきである、コールのイベントメッセージのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきですコンテンツを傍受することで、配信機能間のセキュリティキーとして使用するためのランダムな文字列を含むべきです。

If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the UAS SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.

最初の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-リダイレクトヘッダを送ってはいけません。

8.6. Procedures at Proxy
8.6. プロキシでの手続き

Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.

プロキシ手順の二組が定義される:(1)終端プロキシで発信プロキシでの手順、及び(2)の手順。元のプロキシは、信頼されていないエンドポイントからINVITE要求を受信したプロキシです。

The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.

終端プロキシは信頼されないエンドポイントにINVITEリクエストを送信するプロキシです。

For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non-trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.

そのようなコール転送、開始プロキシとみなされ、信頼されていないエンドポイントからの要求を受けたプロキシとして通話中の変更の目的のために、信頼されていないエンドポイントに要求を送信するプロキシは、受信者のプロキシと考えられています。受信者のプロキシの手順は、プロキシを終了するためのものに含まれていながら、開始プロキシの手順は、プロキシを発信するためのもので、以下に含まれています。

A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers.

両方が信頼されていないエンドポイントからINVITE要求を受信し、P-DCS-LAESもP-DCS-リダイレクトヘッダを生成してはいけません、非信頼できるエンドポイントにINVITE要求を送信するプロキシ。

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-リダイレクトヘッダを通過させなければなりません。

8.6.1. Procedures at Originating Proxy
8.6.1. 発信プロキシでの手順

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, includes this information in the Authorization for Quality of Service [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).

、サービス品質の認可にこの情報が含まれて存在する場合、発信プロキシ発信加入者のための卓越した合法的に許可された監視順序をチェックし、そして、[7]または信号傍受を実行する装置にこの情報(例えば、メディアゲートウェイ)。

If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the originating proxy MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway).

P-DCS-LAESヘッダが(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 header with the surveillance information.

初期でのRequest-URIは、要求がプライベート・URLが含まれているINVITE場合は、発信プロキシは、コールのための本当の目的地、および他の特別な処理情報を見つけることのuserinfo情報を復号化する必要があります。電子監視情報を復号ユーザー情報に含まれている場合、発信プロキシは、監視情報をP-DCS-LAESヘッダを生成する必要があります。

If a 3xx-Redirect response is received to the initial INVITE request prior to a 18x, and if a P-DCS-LAES header is present in the 3xx response, the originating proxy SHOULD include that header unchanged in the reissued INVITE. The originating proxy SHOULD also include a

3XXリダイレクト応答は18Xの前初期INVITE要求を受信した場合、及びP-DCS-LAESヘッダは3xx応答中に存在する場合、発信プロキシは再発行INVITEに不変そのヘッダを含むべきです。元のプロキシも含むべきです

P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred.

元のダイヤルされた番号、新しい宛先番号、及び発生したリダイレクト数を含むP-DCS-リダイレクトヘッダ。

If a 3xx-Redirect response is received to the initial INVITE request after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. If a P-DCS-LAES header is present in the 3xx response, this private-URL MUST contain (1) the electronic surveillance information from the 3xx-Redirect response, (2) the original destination number, (3) the identity of the redirecting party, and (4) the number of redirections of this call.

3xxリダイレクト応答を18倍した後、最初のINVITE要求に受信された場合は、元のプロキシは、プライベート・URLおよび発信エンドポイントに送信されたの3xxリダイレクト応答のContactヘッダ内の場所、それを生成します。 P-DCS-LAESヘッダは3xx応答中に存在する場合、このプライベートURL(3)の同一性を、(2)元の宛先番号、3XXリダイレクト応答を(1)から電子監視情報を含まなければなりませんパーティをリダイレクト、および(4)このコールのリダイレクトの数を。

An originating proxy that processes a REFER request [4] from an untrusted UA, when the originating subscriber has an outstanding lawfully authorized surveillance order, becomes a B2BUA for that request. It SHOULD reissue the request with a P-DCS-LAES header added to the Refer-to's URL. The P-DCS-LAES header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, (2) the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and (3) a random string for use as a security key between the Delivery Functions.

信頼できないUAからREFER要求[4]を処理し、発信プロキシは、発信加入者が未処理の合法的に許可された監視順序を有する場合に、その要求のB2BUAなります。これは、参照してくださいからのURLに追加P-DCS-LAESヘッダで要求を再発行すべきです。 P-DCS-LAESヘッダは、コピー(1)アドレスおよび呼び出しのイベント・メッセージのコピーのローカル電子監視配信機能のポート、(2)アドレスとローカル電子監視配信機能のポートを含むべきです通話内容を傍受する場合は、コンテンツを呼び出し、および配信機能間のセキュリティキーとして使用するために(3)ランダムな文字列。

An initiating proxy that sends a mid-call REFER request including a Refer-to header, when the initiating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header in the Refer-to's URL.

送信開始プロキシ半ば呼び出しを含む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-リダイレクトヘッダを送ってはいけません。

8.6.2. Procedures at Terminating Proxy
8.6.2. 終端プロキシでの手順

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 includes this information in the authorization for Quality of Service [7].

着信加入者のための卓越した合法的に許可された監視オーダーの終端プロキシチェックします。存在する場合、終端プロキシは、サービス品質の権限で、この情報を含む[7]。

The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity, either as headers in the request or response, or as headers attached to URIs in the request or response.

終端プロキシは、いずれかの要求または応答にヘッダとして、又は要求又は応答における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 SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.

終端装置は、(宛先がボイスメール・サーバである場合、例えば、)必要な監視を行うことができない場合、終端プロキシは、応答が要求し(100を除く)第一信頼1XX / 2XX / 3XXにおけるP-DCS-LAESヘッダを含むべきです監視を実行するために、発信プロキシ。 P-DCS-LAESヘッダが呼び出した場合、コールコンテンツのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきである、コールのイベントメッセージのコピーのためにローカル電子監視配信機能のアドレスとポートを含むべきですコンテンツを傍受することで、配信機能間のセキュリティキーとして使用するためのランダムな文字列を含むべきです。

If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the 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 [4] that includes a Refer-to header with a P-DCS-LAES header attached becomes a B2BUA for this request. It MUST generate a private-URL and place it in the Refer-to header sent to the endpoint. This private-URL MUST contain the P-DCS-LAES information from the attached header.

REFERリクエストを中間呼び出し受信プロキシ[4]を参照の-するP-DCS-LAESとヘッダが添付ヘッダ含むこの要求のB2BUAなります。これは、民間URLを生成し、参照してください-するエンドポイントに送信されたヘッダにそれを置かなければなりません。このプライベートURLが添付ヘッダからP-DCS-LAES情報を含まなければなりません。

9. Security Considerations
9.セキュリティの考慮事項

QoS gate coordination, billing information, and electronic surveillance information are all considered to be sensitive information that MUST be protected from eavesdropping and furthermore require integrity checking. It is therefore necessary that the trusted UAs and proxies take precautions to protect this information from eavesdropping and tampering. Use of IPsec or TLS between Proxies is REQUIRED. A minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [8]. Also REQUIRED is mutual authentication (1) between Proxies and (2) between trusted UAs and Proxies, both of which MAY be implemented with administratively pre-shared keys, or through consultation with another trusted third party. If IPsec is to be used, the specification of the security policies and procedures of the administrative domain where these headers are applicable (and all connections between administrative domains in the federation) MUST define an interoperable set of options.

QoSのゲートの調整、課金情報、および電子監視情報は、すべての盗聴から保護し、さらに整合性のチェックを必要としなければならない機密情報であると考えられています。信頼UAとプロキシが盗聴や改ざんからこの情報を保護するための予防策を講じることが必要です。プロキシ間のIPsecまたはTLSを使用する必要があります。 DCSアーキテクチャの最小必須ツー実装IPsec構成は、[8]で与えられます。必要管理事前共有キーで、または別の信頼できる第三者との協議を通じて実現されてもよいどちらも信頼UAとプロキシとの間のプロキシと(2)との間の相互認証(1)です。 IPsecを使用する場合、これらのヘッダは適用可能である管理ドメイン(およびフェデレーション内の管理ドメイン間のすべての接続)のセキュリティポリシーおよび手順の仕様は、オプションの相互運用セットを定義しなければなりません。

10. IANA Considerations
10. IANAの考慮事項

This document defines a number of SIP extension headers, which have been included in the registry of SIP headers defined in [2]. Registration information for new headers is as follows:

この文書では、[2]で定義されたSIPヘッダのレジストリに含まれているSIPの拡張ヘッダの数を定義します。次のように新しいヘッダの登録情報は、次のとおりです。

Header Field Name: P-DCS-Trace-Party-ID RFC Number: 3603 Compact Form: none

ヘッダーフィールド名:P-DCS-トレースパーティ-ID RFC番号:3603コンパクトなフォーム:なし

Header Field Name: P-DCS-OSPS RFC Number: 3603 Compact Form: none

ヘッダーフィールド名:P-DCS-OSPS RFC番号:3603コンパクトなフォーム:なし

Header Field Name: P-DCS-Billing-Info RFC Number: 3603 Compact Form: none

ヘッダーフィールド名:P-DCS-課金-情報RFC番号:3603コンパクトなフォーム:なし

Header Field Name: P-DCS-LAES RFC Number: 3603 Compact Form: none

ヘッダーフィールド名:P-DCS-LAES RFC番号:3603コンパクトなフォーム:なし

Header Field Name: P-DCS-Redirect RFC Number: 3603 Compact Form: none

ヘッダーフィールド名:P-DCS-リダイレクトRFC番号:3603コンパクトなフォーム:なし

11. Intellectual Property Rights Notice
11.知的財産権に関するお知らせ

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。

12. References
12.参考文献
12.1. Normative References
12.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル"、 RFC 3261、2002年6月。

[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[3]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF:ABNF"、RFC 2234、1997年11月。

[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.

[4] R.、 "セッション開始プロトコル(SIP)メソッドを参照してください"、RFC 3515、2003年4月、火花。

[5] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.

[5] IABとIESG、 "盗聴のIETF方針"、RFC 2804、2000年5月。

12.2. Informative References
12.2. 参考文献

[6] DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", Work in Progress.

[6] DCSグループ、進行中で働いて「SIPベースの分散型コール制御メカニズムを利用し、キャリアクラスのテレフォニーサービスを提供するためのアーキテクチャの考慮事項」。

[7] PacketCable Dynamic Quality of Service Specification, pkt-sp-dqos-i07-030815, August 2003.

[7]サービス仕様のPacketCableのダイナミックな品質、PKT-SP-DQOS-i07-030815、2003年8月を。

[8] PacketCable Security Specification, pkt-sp-sec-i09-030728, July 2003.

[8] PacketCableのセキュリティ仕様、PKT-SP-SEC-i09-030728、2003年7月。

[9] PacketCable Event Message Specification, pkt-sp-em-i07-030815, August 2003.

[9] PacketCableのイベントメッセージ仕様、PKT-SP-EM-i07-030815、2003年8月。

[10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.

[10]ジェニングス、C.、ピーターソン、J.とM.ワトソン、 "信頼されたネットワーク内でアサート・アイデンティティのためのセッション開始プロトコル(SIP)のプライベート拡張"、RFC 3325、2002年11月。

13. Acknowledgements
13.謝辞

The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications.

PacketCableのプロジェクトにおける分散型コールシグナリングの仕事は、多くの異なる企業を代表する多数の人々の仕事です。著者は認識し、彼らの支援のために次のことを感謝したいと思います:ジョン・ホイーラー、モトローラ。デビッド・ボードマン、ダニエル・ポール、ARRISインタラクティブ。ビル・ブラム、ジョン・フェロー、ジェイストラター、ジェフOllis、クライヴHolborow、モトローラ。ダグNewlin、グイド・シュスター、Ikhlaqシドゥ、3Com社。ジリ・マトゥーセック、ベイネットワーク。 Farzi Khazai、ノーテル。ジョン・チャップマン、ビルGuckel、マイケルRamalho、シスコ;チャックKalmanek、ダグNortz、ジョンLawser、ジェームズ・チェン、Tung-ハイシャオ、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; 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

紙幣マーシャル(wtm@research.att.com)及びK. K.ラマクリシュナン(kkrama@research.att.com)、AT&T。エド・ミラー(edward.miller@terayon.com)、Terayon。グレン・ラッセル(G.Russell@Cablelabs.com)、CableLabsの。 Burcak Beser(burcak@juniper.net)ジュニパーネットワークス、マイク・Mannette(Michael_Mannette@3com.com)とクルト・スタインブレナー(Kurt_Steinbrenner@3com.com)、3Com社。デイブ・オラン(oran@cisco.com)と

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.

フレミングAndreasenの(fandreas@cisco.com)、シスコシステムズ、ジョン・ピケンズ(jpickens@com21.com)、COM21。 Poornima Lalwaney(poornima.lalwaney@nokia.com)、ノキア。ジョン・フェローズ(jfellows@coppermountain.com)、カッパーマウンテンネットワーク。ドック・エバンス(n7dr@arrisi.com)ARRIS、そしてキース・ケリー(keith@netspeak.com)、NetSpeak。

14. Editors' Addresses
14.エディタのアドレス

Bill Marshall AT&T Florham Park, NJ 07932

ビル・マーシャルAT&Tフローラムパーク、NJ 07932

EMail: wtm@research.att.com

メールアドレス:wtm@research.att.com

Flemming Andreasen Cisco Edison, NJ

フレミングAndreasenのシスコエジソン、NJ

EMail: fandreas@cisco.com

メールアドレス:fandreas@cisco.com

15. Full Copyright Statement
15.完全な著作権声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

著作権(C)インターネット協会(2003)。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。