Internet Engineering Task Force (IETF) K. Drage
Request for Comments: 6050 Alcatel-Lucent
Category: Informational November 2010
ISSN: 2070-1721
A Session Initiation Protocol (SIP) Extension
for the Identification of Services
Abstract
抽象
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.
この文書では、認証されたユーザーのサービスを主張するために、信頼できるSIPサーバのネットワークを有効にするセッション開始プロトコル（SIP）のプライベート拡張機能について説明します。これらの拡張機能を使用するには、生成、輸送、及びそのような情報の利用のために、以前に合意された政策と管理ドメインの内部のみ適用されます。この文書では、異なる信頼ドメイン間または大で、インターネットでの使用のために用いるのに適した一般的なサービス識別モデルを提供していません。
The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs.
文書はまた、両方のサービスとユーザーエージェント（UA）のアプリケーションを識別するためのURNを定義します。このURNは、サービスを識別するために、本文書で定義されたSIPヘッダフィールド内で使用することができ、また、発信者の好みや着信機能に対して定義されたフレームワーク内でサービスとエンドユーザエージェントとの間のアプリケーションの両方の使用を識別します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6050.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6050で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Syntax of the Header Fields . . . . . . . . . . . . . . . . . 6
4.1. The P-Asserted-Service Header . . . . . . . . . . . . . . 6
4.2. The P-Preferred-Service Header . . . . . . . . . . . . . . 7
4.3. Service and Application Definition . . . . . . . . . . . . 8
4.4. Registration Template . . . . . . . . . . . . . . . . . . 8
5. Usage of the P-Preferred-Service and P-Asserted-Service
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Requests . . . . . . . 10
5.1.1. Procedures at User Agent Clients (UAC) . . . . . . . . 10
5.1.2. Procedures at Intermediate Proxies . . . . . . . . . . 11
5.1.3. Procedures at User Agent Servers . . . . . . . . . . . 12
5.2. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Responses . . . . . . 12
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. P-Asserted-Service and P-Preferred-Service Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Definition of Service-ID Values . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service, possibly subject to the user being entitled to that service. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service model suitable for use between different trust domains or for use in the Internet at large.
この文書では、そのサービスを受ける権利がされているユーザに、おそらく対象、サービスを主張するために、信頼できるSIPサーバのネットワークを有効にするセッション開始プロトコル（SIP）のプライベート拡張機能について説明します。これらの拡張機能を使用するには、生成、輸送、及びそのような情報の利用のために、以前に合意された政策と管理ドメインの内部のみ適用されます。この文書では、異なる信頼ドメイン間または大で、インターネットでの使用のために用いるのに適した一般的なサービスモデルを提供していません。
The concept of "service" within SIP has no hard and fast rules. RFC 5897 [RFC5897] provides general guidance on what constitutes a service within SIP and what does not.
SIP内の「サービス」の概念には、ハードと高速なルールを持っていません。 RFC 5897 [RFC5897]はSIP内のサービスを構成し、動かないで一般的なガイダンスを提供します。
This document also makes use of the terms "derived service identification" and "declarative service identification" as defined in RFC 5897 [RFC5897].
この文書はまた、用語「由来サービス識別」とRFC 5897 [RFC5897]で定義される「宣言型サービス識別」を利用します。
It should be noted that RFC 5897 [RFC5897] clearly states that declarative service identification -- the process by which a user agent inserts a moniker into a message that defines the desired service, separate from explicit and well-defined protocol mechanisms -- is harmful.
ユーザエージェントは、所望のサービスを定義するメッセージにモニカを挿入するプロセスは、明示的及び明確に定義されたプロトコルメカニズムから分離 - - 有害であり、RFC 5897 [RFC5897]は明らか宣言サービス識別は、と述べていることに留意すべきです。
During a session setup, proxies may need to understand what service the request is related to in order to know what application server to contact or other service logic to invoke. The SIP INVITE request contains all of the information necessary to determine the service. However, the calculation of the service may be computational and database intensive. For example, a given trust domain's definition of a service might include request authorization. Moreover, the analysis may require examination of the Session Description Protocol (SDP).
セッションのセットアップ中、プロキシはリクエストを呼び出すためにどのようなアプリケーションサーバに連絡するか、他のサービスロジックを知るためにに関連しているもののサービスを理解する必要があるかもしれません。 SIPは、要求がサービスを決定するために必要なすべての情報が含まれていINVITE。しかし、サービスの計算は、計算やデータベースの集中的かもしれません。例えば、サービスの与えられた信頼ドメインの定義は、リクエストの承認が含まれる場合があります。また、分析は、セッション記述プロトコル（SDP）の検査を必要とし得ます。
For example, an INVITE request with video SDP directed to a video-on-demand Request-URI could be marked as an IPTV session. An INVITE request with push-to-talk over cellular (PoC) routes could be marked as a PoC session. An INVITE request with a Require header field containing an option tag of "foogame" could be marked as a foogame session.
例えば、ビデオ・オン・デマンドのRequest-URIに向けた映像SDPとINVITEリクエストはIPTVセッションとしてマークすることができます。 PoCセッションとしてマークすることができ、プッシュ・ツー・トーク（POC）携帯ルート経由でINVITEリクエストを。 「foogame」のオプションタグを含むヘッダを必要とするフィールドを持つINVITEリクエストをfoogameセッションとしてマークすることができます。
NOTE: If the information contained within the SIP INVITE request is not sufficient to uniquely identify a service, the remedy is to extend the SIP signaling to capture the missing element. RFC 5897 [RFC5897] provides further explanation.
注：SIPに含まれる情報は、INVITE要求をした場合は、サービスを一意に識別するのに十分ではない、治療薬は、欠落している要素を捕捉するためにSIPシグナリングを拡張することです。 RFC 5897 [RFC5897]は更なる説明を提供します。
By providing a mechanism to compute and store the results of the domain-specific service calculation, i.e., the derived service identification, this optimization allows a single trusted proxy to perform an analysis of the request and authorize the requestor's permission to request such a service. The proxy may then include a service identifier that relieves other trusted proxies and trusted UAs from performing further duplicate analysis of the request for their service identification purposes. In addition, this extension allows user agent clients outside the trust domain to provide a hint of the requested service.
すなわち、誘導されたサービス識別をドメイン固有のサービスの計算の結果を計算し、格納するための機構を提供することにより、この最適化は、要求の分析を行い、そのようなサービスを要求する要求者の許可を承認する単一の信頼できるプロキシを可能にします。プロキシは、次いで、それらのサービス識別目的のための要求の分析を複製さらに実行することから、他の信頼できるプロキシと信頼のUAを緩和サービス識別子を含んでもよいです。また、この拡張は、信頼ドメイン外のユーザー・エージェント・クライアントが要求されたサービスのヒントを提供することができます。
This extension does not provide for the dialog or transaction to be rejected if the service is not supported end-to-end. SIP provides other mechanisms, such as the option-tag and use of the Require and Proxy-Require header fields, where such functionality is required. No explicitly signaled service identification exists, and the session proceeds for each node's definition of the service in use, on the basis of information contained in the SDP and in other SIP header fields.
この拡張は、サービスをエンドツーエンドでサポートされていない場合は拒否され、ダイアログまたはトランザクションのために提供されていません。 SIPは、必要とし、そのような機能が必要とされるヘッダフィールドを、プロキシ要求のオプションタグと使用などの他のメカニズムを提供します。全く明示SDPおよび他のSIPヘッダフィールドに含まれる情報に基づいて、識別が存在するサービス、および使用中のサービスの各ノードの定義のためのセッション進行を合図しません。
This mechanism is specifically for managing the information needs of intermediate routing devices between the calling user and the user represented by the Request-URI. In support of this mechanism, a URN is defined to identify the services. This URN has wider applicability to additionally identify services and terminal applications. Between end users, caller preferences and callee capabilities as specified in RFC 3840 [RFC3840] and RFC 3841 [RFC3841] provide an appropriate mechanism for indicating such service and application identification. These mechanisms have been extended by RFC 5688 [RFC5688] to provide further capabilities in this area.
この機構は、具体的には発呼ユーザとRequest-URIによって表されるユーザ間の中間ルーティングデバイスの情報ニーズを管理するためのものです。このメカニズムのサポートでは、URNは、サービスを識別するために定義されています。このURNは、さらに、サービスと端末のアプリケーションを識別するために、より広い適用性を有します。エンドユーザ、発呼者の嗜好と着信機能RFC 3840で指定されるように[RFC3840]及びRFC 3841 [RFC3841]の間で、サービスとアプリケーション識別を示すための適切なメカニズムを提供します。これらの機構は、この分野における更なる機能を提供するためにRFC 5688 [RFC5688]によって拡張されてきました。
The mechanism proposed in this document relies on a new header field called 'P-Asserted-Service' that contains a URN. This is supported by a further new header field called 'P-Preferred-Service' that also contains a URN and that allows the UA to express preferences regarding the decisions made on service within the trust domain.
この文書で提案されたメカニズムは、URNが含まれている「P-アサート-サービス」と呼ばれる新しいヘッダフィールドに依存しています。これは、URNが含まれており、それはUAが信頼ドメイン内のサービスに行われた決定についての好みを表現することを可能にする「P-プリファード・サービス」と呼ばれ、さらに新しいヘッダフィールドによってサポートされています。
An example of the P-Asserted-Service header field is:
P-アサート・サービス・ヘッダ・フィールドの例です。
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
P-アサート-サービス：URN：URN-7：3GPP-service.exampletelephony.version1
A proxy server that handles a request can, after authenticating the originating user in some way (for example: digest authentication) to ensure that the user is entitled to that service, insert such a P-Asserted-Service header field into the request and forward it to other trusted proxies. A proxy that is about to forward a request to a proxy server or UA that it does not trust removes all the P-Asserted-Service header field values.
要求を処理するプロキシサーバは、何らかの方法で発信ユーザを認証した後にすることができる：ユーザーがそのサービスを受ける権利があることを保証するために（例えば、ダイジェスト認証）、要求及び前方に、このようなP-アサートサービスヘッダフィールドを挿入します他の信頼のプロキシへのそれ。それは信頼がすべてのP-アサート・サービスヘッダーフィールド値を削除していないことをプロキシサーバーまたはUAにリクエストを転送しようとしているプロキシ。
This document labels services by means of an informal URN. This provides a hierarchical structure for defining services and subservices, and provides an address that can be resolvable for various purposes outside the scope of this document, e.g., to obtain information about the service so described.
この文書は非公式URNによってサービスにラベルを付けます。これには、記述されたサービスに関する情報を取得するために、例えば、サービスおよびサブサービスを定義するための階層構造を提供し、この文書の範囲外で様々な目的のために解決することができるアドレスを提供します。
This document describes private extensions to SIP (see RFC 3261 [RFC3261]) that enable a network of trusted SIP servers to assert the service of end users or end systems. The use of these extensions is only applicable inside a 'trust domain' as defined in "Short Term Requirements for Network Asserted Identity" (see RFC 3324 [RFC3324]). Nodes in such a trust domain are explicitly trusted by its users and end systems to publicly assert the service of each party, and that they have common and agreed-upon definitions of services and homogeneous service offerings. The means by which the network determines the service to assert is outside the scope of this document (though it commonly entails some form of authentication).
この文書では、エンドユーザまたはエンドシステムのサービスを主張するために、信頼できるSIPサーバのネットワークを可能にするSIP（RFC 3261 [RFC3261]を参照）にプライベート拡張機能について説明します。 「ネットワークのための短期要件は、アイデンティティをアサート」で定義されているこれらの拡張機能を使用すると、「信頼ドメイン」内部のみ適用されます（RFC 3324 [RFC3324]を参照）。こうした信頼ドメイン内のノードは、明示的に公に各当事者のサービスを主張するために自社のユーザーおよびエンドシステムから信頼され、そして、彼らは共通して合意されたサービスと、均質なサービスの提供の定義を持っていること。 （それは一般的に、認証のいくつかのフォームを伴うが）ネットワークをアサートするサービスを決定する手段は、この文書の範囲外です。
The mechanism for defining a trust domain is to provide a certain set of specifications known as 'Spec(T)', and then specify compliance to that set of specifications. Spec(T) MUST specify behavior as documented in RFC 3324 [RFC3324].
信頼ドメインを定義するためのメカニズムは、「仕様（T）」として知られている仕様の特定のセットを提供し、その後、仕様のセットへの準拠を指定することです。 RFC 3324 [RFC3324]に記載されているようにスペック（T）の動作を指定しなければなりません。
This document does NOT offer a general service model suitable for inter-domain use or use in the Internet at large. Its assumptions about the trust relationship between the user and the network may not apply in many applications. For example, these extensions do not accommodate a model whereby end users can independently assert their service by use of the extensions defined here. End users assert their service by including the SIP and SDP parameters that correspond to the service they require. Furthermore, since the asserted services are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of RFC 3324 [RFC3324].
この文書では、大規模で、インターネットにおけるドメイン間の使用または使用に適した一般的なサービスモデルを提供していません。ユーザとネットワークとの間の信頼関係についての仮定は、多くのアプリケーションに適用されない場合があります。例えば、これらの拡張機能は、エンドユーザーが独立して、ここで定義された拡張子を使用することによって彼らのサービスを主張できるモデルには対応していません。エンドユーザーは、彼らが必要とするサービスに対応したSIPとSDPのパラメータを含めることによって、彼らのサービスを主張します。アサートサービスは、暗号認定されていないので、彼らは、RFC 3324 [RFC3324]の要件を満たしていない任意のアーキテクチャの偽造、リプレイ、および改ざんの対象となっています。
The asserted services also lack an indication of who specifically is asserting the service, and so it must be assumed that a member of the trust domain is asserting the service. Therefore, the information is only meaningful when securely received from a node known to be a member of the trust domain.
アサートサービスも特にサービスをアサートされ、そして信頼ドメインのメンバーがサービスをアサートしていることを想定しなければならない人の表示を欠いています。安全信頼ドメインのメンバーであることが知られているノードから受信したときしたがって、情報は意味があります。
Despite these limitations, there are sufficiently useful specialized deployments, that meet the assumptions described above and can accept the limitations that result, to warrant informational publication of this mechanism.
これらの制限にもかかわらず、十分に上記の仮定を満たすために、このメカニズムの情報掲載を保証するために、結果としての限界を受け入れることができ便利な専門的な展開があります。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Throughout this document, requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries within a trust domain (for example, back-to-back user agents (B2BUAs)).
本書では、プロキシサーバまたはプロキシ行動への要件や参照が（例えば、バックツーバックユーザエージェント（型B2BUA））信頼ドメイン内の他の仲介業者と同様に適用されます。
The term trust domain in this document has the meaning as defined in RFC 3324 [RFC3324].
この文書の長期信頼ドメインは、RFC 3324 [RFC3324]で定義された意味を持ちます。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234].
以下の構文仕様は、RFC 5234 [RFC5234]に記載されているように拡張バッカスナウア記法（BNF）を使用します。
The P-Asserted-Service header field is used among trusted SIP entities (typically intermediaries) to carry the service information of the user sending a SIP message.
P-アサート・サービス・ヘッダフィールドは、SIPメッセージを送信するユーザのサービス情報を運ぶために、信頼できるSIPエンティティ（典型的に仲介）の間に使用されます。
The P-Asserted-Service header field carries information that is derived service identification. While a declarative service identification can assist in deriving the value transferred in this header field, this should be in the form of streamlining the correct derived service identification.
P-アサート・サービス・ヘッダフィールドは、サービス識別に由来する情報を運びます。宣言型のサービス識別がこのヘッダフィールドに転送される値を導出するのを助けることができるが、これは正しい由来サービス識別を合理化の形態であるべきです。
PAssertedService = "P-Asserted-Service"
HCOLON PAssertedService-value
PAssertedService-value = Service-ID *(COMMA Service-ID)
PAssertedService値=サービス-ID *（COMMAサービス-ID）
See Section 4.4 for the definition of Service-ID in ABNF.
ABNFでサービス-IDの定義については、4.4項を参照してください。
Proxies can (and will) add and remove this header field.
プロキシは（となります）、このヘッダフィールドを追加および削除することができます。
Table 1 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in the reliability of provisional responses in SIP [RFC3262], Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for instant messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
表1は、SIP [RFC3261]、SIP固有のイベント通知[RFC3265]、SIP INFO法で表1及び2 [RFC2976]のセクション7.1、表1および表2に表2に、この文書で定義されたヘッダフィールドを付加しますSIP [RFC3262]、SIP更新方法において、表1及び2 [RFC3311]での暫定的な応答の信頼性は、インスタントメッセージング[RFC3428]のためのSIP拡張で、表1及び2は、SIPにおける表1、方法[RFC3515]をREFERそしてSIPにおける表2および3は、方法[RFC3903]を公開します：
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Asserted-Service R admr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Asserted-Service - - - - o o o
Table 1
表1
Syntactically, there may be multiple P-Asserted-Service header fields in a request. The semantics of multiple P-Asserted-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST provide only one P-Asserted-Service header field value.
構文的に、要求内の複数のP-アサート・サービス・ヘッダフィールドがあってもよいです。同じ要求に現れる複数のP-アサート・サービス・ヘッダフィールドのセマンティクスは、この時点で定義されていません。この仕様の実装は、唯一のP-アサート・サービス・ヘッダフィールド値を提供しなければなりません。
The P-Preferred-Service header field is used by a user agent sending the SIP request to provide a hint to a trusted proxy of the preferred service that the user wishes to be used for the P-Asserted-Service field value that the trusted element will insert.
P-好ましいサービスヘッダフィールドは、ユーザがP-アサートサービスフィールド値のために使用することを望む好ましいサービスの信頼できるプロキシにヒントを提供するためにSIP要求を送信するユーザエージェントによって使用される信頼要素挿入されます。
The P-Preferred-Service header field carries information that is declarative service identification. Such information should only be used to assist in deriving a derived service identification at the recipient entity.
P-好ましいサービスヘッダフィールドは、宣言サービス識別である情報を運びます。そのような情報は、受信側エンティティに由来するサービス識別情報を導出する際に補助するために使用されるべきです。
PPreferredService = "P-Preferred-Service"
HCOLON PPreferredService-value
PPreferredService-value = Service-ID *(COMMA Service-ID)
PPreferredService値=サービスID *（COMMAサービスID）
See Section 4.4 for the definition of Service-ID in ABNF.
ABNFでサービス-IDの定義については、4.4項を参照してください。
Table 2 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in Reliability of provisional responses in SIP [RFC3262],
表2は、SIP [RFC3261]、SIP固有のイベント通知[RFC3265]、SIP INFO法で表1及び2 [RFC2976]のセクション7.1、表1および表2に表2に、この文書で定義されたヘッダフィールドを付加しますSIP [RFC3262]での暫定的な応答の信頼性、
Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for Instant Messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
SIPのUPDATE法[RFC3311]の表1及び2は、SIPにおけるインスタントメッセージング[RFC3428]、表1のためのSIP拡張の表1及び2は、[メソッドを公開SIP方法[RFC3515]、および表2及び3参照しますRFC3903]：
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Preferred-Service R dr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Preferred-Service - - - - o o o
Table 2
表2
Syntactically, there may be multiple P-Preferred-Service header fields in a request. The semantics of multiple P-Preferred-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST only provide one P-Preferred-Service header field value.
構文的に、要求内の複数のP-優先サービスヘッダフィールドがあってもよいです。同じ要求に現れる複数のP-優先サービスヘッダフィールドのセマンティクスは、この時点で定義されていません。この仕様の実装は、1つのP優先サービスヘッダフィールド値を提供しなければなりません。
Service definitions and characteristics are outside the scope of this document. Other standards organizations, vendors, and operators may define their own services and register them.
サービスの定義および特徴は、本文書の範囲外です。他の標準化団体、ベンダー、および事業者は、独自のサービスを定義し、それらを登録することもできます。
A hierarchical structure is defined consisting of service identifiers or application identifiers, and subservice identifiers.
階層構造は、サービス識別子やアプリケーション識別子、およびサブサービス識別子からなる定義されています。
The service and subservice identifiers are as described in Section 1. The URN may also be used to identify a service or an application between end users for use within the context of RFC 3840 [RFC3840] and RFC 3841 [RFC3841].
サービスおよびサブサービス識別子は次のようにセクション1に記載されているURNは、サービス又はRFC 3840 [RFC3840]及びRFC 3841 [RFC3841]のコンテキスト内で使用するためのエンドユーザとの間のアプリケーションを識別するために使用されてもよいです。
IANA maintains a registry of service identifier values that have been assigned. This registry has been created by the actions of Section 8.2 of this document.
IANAが割り当てられているサービス識別子値のレジストリを維持します。このレジストリは、このドキュメントのセクション8.2の行動によって作成されています。
subservice identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the subservices.
サブサービス識別子は、IANAによって管理されていません。これは、サブサービスを管理するサービスを登録する組織の責任です。
Below, we include the registration template for the URN scheme according to RFC 3406 [RFC3406]. The URN scheme is defined as an informal Namespace ID (NID).
以下では、RFC 3406 [RFC3406]に従ったURNスキームの登録テンプレートが含まれています。 URNスキームは非公式ネームスペースID（NID）と定義されます。
Namespace ID: urn-7
名前空間ID：URN-7
Registration Information: Registration version: 1; registration date: 2009-03-22
登録情報：登録バージョン：1;登録日：2009年3月22日
Declared registrant of the namespace: 3GPP Specifications Manager (3gppContact@etsi.org) (+33 (0)492944200)
名前空間の宣言された登録者：3GPP仕様マネージャ（3gppContact@etsi.org）（+33（0）492944200）
Declaration of syntactic structure: The URN consists of a hierarchical service identifier or application identifier, with a sequence of labels separated by periods. The leftmost label is the most significant one and is called 'top-level service identifier', while names to the right are called 'subservices' or 'sub-applications'. The set of allowable characters is the same as that for domain names (see RFC 1123 [RFC1123]) and a subset of the labels allowed in RFC 3958 [RFC3958]. Labels are case-insensitive and MUST be specified in all lowercase. For any given service identifier, labels can be removed right-to-left and the resulting URN is still valid, referring a more generic service, with the exception of the top-level service identifier and possibly the first subservice or sub-application identifier. Labels cannot be removed beyond a defined basic service; for example, the label w.x may define a service, but the label w may only define an assignment authority for assigning subsequent values and not define a service in its own right. In other words, if a service identifier 'w.x.y.z' exists, the URNs 'w.x' and 'w.x.y' are also valid service identifiers, but w may not be a valid service identifier if it merely defines who is responsible for defining x.
統語構造の宣言：URNは、ピリオドで区切られたラベルの配列と、階層サービス識別子やアプリケーション識別子から成ります。左端のラベルは、最も重要な一つであり、右側に名前が「サブサービス」または「サブアプリケーション」と呼ばれているが、「トップレベルのサービス識別子」と呼ばれます。許容可能な文字の集合は、ドメイン名（RFC 1123 [RFC1123]を参照）、RFC 3958で許可されるラベルの部分集合[RFC3958]と同じです。ラベルは、大文字と小文字が区別され、すべて小文字で指定する必要があります。任意の与えられたサービス識別子のために、トップレベルのサービス識別子と、おそらく最初のサブサービスまたはサブアプリケーション識別子を除いて、より一般的なサービスを参照すると、ラベルは、右から左へ除去することができ、得られたURNは依然として有効です。ラベルは、定義された基本的なサービスを超えて削除することはできません。例えば、ラベルw.xは、サービスを定義することができるが、ラベルWは、後続の値を割り当てるための割り当て権限を定義し、それ自体でサービスを定義しなくてもよいです。換言すれば、サービス識別子「w.x.y.z」が存在する場合、のURN「w.x」と「w.x.y」も有効なサービス識別子であるが、それは単にXを定義するための責任者定義する場合、Wは、有効なサービス識別子ではないかもしれません。
Service-ID = "urn:urn-7:" urn-service-id
urn-service-id = top-level *("." sub-service-id)
top-level = let-dig [ *26let-dig ]
sub-service-id = let-dig [ *let-dig ]
let-dig = ALPHA / DIGIT / "-"
While the naming convention above uses the term "service", all the constructs are equally applicable to identifying applications within the UA.
命名規則は、上記の「サービス」という用語を使用していますが、全ての構築物は、UA内のアプリケーションを識別することに等しく適用可能です。
Relevant ancillary documentation: None
関連の補助ドキュメント：なし
Identifier uniqueness considerations: A service identifier identifies a service, and an application identifier an application indicated in the service or application registration (see IANA Considerations (Section 8)). Uniqueness is guaranteed by the IANA registration.
識別子の一意性の考慮事項：サービス識別子（IANAの考慮事項（セクション8）を参照）サービスまたはアプリケーションの登録に示されるアプリケーションサービスを識別し、アプリケーション識別子。一意性は、IANA登録によって保証されています。
Identifier persistence considerations: The service or application identifier for the same service or application is expected to be persistent, although there naturally cannot be a guarantee that a particular service will continue to be available globally or at all times.
識別子の永続性の考慮事項：そこに自然に特定のサービスをグローバルに、またはすべての回で利用可能であり続けることを保証することはできませんが、同じサービスまたはアプリケーションのサービスまたはアプリケーション識別子は、永続的であることが予想されます。
Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 8).
識別子割り当てのプロセス：識別子の割り当て処理はIANAの考慮事項（セクション8）に記載されています。
Process for identifier resolution: There is no single global resolution service for service identifiers or application identifiers.
識別子解決のプロセス：サービス識別子やアプリケーション識別子のための単一のグローバル解決サービスはありません。
Rules for lexical equivalence: 'service' identifiers are compared according to case-insensitive string equality.
字句等価のルール：「サービス」識別子は大文字と小文字を区別しない文字列の平等に応じて比較されます。
Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme.
URN構文に準拠：BNF「構文構造の宣言」では上記このURNスキームの構文を制約します。
Validation mechanism: Validation determines whether a given string is currently a validly assigned URN (see RFC 3406 [RFC3406]). Due to the distributed nature of usage and since not all services are available everywhere, validation in this sense is not possible.
検証メカニズム：検証は、指定された文字列が現在URN（RFC 3406 [RFC3406]を参照）割り当て正当であるか否かを判断します。利用状況の分散性にしていないすべてのサービスがどこでも利用可能なので、この意味での検証ができません。
Scope: The scope for this URN can be local to a single domain, or may be more widely used.
範囲：このURNのスコープは、単一のドメインに対してローカルであってもよく、又はより広く使用されてもよいです。
5. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields
P-好ましい-ServiceおよびP-アサート・サービス・ヘッダー・フィールドの5使い方
5.1. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields in Requests
5.1. 要求におけるP-優先-ServiceおよびP-アサート-サービスヘッダフィールドの使用方法
The UAC MAY insert a P-Preferred-Service in a request that creates a dialog, or a request outside of a dialog. This information can assist the proxies in identifying appropriate service capabilities to apply to the call. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present. Thus, if a service requires a video component, then the SDP has to include the media line associated with that video component; it cannot be assumed from the P-Preferred-Service header field value. Similarly, if the service requires particular SIP functionality for which a SIP extension and a Require header field value is defined, then the request has to include that SIP signaling as well as the P-Preferred-Service header field value.
UACは、ダイアログ、またはダイアログの外で要求を作成し、要求にP-プリファード・サービスを挿入することができます。この情報は、通話に適用するために、適切なサービス機能を識別するのにプロキシを支援することができます。この情報は、他のSIPまたはリクエストに含まれるSDP情報と矛盾してはなりません。また、このサービスの機能を知らせるために必要なSIPやSDP情報が存在しなければなりません。サービスは、ビデオコンポーネントを必要とする場合したがって、次にSDPは、そのビデオ・コンポーネントに関連付けられたメディア行を含まなければなりません。それはP-優先サービスヘッダフィールド値から推定することができません。サービスは、SIPの拡張ヘッダを要求フィールド値が定義されている特定のSIP機能を必要とする場合も同様に、その要求は、SIP P-好ましい・サービス・ヘッダフィールド値、ならびにシグナリングすることを含まなければなりません。
A UAC that is within the same trust domain as the proxy to which it sends a request (e.g., a media gateway or application server) MAY insert a P-Asserted-Service header field in a request that creates a dialog, or a request outside of a dialog. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present.
それが要求を送信するようにプロキシと同じ信頼ドメイン内にあるUAC（例えば、メディアゲートウェイ又はアプリケーションサーバ）が、ダイアログを作成する要求、又は外部要求にP-アサート・サービス・ヘッダフィールドを挿入することができますダイアログの。この情報は、他のSIPまたはリクエストに含まれるSDP情報と矛盾してはなりません。また、このサービスの機能を知らせるために必要なSIPやSDP情報が存在しなければなりません。
A proxy in a trust domain can receive a request from a node that it trusts or a node that it does not trust. When a proxy receives a request from a node it does not trust and it wishes to add a P-Asserted-Service header field, the proxy MUST identify the service appropriate to the capabilities (e.g., SDP) in the request, MAY authenticate the originator of the request (in order to determine whether the user is subscribed for that service). Where the originator of the request is authenticated, the proxy MUST use the identity that results from this checking and authentication to insert a P-Asserted-Service header field into the request.
信頼ドメイン内のプロキシは、それが信頼するノードまたはそれが信頼していないノードからの要求を受け取ることができます。プロキシは、それが信頼していないノードからの要求を受信し、P-アサート・サービス・ヘッダフィールドを追加したい場合、プロキシは、発信元を認証することができる、要求に機能（例えば、SDP）に適切なサービスを識別しなければなりません（ユーザがそのサービスに加入しているかどうかを決定するために）要求。要求の発信元が認証される場合、プロキシは、要求にP-アサート・サービス・ヘッダフィールドを挿入するために、このチェックおよび認証に起因するIDを使用しなければなりません。
When a proxy receives a request containing a P-Preferred-Service header field, the Proxy MAY use the contents of that header field to assist in determining the service to be included in a P-Asserted-Service header field (for instance, to prioritize the order of comparison of filter criteria for potential services that the request could match). The proxy MUST NOT use the contents of the P-Preferred-Service header field to identify the service without first checking against the capabilities (e.g., SDP) contained in the request. If the proxy inserts a P-Asserted-Service header field in the request, the proxy MUST remove the P-Preferred-Service header field before forwarding the request; otherwise, the Proxy SHOULD include the P-Preferred-Service header field when forwarding the request.
プロキシはP-優先サービスヘッダフィールドを含むリクエストを受信すると、プロキシは、優先順位を、例えば、（P-アサートサービスヘッダフィールドに含まれるサービスを決定する際に支援するために、そのヘッダフィールドの内容を使用するかもしれ要求が一致する可能性のある潜在的なサービス）のためのフィルタ基準の比較のために。プロキシは、リクエストに含まれる機能（例えば、SDP）に対する最初の検査なしでサービスを識別するために、P-優先サービスヘッダフィールドの内容を使用してはいけません。プロキシは、要求にP-アサート・サービス・ヘッダフィールドを挿入する場合、プロキシは、要求を転送する前に、P-優先サービスヘッダフィールドを削除する必要があります。要求を転送するとき、さもなければ、プロキシはP-優先サービスヘッダフィールドを含むべきです。
If the proxy receives a request from a node that it trusts, it can use the information in the P-Asserted-Service header field, if any, as if it had authenticated the user itself.
プロキシは、それが信頼するノードからの要求を受信した場合、もしあれば、それはユーザ自身を認証されたかのように、それは、P-アサートサービスヘッダフィールド内の情報を使用することができます。
If there is no P-Asserted-Service header field present, or it is not possible to match the request to a specific service as identified by the service identifier, a proxy MAY add one containing it using its own analysis of the information contained in the SIP request. If the proxy received the request from an element that it does not trust and there is a P-Asserted-Service header present, the proxy MUST replace that header field's contents with a new analysis or remove that header field.
そこにはP-アサートサービスヘッダフィールドが存在するか、またはサービス識別子によって識別される特定のサービスへの要求と一致することができない場合、プロキシは、中に含まれる情報の独自の分析を使用してそれを含むものを加えるかもしれSIPリクエスト。プロキシが、それは信頼していないことを要素からのリクエストを受信し、P-アサート-サービスヘッダが存在する場合、プロキシは新たな分析とそのヘッダフィールドの内容を交換するか、そのヘッダフィールドを削除する必要があります。
The analysis performed to identify such service identifiers is outside the scope of this document. However, it is perfectly valid as a result of the analysis not to include any service identifier in the forwarded request, and thus not include a P-Asserted-Service header field.
このようなサービス識別子を識別するために実行される分析は、この文書の範囲外です。しかし、転送された要求に任意のサービス識別子を含まないので、P-アサートサービスヘッダフィールドを含んでいない分析の結果として完全に有効です。
If a proxy forwards a request to a node outside the proxy's trust domain, there MUST NOT be a P-Asserted-Service header field in the forwarded request.
プロキシはプロキシの信頼ドメイン外のノードに要求を転送した場合、転送された要求にP-アサート・サービスヘッダフィールドがあってはなりません。
For a User Agent Server (UAS) outside the trust domain, the P-Asserted-Service header is removed before it reaches this entity; therefore, there are no procedures for such a device.
信頼ドメイン外のユーザエージェントサーバ（UAS）のために、P-アサートサービスヘッダは、このエンティティに到達する前に除去されます。従って、そのようなデバイスのための手順が存在しません。
However, if a UAS receives a request from a previous element that it does not trust, it MUST NOT use the P-Asserted-Service header field in any way.
UASはそれが信頼していないことを前の要素からの要求を受けた場合は、それがどのような方法でP-アサート・サービスヘッダフィールドを使用してはなりません。
If a UA is part of the trust domain from which it received a request containing a P-Asserted-Service header field, then it can use the value freely, but it MUST ensure that it does not forward the information to any element that is not part of the trust domain.
UAはそれがP-アサートサービスヘッダフィールドを含むリクエストを受信し、そこから信頼ドメインの一部である場合、それは自由に値を使用することができ、それはそれではない任意の要素に情報を転送しないことを保証しなければなりません信頼ドメインの一部。
5.2. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields in Responses
5.2. 応答におけるP-優先-ServiceおよびP-アサート-サービスヘッダフィールドの使用方法
There is no usage of these header fields in responses.
応答にこれらのヘッダフィールドのない使用法はありません。
In this example, proxy.example.com creates a P-Asserted-Service header field from the user identity it discovered from SIP digest authentication, the list of services appropriate to that user, and the services that correspond to the SDP information included in the request. Note that F1 and F2 are about identifying the user and do not directly form part of the capability provided in this document. It forwards this information to a trusted proxy that forwards it to a trusted gateway. Note that these examples consist of partial SIP messages that illustrate only those header fields relevant to the authenticated identity problem.
この例では、proxy.example.comは、SIPダイジェスト認証を、そのユーザに適切なサービスのリスト、およびに含まれるSDP情報に対応するサービスから発見されたユーザーIDからP-アサート・サービス・ヘッダ・フィールドを作成します要求。 F1及びF2は、ユーザを識別する程度で直接本書で提供される機能の一部を形成しないことに留意されたいです。それは、信頼できるゲートウェイに転送し、信頼できるプロキシにこの情報を転送します。これらの実施例は認証されたアイデンティティの問題に関連するだけヘッダフィールドを示す部分的なSIPメッセージからなることに留意されたいです。
* F1 useragent.example.com -> proxy.example.com
* F1 useragent.example.com - > proxy.example.com
INVITE sip:+14085551212@example.com SIP/2.0 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123 To: <sip:+14085551212@example.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Max-Forwards: 70
SIP / 2.0 / TCP useragent.example.com;ブランチ= z9hG4bK-123：+14085551212@example.com SIP / 2.0経由：SIPのINVITE <一口：+14085551212@example.com>から： "匿名" <一口： anonymous@anonymous.invalid>;タグは= 9802748のCall-ID：245780247857024504のCSeq：1最大前方にINVITE：70
v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd t=0 0 m=audio 3456 RTP/AVPF 97 96 b=AS:25.4 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes
V = 0 0 = - IP6 5555 IN 2987933615 2987933615 :: AAA：BBB：CCC：DDD S = - C = IP6 5555 IN :: AAA：BBB：CCC：DDD T = 0、M =オーディオ3456 RTP / AVPF 97 96 B = AS：25.4 = CURRは：QOSローカルのsendrecv A = CURR：リモートなしA = DESがQoS：必須のローカルのsendrecv A = DESがQoS：QoSの必須の遠隔のsendrecv A =のsendrecv A = rtpmap：97 AMRのA =のfmtp：97モード-set = 0,2,5,7。 maxframes
* F2 proxy.example.com -> useragent.example.com
* F2 proxy.example.com - > useragent.example.com
SIP/2.0 407 Proxy Authorization Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123 To: <sip:+14085551212@example.com>;tag=123456 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Proxy-Authenticate: .... realm="sip.example.com"
SIP / 2.0 407プロキシ認証経由：SIP / 2.0 / TCP useragent.example.com;ブランチ= z9hG4bK-123：<SIP：+14085551212@example.com>;タグ= 123456から： "匿名" <一口：匿名@ anonymous.invalid>;タグは= 9802748のCall-ID：245780247857024504のCSeq：1プロキシ認証をINVITE：....レルム= "sip.example.com"
* F3 useragent.example.com -> proxy.example.com
*効果的なOsrzinh.ksmpel.kom - > Broxa.ksmpel.kom
INVITE sip:+14085551212@example.com SIP/2.0 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124 To: <sip:+14085551212@example.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 70 Proxy-Authorization: realm="sip.example.com" user="fluffy" v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd t=0 0 m=audio 3456 RTP/AVPF 97 96 b=AS:25.4 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes
SIP / 2.0 / TCP useragent.example.com;ブランチ= z9hG4bK-124：+14085551212@example.com SIP / 2.0経由：SIPのINVITE <一口：+14085551212@example.com>から： "匿名" <一口： anonymous@anonymous.invalid>;タグ= 9802748のCall-ID：245780247857024504のCSeq：2 INVITE最大フォワード：70プロキシ許可：レルム= "sip.example.com" ユーザ= "ふわふわ" V = 0 0 = - 2987933615 2987933615 IP6 5555 IN :: AAA：BBB：CCC：DDD S = - C = IP6 5555 IN :: AAA：BBB：CCC：DDD T = 0、M =オーディオ3456 RTP / AVPF 97 96 B = AS：25.4 = CURR ：ローカルのsendrecv A = CURRをQOS：リモートなしA = DESをQOS：必須のローカルのsendrecv A = DESをQOS：必須のリモコンをQOS SENDRECV A = SENDRECV A = rtpmap：97 AMR A =のfmtp：97モード設定= 0,2,5 、7; maxframes
* F4 proxy.example.com -> proxy.pstn.example (trusted)
* F4 proxy.example.com - > proxy.pstn.example（信頼できます）
INVITE sip:+14085551212@proxy. pstn.example SIP/2.0 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc To: <sip:+14085551212@example.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 69 P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
SIPのINVITE：プロキシ@ + 14085551212。 pstn.exampleのSIP / 2.0経由：SIP / 2.0 / TCP useragent.example.com;分岐= z9hG4bK-124を介し：SIP / 2.0 / TCP proxy.example.com;分岐= z9hG4bK-ABCに<SIP：+ 14085551212 @ example.com>から： "匿名" <SIP：anonymous@anonymous.invalid>;タグ= 9802748のCall-ID：245780247857024504のCSeq：最大前方にINVITE 2：69 P-アサート・サービス：URN：URN-7：3gpp- service.exampletelephony.version1
v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd t=0 0 m=audio 3456 RTP/AVPF 97 96 b=AS:25.4 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes
V = 0 0 = - IP6 5555 IN 2987933615 2987933615 :: AAA：BBB：CCC：DDD S = - C = IP6 5555 IN :: AAA：BBB：CCC：DDD T = 0、M =オーディオ3456 RTP / AVPF 97 96 B = AS：25.4 = CURRは：QOSローカルのsendrecv A = CURR：リモートなしA = DESがQoS：必須のローカルのsendrecv A = DESがQoS：QoSの必須の遠隔のsendrecv A =のsendrecv A = rtpmap：97 AMRのA =のfmtp：97モード-set = 0,2,5,7。 maxframes
* F5 proxy.pstn.example -> gw.pstn.example (trusted)
* F5のproxy.pstn.example - > gw.pstn.example（信頼できます）
INVITE sip:+14085551212@gw.pstn.example SIP/2.0 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc Via: SIP/2.0/TCP proxy.pstn.example;branch=z9hG4bK-a1b2 To: <sip:+14085551212@example.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 68 P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
+14085551212@gw.pstn.example SIP / 2.0経由：SIP INVITE SIP / 2.0 / TCP useragent.example.comと、分岐= z9hG4bK-124を介し：SIP / 2.0 / TCP proxy.example.com;分岐= z9hG4bK-ABCビア：SIP / 2.0 / TCPのproxy.pstn.example;ブランチ= z9hG4bK-A1B2へ：<SIP：+14085551212@example.com>から： "匿名" <一口：anonymous@anonymous.invalid>;タグ= 9802748 Call- ID：245780247857024504のCSeq：最大前方にINVITE 2：68 P-アサート・サービス：URN：URN-7：3GPP-service.exampletelephony.version1を
v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd t=0 0 m=audio 3456 RTP/AVPF 97 96 b=AS:25.4 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes
V = 0 0 = - IP6 5555 IN 2987933615 2987933615 :: AAA：BBB：CCC：DDD S = - C = IP6 5555 IN :: AAA：BBB：CCC：DDD T = 0、M =オーディオ3456 RTP / AVPF 97 96 B = AS：25.4 = CURRは：QOSローカルのsendrecv A = CURR：リモートなしA = DESがQoS：必須のローカルのsendrecv A = DESがQoS：QoSの必須の遠隔のsendrecv A =のsendrecv A = rtpmap：97 AMRのA =のfmtp：97モード-set = 0,2,5,7。 maxframes
The mechanism provided in this document is a partial consideration of the problem of service identification in SIP. For example, these mechanisms provide no means by which end users can securely share service information end-to-end without a trusted service provider. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust.
本書で提供される機構は、SIPにおけるサービス識別の問題の部分的な考慮事項です。例えば、これらのメカニズムは、エンドユーザーが確実エンドツーエンド信頼できるサービスプロバイダなしにサービス情報を共有することが可能ないかなる手段を提供しません。この情報は信頼の連鎖で最も弱いリンクと同じくらい信頼性がある推移的な信頼によって確保されています。
The trust domain provides a set of servers where the characteristics of the service are agreed for that service identifier value, and where the calling user is entitled to use that service. RFC 5897 [RFC5897] identifies the impact of allowing such service identifier values to "leak" outside of the trust domain, including implications on fraud, interoperability, and stifling of service innovation.
信頼ドメインは、サービスの特性は、そのサービス識別子の値のために合意され、呼び出し元のユーザーがそのサービスを利用する権利がある場所のサーバーのセットを提供します。 RFC 5897 [RFC5897]はせるの影響を識別する、サービス識別子値詐欺、相互運用性に影響を含む信頼ドメインの「漏れ」外、およびサービス革新の息苦しいです。
This document specifies two new SIP header fields: P-Asserted-Service and P-Preferred-Service. Their syntax is given in Section 3. These header fields are defined by the following information, which has been added to the header sub-registry under http://www.iana.org.
P-アサート-ServiceおよびP-プリファード・サービス：この文書では、2つの新しいSIPヘッダフィールドを指定します。その構文は、これらのヘッダフィールドはhttp://www.iana.org下ヘッダーサブレジストリに追加された次の情報によって定義される第3に示されています。
Header Name compact Reference
----------------- ------- ---------
P-Asserted-Service RFC 6050
P-Preferred-Service RFC 6050
Top-level identifiers are identified by labels managed by IANA, according to the processes outlined in RFC 5226 [RFC5226], in a new registry called "Service-ID/Application-ID Labels". Thus, creating a new service at the top-level requires IANA action. The policy for adding service labels is 'specification required'. The following two identifiers are initially defined:
トップレベルの識別子は、「サービスID /アプリケーションIDラベル」と呼ばれる新しいレジストリで、RFC 5226 [RFC5226]に概説された方法に従って、IANAによって管理されたラベルによって識別されます。このように、トップレベルで新しいサービスを作成するIANAのアクションを必要とします。サービスラベルを追加するためのポリシーは、「要求仕様」です。次の二つの識別子が最初に定義されています。
3gpp-service
3GPP-サービス
3gpp-application
3GPP-アプリケーション
subservice identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the subservices.
サブサービス識別子は、IANAによって管理されていません。これは、サブサービスを管理するサービスを登録する組織の責任です。
Application identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the applicable applications.
アプリケーション識別子は、IANAによって管理されていません。これは、該当するアプリケーションを管理するサービスを登録する組織の責任です。
Entries in the registration table have the following format:
登録テーブルのエントリの形式は次のとおりです。
Service/Application Description Reference
--------------------------------------------------------------------
3gpp-service Communication services defined by RFC 6050
3GPP for use by the IM CN subsystem
and its attached UAs. This value
in itself does not define a service
and requires subsequent labels to
define the service.
3gpp-application Applications defined by 3GPP for RFC 6050 use by UAs attached to the IM CN subsystem. This value in itself does not define a service and requires subsequent labels to define the service.
IM CNサブシステムに添付のUAによってRFC 6050の使用のために3GPPで定義された3GPP-アプリケーションアプリケーション。自身でこの値は、サービスを定義し、サービスを定義するために、後続のラベルを必要としません。
Here, the IM CN subsystem stands for the IP Multimedia Core Network subsystem.
ここでは、IM CNサブシステムは、IPマルチメディアコアネットワークサブシステムの略です。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]ワトソン、M.、2002年11月、RFC 3324、 "ネットワークのための短期要件は、アイデンティティをアサート"。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3406] Daigle氏、L.、バンGulik、D.、Iannella、R.、およびP. Faltstrom、 "統一リソース名（URN）名前空間定義メカニズム"、BCP 66、RFC 3406、2002年10月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle氏、L.とA.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、 "セッション開始プロトコル（SIP）のための発信者が設定"、RFC 3841、2004年8月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", RFC 5688, January 2010.
[RFC5688]ローゼンバーグ、J.、 "Aセッション開始プロトコル（SIP）MIMEアプリケーションのサブタイプのためのメディア特徴タグ"、RFC 5688、2010年1月。
[RFC5897] Rosenberg, J., "Identification of Communications Services in the Session Initiation Protocol (SIP)", RFC 5897, June 2010.
[RFC5897]ローゼンバーグ、J.、 "セッション開始プロトコルでの通信サービスの識別（SIP）"、RFC 5897、2010年6月。
Author's Address
著者のアドレス
Keith Drage Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon, Wilts UK
キース糖剤アルカテル・ルーセント・クアドラント、ストーンヒルグリーン、Westleaスウィンドン、Wilts、英国
EMail: drage@alcatel-lucent.com
メールアドレス：drage@alcatel-lucent.com