[要約] RFC 4740は、Diameterプロトコルを使用してSIPアプリケーションを実装するための仕様です。その目的は、Diameterを介してSIPセッションの制御と認証を行うことです。
Network Working Group M. Garcia-Martin, Ed.
Request for Comments: 4740 Nokia
Category: Standards Track M. Belinchon
M. Pallares-Lopez
C. Canales-Valenzuela
Ericsson
K. Tammi
Nokia
November 2006
Diameter Session Initiation Protocol (SIP) Application
Diameterセッション開始プロトコル（SIP）アプリケーション
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（C）IETF Trust（2006）。
Abstract
概要
This document specifies the Diameter Session Initiation Protocol (SIP) application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server.
このドキュメントでは、Diameterセッション開始プロトコル（SIP）アプリケーションについて説明します。これは、Diameterクライアントが認証および許可情報を要求できるようにするDiameterアプリケーションです。このアプリケーションはSIPと組み合わせて使用するように設計されており、SIPサーバーと同じ場所に配置されたDiameterクライアントに、ユーザーの認証とDiameterサーバーからのSIPリソース使用の承認を要求する機能を提供します。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Definitions .....................................................5
4. Acronyms ........................................................6
5. Applicability Statement .........................................6
6. Overview of Operation ...........................................7
6.1. General Architecture .......................................7
6.2. Diameter Server Authenticates the User .....................9
6.3. Delegating Final Authentication Check to the SIP Server ...12
6.4. SIP Server Requests Authentication and Authorization ......15
6.5. Locating the Recipient of the SIP Request .................16
6.6. Update of the User Profile ................................17
6.7. SIP Soft State Termination ................................18
6.8. Diameter Server Discovery .................................19
7. Advertising Application Support ................................21
8. Diameter SIP Application Command Codes .........................22
8.1. User-Authorization-Request (UAR) Command ..................22
8.2. User-Authorization-Answer (UAA) Command ...................23
8.3. Server-Assignment-Request (SAR) Command ...................27
8.4. Server-Assignment-Answer (SAA) Command ....................29
8.5. Location-Info-Request (LIR) Command .......................33
8.6. Location-Info-Answer (LIA) Command ........................33
8.7. Multimedia-Auth-Request (MAR) Command .....................35
8.8. Multimedia-Auth-Answer (MAA) Command ......................36
8.9. Registration-Termination-Request (RTR) Command ............39
8.10. Registration-Termination-Answer (RTA) Command ............39
8.11. Push-Profile-Request (PPR) Command .......................41
8.12. Push-Profile-Answer (PPA) Command ........................42
9. Diameter SIP Application AVPs ..................................44
9.1. SIP-Accounting-Information AVP ............................46
9.1.1. SIP-Accounting-Server-URI AVP ......................47
9.1.2. SIP-Credit-Control-Server-URI AVP ..................47
9.2. SIP-Server-URI AVP ........................................47
9.3. SIP-Server-Capabilities AVP ...............................47
9.3.1. SIP-Mandatory-Capability AVP .......................48
9.3.2. SIP-Optional-Capability AVP ........................48
9.4. SIP-Server-Assignment-Type AVP ............................48
9.5. SIP-Auth-Data-Item AVP ....................................50
9.5.1. SIP-Authentication-Scheme AVP ......................50
9.5.2. SIP-Item-Number AVP ................................51
9.5.3. SIP-Authenticate AVP ...............................51
9.5.4. SIP-Authorization AVP ..............................52
9.5.5. SIP-Authentication-Info AVP ........................52
9.5.6. Digest AVPs ........................................53
9.6. SIP-Number-Auth-Items AVP .................................55
9.7. SIP-Deregistration-Reason AVP .............................55
9.7.1. SIP-Reason-Code AVP ................................55
9.7.2. SIP-Reason-Info AVP ................................56
9.8. SIP-AOR AVP ...............................................56
9.9. SIP-Visited-Network-Id AVP ................................56
9.10. SIP-User-Authorization-Type AVP ..........................56
9.11. SIP-Supported-User-Data-Type AVP .........................57
9.12. SIP-User-Data AVP ........................................57
9.12.1. SIP-User-Data-Type AVP ............................58
9.12.2. SIP-User-Data-Contents AVP ........................58
9.13. SIP-User-Data-Already-Available AVP ......................58
9.14. SIP-Method AVP ...........................................59
10. New Values for Existing AVPs ..................................59
10.1. Extension to the Result-Code AVP Values ..................59
10.1.1. Success Result-Code AVP Values ....................59
10.1.2. Transient Failures Result-Code AVP Values .........60
10.1.3. Permanent Failures Result-Code AVP Values .........60
11. Authentication Details ........................................61
12. Migration from RADIUS .........................................63
12.1. Gateway from RADIUS Client to Diameter Server ............63
12.2. Gateway from Diameter Client to RADIUS Server ............63
12.3. Known Limitations ........................................64
13. IANA Considerations ...........................................64
13.1. Application Identifier ...................................64
13.2. Command Codes ............................................65
13.3. AVP Codes ................................................65
13.4. Additional Values for the Result-Code AVP Value ..........65
13.5. Creation of the SIP-Server-Assignment-Type
Section in the AAA .......................................66
13.6. Creation of the SIP-Authentication-Scheme Section
in the AAA ...............................................66
13.7. Creation of the SIP-Reason-Code Section in the
AAA Registry .............................................66
13.8. Creation of the SIP-User-Authorization-Type
Section in the AAA .......................................66
13.9. Creation of the SIP-User-Data-Already-Available
Section in the ...........................................66
14. Security Considerations .......................................67
14.1. Final Authentication Check in the Diameter
Client/SIP Server ........................................67
15. Contributors ..................................................68
16. Acknowledgements ..............................................68
17. References ....................................................68
17.1. Normative References .....................................68
17.2. Informative References ...................................69
This document specifies the Diameter Session Initiation Protocol (SIP) application. This is a Diameter application that allows a Diameter client to request authentication and authorization information to a Diameter server for SIP-based IP multimedia services (see [RFC3261] about SIP). Furthermore, this Diameter SIP application provides the Diameter client with functions that go beyond the typical authorization and authentication, such as the ability to download or receive updated user profiles, or rudimentary routing functions that can assist a SIP server in finding another SIP server allocated to the user.
このドキュメントでは、Diameterセッション開始プロトコル（SIP）アプリケーションについて説明します。これは、DiameterクライアントがSIPベースのIPマルチメディアサービス用のDiameterサーバーに認証および承認情報を要求できるようにするDiameterアプリケーションです（SIPに関する[RFC3261]を参照）。さらに、このDiameter SIPアプリケーションは、Diameterクライアントに、更新されたユーザープロファイルをダウンロードまたは受信する機能や、SIPサーバーが割り当てられた別のSIPサーバーを見つけるのを支援できる基本的なルーティング機能など、通常の承認と認証を超える機能を提供しますユーザー。
We assume that the SIP server (such as SIP proxy server, registrar, redirect server, or alike) and the Diameter client are co-located in the same node, so that the SIP server is able to receive and process SIP requests and responses. In turn, the SIP server relies on the Authentication, Authorization, and Accounting (AAA) infrastructure for authenticating the SIP request and authorizing the usage of particular SIP services.
SIPサーバー（SIPプロキシサーバー、レジストラ、リダイレクトサーバーなど）とDiameterクライアントが同じノードに共存し、SIPサーバーがSIP要求と応答を受信して処理できると想定しています。次に、SIPサーバーは、SIP要求を認証し、特定のSIPサービスの使用を許可するために、認証、承認、およびアカウンティング（AAA）インフラストラクチャに依存します。
This document provides Diameter procedures to implement certain required functionality when SIP is the protocol chosen to initiate and tear down multimedia sessions or when SIP is used for other non-session-related applications. However, this document does not mandate any particular mapping of SIP procedures to Diameter SIP application procedures, nor does it mandate any particular sequence of events between SIP and Diameter. This document provides useful examples to show the interaction between SIP and the Diameter SIP application in order to achieve the desired functionality.
このドキュメントでは、SIPがマルチメディアセッションを開始および破棄するために選択されたプロトコルである場合、またはSIPが他の非セッション関連アプリケーションに使用される場合に必要な特定の機能を実装するためのDiameter手順について説明します。ただし、このドキュメントでは、SIPプロシージャからDiameter SIPアプリケーションプロシージャへの特定のマッピングは必須ではなく、SIPとDiameter間の特定のイベントシーケンスも必須ではありません。このドキュメントでは、目的の機能を実現するために、SIPとDiameter SIPアプリケーションの間の相互作用を示すのに役立つ例を紹介します。
This application does not require and is not related to other authentication services provided by the Diameter Mobile IPv4 [RFC4004] or the Diameter Network Access Server [RFC4005] applications.
このアプリケーションは、DiameterモバイルIPv4 [RFC4004]またはDiameterネットワークアクセスサーバー[RFC4005]アプリケーションによって提供される他の認証サービスを必要とせず、関連もありません。
This Diameter SIP application is loosely related to the Diameter credit-control application [RFC4006]. Although both applications are independent, the Diameter SIP application is able to supply the addresses of credit-control servers that will be implementing the Diameter credit-control application [RFC4006].
このDiameter SIPアプリケーションは、Diameterクレジット制御アプリケーション[RFC4006]と大まかに関連しています。両方のアプリケーションは独立していますが、Diameter SIPアプリケーションは、Diameterクレジット制御アプリケーション[RFC4006]を実装するクレジット制御サーバーのアドレスを提供できます。
Section 5 discusses assumptions and configurations assumed by this document.
セクション5では、このドキュメントで想定されている前提条件と構成について説明します。
Section 6 provides the reader with informative descriptions of the Diameter SIP application commands and responses and with some guidance about their linkage with SIP procedures.
セクション6は、Diameter SIPアプリケーションのコマンドと応答の有益な説明と、SIP手順との連携に関するガイダンスを読者に提供します。
Advertisement of this application is specified in Section 7.
このアプリケーションの広告は、セクション7で指定されています。
Section 8 provides a normative description of all the new Diameter commands defined by this specification.
セクション8では、この仕様で定義されているすべての新しいDiameterコマンドの規範的な説明を提供します。
This application extends the Result-Code Attribute-Value-Pair (AVP) with some new values. Further information is described in Section 10.
このアプリケーションは、Result-Code Attribute-Value-Pair（AVP）をいくつかの新しい値で拡張します。詳細については、セクション10で説明します。
This application defines some new AVPs. All these AVPs are described in Section 9.
このアプリケーションは、いくつかの新しいAVPを定義します。これらすべてのAVPについては、セクション9で説明します。
Some extra information about authentication is provided in Section 11.
認証に関する追加情報については、セクション11で説明します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」 、および「オプション」は、BCP 14、RFC 2119 [RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。
For the purpose of this document, the following terms and definitions apply:
このドキュメントでは、次の用語と定義が適用されます。
Node: an addressable device attached to a computer network that implements SIP functionality, Diameter functionality, or a combination of both.
ノード：SIP機能、Diameter機能、またはその両方の組み合わせを実装するコンピューターネットワークに接続されたアドレス指定可能なデバイス。
For the purpose of this document, the following terms and definitions given in RFC 3261 [RFC3261] Section 6, apply:
このドキュメントでは、RFC 3261 [RFC3261]セクション6に記載されている次の用語と定義が適用されます。
o Address-of-Record (AOR) o Outbound proxy o Proxy o Registrar o Server (SIP server) o User Agent (UA) o User Agent Client (UAC) o User Agent Server (UAS)
o レコードのアドレス（AOR）oアウトバウンドプロキシoプロキシoレジストラoサーバー（SIPサーバー）oユーザーエージェント（UA）oユーザーエージェントクライアント（UAC）oユーザーエージェントサーバー（UAS）
For the purpose of this document, the following terms and definitions given in RFC 3588 [RFC3588] Section 1.3, apply:
このドキュメントでは、RFC 3588 [RFC3588]セクション1.3に記載されている次の用語と定義が適用されます。
o Authorization o Authentication o Attribute-Value Pair (AVP) o Diameter Client o Diameter Server o Home Realm o Redirect Agent o User
o 許可o認証o属性値ペア（AVP）o Diameterクライアントo Diameterサーバーoホームレルムoリダイレクトエージェントoユーザー
AKA: Authentication and Key Agreement LIR: Location-Info-Request LIA: Location-Info-Answer MAR: Multimedia-Auth-Request MAA: Multimedia-Auth-Answer PPR: Push-Profile-Request PPA: Push-Profile-Answer RTR: Registration-Termination-Request RTA: Registration-Termination-Answer SAR: Server-Assignment-Request SAA: Server-Assignment-Answer SL: Subscriber Locator UAR: User-Authorization-Request UAA: User-Authorization-Answer
AKA：認証とキー合意LIR：ロケーション情報要求LIA：ロケーション情報応答MAR：マルチメディア認証要求MAA：マルチメディア認証応答PPR：プッシュプロファイル要求PPA：プッシュプロファイル応答RTR： Registration-Termination-Request RTA：Registration-Termination-Answer SAR：Server-Assignment-Request SAA：Server-Assignment-Answer SL：Subscriber Locator UAR：User-Authorization-Request UAA：User-Authorization-Answer
This document assumes a general architecture where a Home Realm is composed of one or more nodes implementing Diameter or SIP functions. Users are issuing SIP requests to access SIP resources. For each particular user, the Home Realm needs to authenticate and authorize the usage of those resources and/or the route to the appropriate node. We assume that the database containing the user-related data is located outside the SIP node that requires authorization. Data belonging to different users may be stored in different nodes in the Home Realm, but we assume that all the data related to a particular user is stored in a single node.
このドキュメントは、ホームレルムがDiameterまたはSIP機能を実装する1つ以上のノードで構成される一般的なアーキテクチャを想定しています。ユーザーはSIPリソースにアクセスするためのSIP要求を発行しています。特定のユーザーごとに、ホームレルムはそれらのリソースの使用や適切なノードへのルートを認証および承認する必要があります。ユーザー関連データを含むデータベースは、承認が必要なSIPノードの外部にあると想定しています。異なるユーザーに属するデータはホームレルムの異なるノードに格納される場合がありますが、特定のユーザーに関連するすべてのデータは単一のノードに格納されると想定しています。
Note: Central to the architecture is the fact that the user data is stored in a single point in the network. This restriction does not mandate a particular implementation, e.g., it is possible to implement clusters of databases operating in mirror mode to provide redundancy. The property required by this specification is that the user data the Diameter server has access to is stored safely in what is seen, from the external point of view, as a single user database.
注：アーキテクチャの中心となるのは、ユーザーデータがネットワーク内の単一のポイントに格納されるという事実です。この制限は特定の実装を義務付けるものではありません。たとえば、冗長性を提供するためにミラーモードで動作するデータベースのクラスターを実装することは可能です。この仕様で必要なプロパティは、Diameterサーバーがアクセスできるユーザーデータが、単一のユーザーデータベースとして、外部から見た場合に安全に格納されることです。
This document allows several configurations of the Home Realm. In one configuration, a SIP server (proxy, registrar, etc.) is allocated to a user for the purpose of triggering and executing services. The allocation of the SIP server may be done dynamically, e.g., at the time the user registers in the network. This configuration requires a SIP server, typically located at the edge of the network, that is able to allocate another SIP server for the user and that also supports routing of SIP requests and responses towards that allocated SIP server. Both SIP server nodes implement a Diameter client.
このドキュメントでは、ホームレルムのいくつかの構成を許可しています。 １つの構成では、サービスをトリガーおよび実行する目的で、ＳＩＰサーバー（プロキシ、レジストラなど）がユーザーに割り当てられる。 ＳＩＰサーバの割り当ては、例えば、ユーザがネットワークに登録するときに、動的に行うことができる。この構成では、通常ネットワークのエッジに配置され、ユーザーに別のSIPサーバーを割り当てることができ、割り当てられたSIPサーバーへのSIP要求と応答のルーティングもサポートするSIPサーバーが必要です。両方のSIPサーバーノードは、Diameterクライアントを実装します。
In another configuration, the address of a SIP outbound proxy is configured (by means outside the scope of this specification) into the SIP User Agent. The outbound Diameter client in the SIP outbound proxy node authenticates the user, requests authorization for SIP requests, and performs accounting activities.
別の構成では、SIPアウトバウンドプロキシのアドレスが（この仕様の範囲外で）SIPユーザーエージェントに構成されます。 SIPアウトバウンドプロキシノードのアウトバウンドDiameterクライアントは、ユーザーを認証し、SIPリクエストの承認を要求し、アカウンティングアクティビティを実行します。
This section provides an informative description of how the Diameter SIP application can be used together with SIP. This section is not intended to mandate any specific usage of the Diameter SIP application nor does it mandate a specific mapping between SIP and Diameter messages. We provide a collection of examples that show how the required AAA functionality can be achieved in conjunction with SIP.
このセクションでは、Diameter SIPアプリケーションをSIPと組み合わせて使用する方法について説明します。このセクションは、Diameter SIPアプリケーションの特定の使用法を義務付けることを意図したものではなく、SIPメッセージとDiameterメッセージ間の特定のマッピングを義務付けるものではありません。必要なAAA機能をSIPと組み合わせて実現する方法を示す例のコレクションを提供します。
The Diameter SIP application can be used in a SIP environment where an interface to a AAA infrastructure is required to authenticate and authorize the usage of SIP resources. This application provides support for SIP User Agents and proxies that implement and use HTTP Digest authentication [RFC2617], which is the authentication mechanism mandated by SIP [RFC3261]. The application is extensible and, if need arises, it can be extended to provide support for other authentication mechanisms or extensions to HTTP Digest authentication when they occur.
Diameter SIPアプリケーションは、SIPリソースの使用を認証および承認するためにAAAインフラストラクチャへのインターフェイスが必要なSIP環境で使用できます。このアプリケーションは、SIP [RFC3261]によって義務付けられている認証メカニズムであるHTTPダイジェスト認証[RFC2617]を実装および使用するSIPユーザーエージェントおよびプロキシのサポートを提供します。アプリケーションは拡張可能であり、必要に応じて拡張して、他の認証メカニズムや、HTTPダイジェスト認証の拡張機能がサポートされます。
This application provides limited support for accounting services as follows: the Diameter server is able to provide the addresses of accounting severs to the Diameter client. Figure 1, below, shows a general overview of the integration of the SIP architecture with the AAA architecture.
このアプリケーションは、次のようにアカウンティングサービスの限定的なサポートを提供します。Diameterサーバーは、Diameterクライアントにアカウンティングサーバーのアドレスを提供できます。下の図1は、SIPアーキテクチャとAAAアーキテクチャの統合の概要を示しています。
According to Figure 1, there are one or more SIP User Agents (UAs) that initiate or terminate SIP traffic through one or more SIP servers. Both SIP servers implement a Diameter client that supports the Diameter application described in this specification.
図1によると、1つ以上のSIPサーバーを介してSIPトラフィックを開始または終了する1つ以上のSIPユーザーエージェント（UA）があります。両方のSIPサーバーは、この仕様で説明されているDiameterアプリケーションをサポートするDiameterクライアントを実装しています。
+--------+
UAR/UAA +--->|Diameter|<----+ PPR/PPA
LIR/LIA | | server | | MAR/MAA
| +--------+ | SAR/SAA
| | RTR/RTA
| |
v v
+------+ SIP +--------+ SIP +--------+ SIP +------+
| SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP |
| UA | |server 1| |server 2| | UA |
+------+ +--------+ +--------+ +------+
^ ^
UAR/UAA | |
LIR/LIA | | MAR/MAA
| +--------+ | SAR/SAA
+--->|Diameter|<----+
| SL |
+--------+
Figure 1: Architecture of the Diameter application for SIP
図1：SIPのDiameterアプリケーションのアーキテクチャ
In Figure 1, it can be seen that SIP server 1 sends different Diameter commands and receives different responses than those sent and received by SIP server 2. This is because SIP server 1 in Figure 1 is located at the edge of a network, and its main task is to locate SIP server 2. SIP server 2 is requesting and receiving authentication and authorization data from the Diameter server and is not located at the edge of the network.
図1では、SIPサーバー1は、SIPサーバー2が送受信したものとは異なるDiameterコマンドを送信し、異なる応答を受信していることがわかります。これは、図1のSIPサーバー1がネットワークのエッジにあり、主なタスクは、SIPサーバー2を見つけることです。SIPサーバー2は、Diameterサーバーから認証および承認データを要求および受信しており、ネットワークの端にありません。
This Diameter application assumes that all the data pertaining to a given user is stored in a single Diameter server. For redundancy purposes, several Diameter servers can be configured in a redundancy fashion, in which case all of them keep the data synchronized and operate externally as a single Diameter server.
このDiameterアプリケーションは、特定のユーザーに関するすべてのデータが単一のDiameterサーバーに格納されていることを前提としています。冗長性の目的で、複数のDiameterサーバーを冗長性のある方法で構成できます。その場合、すべてのサーバーがデータの同期を維持し、単一のDiameterサーバーとして外部で動作します。
With respect to SIP server 1 in Figure 1, the Diameter SIP application provides support for the existence of a farm of these servers, typically configured through one or more DNS records that point to several hosts (this is a typical configuration in common SIP deployments). There is no requirement for these types of servers to keep state related to the Diameter SIP application.
図1のSIPサーバー1に関して、Diameter SIPアプリケーションは、これらのサーバーのファームの存在をサポートします。通常、複数のホストを指す1つ以上のDNSレコードを介して構成されます（これは、一般的なSIP展開の一般的な構成です）。 。これらのタイプのサーバーがDiameter SIPアプリケーションに関連する状態を維持する必要はありません。
The Diameter SIP application provides support for a feature that allows an administrative domain to provide a collection of SIP servers 2 (as per Figure 1). Once the user registers for the first time, one of these SIP servers is selected and all the SIP requests related to the user are processed by the same SIP server.
Diameter SIPアプリケーションは、管理ドメインがSIPサーバー2のコレクションを提供できるようにする機能をサポートします2（図1を参照）。ユーザーが初めて登録すると、これらのSIPサーバーの1つが選択され、ユーザーに関連するすべてのSIP要求が同じSIPサーバーによって処理されます。
The Diameter Subscriber Locator (SL) serves the purpose of locating the Diameter server that contains the user-related data. Its functionality is based on the Diameter redirect mechanism and is further described in Section 6.8.
Diameterサブスクライバロケータ（SL）は、ユーザー関連データを含むDiameterサーバーを見つける目的で使用されます。その機能は、Diameterリダイレクトメカニズムに基づいており、セクション6.8で詳しく説明されています。
It should be noted that this document does not mandate any particular SIP/AAA architecture. However, the Diameter SIP application provides the functionality needed to accommodate all the different architectures where SIP and Diameter are used.
このドキュメントは特定のSIP / AAAアーキテクチャを義務付けていないことに注意してください。ただし、Diameter SIPアプリケーションは、SIPとDiameterが使用されるすべての異なるアーキテクチャに対応するために必要な機能を提供します。
The following subsections provide an informative overview of the Diameter SIP application, its commands, and a possible interaction with SIP signaling.
以下のサブセクションでは、Diameter SIPアプリケーション、そのコマンド、およびSIPシグナリングとの可能な相互作用の有益な概要を提供します。
This is the generic mechanism to authenticate users. In this approach, we show an example of an administrative network where the Diameter server is authenticating SIP user requests. This could be the case of a medium-size network where the Diameter server is keeping user records and authenticating SIP requests to perform a certain transaction. We have chosen to show a SIP REGISTER request in the example, but the SIP server could request authentication of any other SIP request.
これは、ユーザーを認証するための一般的なメカニズムです。このアプローチでは、DiameterサーバーがSIPユーザー要求を認証している管理ネットワークの例を示します。これは、Diameterサーバーがユーザーレコードを保持し、SIPリクエストを認証して特定のトランザクションを実行する中規模ネットワークの場合です。この例ではSIP REGISTER要求を表示することを選択しましたが、SIPサーバーは他のSIP要求の認証を要求できます。
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. SIP 401 (Unauthorized) |
8. SIP 401 (Unauth.) |<--------------------------------------|
<--------------------| | |
9. SIP REGISTER | | |
-------------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
|-------------------------------------->|
| | 13. MAR |
| |<------------------|
| | 14. MAA |
| |------------------>|
| 15. SIP 200 (OK) |
16. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | 17. SAR |
| |<------------------|
| | 18. SAA |
| |------------------>|
| | |
Figure 2: Authentication performed in the Diameter server
図2：Diameterサーバーで実行される認証
According to Figure 2, a SIP User Agent Client (UAC) sends a SIP REGISTER request (step 1) to SIP server 1, which receives the SIP request. In Figure 2, we assume that this SIP server is located at the edge of the administrative home domain. The Diameter client in SIP server 1 contacts its Diameter server by sending a Diameter User-Authorization-Request (UAR) message (step 2) to determine if this user is allowed to receive service, and if so, request the address of a local SIP server capable of handling this user. The Diameter server answers with a Diameter User-Authorization-Answer (UAA) message (step 3), which indicates a list of capabilities that SIP server 1 may use to select an appropriate SIP server (SIP server 2) and/or a SIP or SIPS URI pointing to SIP server 2.
図2によると、SIPユーザーエージェントクライアント（UAC）は、SIP REGISTER要求（ステップ1）をSIPサーバー1に送信し、SIPサーバー1はSIP要求を受信します。図2では、このSIPサーバーが管理ホームドメインのエッジにあると想定しています。 SIPサーバー1のDiameterクライアントは、Diameter User-Authorization-Request（UAR）メッセージを送信して（ステップ2）、そのDiameterサーバーに接続し、このユーザーがサービスの受信を許可されているかどうかを判断し、許可されている場合は、ローカルSIPのアドレスを要求します。このユーザーを処理できるサーバー。 Diameterサーバーは、Diameter User-Authorization-Answer（UAA）メッセージ（ステップ3）で応答します。これは、SIPサーバー1が適切なSIPサーバー（SIPサーバー2）および/またはSIPまたはSIPサーバーを指すSIPS URI 2。
SIP server 1 forwards the SIP REGISTER request (step 4) to an appropriate SIP server (SIP server 2). Then the Diameter client in SIP server 2 requests user authentication from the Diameter server by sending a Diameter Multimedia-Auth-Request (MAR) message (step 5). This request also serves to make the Diameter server aware of the SIP or SIPS URI of SIP server 2, so as to return subsequent requests for the same user to the same SIP server 2. The Diameter server responds with a Diameter Multimedia-Auth-Answer (MAA) message (step 6) with Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH. The Diameter server also generates a nonce and includes a challenge in the MAA message. SIP server 2 uses that challenge to map into the WWW-Authenticate header in the SIP 401 (Unauthorized) response (step 7), which is sent back to SIP server 1 and then to the SIP UAC (step 8).
SIPサーバー1は、SIP REGISTER要求（ステップ4）を適切なSIPサーバー（SIPサーバー2）に転送します。次に、SIPサーバー2のDiameterクライアントは、Diameter Multimedia-Auth-Request（MAR）メッセージを送信することにより、Diameterサーバーにユーザー認証を要求します（ステップ5）。この要求は、DiameterサーバーにSIPサーバー2のSIPまたはSIPS URIを認識させるためにも使用され、同じユーザーに対する後続の要求を同じSIPサーバー2に返します。Diameterサーバーは、Diameter Multimedia-Auth-Answerで応答します。 （MAA）メッセージ（ステップ6）。結果コードAVPが値DIAMETER_MULTI_ROUND_AUTHに設定されています。 Diameterサーバーはナンスも生成し、MAAメッセージにチャレンジを含めます。 SIPサーバー2はそのチャレンジを使用して、SIP 401（無許可）応答（ステップ7）のWWW-Authenticateヘッダーにマップします。これは、SIPサーバー1に返され、次にSIP UACに返されます（ステップ8）。
SIP server 1 receives a next SIP REGISTER request containing the user credentials (step 9). Note that SIP server 1 does not need to keep a state, and even more, there is no guarantee that the SIP request arrives at the same SIP server 1; there could be a farm of SIP servers 1 operating in redundant configuration. The Diameter client in SIP server 1 contacts the Diameter server by sending a Diameter UAR message (step 10) to determine the SIP server allocated to the user. The Diameter server sends the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11).
SIPサーバー1は、ユーザー資格情報を含む次のSIP REGISTER要求を受信します（ステップ9）。 SIPサーバー1は状態を保持する必要がないことに注意してください。さらに、SIP要求が同じSIPサーバー1に到着する保証はありません。冗長構成で動作するSIPサーバー1のファームが存在する可能性があります。 SIPサーバー1のDiameterクライアントは、Diameter UARメッセージを送信して（ステップ10）、Diameterサーバーにアクセスし、ユーザーに割り当てられているSIPサーバーを決定します。 Diameterサーバーは、SIPサーバー2のSIPまたはSIPS URIをDiameter UAAメッセージで送信します（ステップ11）。
Then SIP server 1 forwards the SIP REGISTER request to SIP server 2 (step 12). SIP server 2 extracts the credentials from the SIP REGISTER request. The Diameter client in SIP server 2 sends those credentials in a Diameter MAR message (step 13) to the Diameter server. At this point, the Diameter server is able to authenticate the user, and upon success, returns a Diameter MAA message (step 14) with the AVP Result-Code set to the value DIAMETER_SUCCESS.
次に、SIPサーバー1は、SIP REGISTER要求をSIPサーバー2に転送します（ステップ12）。 SIPサーバー2は、SIP REGISTER要求から資格情報を抽出します。 SIPサーバー2のDiameterクライアントは、これらの資格情報をDiameter MARメッセージ（ステップ13）でDiameterサーバーに送信します。この時点で、Diameterサーバーはユーザーを認証でき、成功すると、AVP Result-Codeが値DIAMETER_SUCCESSに設定されたDiameter MAAメッセージ（ステップ14）を返します。
Then SIP server 2 generates a SIP 200 (OK) response (step 15), which is forwarded to SIP server 1 and eventually to the SIP UAC (step 16).
次に、SIPサーバー2はSIP 200（OK）応答を生成し（ステップ15）、SIPサーバー1に転送され、最終的にはSIP UACに転送されます（ステップ16）。
If the Diameter client in SIP server 2 is interested in downloading the user profile information or is required to store the address of the SIP server in the Diameter server, then the Diameter client sends a Diameter SAR message (step 17) to the Diameter server. The Diameter server replies with a Diameter SAA message (step 18) that contains the requested user profile information and the acknowledgement of the SIP server address storage. These actions are needed when the SIP server has to retrieve a user profile used to provide services to the served user, or when the SIP server keeps a state for the user, so the Diameter server needs to store the SIP server's address.
SIPサーバー2のDiameterクライアントがユーザープロファイル情報のダウンロードに関心があるか、SIPサーバーのアドレスをDiameterサーバーに保存する必要がある場合、DiameterクライアントはDiameterサーバーにDiameter SARメッセージを送信します（ステップ17）。 Diameterサーバーは、要求されたユーザープロファイル情報とSIPサーバーアドレスストレージの確認応答を含むDiameter SAAメッセージで応答します（ステップ18）。これらのアクションは、サービスを提供するユーザーにサービスを提供するために使用されるユーザープロファイルをSIPサーバーが取得する必要がある場合、またはSIPサーバーがユーザーの状態を保持する場合に必要であり、DiameterサーバーはSIPサーバーのアドレスを格納する必要があります。
An operator with a large base of installed SIP servers may wish to minimize the number of round-trips between the Diameter client and the Diameter server. We provide support for a mechanism where the Diameter server delegates the final authentication check to the SIP server, thereby saving a round-trip. Section 14.1 discusses the security considerations of this scenario.
インストールされているSIPサーバーのベースが大きいオペレーターは、DiameterクライアントとDiameterサーバー間の往復回数を最小限にしたい場合があります。 Diameterサーバーが最終的な認証チェックをSIPサーバーに委任するメカニズムのサポートを提供し、それによりラウンドトリップを節約します。セクション14.1では、このシナリオのセキュリティに関する考慮事項について説明します。
It must noted that this scenario is not applicable when the Diameter server is configured to use a session MD5 (MD5-sess) algorithm, because the Diameter server requires the client nonce to compute the H(A1) before sending it to the Diameter client. However, the client nonce might not be available at that time.
DiameterサーバーがセッションのMD5（MD5-sess）アルゴリズムを使用するように構成されている場合、Diameterサーバーは、H（A1）をDiameterクライアントに送信する前にクライアントナンスでH（A1）を計算する必要があるため、このシナリオは適用できないことに注意してください。ただし、クライアントnonceがその時点で使用できない場合があります。
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. SIP 401 (Unauthorized) |
8. SIP 401 (Unauth.) |<--------------------------------------|
<--------------------| | |
9. SIP REGISTER | | |
-------------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
|-------------------------------------->|
| | 13. SAR |
| |<------------------|
| | 14. SAA |
| |------------------>|
| 15. SIP 200 (OK) |
16. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | |
Figure 3: Delegation of authentication to the SIP server
図3：SIPサーバーへの認証の委任
Figure 3 shows an example where a SIP server is dynamically allocated to serve a SIP User Agent with the support of the Diameter server. This may be the case of certain architectures, such as that of the 3rd Generation Partnership Project (3GPP) IP Multimedia Core Network Subsystem.
図3は、DiameterサーバーのサポートによりSIPユーザーエージェントを提供するためにSIPサーバーが動的に割り当てられる例を示しています。これは、第3世代パートナーシッププロジェクト（3GPP）IPマルチメディアコアネットワークサブシステムなどの特定のアーキテクチャの場合です。
A first SIP server receives a SIP REGISTER request (step 1) whose target is the home network domain. In Figure 3, we assume that this SIP server is located at the edge of the administrative home domain. The Diameter client in this SIP server requests authorization from the Diameter server to proceed with the registration, by sending a Diameter User-Authorization-Request (UAR) message (step 2). The message includes, among other Attribute-Value-Pairs (AVPs), the SIP Address-Of-Record (AOR) that is included in the SIP REGISTER request. The Diameter server verifies the SIP AOR and, if it is a valid defined user in the home network, authorizes the registration to proceed. The Diameter server responds with a Diameter User-Authorization-Answer (UAA) message (step 3), which informs the Diameter client/SIP server about the result of the user authorization. In case of a successful authorization, the Diameter UAA message indicates the address of a local SIP server (SIP server 2 in Figure 3) and/or a list of capabilities that SIP server 1 may use to select an appropriate SIP server 2.
最初のSIPサーバーは、ターゲットがホームネットワークドメインであるSIP REGISTER要求を受信します（ステップ1）。図3では、このSIPサーバーが管理ホームドメインのエッジにあると想定しています。このSIPサーバーのDiameterクライアントは、Diameter User-Authorization-Request（UAR）メッセージを送信することにより、Diameterサーバーに承認を要求して登録を続行します（ステップ2）。メッセージには、他の属性値ペア（AVP）の中でも、SIP REGISTER要求に含まれるSIPアドレスレコード（AOR）が含まれます。 DiameterサーバーはSIP AORを確認し、それがホームネットワークで有効な定義済みユーザーである場合は、登録を続行することを承認します。 Diameterサーバーは、Diameter User-Authorization-Answer（UAA）メッセージで応答し（ステップ3）、Diameterクライアント/ SIPサーバーにユーザー認証の結果を通知します。認証が成功した場合、Diameter UAAメッセージは、ローカルSIPサーバー（図3のSIPサーバー2）のアドレス、またはSIPサーバー1が適切なSIPサーバー2を選択するために使用できる機能のリストを示します。
When the authorization is successful, SIP server 1 forwards the SIP REGISTER request (step 4) to the appropriate SIP server (SIP server 2). The Diameter client in SIP server 2 requests authentication parameters by sending a Diameter Multimedia-Auth-Request (MAR) message (step 5) to the Diameter server. This request also makes the Diameter server aware of the SIP or SIPS URI of SIP server 2, so as to return subsequent requests of the same user to the same SIP server 2. The Diameter server responds with a Diameter Multimedia-Auth-Answer (MAA) message (step 6), which includes a nonce and all the rest of the parameters necessary for the designated authentication algorithm associated with the user. Among others, the MAA message includes a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617 [RFC2617]), and that allows the Diameter client to calculate the expected response. Then the Diameter client can compare this expected response with the response to the challenge sent from the SIP UA. The absence of the Digest-HA1 AVP in MAA indicates that authentication and authorization take place in the Diameter server, as per the scenario described in Section 6.2.
認証が成功すると、SIPサーバー1はSIP登録要求（ステップ4）を適切なSIPサーバー（SIPサーバー2）に転送します。 SIPサーバー2のDiameterクライアントは、Diameterマルチメディア認証要求（MAR）メッセージ（ステップ5）をDiameterサーバーに送信することにより、認証パラメーターを要求します。また、このリクエストは、DiameterサーバーにSIPサーバー2のSIPまたはSIPS URIを認識させ、同じユーザーの後続のリクエストを同じSIPサーバー2に返します。Diameterサーバーは、Diameter Multimedia-Auth-Answer（MAA ）メッセージ（ステップ6）。これには、ナンスと、ユーザーに関連付けられた指定された認証アルゴリズムに必要な残りのすべてのパラメーターが含まれます。特に、MAAメッセージには、H（A1）を含むDigest-HA1 AVP（RFC 2617 [RFC2617]で定義されている）が含まれ、Diameterクライアントが予期される応答を計算できるようにします。次に、Diameterクライアントは、この予期される応答をSIP UAから送信されたチャレンジへの応答と比較できます。 MAAにDigest-HA1 AVPが存在しないことは、セクション6.2で説明されているシナリオに従って、Diameterサーバーで認証と承認が行われることを示しています。
SIP server 2 creates a SIP 401 (Unauthorized) SIP response (step 7) based on the challenge included in the MAA message, including the authentication material needed by the SIP User Agent Client (UAC) to include the appropriate credentials. SIP server 1 forwards the SIP response to the SIP UAC (step 8).
SIPサーバー2は、MAAメッセージに含まれるチャレンジに基づいてSIP 401（無許可）SIP応答を作成し（ステップ7）、適切な資格情報を含めるためにSIPユーザーエージェントクライアント（UAC）が必要とする認証資料を含みます。 SIPサーバー1はSIP応答をSIP UACに転送します（ステップ8）。
The SIP server 1 receives the next SIP REGISTER request containing the user credentials (step 9). Because SIP server 1 does not need to keep a state (and there is no guarantee that the SIP request arrives to the same SIP server 1), the Diameter client in SIP server 1 contacts the Diameter server again by sending a Diameter UAR message (step 10) to determine the SIP server allocated to the user. The Diameter server sends the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11).
ＳＩＰサーバ１は、ユーザ証明書を含む次のＳＩＰ ＲＥＧＩＳＴＥＲリクエストを受信する（ステップ９）。 SIPサーバー1は状態を保持する必要がないため（また、SIP要求が同じSIPサーバー1に到着する保証はありません）、SIPサーバー1のDiameterクライアントは、Diameter UARメッセージを送信することにより、Diameterサーバーに再度接続します（ステップ10）ユーザーに割り当てられたSIPサーバーを決定します。 Diameterサーバーは、SIPサーバー2のSIPまたはSIPS URIをDiameter UAAメッセージで送信します（ステップ11）。
SIP server 1 forwards the SIP REGISTER request to SIP server 2 (step 12). SIP server 2 validates the credentials by comparing the response supplied by the SIP UA with the expected response calculated by the SIP server 2 (based on the H(A1) received from the Diameter server).
SIPサーバー1は、SIP REGISTER要求をSIPサーバー2に転送します（ステップ12）。 SIPサーバー2は、SIP UAから提供された応答と、SIPサーバー2が計算した予想応答（Diameterサーバーから受信したH（A1）に基づいて）を比較して、資格情報を検証します。
If the credentials are valid, SIP server 2 sends a Diameter Server-Assignment-Request (SAR) message (step 13) requesting the Diameter server to confirm the completion of the authentication procedure and to confirm the SIP or SIPS URI of the SIP server that is currently serving the user. The Diameter SAR message also serves the purpose of requesting that the Diameter server send the user profile to the SIP server. The Diameter server responds with a Diameter Server-Assignment-Answer (SAA) message (step 14). If the Result-Code AVP value does not inform SIP Server 2 of an error, the SAA message can include zero or more SIP-User-Data AVPs containing the information that SIP server 2 needs in order to provide a service to the user.
資格情報が有効な場合、SIPサーバー2はDiameterサーバー割り当て要求（SAR）メッセージを送信し（ステップ13）、Diameterサーバーに認証手順の完了を確認し、SIPサーバーのSIPまたはSIPS URIを確認するように要求します。現在ユーザーにサービスを提供しています。 Diameter SARメッセージは、DiameterサーバーがユーザープロファイルをSIPサーバーに送信することを要求する目的にも役立ちます。 Diameterサーバーは、Diameter Server-Assignment-Answer（SAA）メッセージで応答します（ステップ14）。 Result-Code AVP値がSIPサーバー2にエラーを通知しない場合、SAAメッセージには、ユーザーにサービスを提供するためにSIPサーバー2が必要とする情報を含む0個以上のSIP-User-Data AVPを含めることができます。
SIP server 2 generates a SIP 200 (OK) response (step 15), which is forwarded to SIP server 1 and eventually to the SIP UAC (step 16).
SIPサーバー2はSIP 200（OK）応答を生成し（ステップ15）、これはSIPサーバー1に転送され、最終的にはSIP UACに転送されます（ステップ16）。
Figure 4 depicts a typical scenario where a stateless SIP proxy requests authentication information and authorization to a Diameter server, for the purpose of providing SIP routing services to a SIP User Agent. The SIP proxy server may be configured as an outbound SIP proxy, so that all the requests initiated by the SIP UA traverse the SIP proxy.
図4は、SIPルーティングサービスをSIPユーザーエージェントに提供する目的で、ステートレスSIPプロキシがDiameterサーバーに認証情報と承認を要求する典型的なシナリオを示しています。 SIPプロキシサーバーは、アウトバウンドSIPプロキシとして構成できます。これにより、SIP UAによって開始されたすべての要求がSIPプロキシを通過します。
According to Figure 4, a SIP User Agent sends a SIP request to its outbound SIP proxy server. In this case, the message is a SIP INVITE request (see step 1), but it could be any other SIP request. We assume that this SIP request does not contain any credentials at this time. The outbound SIP proxy server needs to authenticate and authorize the proxy services offered to the user. The Diameter client in the SIP server sends a Multimedia-Auth-Request (MAR) message (step 2). The Diameter server generates a nonce and sends a Multimedia-Auth-Answer (MAA) message (step 3) that includes the nonce and the rest of the data necessary for the SIP server to challenge the user, typically with HTTP Digest Authentication indicated in the MAA message. This data enables the SIP server to create a SIP 407 (Proxy Authentication Required) response (step 4) that contains a challenge. The SIP UA creates a new INVITE request (step 5) that contains the credentials. The Diameter client in the SIP server sends the credentials to the Diameter server in a new Diameter MAR message (step 6). The Diameter server validates the credentials and authorize the SIP transaction in a Diameter MAA message (step 7). The SIP server forwards the SIP INVITE request to its destination (step 8) as per regular SIP procedures. Eventually, the session setup is confirmed with a SIP 200 (OK) response (step 9) that is forwarded to the SIP UA (step 10). The session setup is complete.
図4によると、SIPユーザーエージェントはSIP要求をそのアウトバウンドSIPプロキシサーバーに送信します。この場合、メッセージはSIP INVITE要求（ステップ1を参照）ですが、他のSIP要求の場合もあります。現時点では、このSIP要求には資格情報が含まれていないと想定しています。アウトバウンドSIPプロキシサーバーは、ユーザーに提供されるプロキシサービスを認証および承認する必要があります。 SIPサーバーのDiameterクライアントは、マルチメディア認証要求（MAR）メッセージを送信します（ステップ2）。 Diameterサーバーはナンスを生成し、ナンスとSIPサーバーがユーザーにチャレンジするために必要な残りのデータを含むMultimedia-Auth-Answer（MAA）メッセージを送信します（通常はHTTPダイジェスト認証で示されています）。 MAAメッセージ。このデータにより、SIPサーバーはチャレンジを含むSIP 407（プロキシ認証が必要）応答（ステップ4）を作成できます。 SIP UAは、資格情報を含む新しいINVITE要求を作成します（ステップ5）。 SIPサーバーのDiameterクライアントは、資格情報を新しいDiameter MARメッセージでDiameterサーバーに送信します（ステップ6）。 Diameterサーバーは資格情報を検証し、Diameter MAAメッセージでSIPトランザクションを承認します（ステップ7）。 SIPサーバーは、通常のSIP手順に従って、SIP INVITE要求を宛先に転送します（ステップ8）。最終的に、セッションのセットアップは、SIP UA（ステップ10）に転送されるSIP 200（OK）応答（ステップ9）で確認されます。セッションのセットアップが完了しました。
+--------+ +--------+
|Diameter| | SIP |
| server | | server |
+--------+ +--------+
| |
| |
1. SIP INVITE |
----------------------------------->|
| 2. MAR |
|<------------------|
| 3. MAA |
|------------------>|
| |
4. SIP 407 (Proxy |
Authentication Required) |
<-----------------------------------|
| |
5. SIP INVITE |
----------------------------------->|
| 6. MAR |
|<------------------|
| 7. MAA |
|------------------>| 8. SIP INVITE
| |---------------->
| | 9. SIP 200 (OK)
10. SIP 200 (OK) |<----------------
<-----------------------------------|
| |
Figure 4: SIP server requests authorization
図4：SIPサーバーが承認を要求する
Figure 5 shows the scenario where SIP server 1 may be configured as a SIP edge proxy server, processing SIP traffic at the edge of a network. SIP server 1 receives a SIP INVITE request (step 1). SIP server 1 needs to find the address of SIP server 2, which is serving the recipient of the SIP request. The Diameter client in SIP server 1 sends a Diameter Location-Info-Request (LIR) message (step 2) to the Diameter server. The Diameter server responds with a Diameter Location-Info-Answer (LIA) message (step 3) that contains the SIP or SIPS URI of SIP server 2. SIP server 1 then forwards the SIP INVITE to SIP server 2 (step 4). SIP server 2 eventually forwards the SIP INVITE to the appropriate UAS (step 5).
図5は、SIPサーバー1をSIPエッジプロキシサーバーとして構成し、ネットワークのエッジでSIPトラフィックを処理するシナリオを示しています。 SIPサーバー1はSIP INVITE要求を受信します（ステップ1）。 SIPサーバー1は、SIPリクエストの受信者にサービスを提供しているSIPサーバー2のアドレスを見つける必要があります。 SIPサーバー1のDiameterクライアントは、Diameterロケーション情報要求（LIR）メッセージ（ステップ2）をDiameterサーバーに送信します。 Diameterサーバーは、SIPサーバー2のSIPまたはSIPS URIを含むDiameter Location-Info-Answer（LIA）メッセージで応答します（ステップ3）。次に、SIPサーバー1は、SIP INVITEをSIPサーバー2に転送します（ステップ4）。 SIPサーバー2は最終的にSIP INVITEを適切なUASに転送します（ステップ5）。
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP INVITE | | |
-------------->| 2. LIR | |
|---------------->| |
| 3. LIA | |
|<----------------| |
| 4. SIP INVITE |
|--------------------------------->|
| | | 5. SIP INVITE
| | |-------------->
| | |
| | |
Figure 5: Locating the SIP server of the recipient
図5：受信者のSIPサーバーを見つける
Although the example shows the connection between a SIP INVITE request and the Diameter LIR message, any SIP request other than REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message. (A SIP REGISTER request will trigger a Diameter UAR message, as indicated in Figure 2 and Figure 3.)
この例ではSIP INVITEリクエストとDiameter LIRメッセージ間の接続を示していますが、REGISTER以外のSIPリクエスト（SUBSCRIBE、OPTIONSなど）は同じDiameterメッセージをトリガーします。 （図2および図3に示すように、SIP REGISTER要求はDiameter UARメッセージをトリガーします。）
The scenario described in this section is also applicable in case an outbound SIP server is not interested in authenticating the user, but is required to locate a further SIP server to route the outbound SIP requests. In this case, the outbound SIP server is mapped to SIP server 1 as shown in Figure 5.
このセクションで説明するシナリオは、アウトバウンドSIPサーバーがユーザーの認証に関心がない場合にも適用できますが、アウトバウンドSIPリクエストをルーティングするために別のSIPサーバーを見つけるために必要です。この場合、アウトバウンドSIPサーバーは、図5に示すようにSIPサーバー1にマップされます。
The Diameter SIP application provides a mechanism for a Diameter server to asynchronously download a user profile to a SIP server whenever there is an update of such user profile. It must be noted that the Diameter server also attaches the user profile to the Diameter Server-Assignment-Answer (SAA) message. This is valid for most of the daily situations; however, the administrator may decide to update or modify the user profile for a particular user, due to, e.g., new services made available to the user. This may involve mechanisms outside the scope of this specification, such as human intervention, in the Diameter server. In this situation, the Diameter server is able to push the new user profile into the SIP server allocated to the user.
Diameter SIPアプリケーションは、Diameterサーバーがユーザープロファイルを非同期でSIPサーバーにダウンロードするためのメカニズムを提供します。 Diameterサーバーは、Diameter Server-Assignment-Answer（SAA）メッセージにもユーザープロファイルを添付することに注意してください。これは日常のほとんどの状況で有効です。ただし、管理者は、たとえば、ユーザーが利用できるようになった新しいサービスのために、特定のユーザーのユーザープロファイルを更新または変更する場合があります。これには、Diameterサーバーでの、人間の介入など、この仕様の範囲外のメカニズムが含まれる場合があります。この状況では、Diameterサーバーは、ユーザーに割り当てられたSIPサーバーに新しいユーザープロファイルをプッシュできます。
The scenario is illustrated in Figure 6. When the user profile changes, the Diameter server sends a Diameter Push-Profile-Request (PPR) message (step 1) to the Diameter client in the SIP server allocated to that user (SIP server 2 in the examples). The Diameter PPR message contains one or more SIP-User-Data AVPs, a User-Name AVP and zero or more SIP-AOR AVPs. The Diameter client in SIP server 2 acknowledges the Diameter PPR message by sending a Diameter Push-Profile-Answer (PPA) message (step 2) to the Diameter server.
このシナリオを図6に示します。ユーザープロファイルが変更されると、Diameterサーバーは、Diameter Push-Profile-Request（PPR）メッセージ（ステップ1）を、そのユーザーに割り当てられたSIPサーバー（SIPサーバー2のDiameterクライアント）に送信します。例）。 Diameter PPRメッセージには、1つ以上のSIP-User-Data AVP、User-Name AVP、および0個以上のSIP-AOR AVPが含まれています。 SIPサーバー2のDiameterクライアントは、Diameter Push-Profile-Answer（PPA）メッセージ（ステップ2）をDiameterサーバーに送信することにより、Diameter PPRメッセージを確認します。
+--------+ +--------+
|Diameter| | SIP |
| server | |server 2|
+--------+ +--------+
| |
| 1. PPR |
|------------------>|
| |
| 2. PPA |
|<------------------|
| |
Figure 6: Diameter server pushes an update of the user profile
図6：Diameterサーバーがユーザープロファイルの更新をプッシュする
SIP can create soft states in SIP nodes based on events such as SIP registrations or SIP event subscriptions. These states are periodically refreshed, and cease to exist if they are not refreshed. Additionally, an administrative action can be taken to terminate a SIP soft state, or the SIP UA can explicitly terminate a SIP soft state.
SIPは、SIP登録やSIPイベントサブスクリプションなどのイベントに基づいて、SIPノードにソフトステートを作成できます。これらの状態は定期的に更新され、更新されない場合は存在しなくなります。さらに、管理アクションを実行してSIPソフト状態を終了することも、SIP UAが明示的にSIPソフト状態を終了することもできます。
The Diameter base protocol offers a mechanism to create and delete states in Diameter nodes. These states are called Diameter user sessions. The Diameter server decides whether to use a Diameter user session as a mechanism to map to a SIP soft state. If the Diameter server decides to use Diameter user sessions, the termination of a Diameter user session implies the termination of the corresponding SIP soft state (e.g., registration, event subscription), and vice versa. If the Diameter server does not use Diameter user sessions, this Diameter SIP application offers specific commands to manage the SIP soft states. Implementations compliant with this specification MUST support both mechanisms of session management.
Diameter基本プロトコルは、Diameterノードで状態を作成および削除するメカニズムを提供します。これらの状態は、Diameterユーザーセッションと呼ばれます。 Diameterサーバーは、DiameterユーザーセッションをSIPソフト状態にマップするメカニズムとして使用するかどうかを決定します。 DiameterサーバーがDiameterユーザーセッションを使用することを決定した場合、Diameterユーザーセッションの終了は、対応するSIPソフトステート（たとえば、登録、イベントサブスクリプション）の終了を意味し、その逆も同様です。 DiameterサーバーがDiameterユーザーセッションを使用しない場合、このDiameter SIPアプリケーションは、SIPソフト状態を管理するための特定のコマンドを提供します。この仕様に準拠した実装は、セッション管理の両方のメカニズムをサポートする必要があります。
We provide support for both Diameter client- and Diameter server-initiated session termination. Depending on whether Diameter sessions are used, termination of a SIP soft state can be achieved by one of the following methods:
DiameterクライアントとDiameterサーバーが開始するセッション終了の両方をサポートします。 Diameterセッションが使用されているかどうかに応じて、SIPソフトステートの終了は、次のいずれかの方法で実現できます。
o When the Diameter client (SIP proxy) wants to terminate the SIP soft state and Diameter user sessions are not maintained (i.e., the Auth-Session-State AVP has been previously set to NO_STATE_MAINTAINED), the Diameter client MUST send a Server-Assignment-Request (SAR) message with the SIP-Server-Assignment-Type AVP (Section 9.4) set to any of the deregistration values: TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, USER_DEREGISTRATION_STORE_SERVER_NAME, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA.
o Diameterクライアント（SIPプロキシ）がSIPソフト状態を終了する必要があり、Diameterユーザーセッションが維持されていない場合（つまり、Auth-Session-State AVPが以前にNO_STATE_MAINTAINEDに設定されている場合）、Diameterクライアントはサーバー割り当てを送信する必要があります。 SIP-Server-Assignment-Type AVP（セクション9.4）が登録解除値のいずれかに設定されたリクエスト（SAR）メッセージ：TIMEOUT_DEREGISTRATION、USER_DEREGISTRATION、TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME、USER_DEREGISTRATION_STORE_SERVER_NAME、ADMINISTRATIVE_DEREGISTRATIONO_DEREGISTRATION.DEREGISTRATION
o When the Diameter client (SIP proxy) wants to terminate the SIP soft state and Diameter user sessions are maintained (i.e., the Auth-Session-State AVP has been previously set to STATE_MAINTAINED), the Diameter client MUST send a Session-Termination-Request (STR) message as per regular procedures according to RFC 3588 [RFC3588].
o Diameterクライアント（SIPプロキシ）がSIPソフト状態を終了する必要があり、Diameterユーザーセッションが維持されている（つまり、Auth-Session-State AVPが以前にSTATE_MAINTAINEDに設定されている）場合、DiameterクライアントはSession-Termination-Requestを送信する必要があります（STR）RFC 3588 [RFC3588]に準拠した通常の手順によるメッセージ。
o When the Diameter server wants to terminate the SIP soft state and Diameter user sessions are not maintained (i.e., the Auth-Session-State AVP has been previously set to NO_STATE_MAINTAINED), the Diameter server MUST send a Registration-Termination-Request (RTR) message (see Section 8.9).
o DiameterサーバーがSIPソフト状態を終了する必要があり、Diameterユーザーセッションが維持されていない場合（つまり、Auth-Session-State AVPが以前にNO_STATE_MAINTAINEDに設定されている場合）、DiameterサーバーはRegistration-Termination-Request（RTR）を送信する必要があります。メッセージ（セクション8.9を参照）。
o When the Diameter server wants to terminate the SIP soft state and Diameter user sessions are maintained (i.e., the Auth-Session-State AVP has been previously set to STATE_MAINTAINED), the Diameter server MUST send an Abort-Session-Request (ASR) message as per regular procedures according to RFC 3588 [RFC3588].
o DiameterサーバーがSIPソフト状態を終了する必要があり、Diameterユーザーセッションが維持されている場合（つまり、Auth-Session-State AVPが以前にSTATE_MAINTAINEDに設定されている場合）、DiameterサーバーはAbort-Session-Request（ASR）メッセージを送信する必要があります。 RFC 3588 [RFC3588]に基づく通常の手順に従って。
The basic architecture assumption of this document is that all the data related to a user is stored in a unique Diameter server. Contrary to general opinion, this does not create a single point of failure. It is assumed that Diameter servers are configured in a redundant fashion in an attempt to mitigate the single-point-of-failure problem.
このドキュメントの基本的なアーキテクチャの前提は、ユーザーに関連するすべてのデータが一意のDiameterサーバーに格納されることです。一般的な意見に反して、これは単一障害点を作成しません。単一障害点の問題を軽減するために、Diameterサーバーが冗長構成されていると想定されています。
In large networks, where the number of users may be significantly high, there might be a need to scale the number of Diameter servers. All the data associated with a user is still stored in one Diameter server (typically, operating in a redundant configuration), but the data associated with different users may reside in different Diameter servers.
ユーザーの数が非常に多い大規模なネットワークでは、Diameterサーバーの数を拡張する必要がある場合があります。ユーザーに関連付けられたすべてのデータは1つのDiameterサーバーに格納されます（通常、冗長構成で動作します）が、異なるユーザーに関連付けられたデータは異なるDiameterサーバーに存在する場合があります。
Although this configuration scales well, it introduces a new problem, namely: given the user's SIP AOR as an input, how to determine which of various Diameter servers is storing the data for that particular SIP AOR. We solve this problem with inspiration from the Diameter redirection mechanism specified in RFC 3588 [RFC3588]. We include in the architecture a new Diameter node that, for the purpose of this document, is known as Diameter Subscriber Locator (SL). The Diameter SL contains a database or routing tables that map SIP AORs to Diameter server URIs. A particular Diameter server URI points to the actual Diameter server that stores all the data related to a particular SIP AOR, and in consequence, to the user who owns the SIP AOR. The Diameter SL acts in a similar way to a Diameter Redirect Agent, dispatching Diameter requests (e.g., providing the redirection URI in the answer). The Diameter SL can redirect all the request pertaining to a user by setting the Redirect-Host-Usage AVP with a value ALL_USER, as specified in RFC 3588 [RFC3588].
この構成はスケーラブルですが、新しい問題が発生します。つまり、ユーザーのSIP AORを入力として指定すると、さまざまなDiameterサーバーのどれがその特定のSIP AORのデータを格納しているかを判別する方法です。この問題は、RFC 3588 [RFC3588]で指定されているDiameterリダイレクトメカニズムからインスピレーションを得て解決しています。このドキュメントでは、Diameter Subscriber Locator（SL）と呼ばれる新しいDiameterノードをアーキテクチャに含めています。 Diameter SLには、SIP AORをDiameterサーバーURIにマップするデータベースまたはルーティングテーブルが含まれています。特定のDiameterサーバーURIは、特定のSIP AORに関連するすべてのデータを格納する実際のDiameterサーバーを指し、その結果、SIP AORを所有するユーザーを指します。 Diameter SLは、Diameterリダイレクトエージェントと同様に機能し、Diameterリクエストをディスパッチします（たとえば、応答にリダイレクトURIを提供します）。 Diameter SLは、RFC 3588 [RFC3588]で指定されているように、Redirect-Host-Usage AVPに値ALL_USERを設定することにより、ユーザーに関するすべてのリクエストをリダイレクトできます。
The Diameter SL can be replicated in different nodes along the network, for the purpose of building scalability and redundancy. The database or routing tables have to be consistent across all these different Diameter SLs, so that equal Diameter requests will produce equal Diameter answers, no matter which Diameter SL processes the request.
Diameter SLは、スケーラビリティと冗長性を構築する目的で、ネットワーク上の異なるノードに複製できます。データベースまたはルーティングテーブルは、これらの異なるすべてのDiameter SLで一貫している必要があります。これにより、どのDiameter SLがリクエストを処理しても、同じDiameterリクエストが同じDiameter応答を生成します。
+--------+ +--------+ +--------+ +--------+
| SIP | |Diameter| |Diameter| | SIP |
|server 1| |SL red. | |server 1| |server 2|
+--------+ +--------+ +--------+ +--------+
| | | |
1. SIP INVITE| | | |
------------>| 2. LIR | | |
|---------->| | |
| 3. LIA | | |
|<----------| | |
| 4. LIR | |
|---------------------->| |
| 5. LIA | |
|<----------------------| |
| 6. SIP INVITE | |
|----------------------------------->| 7. SIP INVITE
| | | | ------------->
| | | |
Figure 7: Locating a Diameter server. SL redirecting requests
図7：Diameterサーバーの検索。 SLリダイレクト要求
Figure 7 shows an example of operation of a Diameter SL acting in redirect mode. SIP server 1 receives an INVITE request (step 1) addressed (in the SIP Request-URI) to a user for which the Diameter client in SIP server 1 does not possess routing information. In other words, the Diameter client in SIP server 1 does not know the URI of the Diameter server 1. The Diameter client sends a Diameter LIR message (step 2) to any of the Diameter SLs configured in the network. The address of those SLs is assumed to be pre-provisioned in the Diameter client. The Diameter SL, based on the contents of the SIP-AOR AVP and its own routing tables, determines the Diameter server that stores the information allocated to such user. Then it builds a Diameter LIA message (step 3) that includes a Result-Code AVP set to DIAMETER_REDIRECT_INDICATION and one Redirect-Host AVP, whose value is set to the URI of the Diameter server that stores the information related to such user. Then the Diameter client in SIP server 1 builds a new LIR message (step 4) addressed to the Diameter server received in the Redirect-Host AVP. The rest of the procedure is completed as described in previous sections.
図7は、リダイレクトモードで動作するDiameter SLの動作例を示しています。 SIPサーバー1は、SIPサーバー1のDiameterクライアントがルーティング情報を所有していないユーザーに宛てられた（SIP Request-URIで）INVITE要求（ステップ1）を受信します。つまり、SIPサーバー1のDiameterクライアントは、Diameterサーバー1のURIを認識していません。Diameterクライアントは、Diameter LIRメッセージ（ステップ2）をネットワークで構成されている任意のDiameter SLに送信します。これらのSLのアドレスは、Diameterクライアントで事前にプロビジョニングされていると想定されます。 Diameter SLは、SIP-AOR AVPのコンテンツと独自のルーティングテーブルに基づいて、そのようなユーザーに割り当てられた情報を格納するDiameterサーバーを決定します。次に、DIAMETER_REDIRECT_INDICATIONに設定されたResult-Code AVPと、そのようなユーザーに関連する情報を格納するDiameterサーバーのURIに値が設定された1つのRedirect-Host AVPを含むDiameter LIAメッセージを作成します（ステップ3）。次に、SIPサーバー1のDiameterクライアントは、リダイレクトホストAVPで受信したDiameterサーバーにアドレス指定された新しいLIRメッセージ（ステップ4）を作成します。前のセクションで説明したように、残りの手順は完了します。
Diameter implementations conforming to this specification MUST advertise its support by including an Auth-Application-Id AVP in the Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) commands, according to the Diameter base protocol, RFC 3588 [RFC3588]. This Auth-Application-Id AVP MUST be set to the value of this Diameter SIP application (Section 13.1 indicates the actual value allocated by IANA).
Diameter基本プロトコルであるRFC 3588に従って、この仕様に準拠するDiameter実装は、Capabilities-Exchange-Request（CER）コマンドとCapabilities-Exchange-Answer（CEA）コマンドにAuth-Application-Id AVPを含めることにより、そのサポートをアドバタイズする必要があります[ RFC3588]。このAuth-Application-Id AVPは、このDiameter SIPアプリケーションの値に設定する必要があります（セクション13.1は、IANAによって割り当てられた実際の値を示しています）。
All the Diameter implementations conforming to this specification MUST implement and support the list of Diameter commands listed in Table 1.
この仕様に準拠するすべてのDiameter実装は、表1にリストされているDiameterコマンドのリストを実装およびサポートする必要があります。
+-------------------------------------+-------+------+--------------+
| Command Name | Abbr. | Code | Reference |
+-------------------------------------+-------+------+--------------+
| User-Authorization-Request | UAR | 283 | Section 8.1 |
| User-Authorization-Answer | UAA | 283 | Section 8.2 |
| Server-Assignment-Request | SAR | 284 | Section 8.3 |
| Server-Assignment-Answer | SAA | 284 | Section 8.4 |
| Location-Info-Request | LIR | 285 | Section 8.5 |
| Location-Info-Answer | LIA | 285 | Section 8.6 |
| Multimedia-Auth-Request | MAR | 286 | Section 8.7 |
| Multimedia-Auth-Answer | MAA | 286 | Section 8.8 |
| Registration-Termination-Request | RTR | 287 | Section 8.9 |
| Registration-Termination-Answer | RTA | 287 | Section 8.10 |
| Push-Profile-Request | PPR | 288 | Section 8.11 |
| Push-Profile-Answer | PPA | 288 | Section 8.12 |
+-------------------------------------+-------+------+--------------+
Table 1: Defined command codes
表1：定義されたコマンドコード
Sections defining commands contain the Message Format for that particular command. The Message Formats included in this document are defined as per Section 3.2 of RFC 3588 [RFC3588].
コマンドを定義するセクションには、その特定のコマンドのメッセージ形式が含まれています。このドキュメントに含まれているメッセージ形式は、RFC 3588 [RFC3588]のセクション3.2に従って定義されています。
The User-Authorization-Request (UAR) is indicated by the Command-Code set to 283 and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server to request authorization for the SIP User Agent to route a SIP REGISTER request. Because the SIP REGISTER request implicitly carries a permission to bind an AOR to a contact address, the Diameter client uses the Diameter UAR as a first authorization request towards the Diameter server to authorize the registration. For instance, the Diameter server can verify that the AOR is a legitimate user of the realm.
User-Authorization-Request（UAR）は、283に設定されたコマンドコードと、コマンドフラグの 'R'ビットセットによって示されます。 SIPサーバーのDiameterクライアントは、このコマンドをDiameterサーバーに送信して、SIPユーザーエージェントがSIP REGISTER要求をルーティングするための承認を要求します。 SIP REGISTER要求は暗黙的にAORを連絡先アドレスにバインドする許可を運ぶため、DiameterクライアントはDiameter UARをDiameterサーバーへの最初の許可要求として使用して、登録を許可します。たとえば、Diameterサーバーは、AORがレルムの正当なユーザーであることを確認できます。
The Diameter client in the SIP server requests authorization for one of the possible values defined in the SIP-User-Authorization-Type AVP (Section 9.10).
SIPサーバーのDiameterクライアントは、SIP-User-Authorization-Type AVP（セクション9.10）で定義された可能な値の1つに対する承認を要求します。
The user name used for authentication of the user is conveyed in a User-Name AVP (defined in the Diameter base protocol, RFC 3588 [RFC3588]). The location of the authentication user name in the SIP
ユーザーの認証に使用されるユーザー名は、ユーザー名AVP（Diameter基本プロトコル、RFC 3588 [RFC3588]で定義）で伝達されます。 SIP内の認証ユーザー名の場所
REGISTER request varies depending on the authentication mechanism. When the authentication mechanism is HTTP Digest as defined in RFC 2617 [RFC2617], the authentication user name is found in the "username" directive of the SIP Authorization header field value. This Diameter SIP application only provides support for HTTP Digest authentication in SIP; other authentication mechanisms are not currently supported.
REGISTERリクエストは、認証メカニズムによって異なります。認証メカニズムがRFC 2617 [RFC2617]で定義されているHTTPダイジェストの場合、認証ユーザー名はSIP Authorizationヘッダーフィールド値の「username」ディレクティブにあります。このDiameter SIPアプリケーションは、SIPでのHTTPダイジェスト認証のサポートのみを提供します。他の認証メカニズムは現在サポートされていません。
The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP (Section 9.8). Typically this SIP or SIPS URI is found in the To header field value of the SIP REGISTER request that triggered the Diameter UAR message.
登録されるSIPまたはSIPS URIは、SIP-AOR AVPで伝達されます（セクション9.8）。通常、このSIPまたはSIPS URIは、Diameter UARメッセージをトリガーしたSIP REGISTERリクエストのToヘッダーフィールド値にあります。
The SIP-Visited-Network-Id AVP indicates the network that is providing SIP services (e.g., SIP proxy functionality or any other kind of services) to the SIP User Agent.
SIP-Visited-Network-Id AVPは、SIPサービス（SIPプロキシ機能やその他の種類のサービスなど）をSIPユーザーエージェントに提供しているネットワークを示します。
The Message Format of the UAR command is as follows:
UARコマンドのメッセージフォーマットは次のとおりです。
<UAR> ::= < Diameter Header: 283, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-AOR }
[ Destination-Host ]
[ User-Name ]
[ SIP-Visited-Network-Id ]
[ SIP-User-Authorization-Type ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The User-Authorization-Answer (UAA) is indicated by the Command-Code set to 283 and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter User-Authorization-Request (UAR) command. The Diameter server indicates the result of the requested registration authorization. Additionally, the Diameter server may indicate a collection of SIP capabilities that assists the Diameter client to select a SIP proxy to the AOR under registration.
User-Authorization-Answer（UAA）は、コマンドコードが283に設定され、コマンドフラグの「R」ビットがクリアされることで示されます。 Diameterサーバーは、以前に受信したDiameter User-Authorization-Request（UAR）コマンドへの応答としてこのコマンドを送信します。 Diameterサーバーは、要求された登録認証の結果を示します。さらに、Diameterサーバーは、Diameterクライアントが登録時にAORへのSIPプロキシを選択するのを支援するSIP機能のコレクションを示す場合があります。
In addition to the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1.
RFC 3588 [RFC3588]ですでに定義されている値に加えて、Result-Code AVPにはセクション10.1で定義されている値の1つが含まれる場合があります。
Whenever the Diameter server fails to process the Diameter UAR message, it MUST stop processing and return the relevant error in the Diameter UAA message. When there is success in the process, the Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter UAA message.
DiameterサーバーがDiameter UARメッセージの処理に失敗した場合は常に、処理を停止し、Diameter UAAメッセージで関連するエラーを返す必要があります。プロセスで成功した場合、DiameterサーバーはDiameter UAAメッセージでコードをDIAMETER_SUCCESSに設定する必要があります。
If the Diameter server requires a User-Name AVP value to process the Diameter UAR request, but the Diameter UAR message did not contain a User-Name AVP value, the Diameter server MUST set the Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return it in a Diameter UAA message. Upon reception of this Diameter UAA message with the Result-Code AVP value set to DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests authentication by sending a SIP 401 (Unauthorized) or SIP 407 (Proxy Authentication Required) response back to the originator.
DiameterサーバーがDiameter UARリクエストを処理するためにUser-Name AVP値を必要とするが、Diameter UARメッセージにUser-Name AVP値が含まれていない場合、DiameterサーバーはResult-Code AVP値をDIAMETER_USER_NAME_REQUIREDに設定する必要があります（セクション10.1を参照） .2）をDiameter UAAメッセージで返します。 Result-Code AVP値がDIAMETER_USER_NAME_REQUIREDに設定されたこのDiameter UAAメッセージを受信すると、SIPサーバーは通常、SIP 401（無許可）またはSIP 407（プロキシ認証が必要）の応答を発信者に送り返すことによって認証を要求します。
When the authorization procedure succeeds, the Diameter server constructs a User-Authorization-Answer (UAA) message that MUST include (1) the address of the SIP server already assigned to the user name, (2) the capabilities needed by the SIP server (Diameter client) to select another SIP server for the user, or (3) a combination of the previous two options.
承認手続きが成功すると、DiameterサーバーはUser-Authorization-Answer（UAA）メッセージを作成します。このメッセージには、（1）ユーザー名に既に割り当てられているSIPサーバーのアドレス、（2）SIPサーバーが必要とする機能（ Diameterクライアント）を使用して、ユーザーに別のSIPサーバーを選択するか、（3）前の2つのオプションの組み合わせを選択します。
If the Diameter server is already aware of a SIP server allocated to the user, the Diameter UAA message contains the address of that SIP server.
Diameterサーバーがユーザーに割り当てられたSIPサーバーをすでに認識している場合、Diameter UAAメッセージにはそのSIPサーバーのアドレスが含まれます。
The Diameter UAA message contains the capabilities required by a SIP server to trigger and execute services. It is required that these capabilities are present in the Diameter UAA message due to the possibility that the Diameter client (in the SIP server) allocates a different SIP server to trigger and execute services for that particular user.
Diameter UAAメッセージには、SIPサーバーがサービスをトリガーして実行するために必要な機能が含まれています。 Diameterクライアント（SIPサーバー内）が別のSIPサーバーを割り当てて特定のユーザーのサービスをトリガーおよび実行する可能性があるため、これらの機能はDiameter UAAメッセージに存在する必要があります。
If a User-Name AVP is present in the Diameter UAR message, then the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter User-Authorization-Answer (UAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN.
ユーザー名AVPがDiameter UARメッセージに存在する場合、Diameterサーバーはレルム内のユーザーの存在を確認する必要があります。つまり、ユーザー名AVP値はそのレルム内の有効なユーザーです。 DiameterサーバーがUser-Name AVPで受信したユーザー名を認識しない場合、DiameterサーバーはDiameter User-Authorization-Answer（UAA）メッセージを作成し、Result-Code AVPをDIAMETER_ERROR_USER_UNKNOWNに設定する必要があります。
If a User-Name AVP is present in the Diameter UAR message, then the Diameter server MUST authorize that User-Name AVP value is able to register the SIP or SIPS URI included in the SIP-AOR AVP. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter User-Authorization-Answer (UAA) message.
ユーザー名AVPがDiameter UARメッセージに存在する場合、Diameterサーバーは、ユーザー名AVP値がSIP-AOR AVPに含まれるSIPまたはSIPS URIを登録できることを承認する必要があります。この認証が失敗した場合、DiameterサーバーはResult-Code AVPをDIAMETER_ERROR_IDENTITIES_DONT_MATCHに設定し、Diameter User-Authorization-Answer（UAA）メッセージで送信する必要があります。
Note: Correlation between User-Name and SIP-AOR AVP values is required in order to avoid registration of a SIP-AOR allocated to another user.
注：別のユーザーに割り当てられたSIP-AORの登録を回避するために、ユーザー名とSIP-AOR AVP値の相関が必要です。
If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message, and the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION or REGISTRATION& CAPABILITIES, then the Diameter server SHOULD verify whether the user is allowed to roam into the network specified in the SIP-Visited-Network-Id AVP in the Diameter UAR message. If the user is not allowed to roam into that network, the Diameter AAA server MUST set the Result-Code AVP value in the Diameter UAA message to DIAMETER_ERROR_ROAMING_NOT_ALLOWED.
Diameter UARメッセージにSIP-Visited-Network-Id AVPがあり、Diameter UARメッセージで受信されたSIP-User-Authorization-Type AVP値がREGISTRATIONまたはREGISTRATION＆CAPABILITIESに設定されている場合、Diameterサーバーは、ユーザーは、Diameter UARメッセージのSIP-Visited-Network-Id AVPで指定されたネットワークにローミングできます。ユーザーがそのネットワークへのローミングを許可されていない場合、Diameter AAAサーバーは、Diameter UAAメッセージのResult-Code AVP値をDIAMETER_ERROR_ROAMING_NOT_ALLOWEDに設定する必要があります。
If the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES, then the Diameter server SHOULD verify whether the SIP-AOR AVP value is authorized to register in the Home Realm. Where the SIP AOR is not authorized to register in the Home Realm, the Diameter server MUST set the Result-Code AVP to DIAMETER_AUTHORIZATION_REJECTED and send it in a Diameter UAA message.
Diameter UARメッセージで受信したSIP-User-Authorization-Type AVP値がREGISTRATIONまたはREGISTRATION＆CAPABILITIESに設定されている場合、Diameterサーバーは、SIP-AOR AVP値がホームレルムへの登録を許可されているかどうかを確認する必要があります。 SIP AORがホームレルムへの登録を許可されていない場合、DiameterサーバーはResult-Code AVPをDIAMETER_AUTHORIZATION_REJECTEDに設定し、Diameter UAAメッセージで送信する必要があります。
When the SIP-User-Authorization-Type AVP is not present in the Diameter UAR message, or when it is present and its value is set to REGISTRATION, then:
SIP-User-Authorization-Type AVPがDiameter UARメッセージに存在しない場合、または存在し、その値がREGISTRATIONに設定されている場合、次のようになります。
o If the Diameter server is not aware of any previous registration of the user name (including registrations of other SIP AORs allocated to the same user name), then the Diameter server does not know of any SIP server allocated to the user. In this case, the Diameter server MUST set the Result-Code AVP value to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and the Diameter server SHOULD include the required SIP server capabilities in the SIP-Server-Capabilities AVP value in the Diameter UAA message. The SIP-Server-Capabilities AVP assists the Diameter client (SIP server) to select an appropriate SIP server for the user, according to the required capabilities.
o Diameterサーバーがユーザー名の以前の登録（同じユーザー名に割り当てられた他のSIP AORの登録を含む）を認識していない場合、Diameterサーバーはユーザーに割り当てられたSIPサーバーを認識しません。この場合、Diameterサーバーは、Diameter UAAメッセージのResult-Code AVP値をDIAMETER_FIRST_REGISTRATIONに設定する必要があり、Diameterサーバーは、Diameter UAAメッセージのSIP-Server-Capabilities AVP値に必要なSIPサーバー機能を含める必要があります。 SIP-Server-Capabilities AVPは、必要な機能に従って、Diameterクライアント（SIPサーバー）がユーザーに適切なSIPサーバーを選択するのを支援します。
o In some cases, the Diameter server is aware of a previously assigned SIP server for the same or different SIP AORs allocated to the same user name. In these cases, re-assignment of a new SIP server may or may not be needed, depending on the capabilities of the SIP server. The Diameter server MUST always include the allocated SIP server URI in the SIP-Server-URI AVP of the UAA message. If the Diameter server does not return the SIP capabilities, the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION. Otherwise (i.e., if the Diameter server includes a SIP-Server-Capabilities AVP), then the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_SERVER_SELECTION. Then the Diameter client determines, based on the received information, whether it needs to select a new SIP server.
o 場合によっては、Diameterサーバーは、同じユーザー名に割り当てられた同じまたは異なるSIP AORに対して以前に割り当てられたSIPサーバーを認識します。これらの場合、SIPサーバーの機能に応じて、新しいSIPサーバーの再割り当てが必要な場合と必要でない場合があります。 Diameterサーバーは、割り当てられたSIPサーバーURIをUAAメッセージのSIP-Server-URI AVPに常に含める必要があります。 DiameterサーバーがSIP機能を返さない場合、DiameterサーバーはDiameter UAAメッセージのResult-Code AVPをDIAMETER_SUBSEQUENT_REGISTRATIONに設定する必要があります。それ以外の場合（つまり、DiameterサーバーにSIP-Server-Capabilities AVPが含まれている場合）、Diameterサーバーは、Diameter UAAメッセージのResult-Code AVPをDIAMETER_SERVER_SELECTIONに設定する必要があります。次に、Diameterクライアントは、受信した情報に基づいて、新しいSIPサーバーを選択する必要があるかどうかを判断します。
When the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION&CAPABILITIES, then Diameter Server MUST return the list of capabilities in the SIP-Server-Capabilities AVP value of the Diameter UAA message, it MUST set the Result-Code to DIAMETER_SUCCESS, and it MUST NOT return a SIP-Server-URI AVP. The SIP-Server-Capabilities AVP enables the SIP server (Diameter client) to select another appropriate SIP server for invoking and executing services for the user, depending on the required capabilities. The Diameter server MAY leave the list of capabilities empty to indicate that any SIP server can be selected.
Diameter UARメッセージで受信したSIP-User-Authorization-Type AVP値がREGISTRATION＆CAPABILITIESに設定されている場合、DiameterサーバーはDiameter UAAメッセージのSIP-Server-Capabilities AVP値で機能のリストを返す必要があり、 Result-CodeをDIAMETER_SUCCESSに設定し、SIP-Server-URI AVPを返してはならない（MUST NOT）。 SIP-Server-Capabilities AVPにより、SIPサーバー（Diameterクライアント）は、必要な機能に応じて、ユーザーのサービスを呼び出して実行するための別の適切なSIPサーバーを選択できます。 Diameterサーバーは、機能のリストを空のままにして、任意のSIPサーバーを選択できることを示す場合があります。
When the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to DEREGISTRATION, then:
Diameter UARメッセージで受信されたSIP-User-Authorization-Type AVP値がDEREGISTRATIONに設定されている場合、次のようになります。
o If the Diameter server is aware of a SIP server assigned to the SIP AOR under deregistration, the Diameter server MUST set the Result-Code AVP to DIAMETER_SUCCESS and MUST set the SIP-Server-URI AVP value to the known SIP server, and return them in the Diameter UAA message.
o Diameterサーバーが登録解除中のSIP AORに割り当てられたSIPサーバーを認識している場合、DiameterサーバーはResult-Code AVPをDIAMETER_SUCCESSに設定し、SIP-Server-URI AVP値を既知のSIPサーバーに設定して返す必要があります。 Diameter UAAメッセージ内。
o If the Diameter server is not aware of a SIP server assigned to the SIP AOR under deregistration, then the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.
o Diameterサーバーが登録解除時にSIP AORに割り当てられたSIPサーバーを認識していない場合、DiameterサーバーはDiameter UAAメッセージのResult-Code AVPをDIAMETER_ERROR_IDENTITY_NOT_REGISTEREDに設定する必要があります。
The Message Format of the UAA command is as follows:
UAAコマンドのメッセージ形式は次のとおりです。
<UAA> ::= < Diameter Header: 283, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-URI ]
[ SIP-Server-Capabilities ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ]
[SIP-Server-Capabilities] [Authorization-Lifetime] [Auth-Grace-Period] [Redirect-Host] [Redirect-Host-Usage] [Redirect-Max-Cache-Time] * [Proxy-Info] * [Route-記録] * [AVP]
The Server-Assignment-Request (SAR) command is indicated by the Command-Code set to 284 and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server to indicate the completion of the authentication process and to request that the Diameter server store the URI of the SIP server that is currently serving the user. The main functions of the Diameter SAR command are to inform the Diameter server of the URI of the SIP server allocated to the user, and to store or clear it from the Diameter server. Additionally, the Diameter client can request to download the user profile or part of it.
Server-Assignment-Request（SAR）コマンドは、コマンドコードが284に設定され、コマンドフラグの「R」ビットが設定されていることで示されます。 SIPサーバーのDiameterクライアントはこのコマンドをDiameterサーバーに送信して、認証プロセスの完了を示し、Diameterサーバーが現在ユーザーにサービスを提供しているSIPサーバーのURIを格納するように要求します。 Diameter SARコマンドの主な機能は、Diameterサーバーにユーザーに割り当てられたSIPサーバーのURIを通知し、Diameterサーバーに格納またはクリアすることです。さらに、Diameterクライアントは、ユーザープロファイルまたはその一部のダウンロードを要求できます。
During the registration procedure, a SIP server becomes assigned to the user. The Diameter client in the assigned SIP server MUST include its own URI in the SIP-Server-URI AVP of the Server-Assignment-Request (SAR) Diameter message and send it to the Diameter server. The Diameter server then becomes aware of the allocation of the SIP server to the user name and the server's URI.
登録手続き中に、SIPサーバーがユーザーに割り当てられます。割り当てられたSIPサーバーのDiameterクライアントは、Server-Assignment-Request（SAR）DiameterメッセージのSIP-Server-URI AVPに独自のURIを含め、Diameterサーバーに送信する必要があります。次に、Diameterサーバーは、ユーザー名とサーバーのURIへのSIPサーバーの割り当てを認識します。
The Diameter client in the SIP server MAY send a Diameter SAR message because of other reasons. These reasons are identified in the SIP-Server-Assignment-Type AVP (Section 9.4) value. For instance, a Diameter client in a SIP server may contact the Diameter server to request deregistration of a user, to inform the Diameter server of an authentication failure, or just to download the user profile. For a complete description of all the SIP-Server-Assignment-Type AVP values, see Section 9.4.
SIPサーバーのDiameterクライアントは、他の理由でDiameter SARメッセージを送信する場合があります。これらの理由は、SIP-Server-Assignment-Type AVP（セクション9.4）値で識別されます。たとえば、SIPサーバーのDiameterクライアントは、Diameterサーバーに接続して、ユーザーの登録解除を要求したり、Diameterサーバーに認証の失敗を通知したり、ユーザープロファイルをダウンロードしたりします。すべてのSIP-Server-Assignment-Type AVP値の詳細については、セクション9.4を参照してください。
Typically the reception of a SIP REGISTER request in a SIP server will trigger the Diameter client in the SIP server to send the Diameter SAR message. However, if a SIP server is receiving other SIP request, such as INVITE, and the SIP server does not have the user profile, the Diameter client in the SIP server may send the Diameter SAR message to the Diameter server in order to download the user profile and make the Diameter server aware of the SIP server assigned to the user.
通常、SIPサーバーでSIP REGISTER要求を受信すると、SIPサーバーのDiameterクライアントがDiameter SARメッセージを送信します。ただし、SIPサーバーがINVITEなどの他のSIP要求を受信しており、SIPサーバーにユーザープロファイルがない場合、SIPサーバーのDiameterクライアントは、DiameterサーバーにDiameter SARメッセージを送信してユーザーをダウンロードする場合があります。プロファイルを作成し、Diameterサーバーにユーザーに割り当てられたSIPサーバーを認識させます。
The user profile is an important piece of information that dictates the behavior of the SIP server when triggering or providing services for the user. Typically the user profile is divided into:
ユーザープロファイルは、ユーザーにサービスをトリガーまたは提供するときのSIPサーバーの動作を決定する重要な情報です。通常、ユーザープロファイルは次のように分かれています。
o Services to be rendered to the user when the user is registered and initiates a SIP request.
o ユーザーが登録され、SIP要求を開始したときにユーザーに提供されるサービス。
o Services to be rendered to the user when the user is registered and a SIP request destined to that user arrives to the SIP proxy.
o ユーザーが登録され、そのユーザー宛てのSIPリクエストがSIPプロキシに到着したときにユーザーに提供されるサービス。
o Services to be rendered to the user when the user is not registered and a SIP request destined to that user arrives to the SIP proxy.
o ユーザーが登録されておらず、そのユーザー宛てのSIPリクエストがSIPプロキシに到着したときにユーザーに提供されるサービス。
The SIP-Server-Assignment-Type AVP indicates the reason why the Diameter client (SIP server) contacted the Diameter server. If the Diameter client sets the SIP-Server-Assignment-Type AVP value to REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT, AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client MUST include exactly one SIP-AOR AVP in the Diameter SAR message.
SIP-Server-Assignment-Type AVPは、Diameterクライアント（SIPサーバー）がDiameterサーバーに接続した理由を示します。 DiameterクライアントがSIP-Server-Assignment-Type AVP値をREGISTRATION、RE_REGISTRATION、UNREGISTERED_USER、NO_ASSIGNMENT、AUTHENTICATION_FAILURE、またはAUTHENTICATION_TIMEOUTに設定する場合、Diameterクライアントは、Diameter SARメッセージにSIP-AOR AVPを1つだけ含める必要があります。
The SAR message MAY contain zero or more SIP-Supported-User-Data-Type AVPs. Each of them contains a type of user data understood by the SIP server. This allows the Diameter client to provide an indication to the Diameter server of the different format of user data understood by the SIP server. The Diameter server uses this information to select one or more SIP-User-Data AVPs that will be included in the SAA message.
SARメッセージには、ゼロ以上のSIP-Supported-User-Data-Type AVPが含まれる場合があります。それぞれに、SIPサーバーが理解できるユーザーデータのタイプが含まれています。これにより、Diameterクライアントは、SIPサーバーが理解するさまざまな形式のユーザーデータをDiameterサーバーに表示できます。 Diameterサーバーはこの情報を使用して、SAAメッセージに含まれる1つ以上のSIP-User-Data AVPを選択します。
The Message Format of the SAR command is as follows:
SARコマンドのメッセージ形式は次のとおりです。
<SAR> ::= < Diameter Header: 284, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-Server-Assignment-Type }
{ SIP-User-Data-Already-Available }
[ Destination-Host ]
[ User-Name ]
[ SIP-Server-URI ]
* [ SIP-Supported-User-Data-Type ]
* [ SIP-AOR ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Server-Assignment-Answer (SAA) is indicated by the Command-Code set to 284 and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter Server-Assignment-Request (SAR) command. The response may include the user profile or part of it, if requested.
Server-Assignment-Answer（SAA）は、コマンドコードが284に設定され、コマンドフラグの「R」ビットがクリアされることで示されます。 Diameterサーバーは、以前に受信したDiameterサーバー割り当て要求（SAR）コマンドへの応答としてこのコマンドを送信します。要求には、ユーザープロファイルまたはその一部が含まれます。
In addition to the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1.
RFC 3588 [RFC3588]ですでに定義されている値に加えて、Result-Code AVPにはセクション10.1で定義されている値の1つが含まれる場合があります。
The Result-Code AVP value in the Diameter SAA message may indicate a success or an error in the execution of the Diameter SAR command. If Result-Code AVP value in the Diameter SAA message does not contain an error code, the SAA message MAY include one or more SIP-User-Data AVPs that typically contain the profile of the user, indicating services that the SIP server can provide to that user.
Diameter SAAメッセージのResult-Code AVP値は、Diameter SARコマンドの実行の成功またはエラーを示している場合があります。 Diameter SAAメッセージのResult-Code AVP値にエラーコードが含まれていない場合、SAAメッセージには、通常、ユーザーのプロファイルを含む1つ以上のSIP-User-Data AVPが含まれる場合があり、SIPサーバーが提供できるサービスを示します。そのユーザー。
The Diameter server MAY include one or more SIP-Supported-User-Data-Type AVPs, each one identifying a type of user data format supported in the Diameter server. If there is not a common supported user data type between the Diameter client and the Diameter server, the Diameter server SHOULD declare its list of supported user data types by including one or more SIP-Supported-User-Data-Type AVPs in a Diameter SAA message. This indication is merely for debugging reasons, since there is not a fallback mechanism that allows the Diameter client to retrieve the profile in a supported format.
Diameterサーバーには、1つ以上のSIP-Supported-User-Data-Type AVPが含まれる場合があり、それぞれがDiameterサーバーでサポートされるユーザーデータ形式のタイプを識別します。 DiameterクライアントとDiameterサーバーの間に共通のサポートされるユーザーデータタイプがない場合、Diameterサーバーは、Diameter SAAに1つ以上のSIP-Supported-User-Data-Type AVPを含めることにより、サポートされるユーザーデータタイプのリストを宣言する必要があります（SHOULD）。メッセージ。 Diameterクライアントがサポートされている形式でプロファイルを取得できるようにするフォールバックメカニズムがないため、この表示は単にデバッグ上の理由によるものです。
If the Diameter server requires a User-Name AVP value to process the Diameter SAR request, but the Diameter SAR message did not contain a User-Name AVP value, the Diameter server MUST set the Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return it in a Diameter SAA message. Upon reception of this Diameter SAA message with the Result-Code AVP value set to DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests authentication by generating a SIP 401 (Unauthorized) or SIP 407 (Proxy Authentication Required) response back to the originator.
DiameterサーバーがDiameter SARリクエストを処理するためにUser-Name AVP値を必要とするが、Diameter SARメッセージにUser-Name AVP値が含まれていない場合、DiameterサーバーはResult-Code AVP値をDIAMETER_USER_NAME_REQUIREDに設定する必要があります（セクション10.1を参照） .2）そしてそれをDiameter SAAメッセージで返します。 Result-Code AVP値がDIAMETER_USER_NAME_REQUIREDに設定されたこのDiameter SAAメッセージを受信すると、SIPサーバーは通常、発信者にSIP 401（無許可）またはSIP 407（プロキシ認証が必要）応答を生成して認証を要求します。
If the User-Name AVP is included in the Diameter SAR message, upon reception of the Diameter SAR message, the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter Server-Assignment-Answer (SAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN.
Diameter SARメッセージにUser-Name AVPが含まれている場合、Diameter SARメッセージを受信すると、Diameterサーバーはレルム内のユーザーの存在を確認する必要があります。つまり、User-Name AVP値はその範囲内の有効なユーザーです。レルム。 DiameterサーバーがUser-Name AVPで受信したユーザー名を認識しない場合、DiameterサーバーはDiameter Server-Assignment-Answer（SAA）メッセージを作成し、Result-Code AVPをDIAMETER_ERROR_USER_UNKNOWNに設定する必要があります。
Then the Diameter server MUST authorize that User-Name AVP value is a valid authentication name for the SIP or SIPS URI included in the SIP-AOR AVP of the Diameter SAR message. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter Server-Assignment-Answer (SAA) message.
次に、Diameterサーバーは、User-Name AVP値がDiameter SARメッセージのSIP-AOR AVPに含まれるSIPまたはSIPS URIの有効な認証名であることを承認する必要があります。この認証が失敗した場合、DiameterサーバーはResult-Code AVPをDIAMETER_ERROR_IDENTITIES_DONT_MATCHに設定し、Diameter Server-Assignment-Answer（SAA）メッセージで送信する必要があります。
After successful execution of the Diameter SAR command, the Diameter server MUST clear the "authentication pending" flag and SHOULD move the temporarily stored SIP server URI to permanent storage.
Diameter SARコマンドが正常に実行された後、Diameterサーバーは「認証保留」フラグをクリアする必要があり、一時的に保存されたSIPサーバーURIを永続的なストレージに移動する必要があります（SHOULD）。
The actions of the Diameter server upon reception of the Diameter SAR message depend on the value of the SIP-Server-Assignment-Type:
Diameter SARメッセージの受信時のDiameterサーバーのアクションは、SIP-Server-Assignment-Typeの値によって異なります。
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to REGISTRATION or RE_REGISTRATION, the Diameter server SHOULD verify that there is only one SIP-AOR AVP. Otherwise, the Diameter server MUST answer with a Diameter SAA message with the Result-Code AVP value set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP-User-Data AVP. If there is only one SIP-AOR AVP and if the SIP-User-Data-Already-Available AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include one or more user profile data with the SIP or SIPS URI (SIP-AOR AVP) and all other SIP identities associated with that AVP in the SIP-User-Data AVP value of the Diameter SAA message. On selecting the type of user data, the Diameter server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP in the SAR message) and the local policy. Additionally, the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter server considers the SIP AOR authenticated and registered.
o Diameter SARメッセージのSIP-Server-Assignment-Type AVP値がREGISTRATIONまたはRE_REGISTRATIONに設定されている場合、Diameterサーバーは、SIP-AOR AVPが1つだけであることを確認する必要があります（SHOULD）。それ以外の場合、Diameterサーバーは、Result-Code AVP値がDIAMETER_AVP_OCCURS_TOO_MANY_TIMESに設定されたDiameter SAAメッセージで応答する必要があり、SIP-User-Data AVPを含めてはなりません（MUST NOT）。 SIP-AOR AVPが1つだけあり、SIP-User-Data-Already-Available AVP値がUSER_DATA_NOT_AVAILABLEに設定されている場合、Diameterサーバーは、SIPまたはSIPS URI（SIP-AOR AVP）およびDiameter SAAメッセージのSIP-User-Data AVP値でそのAVPに関連付けられている他のすべてのSIP ID。 Diameterサーバーは、ユーザーデータのタイプを選択する際に、SIPサーバーでサポートされている形式（SARメッセージのSIP-Supported-User-Data-Type AVP）とローカルポリシーを考慮する必要があります（SHOULD）。さらに、Diameterサーバーは、Diameter SAAメッセージでResult-Code AVP値をDIAMETER_SUCCESSに設定する必要があります。 Diameterサーバーは、SIP AORが認証および登録されていると見なします。
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to UNREGISTERED_USER, then the Diameter server MUST store the SIP server address included in the SIP-Server-URI AVP value. The Diameter server will return the SIP server address in Diameter Location-Info-Answer (LIA) messages. If the SIP-User-Data-Already-Available AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include one or more user profile data associated with the SIP or SIPS URI (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP value of the Diameter SAA message. On selecting the type of user data, the Diameter server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP in the SAR message) and the local policy. The Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS. The Diameter server considers the SIP AOR UNREGISTERED, but with a SIP server allocated to trigger and provide services for unregistered users. Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type AVP), the Diameter server MUST verify that there is only one SIP-AOR AVP. Otherwise, the Diameter server MUST answer the Diameter SAR message with a Diameter SAA message, and it MUST set the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP-User-Data AVP. If the User-Name AVP was not present in the Diameter SAR message and the SIP-AOR is not known for the Diameter server, the Diameter server MUST NOT include a User-Name AVP in the Diameter SAA message and MUST set the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN.
o Diameter SARメッセージのSIP-Server-Assignment-Type AVP値がUNREGISTERED_USERに設定されている場合、DiameterサーバーはSIP-Server-URI AVP値に含まれるSIPサーバーアドレスを格納する必要があります。 Diameterサーバーは、Diameter Location-Info-Answer（LIA）メッセージでSIPサーバーアドレスを返します。 SIP-User-Data-Already-Available AVP値がUSER_DATA_NOT_AVAILABLEに設定されている場合、Diameterサーバーは、SIPまたはSIPS URI（SIP-AOR AVP）に関連付けられた1つ以上のユーザープロファイルデータと、SIP- Diameter SAAメッセージのUser-Data AVP値。 Diameterサーバーは、ユーザーデータのタイプを選択する際に、SIPサーバーでサポートされている形式（SARメッセージのSIP-Supported-User-Data-Type AVP）とローカルポリシーを考慮する必要があります（SHOULD）。 Diameterサーバーは、Result-Code AVP値をDIAMETER_SUCCESSに設定する必要があります。 DiameterサーバーはSIP AOR UNREGISTEREDを考慮しますが、未登録のユーザーにサービスをトリガーおよび提供するためにSIPサーバーが割り当てられています。 UNREGISTERED_USER（SIP-Server-Assignment-Type AVP）の場合、DiameterサーバーはSIP-AOR AVPが1つだけであることを確認する必要があることに注意してください。それ以外の場合、DiameterサーバーはDiameter SAAメッセージでDiameter SARメッセージに応答する必要があり、結果コードAVP値をDIAMETER_AVP_OCCURS_TOO_MANY_TIMESに設定する必要があり、SIP-User-Data AVPを含めることはできません。 Diameter SARメッセージにユーザー名AVPが存在せず、DiameterサーバーでSIP-AORが認識されていない場合、DiameterサーバーはDiameter SAAメッセージにユーザー名AVPを含めてはならず（MUST NOT）、結果コードを設定する必要がありますDIAMETER_ERROR_USER_UNKNOWNに対するAVP値。
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA, or ADMINISTRATIVE_DEREGISTRATION, the Diameter server MUST clear the SIP server address associated with all SIP AORs indicated in each of the SIP-AOR AVP values included in the Diameter SAR message. The Diameter server considers all of these SIP AORs as not registered. The Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message.
o Diameter SARメッセージのSIP-Server-Assignment-Type AVP値がTIMEOUT_DEREGISTRATION、USER_DEREGISTRATION、DEREGISTRATION_TOO_MUCH_DATA、またはADMINISTRATIVE_DEREGISTRATIONに設定されている場合、Diameterサーバーは、SIP-AORのそれぞれに示されているすべてのSIP AORに関連付けられているSIPサーバーアドレスをクリアする必要がありますDiameter SARメッセージに含まれるAVP値。 Diameterサーバーは、これらのSIP AORをすべて登録されていないと見なします。 Diameterサーバーは、Diameter SAAメッセージでResult-Code AVP値をDIAMETER_SUCCESSに設定する必要があります。
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or USER_DEREGISTRATION_STORE_SERVER_NAME, the Diameter server MAY keep the SIP server address associated with the SIP AORs included in the SIP-AOR AVP values of the Diameter SAR message, even though the SIP AORs become unregistered. This feature allows a SIP server to request that the Diameter server remain an assigned SIP server for those SIP AORs (SIP-AOR AVP values) allocated to the same user name, and avoid SIP server assignment. The Diameter server MUST consider all these SIP AORs as not registered. If the Diameter server honors the request of the Diameter client (SIP server) to remain as an allocated SIP server, then the Diameter server MUST keep the SIP server assigned to those SIP AORs allocated to the username and MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, when the Diameter server does not honor the request of the Diameter client (SIP server) to remain as an allocated SIP server, the Diameter server MUST clear the SIP server name assigned to those SIP AORs and it MUST set the Result-Code AVP value to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter SAA message.
o Diameter SARメッセージのSIP-Server-Assignment-Type AVP値がTIMEOUT_DEREGISTRATION_STORE_SERVER_NAMEまたはUSER_DEREGISTRATION_STORE_SERVER_NAMEに設定されている場合、Diameterサーバーは、Diameter SARメッセージのSIP-AOR AVP値に含まれているSIP AORに関連付けられたSIPサーバーアドレスを保持できます。 、SIP AORは未登録になります。この機能により、SIPサーバーは、Diameterサーバーが同じユーザー名に割り当てられたSIP AOR（SIP-AOR AVP値）に割り当てられたSIPサーバーであり続けることを要求し、SIPサーバーの割り当てを回避できます。 Diameterサーバーは、これらすべてのSIP AORが登録されていないと見なす必要があります。 DiameterサーバーがDiameterクライアント（SIPサーバー）のリクエストを受け入れて、割り当てられたSIPサーバーとして残る場合、Diameterサーバーは、ユーザー名に割り当てられたSIP AORに割り当てられたSIPサーバーを維持しなければならず、結果コードAVP値を設定しなければなりません（MUST）。 Diameter SAAメッセージのDIAMETER_SUCCESSに。それ以外の場合、Diameterサーバーは、Diameterクライアント（SIPサーバー）のリクエストを、割り当てられたSIPサーバーとして残ることを認めない場合、それらのSIP AORに割り当てられたSIPサーバー名をクリアし、結果コードAVPを設定する必要があります。 Diameter SAAメッセージのDIAMETER_SUCCESS_SERVER_NAME_NOT_STOREDの値。
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to NO_ASSIGNMENT, the Diameter server SHOULD first verify that the SIP-Server-URI AVP value in the Diameter SAR message is the same URI as the one assigned to the SIP-AOR AVP value. If they differ, then the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter SAA message. Otherwise, if the SIP-User-Data-Already-Available AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include the user profile data with the SIP or SIPS URI (SIP-AOR AVP) and all other SIP identities associated with that AVP in the SIP-User-Data AVP value of the Diameter SAA message. On selecting the type of user data, the Diameter server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP in the SAR message) and the local policy.
o Diameter SARメッセージのSIP-Server-Assignment-Type AVP値がNO_ASSIGNMENTに設定されている場合、Diameterサーバーは最初に、Diameter SARメッセージのSIP-Server-URI AVP値が割り当てられたURIと同じであることを確認する必要があります（SHOULD）。 SIP-AOR AVP値。それらが異なる場合、Diameterサーバーは、Diameter SAAメッセージでResult-Code AVP値をDIAMETER_UNABLE_TO_COMPLYに設定する必要があります。それ以外の場合、SIP-User-Data-Already-Available AVP値がUSER_DATA_NOT_AVAILABLEに設定されている場合、Diameterサーバーは、SIPまたはSIPS URI（SIP-AOR AVP）とそれに関連付けられた他のすべてのSIP IDを含むユーザープロファイルデータを含める必要があります（SHOULD）。 Diameter SAAメッセージのSIP-User-Data AVP値のAVP。ユーザーデータのタイプを選択する際、Diameterサーバーは、SIPサーバーでサポートされている形式（SARメッセージのSIP-Supported-User-Data-Type AVP）とローカルポリシーを考慮する必要があります（SHOULD）。
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there is exactly one SIP-AOR AVP in the Diameter SAR message. If the number of occurrences of the SIP-AOR AVP is not exactly one, the Diameter server MUST set the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message, and SHOULD not take further actions. If there is exactly one SIP-AOR AVP in the Diameter SAR message, the Diameter server MUST clear the address of the SIP server assigned to the SIP AOR allocated to the user name, and the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter server MUST consider the SIP AOR as not registered.
o Diameter SARメッセージのSIP-Server-Assignment-Type AVP値がAUTHENTICATION_FAILUREまたはAUTHENTICATION_TIMEOUTに設定されている場合、Diameterサーバーは、Diameter SARメッセージに正確に1つのSIP-AOR AVPがあることを確認する必要があります。 SIP-AOR AVPの発生回数が正確に1でない場合、Diameterサーバーは、Diameter SAAメッセージでResult-Code AVP値をDIAMETER_AVP_OCCURS_TOO_MANY_TIMESに設定する必要があり、それ以上のアクションは行わないでください（SHOULD）。 Diameter SARメッセージにSIP-AOR AVPが1つしかない場合、Diameterサーバーはユーザー名に割り当てられたSIP AORに割り当てられたSIPサーバーのアドレスをクリアする必要があり、DiameterサーバーはResult-Code AVP値をDiameter SAAメッセージのDIAMETER_SUCCESS。 DiameterサーバーはSIP AORが登録されていないと見なす必要があります。
The Message Format of the SAA command is as follows:
SAAコマンドのメッセージ形式は次のとおりです。
<SAA> ::= < Diameter Header: 284, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
* [ SIP-User-Data ]
[ SIP-Accounting-Information ]
* [ SIP-Supported-User-Data-Type ]
[ User-Name ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ]
[Redirect-Max-Cache-Time] * [Proxy-Info] * [Route-Record] * [AVP]
The Location-Info-Request (LIR) is indicated by the Command-Code set to 285 and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server to request routing information, e.g., the URI of the SIP server assigned to the SIP-AOR AVP value allocated to the users.
Location-Info-Request（LIR）は、コマンドコードが285に設定され、コマンドフラグの「R」ビットが設定されていることで示されます。 SIPサーバーのDiameterクライアントは、このコマンドをDiameterサーバーに送信して、ユーザーに割り当てられたSIP-AOR AVP値に割り当てられたSIPサーバーのURIなどのルーティング情報を要求します。
The Message Format of the LIR command is as follows:
LIRコマンドのメッセージ形式は次のとおりです。
<LIR> ::= < Diameter Header: 285, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-AOR }
[ Destination-Host ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Location-Info-Answer (LIA) is indicated by the Command-Code set to 285 and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter Location-Info-Request (LIR) command.
Location-Info-Answer（LIA）は、コマンドコードが285に設定され、コマンドフラグの「R」ビットがクリアされることで示されます。 Diameterサーバーは、以前に受信したDiameter位置情報要求（LIR）コマンドに応答してこのコマンドを送信します。
In addition to the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1. When the Diameter server finds an error in processing the Diameter LIR message, the Diameter server MUST stop the process of the message and answer with a Diameter LIA message that includes the appropriate error code in the Result-Code AVP value. When there is no error, the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter LIA message.
RFC 3588 [RFC3588]ですでに定義されている値に加えて、Result-Code AVPにはセクション10.1で定義されている値の1つが含まれる場合があります。 Diameterサーバーは、Diameter LIRメッセージの処理中にエラーを検出すると、メッセージのプロセスを停止し、Result-Code AVP値に適切なエラーコードを含むDiameter LIAメッセージで応答する必要があります。エラーがない場合、Diameterサーバーは、Diameter LIAメッセージでResult-Code AVP値をDIAMETER_SUCCESSに設定する必要があります。
One of the errors that the Diameter server may find is that the SIP-AOR AVP value is not a valid user in the realm. In such cases, the Diameter server MUST set the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message.
Diameterサーバーが検出する可能性のあるエラーの1つは、SIP-AOR AVP値がレルム内の有効なユーザーではないことです。このような場合、DiameterサーバーはResult-Code AVP値をDIAMETER_ERROR_USER_UNKNOWNに設定し、Diameter LIAメッセージで返す必要があります。
If the Diameter server cannot process the Diameter LIR command, e.g., due to a database error, the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter LIA message. The Diameter server MUST NOT include any SIP-Server-URI or SIP-Server-Capabilities AVP in the Diameter LIA message.
データベースエラーなどが原因で、DiameterサーバーがDiameter LIRコマンドを処理できない場合、DiameterサーバーはResult-Code AVP値をDIAMETER_UNABLE_TO_COMPLYに設定し、Diameter LIAメッセージで返す必要があります。 Diameterサーバーは、Diameter LIAメッセージにSIP-Server-URIまたはSIP-Server-Capabilities AVPを含めてはなりません（MUST NOT）。
The Diameter server may or may not be aware of a SIP server assigned to the SIP-AOR AVP value included in the Diameter LIR message. If the Diameter server is aware of a SIP server allocated to that particular user, the Diameter server MUST include the URI of such SIP server in the SIP-Server-URI AVP and return it in a Diameter LIA message. This is typically the situation when the user is either registered, or unregistered but a SIP server is still assigned to the user.
Diameterサーバーは、Diameter LIRメッセージに含まれるSIP-AOR AVP値に割り当てられたSIPサーバーを認識している場合と認識していない場合があります。 Diameterサーバーが特定のユーザーに割り当てられたSIPサーバーを認識している場合、DiameterサーバーはそのようなSIPサーバーのURIをSIP-Server-URI AVPに含めて、Diameter LIAメッセージで返す必要があります。これは通常、ユーザーが登録されているか、登録されていないが、SIPサーバーがまだユーザーに割り当てられている状況です。
When the Diameter server is not aware of a SIP server allocated to the user (typically the case when the user unregistered), the Result-Code AVP value in the Diameter LIA message depends on whether the Diameter server is aware that the user has services defined for unregistered users:
Diameterサーバーがユーザーに割り当てられたSIPサーバーを認識しない場合（通常、ユーザーが登録解除された場合）、Diameter LIAメッセージのResult-Code AVP値は、Diameterサーバーがユーザーにサービスが定義されていることを認識しているかどうかによって異なります未登録ユーザーの場合：
o Those users who have services defined for unregistered users may require the allocation of a SIP server to trigger and perhaps execute those services. Therefore, when the Diameter server is not aware of an assigned SIP server, but the user has services defined for unregistered users, the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return it in a Diameter LIA message. The Diameter server MAY also include a SIP-Server-Capabilities AVP to facilitate the SIP server (Diameter client) with the selection of an appropriate SIP server with the required capabilities. Absence of the SIP-Server-Capabilities AVP indicates to the SIP server (Diameter client) that any SIP server is suitable to be allocated for the user.
o 未登録のユーザーに対してサービスが定義されているユーザーは、それらのサービスをトリガーして実行するためにSIPサーバーの割り当てが必要になる場合があります。したがって、Diameterサーバーは割り当てられたSIPサーバーを認識していないが、ユーザーが未登録ユーザー用に定義されたサービスを持っている場合、DiameterサーバーはResult-Code AVP値をDIAMETER_UNREGISTERED_SERVICEに設定して、Diameter LIAメッセージで返す必要があります。 Diameterサーバーには、SIPサーバー（Diameterクライアント）が必要な機能を持つ適切なSIPサーバーを選択できるようにするSIP-Server-Capabilities AVPも含まれている場合があります（MAY）。 SIPサーバー機能の欠如AVPは、任意のSIPサーバーがユーザーに割り当てるのに適していることをSIPサーバー（Diameterクライアント）に示します。
o Those users who do not have service defined for unregistered users do not require further processing. The Diameter server MUST set the Result-Code AVP value to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the Diameter client in a Diameter LIA message. The SIP server (Diameter client) may return the appropriate SIP response (e.g., 480 (Temporarily unavailable)) to the original SIP request.
o 未登録のユーザーに対してサービスが定義されていないユーザーは、さらに処理する必要はありません。 Diameterサーバーは、Result-Code AVP値をDIAMETER_ERROR_IDENTITY_NOT_REGISTEREDに設定し、Diameter LIAメッセージでDiameterクライアントに返す必要があります。 SIPサーバー（Diameterクライアント）は、適切なSIP応答（たとえば、480（一時的に利用不可））を元のSIP要求に返します。
The Message Format of the LIA command is as follows:
LIAコマンドのメッセージ形式は次のとおりです。
<LIA> ::= < Diameter Header: 285, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-URI ]
[ SIP-Server-Capabilities ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Multimedia-Auth-Request (MAR) command is indicated by the Command-Code set to 286 and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server to request that the Diameter server authenticate and authorize a user attempt to use some SIP service (in this context, SIP service can be something as simple as a SIP subscription or using the proxy services for a SIP request).
Multimedia-Auth-Request（MAR）コマンドは、コマンドコードが286に設定され、コマンドフラグの「R」ビットが設定されていることで示されます。 SIPサーバーのDiameterクライアントは、このコマンドをDiameterサーバーに送信して、Diameterサーバーがユーザーに何らかのSIPサービスの使用を認証および承認することを要求します（このコンテキストでは、SIPサービスは、SIPサブスクリプションのような単純なものでも、 SIPリクエストのプロキシサービス）。
The MAR command may also register the SIP server's own URI to the Diameter server, so that future LIR/LIA messages can return this URI. If the SIP server is acting as a SIP registrar (see examples in Sections 6.2 and 6.3), its Diameter client MUST include a SIP-Server-URI AVP in the MAR command. In any other cases (see example in Section 6.4), its Diameter client MUST NOT include a SIP-Server-URI AVP in the MAR command.
MARコマンドは、SIPサーバーの独自のURIをDiameterサーバーに登録することもできるため、将来のLIR / LIAメッセージがこのURIを返すことができます。 SIPサーバーがSIPレジストラーとして機能している場合（セクション6.2および6.3の例を参照）、そのDiameterクライアントはMARコマンドにSIP-Server-URI AVPを含める必要があります。その他の場合（6.4項の例を参照）、そのDiameterクライアントはMARコマンドにSIP-Server-URI AVPを含めてはなりません（MUST NOT）。
The SIP-Method AVP MUST include the SIP method name of the SIP request that triggered this Diameter MAR message. The Diameter server can use this AVP to authorize some SIP requests depending on the method.
SIPメソッドAVPには、このDiameter MARメッセージをトリガーしたSIPリクエストのSIPメソッド名を含める必要があります。 Diameterサーバーは、このAVPを使用して、メソッドに応じて一部のSIPリクエストを承認できます。
The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP indicates the target of the SIP request. The value of the AVP is extracted from different places in SIP request, depending on the semantics of the SIP request. For SIP REGISTER messages the SIP-AOR AVP value indicates the intended public user identity under registration, and it is the SIP or SIPS URI populated in the To header field value (addr-spec as per RFC 3261 [RFC3261]) of the SIP REGISTER request. For other types of SIP requests, such as INVITE, SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the intended destination of the request. This is typically populated in the Request-URI of the SIP request. Extracting the SIP-AOR AVP value from the proper SIP header field is the Diameter client's responsibility. Extensions to SIP (new SIP methods or new semantics) may require the SIP-AOR to be extracted from other parts of the request.
Diameter MARメッセージにはSIP-AOR AVPを含める必要があります。 SIP-AOR AVPは、SIPリクエストのターゲットを示します。 AVPの値は、SIP要求のセマンティクスに応じて、SIP要求のさまざまな場所から抽出されます。 SIP REGISTERメッセージの場合、SIP-AOR AVP値は、登録時に意図されたパブリックユーザーIDを示し、SIP REGISTERのToヘッダーフィールド値（RFC 3261 [RFC3261]に従ってaddr-spec）に入力されたSIPまたはSIPS URIです。リクエスト。 INVITE、SUBSCRIBE、MESSAGEなどの他のタイプのSIPリクエストの場合、SIP-AOR AVP値はリクエストの目的の宛先を示します。これは通常、SIP要求のRequest-URIに入力されます。適切なSIPヘッダーフィールドからSIP-AOR AVP値を抽出することは、Diameterクライアントの責任です。 SIPの拡張（新しいSIPメソッドまたは新しいセマンティクス）では、リクエストの他の部分からSIP-AORを抽出する必要がある場合があります。
If the SIP request includes some sort of authentication information, the Diameter client MUST include the user name, extracted from the authentication information of the SIP request, in the User-Name AVP value.
SIP要求に何らかの認証情報が含まれている場合、Diameterクライアントは、SIP要求の認証情報から抽出されたユーザー名をユーザー名AVP値に含める必要があります。
The Message Format of the MAR command is as follows:
MARコマンドのメッセージフォーマットは次のとおりです。
<MAR> ::= < Diameter Header: 286, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-AOR }
{ SIP-Method }
[ Destination-Host ]
[ User-Name ]
[ SIP-Server-URI ]
[ SIP-Number-Auth-Items ]
[ SIP-Auth-Data-Item ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set to 286 and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter Multimedia-Auth-Request (MAR) command.
Multimedia-Auth-Answer（MAA）は、コマンドコードが286に設定され、コマンドフラグの「R」ビットがクリアされることで示されます。 Diameterサーバーは、以前に受信したDiameter Multimedia-Auth-Request（MAR）コマンドに応答してこのコマンドを送信します。
In addition to the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1.
RFC 3588 [RFC3588]ですでに定義されている値に加えて、Result-Code AVPにはセクション10.1で定義されている値の1つが含まれる場合があります。
If the Diameter server requires a User-Name AVP value to process the Diameter MAR request, but the Diameter MAR message did not contain a User-Name AVP value, the Diameter server MUST set the Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return it in a Diameter MAA message. The Diameter server MAY include a SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs with authentication information (e.g., a challenge). Upon reception of this Diameter MAA message with the Result-Code AVP value set to DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests authentication by generating a SIP 401 (Unauthorized) or SIP 407 (Proxy Authentication Required) response back to the originator.
DiameterサーバーがDiameter MARリクエストを処理するためにUser-Name AVP値を必要とするが、Diameter MARメッセージにUser-Name AVP値が含まれていない場合、DiameterサーバーはResult-Code AVP値をDIAMETER_USER_NAME_REQUIREDに設定する必要があります（セクション10.1を参照）。 .2）そしてそれをDiameter MAAメッセージで返します。 Diameterサーバーには、SIP-Number-Auth-Items AVPと、認証情報（チャレンジなど）を含む1つ以上のSIP-Auth-Data-Item AVPが含まれる場合があります。 Result-Code AVP値がDIAMETER_USER_NAME_REQUIREDに設定されたこのDiameter MAAメッセージを受信すると、SIPサーバーは通常、発信者にSIP 401（無許可）またはSIP 407（プロキシ認証が必要）応答を生成して認証を要求します。
If the User-Name AVP is present in the Diameter MAR message, the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter Multimedia-Auth-Answer (MAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN.
ユーザー名AVPがDiameter MARメッセージに存在する場合、Diameterサーバーはレルム内のユーザーの存在を確認する必要があります。つまり、ユーザー名AVP値はそのレルム内の有効なユーザーです。 DiameterサーバーがUser-Name AVPで受信したユーザー名を認識しない場合、DiameterサーバーはDiameter Multimedia-Auth-Answer（MAA）メッセージを作成し、Result-Code AVPをDIAMETER_ERROR_USER_UNKNOWNに設定する必要があります。
If the SIP-Methods AVP value of the Diameter MAR message is set to REGISTER and a User-Name AVP is present, then the Diameter server MUST authorize that User-Name AVP value is able to use the URI included in the SIP-AOR AVP. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter Multimedia-Auth-Answer (MAA) message.
Diameter MARメッセージのSIPメソッドAVP値がREGISTERに設定され、ユーザー名AVPが存在する場合、Diameterサーバーは、ユーザー名AVP値がSIP-AOR AVPに含まれるURIを使用できることを承認する必要があります。 。この認証が失敗した場合、DiameterサーバーはResult-Code AVPをDIAMETER_ERROR_IDENTITIES_DONT_MATCHに設定し、Diameter Multimedia-Auth-Answer（MAA）メッセージで送信する必要があります。
Note: Correlation between User-Name and SIP-AOR AVP values is only required for SIP REGISTER request, to prevent a user from registering a SIP-AOR allocated to another user. In other types of SIP requests (e.g., INVITE), the SIP-AOR indicates the intended destination of the request, rather than the originator of it.
注：ユーザー名とSIP-AOR AVP値の相関は、ユーザーが別のユーザーに割り当てられたSIP-AORを登録できないようにするために、SIP REGISTER要求でのみ必要です。他のタイプのSIPリクエスト（INVITEなど）では、SIP-AORはリクエストの発信者ではなく、リクエストの目的の宛先を示します。
The Diameter server MUST verify whether the authentication scheme (SIP-Authentication-Scheme AVP value) indicated in the grouped SIP-Auth-Data-Item AVP is supported or not. If that authentication scheme is not supported, then the Diameter server MUST set the Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send it in a Diameter Multimedia-Auth-Answer (MAA) message.
Diameterサーバーは、グループ化されたSIP-Auth-Data-Item AVPに示されている認証スキーム（SIP-Authentication-Scheme AVP値）がサポートされているかどうかを検証する必要があります。その認証方式がサポートされていない場合、DiameterサーバーはResult-Code AVPをDIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTEDに設定し、Diameter Multimedia-Auth-Answer（MAA）メッセージで送信する必要があります。
If the SIP-Number-Auth-Items AVP is present in the Diameter MAR message, it indicates the number of authentication data items that the Diameter client is requesting. It is RECOMMENDED that the Diameter server, when building the Diameter MAA message, includes a number of SIP-Auth-Data-Item AVPs that are a subset of the authentication data items requested by the Diameter client in the SIP-Number-Auth-Items AVP value of the Diameter MAR message.
SIP-Number-Auth-Items AVPがDiameter MARメッセージに存在する場合、Diameterクライアントが要求している認証データアイテムの数を示します。 Diameterサーバーが、Diameter MAAメッセージを作成するときに、DiameterクライアントがSIP-Number-Auth-Itemsで要求する認証データアイテムのサブセットであるSIP-Auth-Data-Item AVPの数を含めることをお勧めします。 Diameter MARメッセージのAVP値。
If the SIP-Server-URI AVP is present in the Diameter MAR message, then the Diameter server MUST compare the stored SIP server (assigned to the user) with the SIP-Server-URI AVP value (received in the Diameter MAR message). If they don't match, the Diameter server MUST temporarily save the newly received SIP server assigned to the user, and MUST set an "authentication pending" flag for the user. If they match, the Diameter server shall clear the "authentication pending" flag for the user.
SIP-Server-URI AVPがDiameter MARメッセージに存在する場合、Diameterサーバーは（ユーザーに割り当てられた）保存されたSIPサーバーを（Diameter MARメッセージで受信された）SIP-Server-URI AVP値と比較する必要があります。それらが一致しない場合、Diameterサーバーは、ユーザーに割り当てられた、新しく受信したSIPサーバーを一時的に保存する必要があり、ユーザーに「認証保留」フラグを設定する必要があります。それらが一致する場合、Diameterサーバーはユーザーの「認証保留」フラグをクリアします。
In any other situation, if there is a success in processing the Diameter MAR command and the Diameter server stored the SIP-Server-URI, the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS and return it in a Diameter MAA message.
その他の状況では、Diameter MARコマンドの処理が成功し、DiameterサーバーがSIP-Server-URIを格納している場合、DiameterサーバーはResult-Code AVP値をDIAMETER_SUCCESSに設定して、Diameter MAAメッセージで返す必要があります。
If there is a success in processing the Diameter MAR command, but the Diameter server does not store the SIP-Server-URI because the AVP was not present in the Diameter MAR command, then the Diameter server MUST set the Result-Code AVP value to either:
Diameter MARコマンドの処理は成功したが、AVPがDiameter MARコマンドに存在しなかったためにDiameterサーバーがSIP-Server-URIを格納しない場合、DiameterサーバーはResult-Code AVP値をどちらか：
1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter server is sending authentication credentials to create a challenge.
1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED（Diameterサーバーが認証資格情報を送信してチャレンジを作成する場合）。
2. DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED, if the Diameter server successfully authenticated the user and authorized the SIP server to proceed with the SIP request.
2. DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED（Diameterサーバーがユーザーの認証に成功し、SIPサーバーがSIP要求を続行することを承認した場合）。
Otherwise, the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY, and it MUST NOT include any SIP-Auth-Data-Item AVP.
それ以外の場合、DiameterサーバーはResult-Code AVP値をDIAMETER_UNABLE_TO_COMPLYに設定する必要があり、SIP-Auth-Data-Item AVPを含めることはできません。
The Message Format of the MAA command is as follows:
MAAコマンドのメッセージ形式は次のとおりです。
<MAA> ::= < Diameter Header: 286, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ SIP-AOR ]
[ SIP-Number-Auth-Items ]
* [ SIP-Auth-Data-Item ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Registration-Termination-Request (RTR) command is indicated by the Command-Code set to 287 and the Command Flags' 'R' bit set. The Diameter server sends this command to the Diameter client in a SIP server to indicate to the SIP server that one or more SIP AORs have to be deregistered. The command allows an operator to administratively cancel the registration of a user from a centralized Diameter server.
Registration-Termination-Request（RTR）コマンドは、Command-Codeが287に設定され、コマンドフラグの 'R'ビットが設定されていることで示されます。 Diameterサーバーは、このコマンドをSIPサーバーのDiameterクライアントに送信して、1つ以上のSIP AORを登録解除する必要があることをSIPサーバーに示します。このコマンドを使用すると、オペレーターは中央のDiameterサーバーからユーザーの登録を管理上キャンセルできます。
The Diameter server has the capability to initiate the deregistration of a user and inform the SIP server by means of the Diameter RTR command. The Diameter server can decide whether only one SIP AOR is going to be deregistered, a list of SIP AORs, or all the SIP AORs allocated to the user.
Diameterサーバーには、ユーザーの登録解除を開始し、Diameter RTRコマンドを使用してSIPサーバーに通知する機能があります。 Diameterサーバーは、SIP AORを1つだけ登録解除するか、SIP AORのリストを登録するか、またはユーザーに割り当てられたすべてのSIP AORを登録するかを決定できます。
The absence of a SIP-AOR AVP in the Diameter RTR message indicates that all the SIP AORs allocated to the user identified by the User-Name AVP are being deregistered.
Diameter RTRメッセージにSIP-AOR AVPがないことは、User-Name AVPによって識別されるユーザーに割り当てられているすべてのSIP AORが登録解除されていることを示します。
The Diameter server MUST include a SIP-Deregistration-Reason AVP value to indicate the reason for the deregistration.
Diameterサーバーには、登録解除の理由を示すSIP-Deregistration-Reason AVP値を含める必要があります。
The Message Format of the RTR command is as follows:
RTRコマンドのメッセージ形式は次のとおりです。
<RTR> ::= < Diameter Header: 287, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ SIP-Deregistration-Reason }
[ Destination-Realm ]
[ User-Name ]
* [ SIP-AOR ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Registration-Termination-Answer (RTA) is indicated by the Command-Code set to 287 and the Command Flags' 'R' bit cleared. The Diameter client sends this command in response to a previously received Diameter Registration-Termination-Request (RTR) command.
Registration-Termination-Answer（RTA）は、コマンドコードが287に設定され、コマンドフラグの「R」ビットがクリアされていることで示されます。 Diameterクライアントは、以前に受信したDiameter Registration-Termination-Request（RTR）コマンドに応答してこのコマンドを送信します。
In addition to the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1.
RFC 3588 [RFC3588]ですでに定義されている値に加えて、Result-Code AVPにはセクション10.1で定義されている値の1つが含まれる場合があります。
If the SIP server (Diameter client) requires a User-Name AVP value to process the Diameter RTR request, but the Diameter RTR message did not contain a User-Name AVP value, the Diameter client MUST set the Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return it in a Diameter RTA message.
SIPサーバー（Diameterクライアント）がDiameter RTR要求を処理するためにユーザー名AVP値を必要とするが、Diameter RTRメッセージにユーザー名AVP値が含まれていない場合、Diameterクライアントは結果コードAVP値をDIAMETER_USER_NAME_REQUIREDに設定する必要があります。 （セクション10.1.2を参照）そして、Diameter RTAメッセージで返します。
The SIP server (Diameter client) applies the administrative deregistration to each of the URIs included in each of the SIP-AOR AVP values, or, if there is no SIP-AOR AVP present in the Diameter RTR request, to all the URIs allocated to the User-Name AVP value.
SIPサーバー（Diameterクライアント）は、各SIP-AOR AVP値に含まれている各URI、またはDiameter RTR要求にSIP-AOR AVPが存在しない場合は、割り当てられているすべてのURIに管理登録解除を適用します。 User-Name AVP値。
The value of the SIP-Deregistration-Reason AVP in the Diameter RTR command has an effect on the actions performed at the SIP server (Diameter client):
Diameter RTRコマンドのSIP-Deregistration-Reason AVPの値は、SIPサーバー（Diameterクライアント）で実行されるアクションに影響します。
o If the value is set to PERMANENT_TERMINATION, then the user has terminated his/her registration to the realm. If informing the interested parties (e.g., subscribers to the "reg" event [RFC3680]) about the administrative deregistration is supported through SIP procedures, the SIP server (Diameter client) will do so. The Diameter Client in the SIP Server SHOULD NOT request a new user registration. The SIP server clears the registration state of the deregistered AORs.
o 値がPERMANENT_TERMINATIONに設定されている場合、ユーザーはレルムへの登録を終了しています。関係者（たとえば、「reg」イベント[RFC3680]のサブスクライバー）に管理登録解除について通知することがSIP手順を通じてサポートされている場合、SIPサーバー（Diameterクライアント）はそれを行います。 SIPサーバーのDiameterクライアントは、新しいユーザー登録を要求しないでください。 SIPサーバーは、登録解除されたAORの登録状態をクリアします。
o If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter server informs the SIP server (Diameter client) that a new SIP server has been allocated to the user, due to some reason. The SIP server, if supported through SIP procedures, will inform the interested parties (e.g., subscribers to the "reg" event [RFC3680]) about the administrative deregistration at this SIP server. The Diameter client in the SIP server SHOULD NOT request a new user registration. The SIP server clears the registration state of the deregistered SIP AORs.
o 値がNEW_SIP_SERVER_ASSIGNEDに設定されている場合、Diameterサーバーは、何らかの理由で新しいSIPサーバーがユーザーに割り当てられたことをSIPサーバー（Diameterクライアント）に通知します。 SIPサーバーは、SIP手順でサポートされている場合、関係者（たとえば、「reg」イベント[RFC3680]のサブスクライバー）に、このSIPサーバーでの管理登録解除について通知します。 SIPサーバーのDiameterクライアントは、新しいユーザー登録を要求しないでください。 SIPサーバーは、登録解除されたSIP AORの登録状態をクリアします。
o If the value is set to SIP_SERVER_CHANGE, the Diameter server informs the SIP server (Diameter client) that a new SIP server has to be allocated to the user, e.g., due to user's capabilities requiring a new SIP server, or not enough resources in the current SIP server. If informing the interested parties about the administrative deregistration is supported through SIP procedures (e.g., subscriptions to the "reg" event [RFC3680]), the SIP server will do so. The Diameter client in the SIP Server SHOULD NOT request a new user registration. The SIP server clears the registration state of the deregistered SIP AORs.
o 値がSIP_SERVER_CHANGEに設定されている場合、Diameterサーバーは、SIPサーバー（Diameterクライアント）に、新しいSIPサーバーをユーザーに割り当てる必要があることを通知します。現在のSIPサーバー。管理者による登録解除について関係者に通知することがSIP手順（たとえば、「reg」イベント[RFC3680]へのサブスクリプション）を通じてサポートされている場合、SIPサーバーはそれを行います。 SIPサーバーのDiameterクライアントは、新しいユーザー登録を要求しないでください。 SIPサーバーは、登録解除されたSIP AORの登録状態をクリアします。
o If the value is set to REMOVE_SIP_SERVER, the Diameter server informs the SIP server (Diameter client) that the SIP server will no longer be bound in the Diameter server with that user. The SIP server can delete all data related to the user.
o 値がREMOVE_SIP_SERVERに設定されている場合、DiameterサーバーはSIPサーバー（Diameterクライアント）に、そのユーザーのDiameterサーバーにSIPサーバーがバインドされなくなることを通知します。 SIPサーバーは、ユーザーに関連するすべてのデータを削除できます。
The Message Format of the RTA command is as follows:
RTAコマンドのメッセージ形式は次のとおりです。
<RTA> ::= < Diameter Header: 287, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Push-Profile-Request (PPR) command is indicated by the Command-Code set to 288 and the Command Flags' 'R' bit set. The Diameter server sends this command to the Diameter client in a SIP server to update either the user profile of an already registered user in that SIP server or the SIP accounting information. This allows an operator to modify the data of a user profile or the accounting information and push it to the SIP server where the user is registered.
Push-Profile-Request（PPR）コマンドは、コマンドコードが288に設定され、コマンドフラグの 'R'ビットが設定されていることで示されます。 Diameterサーバーは、このコマンドをSIPサーバーのDiameterクライアントに送信して、そのSIPサーバーに既に登録されているユーザーのユーザープロファイルまたはSIPアカウンティング情報を更新します。これにより、オペレーターはユーザープロファイルのデータまたはアカウンティング情報を変更し、ユーザーが登録されているSIPサーバーにプッシュすることができます。
Each user has a user profile associated with him/her and other accounting information. The profile or the accounting information may change with time, e.g., due to addition of new services to the user. When the user profile or the accounting information changes, the Diameter server sends a Diameter Push-Profile-Request (PPR) command to the Diameter client in a SIP server, in order to start applying those new services.
各ユーザーは、ユーザーに関連付けられたユーザープロファイルとその他の会計情報を持っています。プロファイルまたはアカウンティング情報は、たとえば、ユーザーへの新しいサービスの追加により、時間とともに変化する可能性があります。ユーザープロファイルまたはアカウンティング情報が変更されると、Diameterサーバーは、SIPサーバーのDiameterクライアントにDiameter Push-Profile-Request（PPR）コマンドを送信して、これらの新しいサービスの適用を開始します。
A PPR command MAY contain a SIP-Accounting-Information AVP that updates the addresses of the accounting servers. Changes in the addresses of the accounting servers take effect immediately. The Diameter client SHOULD close any existing accounting session with the existing server and start providing accounting information to the newly acquired accounting server.
PPRコマンドには、アカウンティングサーバーのアドレスを更新するSIP-Accounting-Information AVPが含まれる場合があります。アカウンティングサーバーのアドレスの変更はすぐに有効になります。 Diameterクライアントは、既存のサーバーとの既存のアカウンティングセッションを閉じて、新しく取得したアカウンティングサーバーへのアカウンティング情報の提供を開始する必要があります（SHOULD）。
A PPR command MAY contain zero or more SIP-User-Data AVP values containing the new user profile. On selecting the type of user data, the Diameter server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP sent in a previous SAR message) and the local policy.
PPRコマンドには、新しいユーザープロファイルを含む0個以上のSIP-User-Data AVP値を含めることができます（MAY）。ユーザーデータのタイプを選択する際、Diameterサーバーは、SIPサーバーでサポートされている形式（以前のSARメッセージで送信されたSIP-Supported-User-Data-Type AVP）とローカルポリシーを考慮する必要があります（SHOULD）。
The User-Name AVP indicates the user to whom the profile is applicable.
User-Name AVPは、プロファイルが適用されるユーザーを示します。
The Message Format of the PPR command is as follows:
PPRコマンドのメッセージフォーマットは次のとおりです。
<PPR> ::= < Diameter Header: 288, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ User-Name }
* [ SIP-User-Data ]
[ SIP-Accounting-Information ]
[ Destination-Host ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Push-Profile-Answer (PPA) is indicated by the Command-Code set to 288 and the Command Flags' 'R' bit cleared. The Diameter client sends this command in response to a previously received Diameter Push-Profile-Request (PPR) command.
Push-Profile-Answer（PPA）は、コマンドコードが288に設定され、コマンドフラグの「R」ビットがクリアされることで示されます。 Diameterクライアントは、以前に受信したDiameter Push-Profile-Request（PPR）コマンドに応答してこのコマンドを送信します。
In addition to the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1.
RFC 3588 [RFC3588]ですでに定義されている値に加えて、Result-Code AVPにはセクション10.1で定義されている値の1つが含まれる場合があります。
If there is no error when processing the received Diameter PPR message, the SIP server (Diameter client) MUST download the received user profile from the SIP-User-Data AVP values in the Diameter PPR message and store it associated with the user specified in the User-Name AVP value.
受信したDiameter PPRメッセージの処理中にエラーがない場合、SIPサーバー（Diameterクライアント）は、Diameter PPRメッセージのSIP-User-Data AVP値から受信したユーザープロファイルをダウンロードし、それをユーザー名AVP値。
If the SIP server does not recognize or does not support some of the data transferred in the SIP-User-Data AVP values, the Diameter client in the SIP server MUST return a Diameter PPA message that includes a Result-Code AVP set to the value DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA.
SIPサーバーがSIP-User-Data AVP値で転送されたデータの一部を認識しないかサポートしない場合、SIPサーバーのDiameterクライアントは、値に設定されたResult-Code AVPを含むDiameter PPAメッセージを返さなければなりません（MUST）。 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA。
If the SIP server (Diameter client) receives a Diameter PPR message with a User-Name AVP that is unknown, the Diameter client MUST set the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and MUST return it to the Diameter server in a Diameter PPA message.
SIPサーバー（Diameterクライアント）が不明なUser-Name AVPを含むDiameter PPRメッセージを受信した場合、DiameterクライアントはResult-Code AVP値をDIAMETER_ERROR_USER_UNKNOWNに設定し、Diameter PPAメッセージでDiameterサーバーに返さなければなりません（MUST）。
If the SIP server (Diameter client) receives in the SIP-User-Data-Content AVP value (of the grouped SIP-User-Data AVP) more data than it can accept, it MUST set the Result-Code AVP value to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter server in a Diameter PPA message. The SIP server MUST NOT override the existing user profile with the one received in the PPR message.
SIPサーバー（Diameterクライアント）が（グループ化されたSIP-User-Data AVPの）SIP-User-Data-Content AVP値で受信できるよりも多くのデータを受信する場合、Result-Code AVP値をDIAMETER_ERROR_TOO_MUCH_DATAに設定しなければなりません。これをDiameter PPAメッセージでDiameterサーバーに返す必要があります。 SIPサーバーは、既存のユーザープロファイルをPPRメッセージで受信したもので上書きしてはなりません（MUST NOT）。
If the Diameter server receives the Result-Code AVP value set to DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD force a new re-registration of the user by sending to the Diameter client a Diameter Registration-Termination-Request (RTR) with the SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This will force a re-registration of the user and will trigger a selection of a new SIP server.
Diameterサーバーは、Diameter PPAメッセージでDIAMETER_ERROR_TOO_MUCH_DATAに設定されたResult-Code AVP値を受信した場合、DiameterクライアントにSIPでDiameter Registration-Termination-Request（RTR）を送信することにより、ユーザーの新しい再登録を強制する必要があります（SHOULD）。 -Deregistration-Reason AVP値がSIP_SERVER_CHANGEに設定されました。これにより、ユーザーの再登録が強制され、新しいSIPサーバーの選択がトリガーされます。
If the Diameter client is not able to honor the command, for any other reason, it MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA message.
Diameterクライアントが他の理由でコマンドを受け入れることができない場合、クライアントはResult-Code AVP値をDIAMETER_UNABLE_TO_COMPLYに設定し、Diameter PPAメッセージでそれを返さなければなりません（MUST）。
The Message Format of the PPA command is as follows:
PPAコマンドのメッセージ形式は次のとおりです。
<PPA> ::= < Diameter Header: 288, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
This section defines new AVPs used in this Diameter SIP application. Applications compliant with this specification MUST implement these AVPs.
このセクションでは、このDiameter SIPアプリケーションで使用される新しいAVPを定義します。この仕様に準拠するアプリケーションは、これらのAVPを実装する必要があります。
Table 2 lists the new AVPs defined in this Diameter SIP application. The following abbreviations are used in the Data-Type column:
表2は、このDiameter SIPアプリケーションで定義されている新しいAVPを示しています。 Data-Type列では、次の省略形が使用されています。
o DURI: DiameterURI o E: Enumerated o G: Grouped o OS: OctetString o UTF8S: UTF8String o U32: Unsigned32
o DURI：DiameterURI o E：列挙o G：グループ化o OS：OctetString o UTF8S：UTF8String o U32：Unsigned32
+-----------------------------------+------+----------------+-------+
| Attribute Name | AVP | Reference | Data- |
| | Code | | Type |
+-----------------------------------+------+----------------+-------+
| SIP-Accounting-Information | 368 | Section 9.1 | G |
| SIP-Accounting-Server-URI | 369 | Section 9.1.1 | DURI |
| SIP-Credit-Control-Server-URI | 370 | Section 9.1.2 | DURI |
| SIP-Server-URI | 371 | Section 9.2 | UTF8S |
| SIP-Server-Capabilities | 372 | Section 9.3 | G |
| SIP-Mandatory-Capability | 373 | Section 9.3.1 | U32 |
| SIP-Optional-Capability | 374 | Section 9.3.2 | U32 |
| SIP-Server-Assignment-Type | 375 | Section 9.4 | E |
| SIP-Auth-Data-Item | 376 | Section 9.5 | G |
| SIP-Authentication-Scheme | 377 | Section 9.5.1 | E |
| SIP-Item-Number | 378 | Section 9.5.2 | U32 |
| SIP-Authenticate | 379 | Section 9.5.3 | G |
| SIP-Authorization | 380 | Section 9.5.4 | G |
| SIP-Authentication-Info | 381 | Section 9.5.5 | G |
| SIP-Number-Auth-Items | 382 | Section 9.6 | U32 |
| SIP-Deregistration-Reason | 383 | Section 9.7 | G |
| SIP-Reason-Code | 384 | Section 9.7.1 | E |
| SIP-Reason-Info | 385 | Section 9.7.2 | UTF8S |
| SIP-Visited-Network-Id | 386 | Section 9.9 | UTF8S |
| SIP-User-Authorization-Type | 387 | Section 9.10 | E |
| SIP-Supported-User-Data-Type | 388 | Section 9.11 | UTF8S |
| SIP-User-Data | 389 | Section 9.12 | G |
| SIP-User-Data-Type | 390 | Section 9.12.1 | UTF8S |
| SIP-User-Data-Contents | 391 | Section 9.12.2 | OS |
| SIP-User-Data-Already-Available | 392 | Section 9.13 | E |
| SIP-Method | 393 | Section 9.14 | UTF8S |
+-----------------------------------+------+----------------+-------+
Table 2: Defined AVPs
表2：定義されたAVP
Table 3 expands the table of AVPs included in Section 4.5 of RFC 3588 [RFC3588]. The table indicates the Diameter AVPs defined in this Diameter SIP Application, their possible flag values, and whether the AVP may be encrypted. The acronyms 'M', 'P', and 'V' refer to AVP flags whose semantics are described in RFC 3588 [RFC3588]. The value of the 'Encr' column is also described in RFC 3588 [RFC3588].
表3は、RFC 3588 [RFC3588]のセクション4.5に含まれるAVPの表を拡張したものです。この表は、このDiameter SIPアプリケーションで定義されているDiameter AVP、それらの可能なフラグ値、およびAVPを暗号化できるかどうかを示しています。頭字語「M」、「P」、および「V」は、RFC 3588 [RFC3588]でそのセマンティクスが説明されているAVPフラグを指します。 「Encr」列の値は、RFC 3588 [RFC3588]でも説明されています。
+----------------------------------+------+-----+-----+------+------+
| Attribute Name | MUST | MAY | SHD | MUST | Encr |
| | | | NOT | NOT | |
+----------------------------------+------+-----+-----+------+------+
| SIP-Accounting-Information | M | P | | V | N |
| SIP-Accounting-Server-URI | M | P | | V | N |
| SIP-Credit-Control-Server-URI | M | P | | V | N |
| SIP-Server-URI | M | P | | V | N |
| SIP-Server-Capabilities | M | P | | V | N |
| SIP-Mandatory-Capability | M | P | | V | N |
| SIP-Optional-Capability | M | P | | V | N |
| SIP-Server-Assignment-Type | M | P | | V | N |
| SIP-Auth-Data-Item | M | P | | V | N |
| SIP-Authentication-Scheme | M | P | | V | N |
| SIP-Item-Number | M | P | | V | N |
| SIP-Authenticate | M | P | | V | N |
| SIP-Authorization | M | P | | V | N |
| SIP-Authentication-Info | M | P | | V | N |
| SIP-Number-Auth-Items | M | P | | V | N |
| SIP-Deregistration-Reason | M | P | | V | N |
| SIP-Reason-Code | M | P | | V | N |
| SIP-Reason-Info | M | P | | V | N |
| SIP-Visited-Network-Id | M | P | | V | N |
| SIP-User-Authorization-Type | M | P | | V | N |
| SIP-Supported-User-Data-Type | M | P | | V | N |
| SIP-User-Data | M | P | | V | N |
| SIP-User-Data-Type | M | P | | V | N |
| SIP-User-Data-Contents | M | P | | V | N |
| SIP-User-Data-Already-Available | M | P | | V | N |
| SIP-Method | M | P | | V | N |
+----------------------------------+------+-----+-----+------+------+
Table 3: Summary of the new AVPs flags
表3：新しいAVPフラグの概要
The SIP-Accounting-Information (AVP Code 368) is of type Grouped, and contains the Diameter addresses of those nodes that are able to collect accounting information.
SIP-Accounting-Information（AVPコード368）のタイプはGroupedであり、アカウンティング情報を収集できるノードのDiameterアドレスが含まれています。
The SIP-Accounting-Information AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Accounting-Information AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-Accounting-Information ::= < AVP Header: 368 >
* [ SIP-Accounting-Server-URI ]
* [ SIP-Credit-Control-Server-URI ]
* [ AVP]
The SIP-Accounting-Server-URI AVP (AVP Code 369) is of type DiameterURI. This AVP contains the address of a Diameter server that is able to receive SIP-session-related accounting information.
SIP-Accounting-Server-URI AVP（AVPコード369）のタイプはDiameterURIです。このAVPには、SIPセッション関連のアカウンティング情報を受信できるDiameterサーバーのアドレスが含まれています。
The SIP-Credit-Control-Server-URI AVP (AVP Code 370) is of type DiameterURI. This AVP contains the address of a Diameter server that is able to authorize real-time credit control usage. The Diameter Credit-Control Application [RFC4006] may be used for this purpose.
SIP-Credit-Control-Server-URI AVP（AVPコード370）は、DiameterURIタイプです。このAVPには、リアルタイムのクレジットコントロールの使用を許可できるDiameterサーバーのアドレスが含まれています。 Diameter Credit-Controlアプリケーション[RFC4006]は、この目的で使用できます。
The SIP-Server-URI AVP (AVP Code 371) is of type UTF8String. This AVP contains a SIP or SIPS URI (as defined in RFC 3261 [RFC3261]) that identifies a SIP server.
SIP-Server-URI AVP（AVPコード371）のタイプはUTF8Stringです。このAVPには、SIPサーバーを識別するSIPまたはSIPS URI（RFC 3261 [RFC3261]で定義）が含まれています。
The SIP-Server-Capabilities AVP (AVP Code 372) is of type Grouped. The Diameter indicates in this AVP the requirements for a particular SIP capability, so that the Diameter client (SIP server) is able to select another appropriate SIP server to serve the user.
SIP-Server-Capabilities AVP（AVPコード372）はグループ化タイプです。 Diameterは、このAVPで特定のSIP機能の要件を示すため、Diameterクライアント（SIPサーバー）は、ユーザーにサービスを提供する別の適切なSIPサーバーを選択できます。
The SIP-Server-Capabilities AVP allows a Diameter client (SIP server) to select another SIP server for triggering or executing services to the user. A user may have enabled some services that require the implementation of certain capabilities in the SIP server that triggers or executes those services. For example, the SIP server that triggers or executes services to this user may need to implement SIP servlets [JSR-000116], Call Processing Language (CPL) [RFC3880], or any other kind of capability. Or perhaps that user belongs to a premium users group that has a certain stringent quality-of-service agreement that requires a fast SIP server. The capabilities required or recommended to a given user are conveyed in the SIP-Server-Capabilities AVP. When it receives them, the Diameter client (SIP server) that does the SIP server selection needs to have the means to find out available SIP servers that meet the required or optional capabilities. Such means are outside the scope of this specification.
SIP-Server-Capabilities AVPにより、Diameterクライアント（SIPサーバー）は、ユーザーへのサービスをトリガーまたは実行する別のSIPサーバーを選択できます。ユーザーが、それらのサービスをトリガーまたは実行するSIPサーバーに特定の機能の実装を必要とする一部のサービスを有効にしている可能性があります。たとえば、このユーザーへのサービスをトリガーまたは実行するSIPサーバーは、SIPサーブレット[JSR-000116]、呼処理言語（CPL）[RFC3880]、またはその他の種類の機能を実装する必要がある場合があります。または、そのユーザーは、高速SIPサーバーを必要とする特定の厳しいサービス品質契約を持つプレミアムユーザーグループに属している可能性があります。特定のユーザーに必要または推奨される機能は、SIP-Server-Capabilities AVPで伝達されます。それらを受信すると、SIPサーバーの選択を行うDiameterクライアント（SIPサーバー）は、必要な機能またはオプションの機能を満たす利用可能なSIPサーバーを見つける手段を備えている必要があります。このような手段は、この仕様の範囲外です。
Note that the SIP-Server-Capabilities AVP assists the Diameter client (SIP server) to produce a subset of all the available SIP servers to be allocated to the user in the Home Realm; this is the subset that conforms the requirements of capabilities on a per-user basis. Typically this subset will be formed of more than a single SIP server, so once the subset of those SIP servers is identified, it is possible that several instances of these SIP servers exist, in which case the Diameter client (SIP server) should choose one particular SIP server to execute and trigger services to this user. It is expected that at this point the SIP server (Diameter client) will follow the procedures of RFC 3263 [RFC3263] to allocate one SIP server to the user.
SIP-Server-Capabilities AVPは、Diameterクライアント（SIPサーバー）を支援して、ホームレルムのユーザーに割り当てられるすべての利用可能なSIPサーバーのサブセットを生成することに注意してください。これは、ユーザーごとに機能の要件に適合するサブセットです。通常、このサブセットは複数のSIPサーバーで構成されるため、これらのSIPサーバーのサブセットが特定されると、これらのSIPサーバーの複数のインスタンスが存在する可能性があります。その場合、Diameterクライアント（SIPサーバー）は1つを選択する必要がありますこのユーザーに対してサービスを実行およびトリガーする特定のSIPサーバー。この時点で、SIPサーバー（Diameterクライアント）はRFC 3263 [RFC3263]の手順に従って、1つのSIPサーバーをユーザーに割り当てると予想されます。
The SIP-Server-Capabilities AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Server-Capabilities AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-Server-Capabilities ::= < AVP Header: 372 >
* [ SIP-Mandatory-Capability ]
* [ SIP-Optional-Capability ]
* [ SIP-Server-URI ]
* [ AVP ]
The SIP-Mandatory-Capability AVP (AVP Code 373) is of type Unsigned32. The value represents a certain capability (or set of capabilities) that have to be fulfilled by the SIP server allocated to the user.
SIP-Mandatory-Capability AVP（AVPコード373）のタイプはUnsigned32です。この値は、ユーザーに割り当てられたSIPサーバーが実行する必要がある特定の機能（または機能のセット）を表します。
The semantics of the different values are not standardized, as it is a matter of the administrative network to allocate its own semantics within its own network. Each value has to represent a single capability within the administrative network.
独自のネットワーク内に独自のセマンティクスを割り当てることは管理ネットワークの問題であるため、さまざまな値のセマンティクスは標準化されていません。各値は、管理ネットワーク内の単一の機能を表す必要があります。
The SIP-Optional-Capability AVP (AVP Code 374) is of type Unsigned32. The value represents a certain capability (or set of capabilities) that, optionally, may be fulfilled by the SIP server allocated to the user.
SIP-Optional-Capability AVP（AVPコード374）のタイプはUnsigned32です。値は特定の機能（または機能のセット）を表し、オプションで、ユーザーに割り当てられたSIPサーバーによって実行される場合があります。
The semantics of the different values are not standardized, as it is a matter of the administrative network to allocate its own semantics within its own network. Each value has to represent a single capability within the administrative network.
独自のネットワーク内に独自のセマンティクスを割り当てることは管理ネットワークの問題であるため、さまざまな値のセマンティクスは標準化されていません。各値は、管理ネットワーク内の単一の機能を表す必要があります。
The SIP-Server-Assignment-Type AVP (AVP Code 375) is of type Enumerated and indicates the type of server update being performed in a Diameter Server-Assignment-Request (SAR) operation. The following values are defined: o NO_ASSIGNMENT (0) The Diameter client uses this value to request the user profile of a SIP AOR, without affecting the registration state of that identity.
SIP-Server-Assignment-Type AVP（AVPコード375）は列挙型であり、Diameter Server-Assignment-Request（SAR）操作で実行されているサーバー更新のタイプを示します。次の値が定義されています。o NO_ASSIGNMENT（0）Diameterクライアントは、この値を使用して、そのIDの登録状態に影響を与えることなく、SIP AORのユーザープロファイルを要求します。
o REGISTRATION (1) First SIP registration of a SIP AOR.
o 登録（1）SIP AORの最初のSIP登録。
o RE_REGISTRATION (2) Subsequent SIP registration of a SIP AOR.
o RE_REGISTRATION（2）SIP AORの後続のSIP登録。
o UNREGISTERED_USER (3) The SIP server has received a SIP request (e.g., SIP INVITE) addressed for a SIP AOR that is not registered.
o UNREGISTERED_USER（3）SIPサーバーは、登録されていないSIP AOR宛てのSIPリクエスト（SIP INVITEなど）を受信しました。
o TIMEOUT_DEREGISTRATION (4) The SIP registration timer of an identity has expired.
o TIMEOUT_DEREGISTRATION（4）IDのSIP登録タイマーが満了しました。
o USER_DEREGISTRATION (5) The SIP server has received a request to deregister a SIP AOR.
o USER_DEREGISTRATION（5）SIPサーバーは、SIP AORの登録を解除する要求を受け取りました。
o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) The SIP registration timer of an identity has expired. The SIP server keeps the user data stored and requests the Diameter server to store the SIP server address.
o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME（6）IDのSIP登録タイマーが期限切れになりました。 SIPサーバーはユーザーデータを保存し、DiameterサーバーにSIPサーバーアドレスの保存を要求します。
o USER_DEREGISTRATION_STORE_SERVER_NAME (7) The SIP server has received a user-initiated deregistration request. The SIP server keeps the user data stored and requests the Diameter server to store the SIP server address.
o USER_DEREGISTRATION_STORE_SERVER_NAME（7）SIPサーバーは、ユーザーが開始した登録解除要求を受信しました。 SIPサーバーはユーザーデータを保存し、DiameterサーバーにSIPサーバーアドレスの保存を要求します。
o ADMINISTRATIVE_DEREGISTRATION (8) The SIP server, due to administrative reasons, has deregistered a SIP AOR.
o ADMINISTRATIVE_DEREGISTRATION（8）管理上の理由により、SIPサーバーはSIP AORを登録解除しました。
o AUTHENTICATION_FAILURE (9) The authentication of a user has failed.
o AUTHENTICATION_FAILURE（9）ユーザーの認証に失敗しました。
o AUTHENTICATION_TIMEOUT (10) The authentication timer has expired.
o AUTHENTICATION_TIMEOUT（10）認証タイマーが切れました。
o DEREGISTRATION_TOO_MUCH_DATA (11) The SIP server has requested user profile information from the Diameter server and has received a volume of data higher than it can accept.
o DEREGISTRATION_TOO_MUCH_DATA（11）SIPサーバーがDiameterサーバーからのユーザープロファイル情報を要求し、受け入れることができるよりも大量のデータを受信しました。
The SIP-Auth-Data-Item (AVP Code 376) is of type Grouped and contains the authentication and/or authorization information pertaining to a user.
SIP-Auth-Data-Item（AVPコード376）はグループ化されたタイプであり、ユーザーに関する認証および/または許可情報が含まれています。
When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to include a SIP-Authenticate AVP, the Diameter server MUST send a maximum of one authentication data item (e.g., in case the SIP request contained several credentials). Section 11 contains a detailed discussion and normative text of the case when a SIP request contains several credentials.
Diameterサーバーがグループ化されたSIP-Auth-Data-Item AVPを使用してSIP-Authenticate AVPを含める場合、Diameterサーバーは最大1つの認証データアイテムを送信する必要があります（たとえば、SIPリクエストに複数の資格情報が含まれている場合）。セクション11には、SIP要求に複数の資格情報が含まれている場合の詳細な説明と規範的なテキストが含まれています。
The SIP-Auth-Data-Item AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Auth-Data-Item AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-Auth-Data-Item ::= < AVP Header: 376 >
{ SIP-Authentication-Scheme }
[ SIP-Item-Number ]
[ SIP-Authenticate ]
[ SIP-Authorization ]
[ SIP-Authentication-Info ]
* [ AVP ]
The SIP-Authentication-Scheme AVP (AVP Code 377) is of type Enumerated and indicates the authentication scheme used in the authentication of SIP services. RFC 2617 identifies this value as an "auth-scheme" (see Section 1.2 of RFC 2617 [RFC2617]). The only currently defined value is:
SIP-Authentication-Scheme AVP（AVPコード377）は列挙型で、SIPサービスの認証に使用される認証スキームを示します。 RFC 2617は、この値を「auth-scheme」として識別します（RFC 2617のセクション1.2 [RFC2617]を参照）。現在定義されている唯一の値は次のとおりです。
o DIGEST (0) to indicate HTTP Digest authentication as specified in RFC 2617 [RFC2617] Section 3.2.1. Derivative work is also considered Digest authentication scheme, as long as the "auth-scheme" is identified as Digest in the SIP headers carrying the HTTP authentication. This includes, e.g., the HTTP Digest authentication using AKA [RFC3310].
o RFC 2617 [RFC2617]セクション3.2.1で指定されているHTTPダイジェスト認証を示すDIGEST（0）。 「auth-scheme」がHTTP認証を伝送するSIPヘッダーでDigestとして識別されている限り、派生的な作業もダイジェスト認証スキームと見なされます。これには、AKA [RFC3310]を使用したHTTPダイジェスト認証などが含まれます。
Each HTTP Digest directive (parameter) is transported in a corresponding AVP, whose name follows the pattern Digest-*. The Digest-* AVPs are RADIUS attributes imported from the RADIUS Extension for Digest Authentication [RFC4590] namespace, allowing a smooth transition between RADIUS and Diameter applications supporting SIP. The Diameter SIP application goes a step further by grouping the Digest-* AVPs into the SIP-Authenticate, SIP-Authorization, and SIP-Authentication-Info grouped AVPs that correspond to the SIP WWW-Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization, and Authentication-Info headers fields, respectively.
各HTTPダイジェストディレクティブ（パラメーター）は、名前がパターンDigest- *に従っている対応するAVPで転送されます。 Digest- * AVPは、ダイジェスト認証のRADIUS拡張[RFC4590]ネームスペースからインポートされたRADIUS属性であり、RADIUSとSIPをサポートするDiameterアプリケーション間のスムーズな移行を可能にします。 Diameter SIPアプリケーションは、Digest- * AVPを、SIP WWW-Authenticate / Proxy-Authentication、Authorization / Proxy-に対応するSIP-Authenticate、SIP-Authorization、およびSIP-Authentication-Infoにグループ化されたAVPにグループ化することにより、さらに一歩進んでいます。 AuthorizationおよびAuthentication-Infoヘッダーフィールド。
Note: Due to the fact that HTTP Digest authentication [RFC2617] is the only mandatory authentication mechanism in SIP, this memo only provides support for HTTP Digest authentication and derivative work such as HTTP Digest authentication using AKA [RFC3310]. Extensions to this memo can register new values and new AVPs to provide support for other authentication schemes or extensions to HTTP Digest authentication.
注：HTTPダイジェスト認証[RFC2617]はSIPで唯一の必須認証メカニズムであるため、このメモはHTTPダイジェスト認証と、AKA [RFC3310]を使用したHTTPダイジェスト認証などの派生的な作業のみをサポートします。このメモの拡張機能は、新しい値と新しいAVPを登録して、他の認証スキームやHTTPダイジェスト認証の拡張機能をサポートできます。
Note: Although RFC 2617 [RFC2617] defines the Basic and Digest schemes for authenticating HTTP requests, RFC 3261 [RFC3261] only imports HTTP Digest as a mechanism to provide authentication in SIP.
注：RFC 2617 [RFC2617]はHTTP要求を認証するための基本スキームとダイジェストスキームを定義していますが、RFC 3261 [RFC3261]は、SIPで認証を提供するメカニズムとしてHTTPダイジェストのみをインポートします。
Due to syntactic requirements, HTTP Digest authentication has to escape quote characters in contents of HTTP Digest directives. When translating directives into Digest-* AVPs, the Diameter client or server removes the surrounding quotes where present, as required by the syntax of the Digest-* attributes defined in the "RADIUS Extension for Digest Authentication" [RFC4590].
構文上の要件により、HTTPダイジェスト認証では、HTTPダイジェストディレクティブのコンテンツの引用文字をエスケープする必要があります。ディレクティブをDigest- * AVPに変換するとき、Diameterクライアントまたはサーバーは、「ダイジェスト認証のRADIUS拡張機能」[RFC4590]で定義されているDigest- *属性の構文で要求されるように、周囲の引用符を削除します。
The SIP-Item-Number (AVP Code 378) is of type Unsigned32 and is included in a SIP-Auth-Data-Item grouped AVP in circumstances where there are multiple occurrences of SIP-Auth-Data-Item AVPs and the order of processing is relevant. The AVP indicates the order in which the Grouped SIP-Auth-Data-Item should be processed. Lower values of the SIP-Item-Number AVP indicate that the whole SIP-Auth-Data-Item SHOULD be processed before other SIP-Auth-Data-Item AVPs that contain higher values in the SIP-Item-Number AVP.
SIP-Item-Number（AVPコード378）のタイプはUnsigned32であり、SIP-Auth-Data-Item AVPが複数発生し、処理の順序が異なる場合に、SIP-Auth-Data-Itemグループ化されたAVPに含まれます。関連性があります。 AVPは、グループ化されたSIP-Auth-Data-Itemが処理される順序を示します。 SIP-Item-Number AVPの低い値は、SIP-Item-Number AVPに高い値を含む他のSIP-Auth-Data-Item AVPの前にSIP-Auth-Data-Item全体を処理する必要があることを示します。
The SIP-Authenticate AVP (AVP Code 379) is of type Grouped and contains a reconstruction of either the SIP WWW-Authenticate or Proxy-Authentication header fields specified in RFC 2617 [RFC2617] for the HTTP Digest authentication scheme. Additionally, the AVP may include a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617 [RFC2617]). H(A1) allows the Diameter client to create an expected response and compare it with the Digest response received from the SIP UA.
SIP-Authenticate AVP（AVPコード379）はグループ化されたタイプで、RFC 2617 [RFC2617]で指定されているSIP WWW-AuthenticateまたはProxy-Authenticationヘッダーフィールドの再構成が含まれています。さらに、AVPには、H（A1）を含むDigest-HA1 AVPが含まれる場合があります（RFC 2617 [RFC2617]で定義）。 H（A1）を使用すると、Diameterクライアントは予期される応答を作成し、それをSIP UAから受信したダイジェスト応答と比較できます。
The SIP-Authenticate AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Authenticate AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-Authenticate ::= < AVP Header: 379 >
{ Digest-Realm }
{ Digest-Nonce }
[ Digest-Domain ]
[ Digest-Opaque ]
[ Digest-Stale ]
[ Digest-Algorithm ]
[ Digest-QoP ]
[ Digest-HA1]
* [ Digest-Auth-Param ]
* [ AVP ]
The SIP-Authorization AVP (AVP Code 380) is of type Grouped and contains a reconstruction of either the SIP Authorization or Proxy-Authorization header fields specified in RFC 2617 [RFC2617] for the HTTP Digest authentication scheme.
SIP承認AVP（AVPコード380）はグループ化されたタイプであり、HTTPダイジェスト認証スキームのRFC 2617 [RFC2617]で指定されているSIP承認またはProxy-Authorizationヘッダーフィールドの再構成が含まれています。
The SIP-Authorization AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP許可AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-Authorization ::= < AVP Header: 380 >
{ Digest-Username }
{ Digest-Realm }
{ Digest-Nonce }
{ Digest-URI }
{ Digest-Response }
[ Digest-Algorithm ]
[ Digest-CNonce ]
[ Digest-Opaque ]
[ Digest-QoP ]
[ Digest-Nonce-Count ]
[ Digest-Method]
[ Digest-Entity-Body-Hash ]
* [ Digest-Auth-Param ]
* [ AVP ]
The SIP-Authentication-Info AVP (AVP Code 381) is of type Grouped and contains a reconstruction of the SIP Authentication-Info header specified in RFC 2617 [RFC2617] for the HTTP Digest authentication scheme.
SIP-Authentication-Info AVP（AVPコード381）はグループ化されたタイプであり、HTTPダイジェスト認証スキームのRFC 2617 [RFC2617]で指定されたSIP Authentication-Infoヘッダーの再構成が含まれています。
The SIP-Authentication-Info AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Authentication-Info AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-Authentication-Info ::= < AVP Header: 381 >
[ Digest-Nextnonce ]
[ Digest-QoP ]
[ Digest-Response-Auth ]
[ Digest-CNonce ]
[ Digest-Nonce-Count ]
* [ AVP ]
Note that, in some cases, the Digest-Response-Auth AVP cannot be calculated at the Diameter server, but has to be calculated at the Diameter client (SIP server). For example, if the value of the quality of protection (qop) parameter in Digest is set to "auth-int", then the response-digest (rspauth parameter value in Digest) is calculated with the hash of the body of the SIP response, which is not available at the Diameter server. In this case, the Diameter client (SIP server) must calculate the response-digest once the body of the SIP response is calculated.
場合によっては、Digest-Response-Auth AVPをDiameterサーバーで計算できないが、Diameterクライアント（SIPサーバー）で計算する必要があることに注意してください。たとえば、ダイジェストの保護品質（qop）パラメータの値が「auth-int」に設定されている場合、応答ダイジェスト（ダイジェストのrspauthパラメータ値）は、SIP応答の本文のハッシュで計算されます。 、Diameterサーバーでは使用できません。この場合、SIP応答の本体が計算されると、Diameterクライアント（SIPサーバー）は応答ダイジェストを計算する必要があります。
Therefore, a value of "auth-int" in the Digest-QoP AVP of the SIP-Authentication-Info AVP indicates that the Diameter client (SIP server) MUST compute the Digest "rspauth" parameter value at the Diameter client (SIP server).
したがって、SIP-Authentication-Info AVPのDigest-QoP AVPの「auth-int」の値は、Diameterクライアント（SIPサーバー）がDiameterクライアント（SIPサーバー）でダイジェスト「rspauth」パラメーター値を計算する必要があることを示します。 。
The following AVPs are RADIUS attributes defined in the RADIUS Extension for Digest Authentication [RFC4590] and imported by this specification: Digest-AKA-Auts, Digest-Algorithm, Digest-Auth-Param, Digest-CNonce, Digest-Domain, Digest-Entity-Body-Hash, Digest-HA1, Digest-Method, Digest-Nextnonce, Digest-Nonce, Digest-Nonce-Count, Digest-Opaque, Digest-QoP, Digest-Realm, Digest-Response, Digest-Response-Auth, Digest-URI, Digest-Username, and Digest-Stale.
次のAVPは、ダイジェスト認証のRADIUS拡張[RFC4590]で定義され、この仕様によってインポートされたRADIUS属性です。Digest-AKA-Auts、Digest-Algorithm、Digest-Auth-Param、Digest-CNonce、Digest-Domain、Digest-Entity -Body-Hash、Digest-HA1、Digest-Method、Digest-Nextnonce、Digest-Nonce、Digest-Nonce-Count、Digest-Opaque、Digest-QoP、Digest-Realm、Digest-Response、Digest-Response-Auth、Digest -URI、Digest-Username、およびDigest-Stale。
The Digest-HA1 AVP contains the value, pre-calculated at the Diameter server, of H(A1) as defined in RFC 2617 [RFC2617]. The Diameter client can use H(A1) to calculate the expected Digest response, according to this challenge. If the SIP UA is in possession of the credentials, the calculated expected response and the response sent from the SIP UA will match. The Diameter server MAY include this AVP to enable and assist the SIP server in authenticating the SIP UA.
Digest-HA1 AVPには、Diameterサーバーで事前に計算された、RF（2617）[RFC2617]で定義されているH（A1）の値が含まれています。この課題に従って、DiameterクライアントはH（A1）を使用して予想されるダイジェスト応答を計算できます。 SIP UAがクレデンシャルを所有している場合、計算された予想応答とSIP UAから送信された応答は一致します。 Diameterサーバーは、SIPサーバーがSIP UAを認証することを有効にして支援するために、このAVPを含めることができます。
This scenario is not applicable when the Diameter server is configured to use a session MD5 (MD5-sess) algorithm, because the Diameter server requires the client nonce to compute the H(A1) before sending it to the Diameter client, and the client nonce might not be available when the computation of H(A1) is done. Therefore, if the final authentication is delegated to the Diameter client, it is RECOMMENDED to configure the Diameter server to use algorithms different than MD5-sess in HTTP Digest.
このシナリオは、DiameterサーバーがセッションMD5（MD5-sess）アルゴリズムを使用するように構成されている場合は適用できません。Diameterサーバーは、Diameterクライアントに送信する前にクライアントnonceがH（A1）を計算する必要があり、クライアントnonce H（A1）の計算が完了すると、使用できない場合があります。したがって、最終認証がDiameterクライアントに委任される場合は、HTTPダイジェストでMD5-sessとは異なるアルゴリズムを使用するようにDiameterサーバーを構成することをお勧めします。
It is up to the Diameter server to include a Digest-HA1 AVP. The Diameter server calculates the Digest H(A1) with the username, password, and realm (and nonce and cnonce, if applicable) as inputs, and places the result in the Digest-HA1 AVP value. For more details of the A1 computation, see RFC 2617 [RFC2617] Section 3.2.2.2. The Diameter client can calculate the Digest expected response with H(A1) as input, as described in RFC 2617 [RFC2617] Section 3.2.2.
Digest-HA1 AVPを含めるかどうかは、Diameterサーバー次第です。 Diameterサーバーは、ユーザー名、パスワード、およびレルム（該当する場合はnonceおよびcnonce）を入力として使用してダイジェストH（A1）を計算し、その結果をDigest-HA1 AVP値に格納します。 A1計算の詳細については、RFC 2617 [RFC2617]セクション3.2.2.2を参照してください。 RFC 2617 [RFC2617]セクション3.2.2で説明されているように、DiameterクライアントはH（A1）を入力として使用してダイジェスト予想応答を計算できます。
Section 11 provides further normative details about the usage of the Digest-HA1 AVP.
セクション11では、Digest-HA1 AVPの使用に関する規範的な詳細を提供します。
The Digest-Entity-Body-Hash AVP contains a hash of the entity body contained in the SIP message. This hash is required by HTTP Digest with quality of protection set to "auth-int". Diameter clients MUST use this AVP to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the Diameter server requires verification of the integrity of the entity body (e.g., qop parameter set to "auth-int").
Digest-Entity-Body-Hash AVPには、SIPメッセージに含まれるエンティティボディのハッシュが含まれます。このハッシュは、保護品質が「auth-int」に設定されたHTTPダイジェストで必要です。 Diameterクライアントは、HTTPダイジェストが認証メカニズムであり、Diameterサーバーがエンティティボディの整合性の検証を必要とする場合（たとえば、「auth-int」に設定されたqopパラメータ）、このAVPを使用してエンティティボディのハッシュを転送する必要があります。
The clarifications described in Section 22.4 of RFC 3261 [RFC3261] about the hash of empty entity bodies apply to the Digest-Entity-Body-Hash AVP.
空のエンティティボディのハッシュに関するRFC 3261 [RFC3261]のセクション22.4で説明されている説明は、Digest-Entity-Body-Hash AVPに適用されます。
The Digest-Auth-Param AVP is the mechanism whereby the Diameter client and Diameter server can exchange possible extension parameters contained in Digest headers that are either not understood by the Diameter client or for which there are no corresponding stand-alone AVPs. Unlike the previously listed Digest-* AVPs, the Digest-Auth-Param contains not only the value, but also the parameter name, since it is unknown to the Diameter client. The Diameter node MUST insert one Digest parameter/value combination per AVP value. If the Digest header contains several unknown parameters, then the Diameter implementation MUST repeat this AVP and each instance MUST contain one different unknown Digest parameter/value combination. This AVP corresponds to the "auth-param" parameter defined in Section 3.2.1 of RFC 2617 [RFC2617].
Digest-Auth-Param AVPは、DiameterクライアントとDiameterサーバーが、Diameterクライアントが理解できないか、対応するスタンドアロンAVPがないDigestヘッダーに含まれる可能な拡張パラメーターを交換できるメカニズムです。前述のDigest- * AVPとは異なり、Digest-Auth-Paramには、Diameterクライアントには不明であるため、値だけでなくパラメーター名も含まれています。 Diameterノードは、AVP値ごとに1つのダイジェストパラメータ/値の組み合わせを挿入する必要があります。 Digestヘッダーにいくつかの不明なパラメーターが含まれている場合、Diameter実装はこのAVPを繰り返す必要があり、各インスタンスには1つの異なる不明なDigestパラメーター/値の組み合わせが含まれている必要があります。このAVPは、RFC 2617 [RFC2617]のセクション3.2.1で定義されている「auth-param」パラメーターに対応しています。
Example: Assume that the Diameter server wants the SIP server to send a "foo" parameter with the value set to "bar", so that the SIP server sends that combination in a SIP WWW-Authenticate header field. The Diameter server builds a grouped SIP-Authenticate AVP that contains a Digest-Auth-Param whose value is set to foo="bar". Then the SIP server creates the WWW-Authenticate header field with all the digest parameters (received in Digest-* AVPs) and adds the foo="bar" parameter to that header field.
例：Diameterサーバーが、値が「bar」に設定された「foo」パラメーターをSIPサーバーに送信して、SIPサーバーがその組み合わせをSIP WWW-Authenticateヘッダーフィールドで送信することを望んでいると想定します。 Diameterサーバーは、値がfoo = "bar"に設定されたDigest-Auth-Paramを含むグループ化されたSIP-Authenticate AVPを構築します。次に、SIPサーバーは、すべてのダイジェストパラメーター（Digest- * AVPで受信）を含むWWW-Authenticateヘッダーフィールドを作成し、そのヘッダーフィールドにfoo = "bar"パラメーターを追加します。
The SIP-Number-Auth-Items AVP (AVP Code 382) is of type Unsigned32 and indicates the number of authentication and/or authorization credentials that the Diameter server included in a Diameter message.
SIP-Number-Auth-Items AVP（AVPコード382）は、Unsigned32タイプであり、DiameterサーバーがDiameterメッセージに含めた認証および/または承認資格情報の数を示します。
When the AVP is present in a request, it indicates the number of SIP-Auth-Data-Items the Diameter client is requesting. This can be used, for instance, when the SIP server is requesting several pre-calculated authentication credentials. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual number of items that the Diameter server included.
AVPがリクエストに存在する場合、DiameterクライアントがリクエストしているSIP-Auth-Data-Itemsの数を示します。これは、たとえば、SIPサーバーが事前に計算されたいくつかの認証資格情報を要求しているときに使用できます。応答メッセージのSIP-Number-Auth-Items AVPは、Diameterサーバーに含まれている実際のアイテム数を示します。
The SIP-Deregistration-Reason AVP (AVP Code 383) is of type Grouped and indicates the reason for a deregistration operation.
SIP-Deregistration-Reason AVP（AVPコード383）はグループ化されたタイプであり、登録解除操作の理由を示します。
The SIP-Deregistration-Reason AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Deregistration-Reason AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-Deregistration-Reason ::= < AVP Header: 383 >
{ SIP-Reason-Code }
[ SIP-Reason-Info ]
* [ AVP ]
The SIP-Reason-Code AVP (AVP Code 384) is of type Enumerated and defines the reason for the network initiated deregistration. The following values are defined:
SIP-Reason-Code AVP（AVPコード384）は列挙型であり、ネットワークによって開始される登録解除の理由を定義します。以下の値が定義されています。
o PERMANENT_TERMINATION (0) o NEW_SIP_SERVER_ASSIGNED (1) o SIP_SERVER_CHANGE (2) o REMOVE_SIP_SERVER (3)
o PERMANENT_TERMINATION（0）o NEW_SIP_SERVER_ASSIGNED（1）o SIP_SERVER_CHANGE（2）o REMOVE_SIP_SERVER（3）
The SIP-Reason-Info AVP (AVP Code 385) is of type UTF8String and contains textual information that can be rendered to the user, about the reason for a deregistration.
SIP-Reason-Info AVP（AVPコード385）はUTF8Stringタイプであり、登録解除の理由について、ユーザーに表示できるテキスト情報が含まれています。
The SIP-AOR AVP is a RADIUS attribute imported from the RADIUS Extension for Digest Authentication [RFC4590] namespace, allowing a smooth transition between RADIUS and Diameter applications supporting SIP. The SIP-AOR AVP carries the URI of the intended user related to the SIP request (whose location in SIP may vary depending on the actual SIP request and whether the SIP server is acting on Diameter due to a SIP-originated or terminating requests).
SIP-AOR AVPは、ダイジェスト認証のRADIUS拡張[RFC4590]ネームスペースからインポートされたRADIUS属性であり、RADIUSとSIPをサポートするDiameterアプリケーション間のスムーズな移行を可能にします。 SIP-AOR AVPは、SIPリクエストに関連する対象ユーザーのURIを伝達します（SIP内の場所は、実際のSIPリクエストと、SIPが発信またはリクエストを終了するためにSIPサーバーがDiameterで動作しているかどうかによって異なります）。
The Diameter client (SIP server) uses the value found in a SIP Request-URI or a header field value of the SIP request to construct the SIP-AOR AVP. The selection of a Request-URI or a particular header field to create the value of the SIP-AOR AVP depends on the semantics of the SIP message and whether the SIP server is acting for originating or terminating requests. For instance, when the SIP server receives an INVITE request addressed to the served user (e.g., the SIP server is receiving a terminating SIP request), it maps the SIP Request-URI of the SIP request to this AVP. However, when the SIP server receives an INVITE request originated by the served user, it can map either the P-Asserted-Identity or the From header field values to this AVP. If the SIP server is acting as a SIP registrar, then it maps the To header field of the REGISTER request to the SIP-AOR AVP.
Diameterクライアント（SIPサーバー）は、SIPリクエストURIにある値またはSIPリクエストのヘッダーフィールド値を使用して、SIP-AOR AVPを構築します。 SIP-AOR AVPの値を作成するためのRequest-URIまたは特定のヘッダーフィールドの選択は、SIPメッセージのセマンティクスと、SIPサーバーが要求の発信または終了のどちらのために機能しているかによって異なります。たとえば、SIPサーバーが、対応するユーザーに宛てられたINVITE要求を受信すると（たとえば、SIPサーバーが終了SIP要求を受信している場合）、SIP要求のSIP Request-URIをこのAVPにマッピングします。ただし、SIPサーバーは、サービスを提供するユーザーからのINVITE要求を受信すると、P-Asserted-IdentityまたはFromヘッダーフィールド値をこのAVPにマップできます。 SIPサーバーがSIPレジストラーとして機能している場合は、REGISTER要求のToヘッダーフィールドをSIP-AOR AVPにマップします。
The SIP-Visited-Network-Id AVP (AVP Code 386) is of type UTF8String. This AVP contains an identifier that helps the home network identify the visited network (e.g., the visited network domain name), in order to authorize roaming to that visited network.
SIP-Visited-Network-Id AVP（AVPコード386）のタイプはUTF8Stringです。このAVPには、訪問先ネットワークへのローミングを許可するために、訪問先ネットワーク（訪問先ネットワークドメイン名など）をホームネットワークが識別するのに役立つ識別子が含まれています。
The SIP-User-Authorization-Type AVP (AVP Code 387) is of type Enumerated and indicates the type of user authorization being performed in a User Authorization operation, i.e., the Diameter User-Authorization-Request (UAR) command. The following values are defined: o REGISTRATION (0) This value is used for initial registration or re-registration. This is the default value.
SIP-User-Authorization-Type AVP（AVPコード387）は列挙型で、ユーザー認証操作、つまりDiameter User-Authorization-Request（UAR）コマンドで実行されるユーザー認証のタイプを示します。次の値が定義されています。o REGISTRATION（0）この値は、初期登録または再登録に使用されます。これがデフォルト値です。
o DEREGISTRATION (1) This value is used for deregistration.
o DEREGISTRATION（1）この値は、登録解除に使用されます。
o REGISTRATION_AND_CAPABILITIES (2) This value is used for initial registration or re-registration when the SIP server explicitly requests the Diameter server to get capability information. This capability information helps the SIP server to allocate another SIP server to serve the user.
o REGISTRATION_AND_CAPABILITIES（2）この値は、SIPサーバーがDiameterサーバーに機能情報の取得を明示的に要求するときに、初期登録または再登録に使用されます。この機能情報は、SIPサーバーがユーザーにサービスを提供する別のSIPサーバーを割り当てるのに役立ちます。
The SIP-Supported-User-Data-Type AVP (AVP Code 388) is of type UTF8String and contains a string that identifies the type of supported user data (user profile, see SIP-User-Data AVP (Section 9.12)) supported in the node. The AVP can be repeated, if the SIP server supports several user data types. In case of repetition, the Diameter client should order the different instances of this AVP according to its preferences.
SIP-Supported-User-Data-Type AVP（AVPコード388）のタイプはUTF8Stringで、サポートされているユーザーデータのタイプ（ユーザープロファイル、SIP-User-Data AVP（セクション9.12）を参照）を識別する文字列が含まれています。ノード。 SIPサーバーが複数のユーザーデータタイプをサポートしている場合は、AVPを繰り返すことができます。繰り返しの場合、DiameterクライアントはこのAVPのさまざまなインスタンスをその設定に従って順序付けする必要があります。
When the Diameter client inserts this AVP in a SAR message, it allows the Diameter client to provide an indication to the Diameter server of the types of user data supported by the SIP server. The Diameter server, upon inspection of these AVPs, will return a suitable SIP-User-Data AVP (Section 9.12) of the type indicated in the SIP-User-Data-Type AVP (Section 9.12.1).
DiameterクライアントがこのAVPをSARメッセージに挿入すると、Diameterクライアントは、SIPサーバーがサポートするユーザーデータのタイプをDiameterサーバーに示すことができます。 Diameterサーバーは、これらのAVPを検査すると、SIP-User-Data-Type AVP（セクション9.12.1）で示されたタイプの適切なSIP-User-Data AVP（セクション9.12）を返します。
The SIP-User-Data AVP (AVP Code 389) is of type Grouped. This AVP allows the Diameter server to transport user-specific data, such as a user profile, to the SIP server (in the Diameter client). The Diameter server selects a type of user data that is understood by the SIP server in the Diameter client, and has been indicated in a SIP-Supported-User-Data-Type AVP. In case the Diameter client indicated support for several types of user data, the Diameter server SHOULD choose the first type supported by the client.
SIP-User-Data AVP（AVPコード389）はグループ化タイプです。このAVPにより、Diameterサーバーは、ユーザープロファイルなどのユーザー固有のデータを（Diameterクライアント内の）SIPサーバーに転送できます。 Diameterサーバーは、DiameterクライアントのSIPサーバーによって認識され、SIP-Supported-User-Data-Type AVPで示されているユーザーデータのタイプを選択します。 Diameterクライアントがいくつかのタイプのユーザーデータのサポートを示した場合、Diameterサーバーはクライアントがサポートする最初のタイプを選択する必要があります（SHOULD）。
The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP that indicates the type of user data included in the SIP-User-Data-Contents-AVP.
SIP-User-Dataグループ化AVPには、SIP-User-Data-Contents-AVPに含まれるユーザーデータのタイプを示すSIP-User-Data-Type AVPが含まれています。
The SIP-User-Data AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-User-Data AVPは次のように定義されます（RFC 3588 [RFC3588]のgrouped-avp-defに従って）：
SIP-User-Data ::= < AVP Header: 389 >
{ SIP-User-Data-Type }
{ SIP-User-Data-Contents }
* [ AVP ]
The SIP-User-Data AVP (AVP Code 390) is of type UTF8String and contains a string that identifies the type of user data included in the SIP-User-Data AVP (Section 9.12).
SIP-User-Data AVP（AVPコード390）のタイプはUTF8Stringで、SIP-User-Data AVPに含まれるユーザーデータのタイプを識別する文字列が含まれています（セクション9.12）。
This document does not specify a convention to characterize the type of user data contained in the SIP-User-Data AVP (Section 9.12). It is believed that in most cases this feature will be used in environments controlled by a network administrator who can configure both the client and server to assign the same value type at the client and server. It is also RECOMMENDED that organizations developing their own profile of SIP-User-Data AVP (Section 9.12) allocate a type based on their canonical DNS name. For instance, organization "example.com" can define several types of SIP-User-Data and allocate the types "type1.dsa.example.com", "type2.dsa.example.com", and so on. This convention will avoid a clash in the allocation of types of SIP-User-Data AVP (Section 9.12).
このドキュメントでは、SIP-User-Data AVP（セクション9.12）に含まれるユーザーデータのタイプを特徴付ける規則を指定していません。ほとんどの場合、この機能は、クライアントとサーバーの両方でクライアントとサーバーに同じ値タイプを割り当てるように構成できるネットワーク管理者によって制御される環境で使用されると考えられています。 SIP-User-Data AVP（セクション9.12）の独自のプロファイルを開発している組織が、正規のDNS名に基づいてタイプを割り当てることも推奨されます。たとえば、組織「example.com」はいくつかのタイプのSIP-User-Dataを定義し、タイプ「type1.dsa.example.com」、「type2.dsa.example.com」などを割り当てることができます。この規則により、SIP-User-Data AVPのタイプの割り当ての衝突が回避されます（セクション9.12）。
The SIP-User-Data-Contents AVP (AVP Code 391) is of type OctetString. The Diameter peers do not need to understand the value of this AVP.
SIP-User-Data-Contents AVP（AVPコード391）のタイプはOctetStringです。 Diameterピアは、このAVPの価値を理解する必要はありません。
The AVP contains the user profile data required for a SIP server to give service to the user.
AVPには、SIPサーバーがユーザーにサービスを提供するために必要なユーザープロファイルデータが含まれています。
The SIP-User-Data-Already-Available AVP (AVP Code 392) is of type Enumerated and gives an indication to the Diameter server about whether the Diameter client (SIP server) already received the portion of the user profile needed in order to serve the user. The following values are defined:
SIP-User-Data-Already-Available AVP（AVPコード392）は列挙型であり、Diameterクライアント（SIPサーバー）が、サービスを提供するために必要なユーザープロファイルの一部をすでに受信しているかどうかを示しますユーザー。以下の値が定義されています。
o USER_DATA_NOT_AVAILABLE (0) The Diameter client (SIP server) does not have the data that it needs to serve the user.
o USER_DATA_NOT_AVAILABLE（0）Diameterクライアント（SIPサーバー）には、ユーザーにサービスを提供するために必要なデータがありません。
o USER_DATA_ALREADY_AVAILABLE (1) The Diameter client (SIP server) already has received the data that it needs to serve the user.
o USER_DATA_ALREADY_AVAILABLE（1）Diameterクライアント（SIPサーバー）は、ユーザーにサービスを提供するために必要なデータをすでに受信しています。
The SIP-Method-AVP (AVP Code 393) is of type UTF8String and contains the method of the SIP request that triggered the Diameter message. The Diameter server MUST use this AVP solely for authorization of SIP requests, and MUST NOT use it to compute the Digest authentication. To compute the Digest authentication, the Diameter server MUST use the Digest-Method AVP instead.
SIP-Method-AVP（AVPコード393）はUTF8Stringタイプで、DiameterメッセージをトリガーしたSIPリクエストのメソッドが含まれています。 Diameterサーバーは、SIPリクエストの承認のためだけにこのAVPを使用しなければならず（MUST）、ダイジェスト認証の計算にそれを使用してはなりません（MUST NOT）。ダイジェスト認証を計算するには、Diameterサーバーが代わりにDigest-Method AVPを使用する必要があります。
This section defines new values that the Diameter SIP application extends to already existing AVPs.
このセクションでは、Diameter SIPアプリケーションが既存のAVPに拡張する新しい値を定義します。
The Result-Code AVP is already defined in RFC 3588 [RFC3588]. In addition to the values already defined in RFC 3588 [RFC3588], the Diameter SIP application defines the following new Result-Code AVP values:
Result-Code AVPはRFC 3588 [RFC3588]ですでに定義されています。 RFC 3588 [RFC3588]ですでに定義されている値に加えて、Diameter SIPアプリケーションは次の新しいResult-Code AVP値を定義します。
A Diameter peer uses Result-Code AVP values that fall into the success category to inform the remote peer that a request has been successfully completed.
Diameterピアは、成功カテゴリに分類されるResult-Code AVP値を使用して、リクエストが正常に完了したことをリモートピアに通知します。
o DIAMETER_FIRST_REGISTRATION 2003 The user was not previously registered. The Diameter server has now authorized the registration.
o DIAMETER_FIRST_REGISTRATION 2003ユーザーは以前に登録されていません。これで、Diameterサーバーが登録を承認しました。
o DIAMETER_SUBSEQUENT_REGISTRATION 2004 The user is already registered. The Diameter server has now authorized the re-registration.
o DIAMETER_SUBSEQUENT_REGISTRATION 2004ユーザーは既に登録されています。これで、Diameterサーバーが再登録を承認しました。
o DIAMETER_UNREGISTERED_SERVICE 2005 The user is not currently registered, but the requested service can still be granted to the user.
o DIAMETER_UNREGISTERED_SERVICE 2005ユーザーは現在登録されていませんが、要求されたサービスは引き続きユーザーに付与できます。
o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2006 The request operation was successfully processed. The Diameter server does not keep a record of the SIP server address assigned to the user.
o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2006要求操作は正常に処理されました。 Diameterサーバーは、ユーザーに割り当てられたSIPサーバーアドレスの記録を保持しません。
o DIAMETER_SERVER_SELECTION 2007 The Diameter server has authorized the registration. The user has already been assigned a SIP server, but it may be necessary to select a new SIP server for the user.
o DIAMETER_SERVER_SELECTION 2007 Diameterサーバーが登録を承認しました。ユーザーにはすでにSIPサーバーが割り当てられていますが、ユーザー用に新しいSIPサーバーを選択する必要がある場合があります。
o DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2008 The requested operation was successfully executed. The Diameter server is sending a number of authentication credentials in the answer message. The Diameter server does not keep a record of the SIP server.
o DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2008要求された操作は正常に実行されました。 Diameterサーバーは、応答メッセージでいくつかの認証資格情報を送信しています。 DiameterサーバーはSIPサーバーの記録を保持しません。
A Diameter peer uses a Result-Code AVP value that falls in the transient failures category to inform the remote peer that a request could not be satisfied at the time it was received, but it MAY be satisfied by the Diameter peer in the future.
Diameterピアは、一時的な障害のカテゴリに含まれるResult-Code AVP値を使用して、要求が受信されたときに要求を満たせなかったことをリモートピアに通知しますが、将来はDiameterピアによって満たされる可能性があります。
o DIAMETER_USER_NAME_REQUIRED 4013 The Diameter request did not contain a User-Name AVP, which is required to complete the transaction. The Diameter peer MAY include a User-Name AVP and attempt the request again.
o DIAMETER_USER_NAME_REQUIRED 4013 Diameterリクエストに、トランザクションを完了するために必要なユーザー名AVPが含まれていませんでした。 Diameterピアにユーザー名AVPを含めて、要求を再試行してもよい（MAY）。
A Diameter peer uses a Result-Code AVP value that falls into the permanent failure category to inform the remote peer that the request failed and should not be attempted again.
Diameterピアは、永続的な失敗カテゴリに該当するResult-Code AVP値を使用して、リクエストが失敗したため、再試行しないことをリモートピアに通知します。
o DIAMETER_ERROR_USER_UNKNOWN 5032 The SIP-AOR AVP value does not belong to a known user in this realm.
o DIAMETER_ERROR_USER_UNKNOWN 5032 SIP-AOR AVP値は、このレルムの既知のユーザーに属していません。
o DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5033 The value in one of the SIP-AOR AVPs is not allocated to the user specified in the User-Name AVP.
o DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5033 SIP-AOR AVPのいずれかの値が、ユーザー名AVPで指定されたユーザーに割り当てられていません。
o DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5034 A query for location information is received for a SIP AOR that has not been registered before. The user to which this identity belongs cannot be given service in this situation.
o DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5034以前に登録されていないSIP AORの位置情報のクエリが受信されました。このIDが属するユーザーは、この状況ではサービスを提供できません。
o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5035 The user is not allowed to roam to the visited network.
o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5035ユーザーは、アクセスしたネットワークへのローミングを許可されていません。
o DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5036 The identity being registered has already been assigned a server and the registration status does not allow that it is overwritten.
o DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5036登録中のIDはすでにサーバーに割り当てられており、登録ステータスでは上書きできません。
o DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5037 The authentication scheme indicated in an authentication request is not supported.
o DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5037認証要求で示された認証方式はサポートされていません。
o DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5038 The SIP server address sent in the SIP-Server-URI AVP value of the Diameter Server-Assignment-Request (SAR) command is the same SIP server address that is currently assigned to the user name, but the SIP-Server-Assignment-Type AVP is not allowed. For example, the user is registered and the Server-Assignment-Request indicates the assignment for an unregistered user.
o DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5038 Diameter Server-Assignment-Request（SAR）コマンドのSIP-Server-URI AVP値で送信されたSIPサーバーアドレスは、現在ユーザー名に割り当てられているSIPサーバーアドレスと同じですが、SIP-Server-Assignment -Type AVPは許可されていません。たとえば、ユーザーは登録されており、Server-Assignment-Requestは未登録ユーザーの割り当てを示しています。
o DIAMETER_ERROR_TOO_MUCH_DATA 5039 The Diameter peer in the SIP server receives more data than it can accept. The SIP server cannot overwrite the already stored data.
o DIAMETER_ERROR_TOO_MUCH_DATA 5039 SIPサーバーのDiameterピアが、受け入れることができない量のデータを受信しました。 SIPサーバーは、すでに保存されているデータを上書きできません。
o DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5040 The SIP server informs the Diameter server that the received subscription data contained information that was not recognized or supported.
o DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5040 SIPサーバーはDiameterサーバーに、受信したサブスクリプションデータに認識またはサポートされていない情報が含まれていることを通知します。
Authenticating a user can occur through various mechanisms. Currently HTTP Digest authentication is supported. The actual authentication is performed in either the SIP server or the Diameter server.
ユーザーの認証は、さまざまなメカニズムを通じて行われます。現在、HTTPダイジェスト認証がサポートされています。実際の認証は、SIPサーバーまたはDiameterサーバーのいずれかで実行されます。
If the Diameter server wants to assure that authentication will take place in the Diameter server (as opposed to a delegated authentication taking place in the SIP server), it MUST NOT include a Digest-HA1 AVP (part of the grouped SIP-Authenticate AVP, which in turn is part of the SIP-Auth-Data-Item AVP) in a MAA message. The Diameter server MAY include a pre-calculated Digest-HA1 AVP in the MAA message if it wants to delegate authentication of the user to the SIP server.
Diameterサーバーが（SIPサーバーで行われる委任認証とは対照的に）認証がDiameterサーバーで行われることを保証したい場合は、Digest-HA1 AVP（グループ化されたSIP-Authenticate AVPの一部）を含めてはなりません。これは、MAAメッセージのSIP-Auth-Data-Item AVP）の一部です。 Diameterサーバーは、ユーザーの認証をSIPサーバーに委任したい場合、MAAメッセージに事前に計算されたDigest-HA1 AVPを含めることができます。
Note that on systems where the SIP User Agent is using HTTP Digest authentication [RFC2617] inside of Transport Layer Security (TLS) [RFC4346], where only the SIP proxy server has a certificate, delegating authentication to the SIP server (by making Digest-HA1 available to the SIP server) might reduce the load on the Diameter server.
SIPユーザーエージェントがトランスポート層セキュリティ（TLS）[RFC4346]内でHTTPダイジェスト認証[RFC2617]を使用しているシステムでは、SIPプロキシサーバーのみが証明書を持ち、認証をSIPサーバーに委任することに注意してください（ダイジェストSIPサーバーで利用可能なHA1）により、Diameterサーバーの負荷が軽減される場合があります。
When requesting authentication, the Diameter client indicates in the SIP-Number-Auth-Items AVP value of a Diameter MAR message how many authentication credentials are being requested. In the Diameter MAA message, the Diameter server MAY include more than one SIP-Auth-Data-Item AVP, but it is only useful for the Diameter client if the Digest-QoP AVP was set to 'auth-int' (in the MAR message), and if future authentications will have the same realm. When including more than one SIP-Auth-Data-Item AVP, the Diameter server SHOULD indicate how many instances of SIP-Auth-Data-Item AVPs are present with the SIP-Number-Auth-Items AVP. This number may be different from the one requested in the Diameter MAR message. If multiple SIP-Auth-Data-Item AVPs are present, and their ordering is significant, the Diameter server MUST include a SIP-Item-Number AVP in each grouping to indicate the order. The SIP-Authentication-Scheme AVP indicates "Digest" and the SIP-Authenticate AVP contains data (typically a challenge of some kind) that the user can use for her authentication. The grouped SIP-Authorization AVP contains the AVPs that conform to the response expected from the user.
Diameterクライアントは、認証を要求するときに、Diameter MARメッセージのSIP-Number-Auth-Items AVP値で、要求されている認証資格情報の数を示します。 Diameter MAAメッセージには、Diameterサーバーに複数のSIP-Auth-Data-Item AVPが含まれる場合がありますが、これは、Digest-QoP AVPが「auth-int」に設定されている場合にのみ有効です（MAR内）メッセージ）、および将来の認証が同じレルムを持つ場合。複数のSIP-Auth-Data-Item AVPを含める場合、Diameterサーバーは、SIP-Number-Auth-Items AVPと共に存在するSIP-Auth-Data-Item AVPのインスタンスの数を示す必要があります（SHOULD）。この番号は、Diameter MARメッセージで要求された番号とは異なる場合があります。複数のSIP-Auth-Data-Item AVPが存在し、それらの順序が重要な場合、Diameterサーバーは各グループにSIP-Item-Number AVPを含めて順序を示す必要があります。 SIP-Authentication-Scheme AVPは「ダイジェスト」を示し、SIP-Authenticate AVPには、ユーザーが認証に使用できるデータ（通常はある種のチャレンジ）が含まれています。グループ化されたSIP-Authorization AVPには、ユーザーから期待される応答に準拠するAVPが含まれています。
If the Diameter server performs the authentication of the user, the Diameter MAR message that the Diameter client sends to the Diameter server MUST include all the authentication credentials supplied by the SIP UA (there might be more than one credential, e.g., different realms, authentication of proxies, etc.). Each credential is inserted in a grouped SIP-Authorization AVP (part of the grouped SIP-Auth-Data-Item AVP). The Diameter client MUST insert a SIP-Number-Auth-Items AVP with the value set to the number of credentials enclosed. If necessary, the Digest-Entity-Body-Hash AVP will contain a hash of the body, needed to perform the authentication. If the authentication is successful, the Diameter MAA message will contain a Result-Code AVP indicating success, and if necessary, the Diameter server MAY include one or more SIP-Auth-Data-Item AVPs to provide further authentication credentials to the SIP server. If the authentication is unsuccessful due to missing credentials, the Diameter MAA message will include a SIP-Auth-Data-Item AVP with the SIP-Authentication-Scheme and SIP-Authenticate AVPs containing data (typically a challenge of some kind) that the user can use to authenticate itself.
Diameterサーバーがユーザーの認証を実行する場合、DiameterクライアントがDiameterサーバーに送信するDiameter MARメッセージには、SIP UAによって提供されるすべての認証資格情報を含める必要があります（異なるレルム、認証など、複数の資格情報が存在する場合があります）プロキシなど）。各資格情報は、グループ化されたSIP-Authorization AVP（グループ化されたSIP-Auth-Data-Item AVPの一部）に挿入されます。 Diameterクライアントは、SIP-Number-Auth-Items AVPを、囲まれた資格情報の数に設定された値で挿入する必要があります。必要に応じて、Digest-Entity-Body-Hash AVPには、認証の実行に必要な本文のハッシュが含まれます。認証が成功した場合、Diameter MAAメッセージには成功を示すResult-Code AVPが含まれ、必要に応じて、Diameterサーバーは1つ以上のSIP-Auth-Data-Item AVPを含めて、SIPサーバーに追加の認証資格情報を提供できます。資格情報の欠落が原因で認証が失敗した場合、Diameter MAAメッセージには、SIP-Auth-Data-Item AVPと、ユーザーがデータ（通常は何らかのチャレンジ）を含むSIP-Authentication-SchemeおよびSIP-Authenticate AVPが含まれます。自身を認証するために使用できます。
There are situations where a SIP request traverses several proxies, and each of the proxies requests to authenticate the SIP UA. In this situation, it is a valid scenario that a SIP request received at a SIP server contains several sets of credentials. The 'realm' directive in HTTP is the key that the Diameter client can use to determine which credential is applicable. Also, none of the realms may be of interest to the Diameter client, in which case the Diameter client MUST consider that no credentials (of interest) were sent. In any case, a Diameter client MUST send zero or exactly one credential to the Diameter server. The Diameter client MUST choose the credential based on the 'realm' directive in the Authorization/Proxy-Authorization header field, and it MUST match the realm of the Diameter client.
SIP要求がいくつかのプロキシを通過し、各プロキシがSIP UAを認証するよう要求する状況があります。この状況では、SIPサーバーで受信されたSIP要求にいくつかの資格情報のセットが含まれているのは有効なシナリオです。 HTTPの「レルム」ディレクティブは、Diameterクライアントがどの資格を適用できるかを判断するために使用できるキーです。また、Diameterクライアントが対象とする領域がない場合もあります。その場合、Diameterクライアントは、（対象となる）資格情報が送信されなかったことを考慮しなければなりません（MUST）。いずれの場合も、Diameterクライアントは、0または1つの資格をDiameterサーバーに送信する必要があります。 Diameterクライアントは、Authorization / Proxy-Authorizationヘッダーフィールドの「realm」ディレクティブに基づいて資格を選択する必要があり、Diameterクライアントのレルムと一致する必要があります。
It must be noted that nonces are always generated in the Diameter server.
nonceは常にDiameterサーバーで生成されることに注意してください。
RADIUS offers support for HTTP Digest authentication in the RADIUS Extension for Digest Authentication [RFC4590]. A number of AVPs (the Digest-* AVPs) of this Diameter SIP application are imported from the RADIUS attributes namespace, thus making the migration from RADIUS to Diameter smooth.
RADIUSは、ダイジェスト認証のRADIUS拡張[RFC4590]でHTTPダイジェスト認証をサポートしています。このDiameter SIPアプリケーションの多数のAVP（Digest- * AVP）はRADIUS属性ネームスペースからインポートされるため、RADIUSからDiameterへの移行がスムーズになります。
Note that the RADIUS Extension for Digest Authentication [RFC4590] provides a more limited scope than this Diameter SIP application. Specifically, the RADIUS extension for Digest Authentication merely provides support for HTTP Digest authentication, whereas the Diameter SIP application provides support for user location, profile downloading and update, etc.
ダイジェスト認証のRADIUS拡張[RFC4590]は、このDiameter SIPアプリケーションよりも制限されたスコープを提供することに注意してください。具体的には、ダイジェスト認証のRADIUS拡張機能はHTTPダイジェスト認証のサポートを提供するだけですが、Diameter SIPアプリケーションはユーザーの場所、プロファイルのダウンロードと更新などのサポートを提供します。
The following sections discuss several configurations in which a gateway translates RADIUS to Diameter and vice versa.
次のセクションでは、ゲートウェイがRADIUSをDiameterに、またはその逆に変換するいくつかの構成について説明します。
The gateway maps Access-Request messages to MAR request. If a RADIUS Access-Request message contains at least one Digest-* attribute, the gateway maps all Digest-* attributes to the AVPs of a Diameter SIP-Authorization AVP, constructs a MAR message, and sends it to the Diameter server. If the RADIUS Access-Request message does not contain any Digest-* attribute, then the RADIUS client does not want to apply HTTP Digest authentication, in which case, actions at the gateway are outside the scope of this document.
ゲートウェイはAccess-RequestメッセージをMAR要求にマッピングします。 RADIUS Access-Requestメッセージに少なくとも1つのDigest- *属性が含まれている場合、ゲートウェイはすべてのDigest- *属性をDiameter SIP-Authorization AVPのAVPにマップし、MARメッセージを作成して、Diameterサーバーに送信します。 RADIUS Access-RequestメッセージにDigest- *属性が含まれていない場合、RADIUSクライアントはHTTPダイジェスト認証を適用したくないため、ゲートウェイでのアクションはこのドキュメントの範囲外です。
The Diameter server responds with a MAA message. If the MAA message contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH and contains challenge parameters in a SIP-Authenticate AVP, then the gateway translates the AVPs of SIP-Authenticate AVP and puts the resulting RADIUS attributes into an Access-Challenge message. It sends the Access-Challenge message to the RADIUS client.
DiameterサーバーはMAAメッセージで応答します。 MAAメッセージに値DIAMETER_MULTI_ROUND_AUTHに設定されたResult-Code AVPが含まれ、SIP-Authenticate AVPにチャレンジパラメータが含まれている場合、ゲートウェイはSIP-Authenticate AVPのAVPを変換し、結果のRADIUS属性をAccess-Challengeメッセージに入れます。 Access-ChallengeメッセージをRADIUSクライアントに送信します。
If the MAA message contains a SIP-Authentication-Info and a Digest-Response AVP, the gateway converts these AVPs to the corresponding RADIUS attributes and constructs a RADIUS message. If the Result-Code AVP is DIAMETER_SUCCESS, an Access-Accept is sent. In all other cases, an Access-Reject is sent.
MAAメッセージにSIP-Authentication-InfoおよびDigest-Response AVPが含まれている場合、ゲートウェイはこれらのAVPを対応するRADIUS属性に変換し、RADIUSメッセージを作成します。 Result-Code AVPがDIAMETER_SUCCESSの場合、Access-Acceptが送信されます。それ以外の場合はすべて、Access-Rejectが送信されます。
The Diameter client sends a Diameter MAR message to the gateway. If the MAR message does not contain SIP-Auth-Data-Item AVPs, the gateway constructs an Access-Request message and maps the SIP-AOR and SIP-Method AVPs to RADIUS attributes. The gateway sends the Access-Request message to the RADIUS server, which will respond with an Access-Challenge. The gateway creates a MAA message with a Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH and maps the Digest-* attributes to Diameter AVPs in a SIP-Authenticate AVP. The gateway sends the resulting MAA to the Diameter client, which will respond with a new MAR.
Diameterクライアントは、Diameter MARメッセージをゲートウェイに送信します。 MARメッセージにSIP-Auth-Data-Item AVPが含まれていない場合、ゲートウェイはAccess-Requestメッセージを作成し、SIP-AORおよびSIP-Method AVPをRADIUS属性にマッピングします。ゲートウェイはAccess-RequestメッセージをRADIUSサーバーに送信し、RADIUSサーバーはAccess-Challengeで応答します。ゲートウェイは、Result-Code AVPがDIAMETER_MULTI_ROUND_AUTHに設定されたMAAメッセージを作成し、Digest- *属性をSIP-Authenticate AVPのDiameter AVPにマップします。ゲートウェイは結果のMAAをDiameterクライアントに送信し、Diameterクライアントは新しいMARで応答します。
The gateway checks the SIP-Auth-Data-Item AVPs of this MAR for an AVP where the Digest-Realm AVP matches the locally configured realm value. It takes the AVPs from this SIP-Auth-Data-Item AVP, converts them into the corresponding RADIUS attributes and constructs a RADIUS Access-Request message. The gateway sends the Access-Request message to the RADIUS server. If the RADIUS server responds with an Access-Accept message, the gateway converts the RADIUS attributes to Diameter AVPs, constructs a MAA message with a Result-Code AVP set to DIAMETER_SUCCESS and sends this message to the Diameter client. If the RADIUS server responds with an Access-Reject message, the gateway converts the RADIUS attributes to Diameter AVPs, constructs a MAA message with a Result-Code AVP set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH, and sends this message to the Diameter client.
ゲートウェイは、このMARのSIP-Auth-Data-Item AVPをチェックして、Digest-Realm AVPがローカルに設定されたレルム値と一致するAVPを探します。このSIP-Auth-Data-Item AVPからAVPを取得し、それらを対応するRADIUS属性に変換して、RADIUS Access-Requestメッセージを作成します。ゲートウェイはAccess-RequestメッセージをRADIUSサーバーに送信します。 RADIUSサーバーがAccess-Acceptメッセージで応答すると、ゲートウェイはRADIUS属性をDiameter AVPに変換し、Result-Code AVPがDIAMETER_SUCCESSに設定されたMAAメッセージを作成し、このメッセージをDiameterクライアントに送信します。 RADIUSサーバーがAccess-Rejectメッセージで応答した場合、ゲートウェイはRADIUS属性をDiameter AVPに変換し、Result-Code AVPがDIAMETER_ERROR_IDENTITIES_DONT_MATCHに設定されたMAAメッセージを作成し、このメッセージをDiameterクライアントに送信します。
As mentioned earlier, there is not a 100% match between the Diameter SIP application and the RADIUS Extension for Digest Authentication [RFC4590]. In particular, the RADIUS Extension for Digest Authentication [RFC4590] does not offer equivalent functionality to the Diameter UAR/UAA, SAR/SAA, LIR/LIA, RTR/RTA, and PPR/PPA messages defined by this specification.
前述のように、Diameter SIPアプリケーションとダイジェスト認証のRADIUS拡張機能[RFC4590]は100％一致していません。特に、ダイジェスト認証のRADIUS拡張[RFC4590]は、この仕様で定義されているDiameter UAR / UAA、SAR / SAA、LIR / LIA、RTR / RTA、およびPPR / PPAメッセージと同等の機能を提供しません。
This document serves as IANA registration request for a number of items that should be registered in the AAA parameters registry.
このドキュメントは、AAAパラメータレジストリに登録する必要があるいくつかの項目のIANA登録要求として機能します。
This document defines a standards-track Application-ID that falls into the Application Identifier standards-track address space defined by RFC 3588 [RFC3588] Section 11.3. This Application-ID has been registered in the Application IDs sub-registry of the AAA parameters registry with the following data:
このドキュメントでは、RFC 3588 [RFC3588]セクション11.3で定義されているアプリケーションID標準トラックアドレススペースに該当する標準トラックアプリケーションIDを定義しています。このアプリケーションIDは、AAAパラメータレジストリのアプリケーションIDサブレジストリに次のデータとともに登録されています。
ID values Name Reference
----------- ------------------------ ---------
6 Diameter Session Initiation RFC 4740
Protocol (SIP) Application
This document defines new standard commands whose Command Codes are to be allocated within the standard permanent Command Codes address space defined in RFC 3588 [RFC3588] Section 11.2.1. These command codes should be registered in the Command Codes sub-registry of the AAA parameters registry.
このドキュメントでは、RFC 3588 [RFC3588]セクション11.2.1で定義されている標準の永続的なコマンドコードアドレス空間内に割り当てられるコマンドコードを持つ新しい標準コマンドを定義します。これらのコマンドコードは、AAAパラメータレジストリのコマンドコードサブレジストリに登録する必要があります。
Table 1 in Section 8 contains the detailed list of Command Code names and values that are part of this Diameter application.
セクション8の表1には、このDiameterアプリケーションの一部であるコマンドコード名と値の詳細なリストが含まれています。
This document defines new standard AVPs, whose AVP Codes are to be allocated within the AVP Codes address space defined in RFC 3588 [RFC3588] Section 11.4. These AVP codes have been registered in the AVP Codes sub-registry of the AAA parameters registry.
このドキュメントでは、RFC 3588 [RFC3588]セクション11.4で定義されているAVPコードアドレススペース内に割り当てられるAVPコードが含まれる新しい標準AVPを定義します。これらのAVPコードは、AAAパラメータレジストリのAVPコードサブレジストリに登録されています。
Table 2 in Section 9 contains the detailed list of AVP names and AVP codes that are part of this Diameter application.
セクション9の表2には、このDiameterアプリケーションの一部であるAVP名とAVPコードの詳細なリストが含まれています。
This document defines new standard Result-Code AVP values to be allocated within the Result-Code AVP address space defined in RFC 3588 [RFC3588] Section 14.4.1. These values are listed in the Result-Code AVP values section of the AVP Specific Values sub-registry of the AAA parameters registry.
このドキュメントでは、RFC 3588 [RFC3588]セクション14.4.1で定義されているResult-Code AVPアドレス空間内に割り当てられる新しい標準のResult-Code AVP値を定義しています。これらの値は、AAAパラメータレジストリのAVP Specific ValuesサブレジストリのResult-Code AVP値セクションにリストされています。
Section 10.1.1 lists the new Result-Code AVP values that fall into the success category, according to RFC 3588 [RFC3588] Section 7.1.2.
セクション10.1.1は、RFC 3588 [RFC3588]セクション7.1.2に従って、成功カテゴリに分類される新しいResult-Code AVP値を示しています。
Section 10.1.2 lists the new Result-Code AVP values that fall into the transient failures category, according to RFC 3588 [RFC3588] Section 7.1.4.
セクション10.1.2は、RFC 3588 [RFC3588]セクション7.1.4に従って、一時的な障害カテゴリに分類される新しいResult-Code AVP値を示しています。
Section 10.1.3 lists the new Result-Code AVP values that fall into the permanent failures category, according to RFC 3588 [RFC3588] Section 7.1.5.
セクション10.1.3は、RFC 3588 [RFC3588]セクション7.1.5に従って、永続的な障害カテゴリに分類される新しいResult-Code AVP値を示しています。
13.5. Creation of the SIP-Server-Assignment-Type Section in the AAA Registry
13.5. AAAレジストリでのSIP-Server-Assignment-Typeセクションの作成
This document defines a new SIP-Server-Assignment-Type AVP (see Section 9.4). This AVP is of type Enumerated. We define an initial set of values that should be registered by IANA. IANA should create a new "SIP-Sever-Assignment-Type AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is listed in Section 9.4.
このドキュメントでは、新しいSIP-Server-Assignment-Type AVPを定義しています（セクション9.4を参照）。このAVPは列挙型です。 IANAによって登録される初期値のセットを定義します。 IANAは、AAAパラメータレジストリのAVP Specific Valuesサブレジストリの下に、新しい「SIP-Sever-Assignment-Type AVP値」セクションを作成する必要があります。値の初期リストはセクション9.4にリストされています。
13.6. Creation of the SIP-Authentication-Scheme Section in the AAA Registry
13.6. AAAレジストリでのSIP-Authentication-Schemeセクションの作成
This document defines a new SIP-Authentication-Scheme AVP (see Section 9.5.1). This AVP is of type Enumerated. We currently define a single value that should be registered by IANA. IANA should create a new "SIP-Authentication-Scheme AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is included in Section 9.5.1.
このドキュメントでは、新しいSIP-Authentication-Scheme AVPを定義しています（セクション9.5.1を参照）。このAVPは列挙型です。現在、IANAによって登録される単一の値を定義しています。 IANAは、AAAパラメータレジストリのAVP Specific Valuesサブレジストリの下に、新しい「SIP-Authentication-Scheme AVP値」セクションを作成する必要があります。値の初期リストは、セクション9.5.1に含まれています。
This document defines a new SIP-Reason-Code AVP (see Section 9.7.1). This AVP is of type Enumerated. We define an initial set of values that should be registered by IANA. IANA should create a new "SIP-Reason-Code AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is listed in Section 9.7.1.
このドキュメントでは、新しいSIP-Reason-Code AVPを定義しています（セクション9.7.1を参照）。このAVPは列挙型です。 IANAによって登録される初期値のセットを定義します。 IANAは、AAAパラメータレジストリのAVP Specific Valuesサブレジストリの下に、新しい「SIP-Reason-Code AVP値」セクションを作成する必要があります。値の初期リストは、セクション9.7.1にリストされています。
13.8. Creation of the SIP-User-Authorization-Type Section in the AAA Registry
13.8. AAAレジストリでのSIP-User-Authorization-Typeセクションの作成
This document defines a new SIP-User-Authorization-Type AVP (see Section 9.10). This AVP is of type Enumerated. We define an initial set of values that should be registered by IANA. IANA should create a new "SIP-User-Authorization-Type AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is listed in Section 9.10.
このドキュメントでは、新しいSIP-User-Authorization-Type AVPを定義しています（セクション9.10を参照）。このAVPは列挙型です。 IANAによって登録される初期値のセットを定義します。 IANAは、AAAパラメータレジストリのAVP Specific Valuesサブレジストリの下に、新しい「SIP-User-Authorization-Type AVP値」セクションを作成する必要があります。値の初期リストは、セクション9.10にリストされています。
13.9. Creation of the SIP-User-Data-Already-Available Section in the AAA Registry
13.9. AAAレジストリでのSIP-User-Data-Already-Availableセクションの作成
This document defines a new SIP-User-Data-Already-Available AVP (see Section 9.13). This AVP is of type Enumerated. We define an initial set of values which should be registered by IANA. IANA should create a new "SIP-User-Data-Already-Available AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is listed in Section 9.13.
このドキュメントでは、新しいSIP-User-Data-Already-Available AVPを定義しています（セクション9.13を参照）。このAVPは列挙型です。 IANAによって登録される初期値のセットを定義します。 IANAは、AAAパラメータレジストリのAVP Specific Valuesサブレジストリの下に、新しい「SIP-User-Data-Already-Available AVP値」セクションを作成する必要があります。値の初期リストは、セクション9.13にリストされています。
This memo does not describe a stand-alone protocol, but a particular application for the Diameter protocol [RFC3588]. Consequently, all the security considerations applicable to Diameter automatically apply to this memo. In particular, Section 13 of RFC 3588 applies to this memo.
このメモは、スタンドアロンのプロトコルについてではなく、Diameterプロトコル[RFC3588]の特定のアプリケーションについて説明しています。したがって、Diameterに適用可能なセキュリティに関する考慮事項はすべて、このメモに自動的に適用されます。特に、RFC 3588のセクション13がこのメモに適用されます。
This Diameter SIP application allows a Diameter client to use the properties of HTTP Digest authentication [RFC2617] by evaluating or sending to the Diameter server the credentials supplied by a user. The discussion of HTTP Digest authentication in Section 4 of RFC 2617 [RFC2617] is also applicable to this memo.
このDiameter SIPアプリケーションを使用すると、Diameterクライアントは、ユーザーが指定した資格情報を評価またはDiameterサーバーに送信することにより、HTTPダイジェスト認証[RFC2617]のプロパティを使用できます。 RFC 2617 [RFC2617]のセクション4でのHTTPダイジェスト認証の説明は、このメモにも当てはまります。
This Diameter SIP application also allows a Diameter client to use the properties of HTTP Digest authentication using AKA [RFC3310] by evaluating or sending to the Diameter server the credentials supplied by a user. Section 5 of RFC 3310 [RFC3310] is also applicable to this memo.
このDiameter SIPアプリケーションでは、Diameterクライアントが、ユーザーが指定した資格情報を評価またはDiameterサーバーに送信することにより、AKA [RFC3310]を使用したHTTPダイジェスト認証のプロパティを使用することもできます。 RFC 3310 [RFC3310]のセクション5もこのメモに適用されます。
The Diameter SIP application can be configured to operate in a scenario where the final authentication check is performed in the Diameter client (SIP server). There are a number of security considerations associated to it; all of them are consequences of the requirement to transfer H(A1) from the Diameter server to the Diameter client:
Diameter SIPアプリケーションは、最終的な認証チェックがDiameterクライアント（SIPサーバー）で実行されるシナリオで動作するように構成できます。これには、セキュリティに関する考慮事項がいくつかあります。これらはすべて、H（A1）をDiameterサーバーからDiameterクライアントに転送する要件の結果です。
o Both Diameter client and server must trust each other, such as when both client and server belong to the same administrative domain.
o クライアントとサーバーの両方が同じ管理ドメインに属している場合など、Diameterクライアントとサーバーの両方が互いに信頼している必要があります。
o To avoid eavesdroppers, the transport protocol between the Diameter client and server MUST be secured. RFC 3588 [RFC3588] specifies TLS [RFC4346] and IPsec as possible transport protection mechanisms for Diameter.
o 盗聴を回避するには、Diameterクライアントとサーバー間の転送プロトコルを保護する必要があります。 RFC 3588 [RFC3588]は、Diameterの可能なトランスポート保護メカニズムとしてTLS [RFC4346]およびIPsecを指定しています。
Due to these security considerations, it is RECOMMENDED to configure the Diameter SIP application to operate in the mode where the final authentication check is performed in the Diameter server.
これらのセキュリティ上の考慮事項のため、Diameterサーバーで最終的な認証チェックが実行されるモードで動作するようにDiameter SIPアプリケーションを構成することをお勧めします。
The authors would like to thank the following contributors who made substantial contributions to this work:
著者は、この作業に多大な貢献をしてくれた以下の貢献者に感謝します。
Pete McCann Lucent
ピート・マッキャン・ルーセント
Jaakko Rajaniemi Nokia
Jaakko Rajaniemi Nokia
Wolfgang Beck (Deutsche Telekom AG) provided the text in Section 12, "Migration from RADIUS".
Wolfgang Beck（Deutsche Telekom AG）がセクション12「RADIUSからの移行」のテキストを提供しました。
The authors would like to thank Tony Johansson and Kevin Purser for their invaluable contribution to the start-up of this application and the continuous progress. The authors would like to thank Daniel Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior, Wolfgang Beck, Ulrich Wiehe, Cullen Jennings, Anu Leinonen, Glen Zorn, German Blanco, Mikko Aittola, Bert Wijnen, and Sam Hartman for their reviews and valuable comments.
著者は、このアプリケーションの起動と継続的な進歩に対する貴重な貢献をしてくれたTony JohanssonとKevin Purserに感謝します。著者は、Daniel Warren、Jayshree Bharatia、Kuntal Chowdhury、Jari Arkko、Avi Lior、Wolfgang Beck、Ulrich Wiehe、Cullen Jennings、Anu Leinonen、Glen Zorn、German Blanco、Mikko Aittola、Bert Wijnen、Sam Hartmanに感謝します。レビューと貴重なコメント。
The Diameter SIP application is based on the Diameter application for the Cx interface of the 3GPP IP Multimedia Subsystem [3GPP.29.229]. The authors would like to thank 3GPP Working Group CN4 for this work.
Diameter SIPアプリケーションは、3GPP IPマルチメディアサブシステム[3GPP.29.229]のCxインターフェイス用のDiameterアプリケーションに基づいています。著者は、この作業について3GPPワーキンググループCN4に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、1999年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
[RFC3310] Niemi、A.、Arkko、J。、およびV. Torvinen、「Hypertext Transfer Protocol（HTTP）Digest Authentication Using Authentication and Key Agreement（AKA）」、RFC 3310、2002年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[RFC4590] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 4590, July 2006.
[RFC4590] Sterman、B.、Sadolevsky、D.、Schwartz、D.、Williams、D。、およびW. Beck、「RADIUS Extension for Digest Authentication」、RFC 4590、2006年7月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、2002年6月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680] Rosenberg、J。、「A Session Initiation Protocol（SIP）Event Package for Registrations」、RFC 3680、2004年3月。
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[RFC3880] Lennox、J.、Wu、X。、およびH. Schulzrinne、「Call Processing Language（CPL）：A Language for User Control of Internet Telephony Services」、RFC 3880、2004年10月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T。、およびP. McCann、「Diameter Mobile IPv4 Application」、RFC 4004、2005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.
[RFC4006] Hakala、H.、Mattila、L.、Koskinen、J-P。、Stura、M。、およびJ. Loughney、「Diameter Credit-Control Application」、RFC 4006、2005年8月。
[3GPP.29.229] 3GPP, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 5.12.0, June 2006.
[3GPP.29.229] 3GPP、「Diameterプロトコルに基づくCxおよびDxインターフェイス、プロトコルの詳細」、3GPP TS 29.229 5.12.0、2006年6月。
[JSR-000116] Java Community Process, "SIP Servlet API Specification 1.0 Final Release", JSR 000116, March 2003.
[JSR-000116] Javaコミュニティプロセス、「SIPサーブレットAPI仕様1.0最終リリース」、JSR 000116、2003年3月。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin (Editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
みぐえｌ あ。 がｒしあーまｒちん （えぢとｒ） のきあ Ｐ。お。 ぼｘ ４０７ のきあ ＧろうＰ、 ふぃん ０００４５ ふぃんぁんｄ
Phone: +358 50 480 4586
EMail: miguel.an.garcia@nokia.com
Maria-Carmen Belinchon Ericsson Via de los Poblados 13 Madrid 28033 Spain
Maria-Carmen Belinchon Ericsson Via de los Poblados 13マドリード28033スペイン
Phone: +34 91 339 3535
EMail: maria.carmen.belinchon@ericsson.com
Miguel A. Pallares-Lopez Ericsson Via de los Poblados 13 Madrid 28033 Spain
ミゲルA.パラレスロペスエリクソンVia de los Poblados 13マドリード28033スペイン
Phone: +34 91 339 4222
EMail: miguel-angel.pallares@ericsson.com
Carolina Canales-Valenzuela Ericsson Via de los Poblados 13 Madrid 28033 Spain
カロライナカナレスヴァレンズエラエリクソンVia de los Poblados 13マドリード28033スペイン
Phone: +34 91 339 2680 EMail: carolina.canales@ericsson.com Kalle Tammi Nokia P.O.Box 785 Tampere 33101 Finland
電話：+34 91 339 2680メール：carolina.canales@ericsson.com Kalle Tammi Nokia P.O. Box 785 Tampere 33101 Finland
Phone: +358 40 505 8670
EMail: kalle.tammi@nokia.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（C）IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は「現状のまま」で提供され、寄稿者、彼/彼女の代理人または組織は（もしあれば）、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースの免責事項明示または黙示を問わず、ここに記載されている情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証を侵害するものではないことを含むすべての保証。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。