[要約] RFC 8496は、SIPのP-Charge-Info拡張機能に関するものであり、非公開のヘッダーフィールド（P-Header）を定義しています。目的は、通話料金情報を含むプライベートな情報をSIPメッセージに追加することです。
Internet Engineering Task Force (IETF) D. York
Request for Comments: 8496 Individual
Category: Informational T. Asveren
ISSN: 2070-1721 Ribbon Communications
October 2018
P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)
P-Charge-Info：セッション開始プロトコル（SIP）のプライベートヘッダーフィールド（Pヘッダー）拡張
Abstract
概要
This text documents the current usage of P-Charge-Info, an existing Session Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged. This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA.
このテキストは、課金対象のパーティに関する請求情報を伝達するために使用される既存のセッション開始プロトコル（SIP）プライベートヘッダーフィールド（P-Header）であるP-Charge-Infoの現在の使用法を文書化しています。このP-Headerは現在、いくつかの機器ベンダーおよびキャリアによって生産で使用されており、少なくとも2007年から使用されています。このドキュメントでは、このヘッダーフィールドのIANAへの登録について詳しく説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8496.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8496で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Purpose of This Document . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. The P-Charge-Info Header . . . . . . . . . . . . . . . . . . 5
5.1. Applicability Statement for the P-Charge-Info Header
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Usage of the P-Charge-Info Header Field . . . . . . . . . 5
5.2.1. Procedures at the UA . . . . . . . . . . . . . . . . 5
5.2.2. Procedures at the Proxy . . . . . . . . . . . . . . . 6
5.3. Use-Case Example . . . . . . . . . . . . . . . . . . . . 6
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.1. Trust Relationship . . . . . . . . . . . . . . . . . . . 7
8.2. Untrusted Peers . . . . . . . . . . . . . . . . . . . . . 8
8.2.1. Ingress from Untrusted Peers . . . . . . . . . . . . 8
8.2.2. Egress to Untrusted Peers . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Alternatives . . . . . . . . . . . . . . . . . . . . 10
A.1. P-Charging-Vector . . . . . . . . . . . . . . . . . . . . 10
A.2. P-DCS-Billing-Info . . . . . . . . . . . . . . . . . . . 10
A.3. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
In certain network configurations, several network entities have found it useful to decouple the identity of the caller (what is normally thought of as "Caller ID") from the identity/number used for billing purposes. This document records the current usage of P-Charge-Info, a private SIP header field, to provide simple billing information and details the registration of this header field with IANA as required by Section 4 of [RFC5727].
特定のネットワーク構成では、いくつかのネットワークエンティティが、請求の目的で使用されるID /番号から発信者のID（通常は「発信者ID」と見なされます）を切り離すと便利であることがわかりました。このドキュメントでは、プライベートなSIPヘッダーフィールドであるP-Charge-Infoの現在の使用状況を記録して、簡単な請求情報を提供し、[RFC5727]のセクション4で要求されているように、このヘッダーフィールドのIANAへの登録について詳しく説明します
In a typical configuration, the identity of the caller, commonly referred to as "Caller ID" by end users, is derived from one of the following SIP header fields:
典型的な構成では、エンドユーザーによって一般に「発信者ID」と呼ばれる発信者のIDは、次のSIPヘッダーフィールドのいずれかから取得されます。
o P-Asserted-Identity
o P-Asserted-Identity
o From (in the absence of P-Asserted-Identity)
o から（P-Asserted-Identityがない場合）
(NOTE: Some service providers have also used the Remote-Party-ID header field, but this was never standardized and was replaced by P-Asserted-Identity in [RFC3325].)
（注：一部のサービスプロバイダーはRemote-Party-IDヘッダーフィールドも使用していますが、これは標準化されておらず、[RFC3325]でP-Asserted-Identityに置き換えられました。）
This identity/number is typically presented to the receiving user agent (UA), where it is usually displayed for the end user. It is also typically used for billing purposes by the network entities involved in carrying the session.
このID /番号は通常、受信側のユーザーエージェント（UA）に提示され、通常はエンドユーザーに表示されます。また、通常、セッションの実行に関与するネットワークエンティティによる課金の目的で使用されます。
However, in some network configurations, the "Caller ID" presented to the receiving UA may be different from the number to be used for billing purposes.
ただし、一部のネットワーク構成では、受信側のUAに提示される「発信者ID」が、課金目的で使用される番号と異なる場合があります。
In this case, there exists a need for a way to pass an additional billing identifier that can be used between network entities in order to correctly bill for services.
この場合、サービスに対して正しく課金するために、ネットワークエンティティ間で使用できる追加の課金識別子を渡す方法が必要です。
Several carriers, application providers, and equipment providers have been using the P-Charge-Info header field since at least 2007 as a simple mechanism to exchange this billing identifier.
いくつかのキャリア、アプリケーションプロバイダー、および機器プロバイダーは、この請求IDを交換する単純なメカニズムとして、少なくとも2007年以降、P-Charge-Infoヘッダーフィールドを使用しています。
This document specifies the use of the P-Charge-Info header field in INVITE requests. The header field might be useful in other SIP messages, but such use is beyond the scope of this document.
このドキュメントでは、INVITEリクエストでのP-Charge-Infoヘッダーフィールドの使用について説明しています。ヘッダーフィールドは他のSIPメッセージで役立つ場合がありますが、そのような使用はこのドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The key words describe requirements needed to interoperate with existing usage.
キーワードは、既存の使用法と相互運用するために必要な要件を説明しています。
This document has been prepared to document the existing deployed usage of the P-Charge-Info header field and to comply with Section 4 of [RFC5727] in registering this header field with IANA. It is noted that RFC 5727 specifically deprecates new usage of "P-" header fields, but P-Charge-Info has been in deployment since before 2007 and predates RFC 5727. Given this, the authors believe that P-Charge-Info is a "grandfathered case" per Section 4 of RFC 5727.
このドキュメントは、P-Charge-Infoヘッダーフィールドの既存の展開された使用法を文書化し、このヘッダーフィールドをIANAに登録する際に[RFC5727]のセクション4に準拠するように準備されています。 RFC 5727は「P-」ヘッダーフィールドの新しい使用法を特に非推奨としていますが、P-Charge-Infoは2007年より前から配備されており、RFC 5727よりも古いものです。 RFC 5727のセクション4による「祖父の場合」
The simplest use case for P-Charge-Info is an enterprise environment where each SIP endpoint has a direct number that is passed by the enterprise SIP proxy across to a SIP proxy at a SIP service provider who provides connectivity to the Public Switched Telephone Network (PSTN). Rather than cause the SIP service provider to have to track each individual direct number for billing purposes, the enterprise SIP proxy sends, in the P-Charge-Info header field, a single billing identifier that the SIP service provider uses for billing purposes.
P-Charge-Infoの最も単純な使用例は、各SIPエンドポイントに、企業のSIPプロキシから公衆電話交換網への接続を提供するSIPサービスプロバイダーのSIPプロキシに渡される直接の番号があるエンタープライズ環境です（ PSTN）。エンタープライズSIPプロキシは、SIPサービスプロバイダーに請求のために個々の直接番号を追跡させるのではなく、P-Charge-Infoヘッダーフィールドで、SIPサービスプロバイダーが請求目的で使用する単一の請求識別子を送信します。
As another example, a hosted telephony provider or hosted voice-application provider may have a large SIP network with customers who are distributed over a very large geographic area and use local-market PSTN numbers, although the network has only a very few actual PSTN interconnection points.
別の例として、ホストされたテレフォニープロバイダーまたはホストされた音声アプリケーションプロバイダーは、非常に広い地理的領域に分散し、ローカル市場のPSTN番号を使用する顧客との大規模なSIPネットワークを持っている場合がありますが、ネットワークには実際のPSTN相互接続はほとんどありませんポイント。
The customers may all have local phone numbers, yet outgoing calls are actually routed across a SIP network and out specific PSTN gateways or across specific SIP connections to other SIP service providers. The hosted provider may want to pass a billing identifier to its SIP service providers either for the purpose of simplicity in billing or to obtain better rates from the SIP service providers.
顧客はすべて市内電話番号を持っている可能性がありますが、発信コールは実際にはSIPネットワークを経由して特定のPSTNゲートウェイを介して、または他のSIPサービスプロバイダーへの特定のSIP接続を経由してルーティングされます。ホステッドプロバイダーは、課金を簡素化するため、またはSIPサービスプロバイダーからより良いレートを取得するために、SIPサービスプロバイダーに課金IDを渡す必要がある場合があります。
The P-Charge-Info header field is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.
P-Charge-Infoヘッダーフィールドは、単一のプライベート管理ドメイン内、またはドメイン間に信頼関係がある異なる管理ドメイン間に適用できます。
The P-Charge-Info header field is used to convey information about the identity of the party to be charged. The P-Charge-Info header field is typically inserted into a SIP request, usually an INVITE, by one of the following:
P-Charge-Infoヘッダーフィールドは、課金されるパーティのIDに関する情報を伝えるために使用されます。 P-Charge-Infoヘッダーフィールドは、通常、次のいずれかによってSIPリクエスト（通常はINVITE）に挿入されます。
o the SIP proxy on the originating network;
o 発信元ネットワーク上のSIPプロキシ。
o a PSTN gateway acting as a SIP UA; or
o SIP UAとして機能するPSTNゲートウェイ。または
o an application server generating billing information.
o 請求情報を生成するアプリケーションサーバー。
P-Charge-Info is to be used by the SIP entity that provides billing services for a session. This could be an entity that is generating billing records or another entity interacting with it. Upon receipt of an INVITE request with the P-Charge-Info header field, such an entity MAY use the value present in P-Charge-Info as indicating the party responsible for the charges associated with the session. This decision, for example, could be based on local policy.
P-Charge-Infoは、セッションに課金サービスを提供するSIPエンティティによって使用されます。これは、請求レコードを生成しているエンティティまたはそれとやり取りしている別のエンティティである可能性があります。 P-Charge-Infoヘッダーフィールドを含むINVITEリクエストを受信すると、そのようなエンティティは、P-Charge-Infoにある値を使用して、セッションに関連する料金の責任者を示すことができます。この決定は、たとえば、ローカルポリシーに基づく可能性があります。
The P-Charge-Info header field may be inserted by PSTN gateways or application servers acting as a SIP UA.
P-Charge-Infoヘッダーフィールドは、SIP UAとして機能するPSTNゲートウェイまたはアプリケーションサーバーによって挿入されます。
The P-Charge-Info header field is ignored by an end-user UA and should not normally be received by such a UA. It MUST NOT be sent to an end-user UA, as this would provide information to the UA about the party to be charged; providing such information may cause security-related issues; for example, calling-party information would be known by the UA for an otherwise anonymous call. A UA SHOULD ignore it if it receives this header. Similarly, an end-user UA originating a SIP message SHOULD NOT insert this header field.
P-Charge-InfoヘッダーフィールドはエンドユーザーUAによって無視され、通常はそのようなUAによって受信されるべきではありません。エンドユーザーのUAに送信してはなりません。これは、課金対象のパーティーに関する情報をUAに提供するためです。そのような情報を提供すると、セキュリティ関連の問題が発生する可能性があります。たとえば、発呼側の情報は、それ以外の場合は匿名の呼び出しでUAによって認識されます。 UAは、このヘッダーを受け取った場合は無視する必要があります（SHOULD）。同様に、SIPメッセージを発信するエンドユーザーUAは、このヘッダーフィールドを挿入してはなりません（SHOULD NOT）。
A PSTN gateway or application server acting as a UA MAY use the content of the P-Charge-Info header field present in an INVITE request it received as the identity to be charged for the session for billing-related procedures, e.g., in a billing record or during interaction with another entity generating billing records. A PSTN gateway or application server acting as a UA MAY use the content of the P-Charge-Info header field to populate information about the identity of the party to charge in another type of signaling, such as ISDN User Part (ISUP).
UAとして機能するPSTNゲートウェイまたはアプリケーションサーバーは、IDとして受信したINVITE要求に含まれるP-Charge-Infoヘッダーフィールドのコンテンツを使用して、課金関連の手順（たとえば、課金など）のセッションに課金する必要があります。記録、または請求記録を生成する別のエンティティとの対話中。 UAとして機能するPSTNゲートウェイまたはアプリケーションサーバーは、P-Charge-Infoヘッダーフィールドのコンテンツを使用して、ISDNユーザーパーツ（ISUP）などの別のタイプのシグナリングで課金する当事者のIDに関する情報を入力できます。
A SIP proxy that supports this extension and receives a request, typically a SIP INVITE, MAY insert a P-Charge-Info header field. The contents of the inserted header field may be decided based on local policy or by querying an external entity to determine the identity of the party to be charged.
この拡張をサポートし、要求を受信するSIPプロキシ（通常はSIP INVITE）は、P-Charge-Infoヘッダーフィールドを挿入できます（MAY）。挿入されたヘッダーフィールドの内容は、ローカルポリシーに基づいて、または外部エンティティに問い合わせて課金対象のパーティのIDを決定することによって決定できます。
When a proxy receives an INVITE request, it MAY use the content of the P-Charge-Info header field contained in the request for billing-related procedures, e.g., in a billing record or during interaction with another entity that is generating billing records.
プロキシは、INVITEリクエストを受信すると、課金関連の手順のリクエストに含まれるP-Charge-Infoヘッダーフィールドのコンテンツを使用できます（たとえば、課金レコード内、または課金レコードを生成している別のエンティティとの対話中）。
A SIP proxy that does not support this extension will pass any received P-Charge-Info header field unmodified, in compliance with RFC 3261.
この拡張をサポートしないSIPプロキシは、RFC 3261に準拠して、受信したP-Charge-Infoヘッダーフィールドを変更せずに渡します。
A proxy supporting this extension MUST remove the P-Charge-Info header field before sending a request to a UA that is not acting as a PSTN gateway or appropriate application server, if the role of the UA is known.
この拡張をサポートするプロキシは、UAの役割がわかっている場合、PSTNゲートウェイまたは適切なアプリケーションサーバーとして機能していないUAにリクエストを送信する前に、P-Charge-Infoヘッダーフィールドを削除する必要があります。
The content of the P-Charge-Info header field is typically just a SIP/tel URI used as a billing indicator. An example could be as simple as one of:
P-Charge-Infoヘッダーフィールドの内容は、通常、請求インジケータとして使用される単なるSIP / tel URIです。例は次のいずれかと同じくらい簡単です：
P-Charge-Info: <sip:+14075550134@example.net;user=phone>
P-Charge-Info: <sip:+12345550167@example.com>
P-Charge-Info: <sips:1234@example.com>
P-Charge-Info: <tel:+14075551234>
Any other applicable SIP URI could be used.
その他の該当するSIP URIを使用できます。
This RFC contains the definition of one or more SIP header fields that allow choosing between addr-spec and name-addr when constructing header-field values. [RFC8217] prohibits the use of addr-spec if its value would contain a comma, semicolon, or question mark.
このRFCには、ヘッダーフィールド値を作成するときにaddr-specとname-addrのどちらかを選択できる1つ以上のSIPヘッダーフィールドの定義が含まれています。 [RFC8217]は、値にカンマ、セミコロン、または疑問符が含まれる場合、addr-specの使用を禁止します。
The private header field specified here is described in both prose and an augmented Backus-Naur Form (BNF) defined in [RFC5234]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementors need to be familiar with the notation and contents of [RFC3261] and [RFC5234] to understand this document.
ここで指定されるプライベートヘッダーフィールドは、散文と、[RFC5234]で定義されている拡張バッカスナウアフォーム（BNF）の両方で説明されています。さらに、いくつかのBNF定義はSIPから継承され、ここでは繰り返されません。このドキュメントを理解するには、実装者は[RFC3261]と[RFC5234]の表記法と内容に精通している必要があります。
The syntax of the P-Charge-Info header field is described as follows:
P-Charge-Infoヘッダーフィールドの構文は次のとおりです。
P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec) ; name-addr and addr-spec are specified in RFC 3261
P-Charge-Info = "P-Charge-Info" HCOLON（name-addr / addr-spec）; name-addrおよびaddr-specはRFC 3261で指定されています
The SIP URI contained in the name-addr/addr-spec is the billing indicator that is passed between the parties.
name-addr / addr-specに含まれるSIP URIは、パーティ間で渡される請求インジケータです。
This specification registers a new proprietary SIP header field according to the procedures defined in [RFC5727].
この仕様は、[RFC5727]で定義された手順に従って、新しい独自のSIPヘッダーフィールドを登録します。
The P-Charge-Info private header field has been registered in the "Header Fields" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry as follows:
P-Charge-Infoプライベートヘッダーフィールドは、次のように「Session Initiation Protocol（SIP）Parameters」レジストリの「Header Fields」サブレジストリに登録されています。
Header Field Name: P-Charge-Info
ヘッダーフィールド名：P-Charge-Info
Compact Form: none
コンパクトフォーム：なし
Reference: RFC 8496
リファレンス：RFC 8496
Given that the information contained in the P-Charge-Info header field will be used for billing purposes, the proxies and other SIP entities that share this information MUST have a trust relationship.
P-Charge-Infoヘッダーフィールドに含まれる情報が課金目的で使用される場合、この情報を共有するプロキシおよびその他のSIPエンティティは信頼関係を持つ必要があります。
If an untrusted entity were inserted between the trusted entities, it could potentially interfere with the billing records for the call. If the SIP connections are not made over a private network, a mechanism for securing the confidentiality and integrity of the SIP connection MUST be used to protect the information. One such mechanism could be TLS encryption of the SIP signaling stream.
信頼できないエンティティが信頼できるエンティティの間に挿入された場合、通話の請求レコードに干渉する可能性があります。 SIP接続がプライベートネットワークを介して行われない場合は、SIP接続の機密性と整合性を保護するメカニズムを使用して、情報を保護する必要があります。そのようなメカニズムの1つは、SIPシグナリングストリームのTLS暗号化です。
If the P-Charge-Info header field was accepted by a SIP entity from an untrusted peer, there is the potential for fraud if the untrusted entity sent incorrect information, either inadvertently or maliciously.
P-Charge-Infoヘッダーフィールドが信頼できないピアからのSIPエンティティによって受け入れられた場合、信頼できないエンティティが誤ってまたは悪意により誤った情報を送信した場合、詐欺の可能性があります。
Therefore, a SIP entity MUST remove and ignore the P-Charge-Info header field when it is received from an untrusted entity.
したがって、SIPエンティティは、信頼されていないエンティティから受信したP-Charge-Infoヘッダーフィールドを削除して無視する必要があります。
If the P-Charge-Info header field was sent by a SIP entity to an untrusted peer, there is potential for exposure of network information that is internal to a trust domain. For instance, the untrusted entity may learn the identities of public SIP proxies used within the trust domain, which could then potentially be directly attacked.
P-Charge-InfoヘッダーフィールドがSIPエンティティによって信頼されていないピアに送信された場合、信頼ドメインの内部にあるネットワーク情報が漏洩する可能性があります。たとえば、信頼されていないエンティティは、信頼ドメイン内で使用されているパブリックSIPプロキシのIDを学習し、直接攻撃される可能性があります。
If an implementation does not strip P-Charge-Info from the message where specified in this document, it introduces serious privacy risks. Examples include revealing third-party billing relationships that might be sensitive, as well as unmasking the identity of callers who wish to remain anonymous. Depending on circumstances, the latter case may result in unwanted harassment and even physical harm to the calling party.
このドキュメントで指定されているメッセージからP-Charge-Infoを削除しない実装では、重大なプライバシーリスクが生じます。例としては、機密である可能性のあるサードパーティの課金関係を明らかにしたり、匿名を希望する発信者の身元を明らかにしたりします。状況によっては、後者の場合、発呼者に望ましくない嫌がらせが加えられたり、身体に危害が加えられたりすることもあります。
Therefore, a SIP entity MUST remove the P-Charge-Info header field when it is sent to an untrusted entity.
したがって、SIPエンティティは、信頼されていないエンティティに送信されるときに、P-Charge-Infoヘッダーフィールドを削除する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, DOI 10.17487/RFC5727, March 2010, <https://www.rfc-editor.org/info/rfc5727>.
[RFC5727] Peterson、J.、Jennings、C。、およびR. Sparks、「Session Initiation Protocol（SIP）およびReal-time Applications and Infrastructure Areaの変更プロセス」、BCP 67、RFC 5727、DOI 10.17487 / RFC5727 、2010年3月、<https://www.rfc-editor.org/info/rfc5727>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8217] Sparks, R., "Clarifications for When to Use the name-addr Production in SIP Messages", RFC 8217, DOI 10.17487/RFC8217, August 2017, <https://www.rfc-editor.org/info/rfc8217>.
[RFC8217] Sparks、R。、「SIPメッセージでname-addrプロダクションを使用する場合の説明」、RFC 8217、DOI 10.17487 / RFC8217、2017年8月、<https://www.rfc-editor.org/info/ rfc8217>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325]ジェニングス、C。、ピーターソン、J。、およびM.ワトソン、「信頼されたネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」、RFC 3325、DOI 10.17487 / RFC3325、2002年11月、<https ：//www.rfc-editor.org/info/rfc3325>。
[RFC5503] Andreasen, F., McKibben, B., and B. Marshall, "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", RFC 5503, DOI 10.17487/RFC5503, March 2009, <https://www.rfc-editor.org/info/rfc5503>.
[RFC5503] Andreasen、F.、McKibben、B。、およびB. Marshall、「PacketCable Distributed Call Signaling Architectureをサポートするためのプライベートセッション開始プロトコル（SIP）プロキシからプロキシへの拡張」、RFC 5503、DOI 10.17487 / RFC5503、 2009年3月、<https://www.rfc-editor.org/info/rfc5503>。
[RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July 2014, <https://www.rfc-editor.org/info/rfc7315>.
[RFC7315] Jesske、R.、Drage、K。、およびC. Holmberg、「3GPPのセッション開始プロトコル（SIP）に対するプライベートヘッダー（Pヘッダー）拡張」、RFC 7315、DOI 10.17487 / RFC7315、2014年7月、<https://www.rfc-editor.org/info/rfc7315>。
P-Charging-Vector is defined in Section 4.6 of [RFC7315] and used by the 3GPP to carry information related to the charging of a session. There are, however, some differences in the semantics associated with P-Charging-Vector and P-Charge-Info. P-Charging-Vector is mainly used to carry information for correlation of multiple charging records generated for a single session. On the other hand, P-Charge-Info is used to convey information about the party to be billed for a call. Furthermore, P-Charging-Vector has a mandatory icid-value parameter that is a globally unique value to identify the session for which the charging information is generated. Such a globally unique identifier is not necessary when carrying information about the user to be billed when it is attached to the corresponding session-related signaling.
P-Charging-Vectorは[RFC7315]のセクション4.6で定義されており、セッションの課金に関する情報を伝達するために3GPPによって使用されます。ただし、P-Charging-VectorとP-Charge-Infoに関連するセマンティクスにはいくつかの違いがあります。 P-Charging-Vectorは、主に、単一のセッションで生成された複数の課金レコードの相関情報を運ぶために使用されます。一方、P-Charge-Infoは、通話に対して課金されるパーティに関する情報を伝えるために使用されます。さらに、P-Charging-Vectorには、課金情報が生成されるセッションを識別するためのグローバルに一意の値である必須のicid-valueパラメーターがあります。そのようなグローバルに一意の識別子は、対応するセッション関連のシグナリングにアタッチされているときに課金されるユーザーに関する情報を運ぶ場合は必要ありません。
P-DCS-Billing-Info is defined in Section 7 of [RFC5503] and used for passing billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. For many billing situations, particularly the very large-scale residential telephone networks for which this header field is designed, P-DCS-Billing-Info is an excellent solution. However, this ability to address a range of situations adds complexity. According to RFC 5503, the following information is mandatory to include in each use of the P-DCS-Billing-Info header field:
P-DCS-Billing-Infoは[RFC5503]のセクション7で定義されており、PacketCable分散型コールシグナリングアーキテクチャの信頼できるエンティティ間で課金情報を渡すために使用されます。多くの課金状況、特にこのヘッダーフィールドが設計されている非常に大規模な住宅電話ネットワークでは、P-DCS-Billing-Infoは優れたソリューションです。ただし、さまざまな状況に対処するこの機能により、複雑さが増します。 RFC 5503によれば、P-DCS-Billing-Infoヘッダーフィールドを使用するたびに、次の情報を含める必要があります。
o Billing-Correlation-ID, a globally unique identifier
o Billing-Correlation-ID、グローバルに一意の識別子
o Financial-Entity-ID
o 金融機関ID
o RKS-Group-ID (record-keeping server)
o RKS-Group-ID（記録保持サーバー）
The P-DCS-Billing-Info header field may also include a variety of additional parameters.
P-DCS-Billing-Infoヘッダーフィールドには、さまざまな追加パラメーターが含まれる場合もあります。
While this may work well in many billing scenarios, there are other billing scenarios that do not need this level of complexity. In those simpler scenarios, all that is needed is a number to use for billing. P-Charge-Info provides this simple solution for simple billing scenarios.
これは多くの請求シナリオでうまく機能するかもしれませんが、このレベルの複雑さを必要としない他の請求シナリオがあります。これらのより単純なシナリオでは、必要なのは請求に使用する数だけです。 P-Charge-Infoは、単純な請求シナリオにこの単純なソリューションを提供します。
Additionally, according to Section 7.3 of RFC 5503, it is mandatory for a UA to create a Billing-Correlation-ID and insert this into the P-DCS-Billing-Info header field (along with the other required information) sent in the initial SIP INVITE. This again makes sense for the residential-telephone-service environment for which this header field is designed. In contrast, P-Charge-Info is designed to be used among proxies and not at all by normal user agents. (P-Charge-Info may, though, be used by user agents associated with PSTN gateways.)
さらに、RFC 5503のセクション7.3によると、UAはBilling-Correlation-IDを作成し、これを最初に送信されたP-DCS-Billing-Infoヘッダーフィールドに（他の必要な情報とともに）挿入する必要がありますSIP INVITE。これは、このヘッダーフィールドが設計されている住宅用電話サービス環境にとっても意味があります。対照的に、P-Charge-Infoはプロキシ間で使用されるように設計されており、通常のユーザーエージェントではまったく使用されません。 （ただし、P-Charge-Infoは、PSTNゲートウェイに関連付けられたユーザーエージェントによって使用される場合があります。）
Early reviewers of this document asked why the P-Asserted-Identity header field documented in [RFC3325] could not be used. As mentioned in the use-case example above, P-Asserted-Identity is used to indicate the identity of the calling party. However, in this instance, the requirement is to provide an additional identity of the SIP-to-PSTN interconnect point.
この文書の初期のレビューアは、[RFC3325]に文書化されているP-Asserted-Identityヘッダーフィールドを使用できない理由を尋ねました。上記の使用例で述べたように、P-Asserted-Identityは、発呼者のアイデンティティを示すために使用されます。ただし、この場合の要件は、SIPからPSTNへの相互接続ポイントの追加のIDを提供することです。
It would be typical to find both P-Asserted-Identity and P-Charge-Info used in a SIP exchange. P-Asserted-Identity would be used to provide the caller identity that would be displayed to the end user as "Caller ID", while P-Charge-Info would provide the billing identifier used for the billing associated with the call.
SIP交換で使用されるP-Asserted-IdentityとP-Charge-Infoの両方を見つけるのが一般的です。 P-Asserted-Identityは、エンドユーザーに「発信者ID」として表示される発信者のIDを提供するために使用され、P-Charge-Infoは、通話に関連付けられた課金に使用される課金識別子を提供します。
Acknowledgements
謝辞
The authors thank the following people for their comments: Keith Drage, Miguel Garcia, Sumit Garg, John Haluska, Juha Heinanen, Christer Holmberg, Paul Kyzivat, Adam Roach, Jonathan Rosenberg, Henning Schulzrinne, Tom Taylor, and Glen Wang.
著者は、コメントしてくれた以下の人々に感謝します：キースドラゲ、ミゲルガルシア、スミットガルグ、ジョンハルスカ、ジュハハイナネン、クリスターホルムバーグ、ポールキジバット、アダムローチ、ジョナサンローゼンバーグ、ヘニングシュルズリンネ、トムテイラー、グレンワン。
Authors' Addresses
著者のアドレス
Dan York Individual Keene, NH United States of America
Dan York個人Keene、NHアメリカ合衆国
Email: dyork@lodestar2.com
Tolga Asveren Ribbon Communications 3 Paragon Way, Suite 100 Freehold, NJ 007728 United States of America
Tolga Asveren Ribbon Communications 3 Paragon Way、Suite 100 Freehold、NJ 007728アメリカ合衆国
Email: tasveren@rbbn.com